Call-Sharing Models and Cost Allocation
Part of the Planning Week chain · previous: Post-Mortem and RCA for Workforce Operations · next: Vendor Change Control for Routing
Call-Sharing Models and Cost Allocation is the routing section of a function's standard that defines how contact volume is shared across nodes and how the cost of shared volume is allocated: four models (percentage allocation, overflow, skills-based pooling, and value with capacity state), each with its allocation rule, and one comparison key across nodes so that a shared contact costs and counts the same wherever it lands. It matters because sharing is the lever every multi-node estate pulls daily, and an estate that shares without a cost rule argues about the invoice instead of the forecast. The page produces section S-3.10.1 of the Standard on the ten-block template (template SS) and is worked in a session with Wiki:Packs/ROC Standard Authoring (CP-OPS-003).
The page is shelf material and restates nothing its neighbors carry. The mechanics of an agent handling more than one channel are on Multi-Channel and Blended Operations; the pooling benefit, its limits and its double-counting trap on Multi-Skill Pooling and the Double-Counting Trap; the moment-of-assignment decision on Skill-Based Routing; the value-and-capability routing rule on Value First, Then Route; the resolved case as the denominator on which cost and quality become comparable on Sourcing Design Axes: Node and Client Ownership; the variance and budget mechanics on Workforce Financial Governance. What this page adds is the standard's form: which model is in force for which body of work, what it costs, who may change it, and what the sharing volume says about the plan.
The vocabulary is the chain's: a node is a place work can sit: a hub (in-country depth), a service center (badged arbitrage at scale), a partner (speed, market access, flex), or automated; a supply seat is a partner capacity block (one supplier, one body of work, one commercial form); the gate is the six-test, five-outcome check a placement question runs through, on The Placement Gate; the migration is the worked example's phased servicing-platform migration, referred to only that way.
Sharing is a placement decision executed in routing
Sharing is often administered as a routing function, with the console owner deciding where the overflow goes. On this wiki the decision of where work should sit belongs to the placement function, the concept that work sits where objectives and constraints say, at every horizon; routing executes the decision. A sharing arrangement is therefore an output of the gate The Placement Gate describes, recorded with its justification, and the routing configuration is its execution. This section governs the execution and the accounting; it does not decide the sharing. The node owner, the owner of the body of work placed at a node and never the operator of the node, decides; the function owns the method and the record.
Four models are in use, and an estate usually runs more than one:
| Model | What it does | Where it fits | What it hides |
|---|---|---|---|
| Percentage allocation | A fixed share of a body of work's volume is sent to each node | A partner supply seat contracted on share; a heritage that has always split by share | The share is set by the contract, not by the capacity state, so it is wrong at both ends of the day |
| Overflow | Work looks to its primary node first and overflows to a predetermined secondary when a threshold is crossed | Hubs with a partner or a second hub as relief | The primary node's threshold is a placement decision dressed as a routing parameter |
| Skills-based pooling | Every eligible post at every node is one virtual pool; routing picks the next eligible post regardless of node | Bodies of work whose comparison key is settled and whose nodes are on one instrument | The pooling benefit is real, and it is overstated by exactly the double count Multi-Skill Pooling and the Double-Counting Trap names; a pool across nodes on different definitions is not a pool |
| Value with capacity state | Each contact is valued first, then routed on value and the capability and current capacity state of each destination | Later; it needs the value scores and the two-dimension routing rule Value First, Then Route describes | Nothing yet; it is the model the others converge on, and it is the one the engine runs |
A fifth pattern is sometimes treated as a sharing model: routing a contact type to a dedicated high-skill node. On this wiki that is a placement outcome recorded at the gate, not a sharing model, because it moves the work rather than sharing it, and it is what a specialty portfolio is for.
The limits of pooling, and why a chain of limited cross-training captures most of its benefit, are on Multi-Skill Pooling and the Double-Counting Trap and are not re-derived here. The queueing economies of pooling are Gans, Koole and Mandelbaum's;[1] the cost rule's fairness property is Eccles's;[2] the routing mechanics are Koole's.[3]
Cost allocation
One rule is the default, because it settles the argument both nodes make: shared volume is charged at the loaded rate of the node being helped. The helping node earns more than an idle post would; the helped node pays what adequate staffing would have cost it; neither can claim the other's cost structure. It is a transfer price, and it has the property the transfer-pricing literature asks for: it is set by a rule both parties knew before the volume moved, not negotiated after.[2] Three refinements are the Standard's:
- The rate is a published figure with a grade. A loaded rate that is [E] is charged as a range and trued up when it is [M]; a rate carried from a previous year is [A] and may not price a sharing arrangement alone.
- The comparison key is the resolved case, not the hour. Cost per hour and quality per sampled interaction are not comparable across nodes; both are read on the resolved case, and an arrangement priced on hours is re-read on cases before the sharing is judged. This is the denominator rule Sourcing Design Axes: Node and Client Ownership states.
- Percentage allocation prices the contract, not the sharing. Under a share contract the cost of shared volume is the contract's rate card, and the sharing decision's cost is the difference between what the share sent and what the capacity state would have sent; that difference is reported, not buried.
Sharing volume as a planning signal
A high volume of shared contacts between two nodes is commonly read as a forecasting failure at each. The Standard keeps the signal and changes its reading (Inferred). Sustained sharing above the planned share is a finding about the plan, and the plan has three parts that could be wrong: the forecast for one node may be biased, the placement that set the primary node may have been wrong, or the capacity state at one node may have moved. Which of the three is a register question, not a routing adjustment, and the weekly sharing review opens a row for it rather than moving the threshold. Sharing that stays inside the planned share is the arrangement working.
The ten blocks, filled
Purpose
Execute the sharing arrangements the placement function has decided, price shared volume by a rule known in advance on a key that makes nodes comparable, and read sustained sharing as a signal about the plan.
Inputs
The gate output that set the arrangement (interface row: Operations); the loaded rate by node and its grade (interface row: Finance); the contract mechanism and rate card at a partner supply seat (interface row: Delivery partners); the capacity state by node from intraday automation; the forecast and the lock for each body of work.
Outputs
The routing configuration in force per body of work, with its model, threshold and share; the weekly sharing report (planned share, actual share, cost allocated, the register row opened if any); the allocation change record under Vendor Change Control for Routing.
Roles
The placement lead owns the arrangement's justification; the real-time lead executes threshold and share changes inside the arrangement; the change-control board approves any change to the arrangement itself; the finance partner owns the rate; the node owner decides.
Method
The L1 flow is one page, twelve steps, four decisions.
| # | Step | Owner | Next |
|---|---|---|---|
| 1 | Receive the arrangement from the gate: body of work, nodes, model, planned share or threshold, justification | placement lead | 2 |
| 2 | Is every node in the arrangement on the same comparison key and the same activity-code dictionary? | standardization lead | yes → 4 · no → 3 |
| 3 | Register the gap as a dated accommodation; share on percentage allocation until it closes | standardization lead | 4 |
| 4 | Configure the routing model; publish the loaded rate and its grade for each node | real-time lead; finance partner | 5 |
| 5 | Run; allocate the cost of shared volume weekly at the helped node's rate | real-time lead | 6 |
| 6 | Has shared volume exceeded the planned share for three consecutive weeks? | real-time lead | yes → 7 · no → 8 |
| 7 | Open a register row: forecast bias, placement error, or capacity-state move; do not move the threshold | placement lead | 8 |
| 8 | Publish the weekly sharing report | real-time lead | 9 |
| 9 | Has a change to the arrangement been proposed, or has the gate retired it? | placement lead | changed → 10 · retired → 12 · neither → 5 |
| 10 | Send the change to the change-control board under Vendor Change Control for Routing | submitter | 11 |
| 11 | Did the board approve the change? | change-control board | yes → 1 · no → 5, the arrangement stands and the price is recorded |
| 12 | Close the arrangement: stop the routing configuration, close its register rows, archive the record with the gate output that retired it | placement lead | End |
The L2 step table runs about twenty-five rows on the fifteen columns of Process Decomposition (L0–L3) and is produced by the pack. Its job aids are the model configuration sheet per platform (annex), the rate table and the weekly report layout.
Metrics
Planned share against actual share by arrangement; cost allocated per resolved case by node; register rows opened from the sharing review; arrangements on a shared comparison key (a proportion). The first three belong to Level 3; sharing driven by capacity state belongs to Level 4.
Tools
The routing layer (configured through the annex); intraday automation for the capacity state; the reporting platform for the weekly report; the data core for the rate table and the resolved-case count.
Controls
No arrangement without a gate output; no threshold change outside the real-time lead's published bounds; every change to an arrangement through change control; the acceptance gate the section passed.
Maturity
Level 1: sharing by phone call between supervisors. Level 2: percentage allocation and overflow per heritage, priced by whoever wrote the contract. Level 3: arrangements recorded with their justification, priced by the rule, reviewed weekly on the resolved case. Level 4: skills-based pooling across nodes on one instrument; the sharing review is a register row the team opens. Level 5: value with capacity state; the engine recomputes the arrangement on trigger.
Node attribute and vendor paragraph
All nodes. At a partner supply seat the model is usually fixed by the contract mechanism (share, fixed volume per period, or interval staffing); the cost rule is the rate card, not the helped node's rate; the difference between contracted and capacity-state sharing is reported as the arrangement's cost; and any change to the share is a change-control item with the partner's confirmation.
Worked example
The chain's function, on the migrating book's voice work, hub and partner nodes, during the migration's service break (Wed 8 to Fri 10 Apr 2026). The arrangement in force was overflow from the hub to the partner at a threshold, with a planned share of 3 percent of the hub's offered volume [A]. The service break pushed shared volume that week to 6.5 percent [C] of the hub's offered, allocated at the hub's loaded rate, index 1.00; the partner's own loaded rate was index 0.62 [E], range 0.58 to 0.66. The excess was matched to event CAL-002 on the Forecast Collision Calendar and closed without a register row, because a known event, not a plan error, explained it. In the four weeks after, shared volume ran 4.1, 4.4, 4.0 and 4.6 percent [C] against the planned 3 percent; the step 6 test tripped at the third consecutive week above plan, and the review opened a register row: the hub's post-migration handle time at 452 seconds [M] against a plan built on 412 seconds carried [A] had moved the hub's capacity state, and the finding was a forecast assumption, not a routing threshold. The threshold was not moved. Index figures replace currency so that no rate is disclosed; the percentages are the example's.
The artifact this page produces
Section S-3.10.1 on the ten-block template, template SS, and the arrangement register. One filled example row:
| ID | Body of work | Nodes | Model | Planned share or threshold | Cost rule | Comparison key | Justification (gate output) | Owner (seat) |
|---|---|---|---|---|---|---|---|---|
| S-3.10.1 | the migrating book, voice | hub → partner | overflow | 3 percent of hub offered [A] | helped node's loaded rate, index 1.00 | resolved case | relief during the migration; recompute on phase 3 | placement lead |
Produced in a working session with Wiki:Packs/ROC Standard Authoring (CP-OPS-003); the filled set is part of blueprint v0.1.
What would change this
The section claims that pricing shared volume at the helped node's rate on the resolved case ends the invoice argument, and that sustained sharing above plan is a plan finding rather than a routing one. If arrangements priced by the rule still generated a dispute at every close, the rule would not be the settlement it claims to be; and if register rows opened from the sharing review found, more often than not, that the threshold was simply set wrong at placement, the signal would be a routing signal after all and step 7 would be rewritten to allow the threshold to move. Two quarters of weekly reports and their register rows are the observation.
How this connects
- Previous in the chain: Post-Mortem and RCA for Workforce Operations — the learning loop the incident set closes with
- Next in the chain: Vendor Change Control for Routing — the change record any allocation change produces
- Decided at: Work Placement Landscape (the bands the nodes belong to) and the gate on The Placement Gate
- Defers to: Multi-Channel and Blended Operations (channel blending) · Multi-Skill Pooling and the Double-Counting Trap (the pooling benefit, correctly counted) · Skill-Based Routing (the assignment decision) · Value First, Then Route (the fourth model) · Sourcing Design Axes: Node and Client Ownership (the resolved case as the shared denominator) · Workforce Financial Governance (variance and budget mechanics)
Maturity Model Position
Percentage allocation and overflow are Level 2 on the WFM Labs Maturity Model™; recording the arrangement with its justification, pricing it by the rule on the resolved case and reviewing it weekly is the Level 3 section this page defines; value with capacity state is Level 4. Four scales on this wiki use the word "level"; Planning Week for a Workforce Function states which is which. This page uses the documentation levels for its flow and the maturity Levels 1–5 in the Maturity block.
See Also
- Planning Week for a Workforce Function
- Anatomy of a ROC Standard
- Vendor Change Control for Routing
- The Placement Gate
- Work Placement Landscape
- Human Gates and Number Grades — the number grades used on this page
References
- ↑ Gans, N., Koole, G., & Mandelbaum, A. (2003). Telephone call centers: tutorial, review, and research prospects. Manufacturing & Service Operations Management, 5(2), 79–141. doi:10.1287/msom.5.2.79.16071 — the pooling of queues and the economies it yields, and their limits.
- ↑ 2.0 2.1 Eccles, R. G. (1983). Control with fairness in transfer pricing. Harvard Business Review, 61(6), 149–161 — a transfer price set by a rule known in advance is accepted where a negotiated one is disputed.
- ↑ Koole, G. (2013). Call Center Optimization. Amsterdam: MG Books. ISBN 978-90-820179-0-8 — overflow and allocation routing and their effect on service level.
