Designated, Shared and Dedicated: What the Words Implement
Designated, shared and dedicated are the three words service businesses use to describe how a client's work is staffed, and in most estates the middle word — designated — carries five different meanings at once. It is a commercial promise, a routing configuration, a statistical band, a cognitive-load device and a soft preference weight, depending on who is speaking, and only one of the five is implemented anywhere a system can inspect.
This page separates the readings, states what each one actually implements and what can be tested about it, explains why designation cannot be guaranteed as usually sold, and sets out the tension between designation and gate expansion that a merged estate must decide before it can do either. The pooling mathematics underneath the words is owned by Pooling Architecture in Service Workforces, which also shows that designated is not a tier; the pricing of pinned capacity is owned by The Workforce Broker; the client-ownership axis the words sit on is owned by Sourcing Design Axes: Node and Client Ownership.
The three words
Shared work is served by a pool that also serves other clients; any eligible agent may take any eligible contact. Dedicated work is served by a pool that serves no one else; the client has bought the pool's exclusivity and, in a well-run estate, pays the pooling penalty that exclusivity costs — a penalty that Pooling Architecture in Service Workforces shows is a function of per-account volume rather than total volume, so aggregate scale does not rescue an estate of small accounts. Designated sits between them and is where the trouble is: it promises that a client's work will usually be handled by a particular group of people, without either exclusivity or a stated bound on "usually." Pooling Architecture in Service Workforces settles the commercial question — designated names no testable parameter and is therefore not a tier. This page takes that as given and asks a different one: if the word is not a tier, what are the five things people are using it to mean?
Five readings of one word
In practice the word is used in five distinguishable ways, frequently by people in the same meeting.[1]
| Reading | Who uses it | What it implements | What can be tested |
|---|---|---|---|
| The promise | Sales and account management | "There are people who should always be on this account" — a commitment written into offers and quarterly reviews | Nothing, as written: no parameter is named, so no breach can be detected |
| The routing state | Platform and telephony teams | A team configured as designated in the routing platform, if the platform supports it; where the platform defaults to shared, teams are often left that way | Configuration is inspectable: the number of genuinely designated teams is a fact, and it is usually very small |
| The client-count band | Workforce planning | A gate is "designated" when it holds few clients (an order of ten) and "shared" when it holds many (an order of a hundred); fewer clients per gate means a higher statistical likelihood that the same people serve the same customers; the figures are illustrative orders of magnitude, not thresholds | Client count per gate is measurable, but the band drifts as clients are added and gates resized, and nobody sets it |
| The policy-load device | Solutions design and operations | A smaller team serves a smaller book so that agents need not hold every client's policy exceptions in memory; designation is proposed when a client carries many exceptions | Exception load per agent is measurable in principle; the reading explains what designation is for rather than what it promises |
| The preference weight | Routing design, some suppliers | Agents carry a home queue as primary skill and neighbouring queues as reserve skill, so a client's work is preferred, not reserved — a soft weight in the routing algorithm | The weight is a configuration and can be read; it is affinity, which Pooling Architecture in Service Workforces identifies as the honest origin of the word; Chaining and Flexibility Design owns the topology that makes it work |
The five readings are not five errors. Each describes something real about how the estate works. The failure is that they share one word, so a promise made in the first reading is assumed to be delivered by the second, measured by the third, justified by the fourth and implemented by the fifth, when in fact the readings are only loosely coupled and one of them — the promise — has no implementation at all.
The readings also map onto the mechanism decomposition at Pooling Architecture in Service Workforces: the promise claims exclusivity, the client-count band and the policy-load device describe eligibility, the routing state implements eligibility where the platform partitions hard and affinity where it only weights, and the preference weight is affinity in every case. The commercial word spans all three, which is why no single parameter can carry it.
Only one reading is configured
The routing state is the only reading a system can be asked about, and asking it is usually revealing.[1] In estates whose routing platform has no simple way to build designated teams, every team is configured as shared, and the only genuinely designated populations are residual groups carried over from a predecessor platform that did support them. The consequence is the one described at When the Platform Decides the Product: a platform default silently rewrote a commercial promise, and nobody decided it. What the commercial team believes it is selling and what the platform is delivering can differ across the great majority of the client base without anyone being wrong on their own terms — the salesperson is describing the promise, the telephony engineer is describing the configuration, and they are using the same word.
Why designation cannot be guaranteed
Once the promise is separated from the configuration, the question becomes what can be promised. The answer follows from the client-count reading: what a designated gate actually delivers is a likelihood — the probability that a given customer is served by someone who has served that client before — and the likelihood is a function of the gate's client count, its size, and the arrival pattern of each client's work. Two properties follow.
- It is emergent, not designed. Nobody sets the client count; it drifts as clients are added and gates are resized to meet service targets. A client can move from designated-in-practice to shared-in-practice without a decision being taken.
- Its function is cognitive, not experiential. The policy-load reading is the only one that explains why designation exists. Working memory is bounded, and cognitive load theory[2] makes it plausible that holding many clients' exception rules degrades performance; a smaller book per agent is a load-management device. The extrapolation from instructional tasks to a service book is reasoned, not measured: as Pooling Architecture in Service Workforces notes, no published study establishes an accounts-per-person capacity function for service work. That has a direct consequence: as policy tooling improves and exceptions are surfaced by the system rather than remembered by the agent, the case for designation shrinks — independently of anything the commercial team decides.
The collision with gate expansion
Gate expansion — consolidating small pools into larger ones — is the standard remedy for the small-gate inefficiencies described at Deferrable Work and the Idle Cushion and at Gate Expansion: What It Buys and What It Spends. More clients per gate is, by the client-count reading, the definition of less designated. Every gate expanded converts a designated-in-practice client into a shared-in-practice one, and if the promise reading is still being sold, every gate expanded creates a commitment that will be discovered broken one client at a time, in quarterly reviews, after the fact. An estate cannot both keep selling designation and keep expanding gates unless it first decides what designation means.
Reconciling the readings
The reconciliation is a business decision, not a routing decision, and it has four parts.
- Choose the deliverable. Either designation is a priced likelihood — a stated parameter (a target repeat-pairing rate, or a maximum client count per gate) that can be tested, breached and remedied — or it is retired in favor of two honest states: shared, and dedicated at its computed price. The unified offer definition is a commercial artifact, and its accountable owner is the commercial or offer-management function that determines what is sold — the Roles gap the maturity position below names.
- Separate the function from the promise. Where designation exists to manage policy-exception load, name that as the requirement and meet it by the cheapest means — tooling, knowledge surfacing, or a smaller book — rather than by a commercial tier.
- Decide which mechanism delivers it. Repeat pairing can be produced by gate composition, which drifts, or by a configured affinity weight, which does not. If a parameter is to be promised, it should be met by the configured mechanism — the emergent one cannot be held to a number.
- Sequence it ahead of gate expansion. Decide what is promised before gates are widened, so that each expansion is checked against a stated parameter rather than discovered against an unstated one.
The commercial framing that makes the reconciliation sellable is the one The Workforce Broker describes as priced designation: a discount for clients who permit unconstrained delivery, rather than a premium for a promise that cannot be kept.
Maturity Model Position
The five-readings collision is a Level 2 condition on the WFM Labs Maturity Model™ scored against the GRPI-T pillars of The Maturity Diagnostic and Pathways: a Roles problem, because no function owns the definition, presenting as a vocabulary problem — and it bounds Level 3 and Level 4 work in the Technology and Processes pillars. Gate expansion, pooled routing and value-based placement all presuppose that the estate knows what it has promised about pool membership. In the terms of the diagnostic, a Technology pillar two levels above the Roles pillar is a liability the next move must repair first.
See Also
- Pooling Architecture in Service Workforces — why designated is not a tier; the dedication penalty
- The Workforce Broker — the pinning taxonomy and priced designation
- Sourcing Design Axes: Node and Client Ownership — the client-ownership axis
- Chaining and Flexibility Design — the topology that makes affinity routing work
- Gate Expansion: What It Buys and What It Spends — the collision in full
- When the Platform Decides the Product — how a default became a promise
- Inherited Sourcing Doctrine in Merged Service Estates — why the words diverged by heritage
References
- ↑ 1.0 1.1 Practitioner observation across multi-heritage service estates; a consistent pattern rather than a measured result.
- ↑ Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285. doi:10.1207/s15516709cog1202_4.
