Most contact centres still plan with one shrinkage number. Thirty percent, thirty-five, whatever the historical average says, applied uniformly across the whole operation. That worked when everyone sat in the same building on the same shift pattern. In a hybrid operation, where part of your team is on site and part is remote on any given day, a single blended figure quietly hides two very different availability profiles, and the schedule you build from it will be wrong in both directions.
Why shrinkage matters more than most planners treat it
Erlang C tells you how many agents must be available in an interval to hit your service level. It does not tell you how many to schedule. Shrinkage is the bridge between those two numbers, and getting it wrong is the single fastest way to under-staff a well-forecasted day. If you need 50 agents available and your true shrinkage is 30%, you schedule 72, not 50. Plan with 25% when reality is 32% and you are short roughly five agents in every interval, all day, with a forecast that was perfectly accurate.
Where remote and on-site shrinkage actually diverge
The two populations differ in specific, predictable ways, and they do not cancel each other out.
Unplanned absence tends to run lower for remote agents. A mild illness, a snowstorm, a transport strike, none of these stop someone logging in from home, whereas on-site staff lose the full day.
Commute-driven lateness is close to zero for remote agents and a real, recurring shrinkage contributor on site, concentrated at shift-start intervals rather than spread evenly across the day.
Ad-hoc off-phone time often runs higher for remote agents in the opposite direction, technical issues, connectivity drops, home interruptions, and the small unlogged gaps that a supervisor walking the floor would have absorbed instantly on site.
Coaching, huddles, and training land differently too. On-site teams frequently get pulled into unscheduled side-of-desk conversations that never appear on any schedule. Remote coaching is usually booked in advance, which makes it planned shrinkage rather than unplanned, and therefore something you can build around.
Blend those together into one average and you get a number that describes neither group accurately.
What splitting it actually looks like
Track shrinkage separately for the two populations first, at minimum splitting planned from unplanned within each. Then apply each rate to the headcount actually working that way in each interval. If Monday has 60% of your staff on site and Thursday has 30%, your effective shrinkage assumption should differ between those two days automatically, because the mix differs. A single blended rate cannot do that, it will over-schedule your lightest on-site day and under-schedule your heaviest one.
Once you have both rates, feed the weighted result into your staffing calculation. The Shrinkage Calculator on this site handles the category breakdown, and the Erlang C Staffing Calculator applies it to convert available-agent requirements into scheduled headcount.
Two practical cautions
Do not split the number until you have enough clean data behind each population. A remote shrinkage rate built on three weeks of a fifteen-person pilot is not a rate, it is noise, and acting on it will cost you more accuracy than the blended number was costing.
Second, watch for the mix changing underneath you. Hybrid ratios move as policies shift, as teams grow, and seasonally. A split-shrinkage model that assumes last quarter's on-site percentage is just a differently-shaped version of the same stale-assumption problem you were trying to fix.
The takeaway
Hybrid is not a temporary arrangement most operations are waiting out, it is the operating model. The planning inputs should reflect that. Splitting shrinkage by work location is one of the least glamorous changes a WFM team can make, and one of the few that improves schedule accuracy without new software, new headcount, or a vendor conversation. It just requires tracking the two groups separately and being honest about the fact that they were never really the same population to begin with.