Multichannel Capacity Model Assembly
Multichannel Capacity Model Assembly is the order in which a workforce function combines the requirements of its channels into one staffing plan: interval-based requirements for voice and chat, a workload-based requirement for email, a decision per pool on dedicated or blended service, one application of shrinkage at the pool level, and a reconciliation of the assembled plan to the time ledger. It matters because the three requirements are computed in different units over different periods, and a plan that adds them unconverted, applies shrinkage per channel, or lets one agent-hour satisfy two channels is wrong by an amount no row shows. The page is part of the Workforce Data Definitions Framework; the models per channel are on Service Level Mathematics for Voice, Chat and Email, the unit ladder on Workload Units and the Roll-Up to FTE, the cost of splitting a pool on Pooling Architecture in Service Workforces.
Two kinds of requirement
A voice or chat requirement is a count of agents per interval from a queueing or simulation model at a goal in seconds, with an occupancy the planner does not choose embedded in it.[1] An email requirement is a count of productive hours per shift or day, items multiplied by handling time plus the backlog to clear, against a goal in hours or days: sequential workload whose staff need equals workload hours.[2] They meet only as productive hours over one period, before shrinkage.
| Interval-based (voice, chat) | Workload-based (email, cases) | |
|---|---|---|
| Output of the channel model | agents per interval | productive hours per shift or day |
| Occupancy | an output of the model | not a term in the model: workload hours are divided by productive hours per agent on the channel, and the in-work share of productive time is a reported ratio |
| What varies the requirement | arrival shape within the day | arrival volume across days, and the backlog carried in |
| Converted to the common unit by | agents × interval length, summed | hours as computed, plus buffer |
The assembly order
- Requirement per channel, in its own unit, before shrinkage. A channel whose handling time is [E] produces an [E] requirement, which the plan inherits on its lineage card (
LN-003, fed byLN-004, the email model; Data Lineage Card for Planning Models). - Convert to productive hours over one period: agents per interval times interval length, summed; email is already hours.
- Decide the pool design per channel pair. Dedicated or blended, by the dimensions on Pooling Architecture in Service Workforces; a register entry with an owner.
- For blended pools, size voice first, then the reserve. The voice requirement per interval is the floor; email capacity is what the two-class model or a simulation returns at the signed reserve, never the idle time.
- Residual email to a dedicated pool, sized by the workload model with its own buffer.
- Sum to productive hours per pool per period, at the grade of the weakest channel; an all-[M] chain yields [C], never [M].
- Apply shrinkage once, at the pool. A blended agent's break is one break; applying each channel's factor before adding counts it twice.
- Roll up to FTE and reconcile. Per Workload Units and the Roll-Up to FTE, then the reconciliation below, then the monthly cycle.
Blended versus dedicated, and the reserve
Pooling two classes of work needs fewer agents than two dedicated groups at the same goals, and the difference is the dedication penalty;[1] two skills per agent capture most of it in simulated multi-skill centres.[3] Pooling Architecture in Service Workforces derives the penalty.
The peer-reviewed answer for a delay-constrained class sharing agents with a deferrable one is a priority with a threshold: agents take deferrable work only when free agents exceed a reserve, optimal for equal service times and a close approximation otherwise,[4] and an adaptive threshold holds a call-wait limit under time-varying arrivals while maximising email throughput.[5] These results are Established; reading the deferrable class as email is an inference the 2015 paper makes explicit. A blended pool's email capacity is therefore neither "the idle time" nor "a share of the available state": it is what the two-class model or a simulation returns at the reserve, and a static reading of the voice model misstates it, because an agent inside an email item is not free when a call arrives. The reserve is a signed register entry, SET LOCALLY, owned by the real-time lead. A pool is dedicated to email by eligibility, by contract, or because the residual exceeds what a blended pool absorbs at its reserve; never because the platform cannot tell email time from available time, a measurement gap handled on Production Accounting for Blended Agents.
Reconciliation to the ledger
The assembled plan is a forecast of the ledger, compared row by row with the ledger the period produced, because each gap is owned by a different seat.
| Plan row | Ledger row | What a gap means |
|---|---|---|
| Productive hours per pool | tier 5, summed over the pool | supply delivered differed from supply planned: a shrinkage or scheduling variance, owned by the roll-up |
| In-work hours per channel | tier 6 per channel | the workload or handling-time input was wrong by the gap's share; the channel's definition (AHT-01 for voice and chat; AHT-02, RG-008, for email) is re-measured at its source row (ST-001 for voice, ST-013 for chat, ST-007 for email)
|
| Available-idle hours | tier 5 minus tier 6 | implied occupancy differed from the model's; on a blended pool, also where email worked inside an available state hides |
| Email hours absorbed by the blended pool | tier 6, email, blended seats only | the reserve delivered more or less than modelled; the reserve or the two-class model is re-parameterized |
Where double counting enters
Double counting enters at three places, each with a test on Reconciliation Tests for Time Accounting.
The same hour in two requirements. A blended agent's idle hour is counted as email capacity and as the safety capacity the voice model already holds; added together, the plan is short by the overlap. Test: T-04 Cross-system double count: for every agent-interval, in-work time summed across channels does not exceed productive time, and minutes claimed by more than one system are within tolerance. Beside it, a plan check: email hours credited to the blended pool do not exceed what the two-class model or simulation returns at the signed reserve.
Elapsed time as handling time. An email open for a day consumed a fraction of it in agent attention; a requirement built on open-to-close time inflates the channel by the pend time, and the same minutes are claimed by every item open during them (the chat analogue is on Chat Concurrency and Handle Time). Test: T-05 Item-count against time: items closed times the register's handling time per item against recorded in-work time, within tolerance of one. A ratio well below one means agents sat in a work state through pends, idle or batch closing, the signature of open-to-close stamps; a ratio well above one means items closed outside any in-work state, which T-06 isolates.
Availability bleed. Email worked inside a voice available state is booked as idle availability, because telephony availability is a product of idle time and includes auxiliary time.[6] The voice model sees low occupancy and concludes the pool is overstaffed; the email requirement sees no in-work time; the hour is voice slack and, if email is sized separately, email work at once. Test: T-06 Availability-bleed: items closed per hour of available-idle time at blended seats, within tolerance of zero. Until it passes, the function reports the bleed beside occupancy and sizes email from items and sampled handling time.
Worked example
Numbers are synthetic [E]; computed values are [C]. One day, one blended pool. Voice needs 25 agents per interval across eight hours, 200 productive hours [C]; at 20 erlangs that leaves 40 idle agent-hours [C]. Email workload is 180 hours [C] plus a 45-hour backlog [C], from 1,200 and 300 items at 9 minutes [E]. A naive assembly credits all 40 idle hours to email; a static reading of the voice model puts about 28 hours a day above a reserve of two [C]. A discrete-event simulation of the pool, voice priority and non-preemptive nine-minute items, shows that at that reserve the voice service level falls to about 39 percent, and that holding 80 percent in 20 seconds needs a reserve of about 10 agents, at which the pool absorbs about 9 hours of email a day [C]. The dedicated email requirement is therefore about 216 hours [C] plus the workload model's buffer. Shrinkage is applied once per pool. After the day, email in-work hours at blended seats are compared with the 9 planned, and any gap is recorded against the reserve's register entry, not the voice model.
Maturity Model Position
Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a function that computes each channel's requirement separately and adds them is at Level 2. It is at Level 3 when the assembly follows the order above, blended pools carry a signed reserve, shrinkage is applied once per pool and the plan reconciles to the ledger row by row, because a rule that moves agents between channels can be released only on a plan whose double counts are tested (Human Gates and Number Grades); at Level 4 the assembly is a simulation of the routing as configured, read from the registers.
See Also
- Workforce Data Definitions Framework — the hub: the ledger and registers the assembly reads
- Service Level Mathematics for Voice, Chat and Email — the requirement model per channel and their combination
- Workload Units and the Roll-Up to FTE — the unit ladder and the shrinkage rungs applied after assembly
- Pooling Architecture in Service Workforces — exclusivity, eligibility, affinity and the dedication penalty
- Reconciliation Tests for Time Accounting — T-04, T-05 and T-06, which catch the three double counts
- Production Accounting for Blended Agents — availability bleed and its separation
- Multi-Channel and Blended Operations — the operating context
References
- ↑ 1.0 1.1 Gans, N., Koole, G., & Mandelbaum, A. (2003). "Telephone Call Centers: Tutorial, Review, and Research Prospects". Manufacturing & Service Operations Management 5(2), 79–141, section 4. doi:10.1287/msom.5.2.79.16071.
- ↑ Reynolds, P. (2005). "Evaluating staffing tradeoffs". Connections Magazine, July/August 2005. connectionsmagazine.com.
- ↑ Wallace, R. B., & Whitt, W. (2005). "A staffing algorithm for call centers with skill-based routing". Manufacturing & Service Operations Management 7(4), 276–294. doi:10.1287/msom.1050.0086.
- ↑ Bhulai, S., & Koole, G. (2003). "A queueing model for call blending in call centers". IEEE Transactions on Automatic Control 48(8), 1434–1438. doi:10.1109/TAC.2003.815038.
- ↑ Legros, B., Jouini, O., & Koole, G. (2015). "Adaptive threshold policies for multi-channel call centers". IIE Transactions 47(4), 414–430. doi:10.1080/0740817X.2014.928965.
- ↑ LaReau, T. (2012, updated 2018). "Constructive use of occupancy". ICMI. icmi.com.
