Intent Normalization Before Work Placement
Intent normalization before work placement is the discipline of agreeing one taxonomy of what a contact is for — its intent — across every channel and every brand of a service estate, at the routing layer, before any supply-side placement design is attempted. It rests on a sequencing observation that is easy to state and routinely skipped: a placement design assumes that work arrives correctly labelled, so if the labels differ by channel or by heritage brand, work lands in queues that were defined for other work, and no amount of supply-side definition — of gates, skills, pools or node economics — can deliver fungibility across it. Intent normalization is therefore the demand-side half of a definitions program whose supply-side half is described at Platform Migration as a Definitional Forcing Function, and the two are one program seen from two sides. The routing discipline that consumes normalized intents is at Next Generation Routing; the classification technology that produces intent labels is at Speech Analytics; the moment-of-assignment mechanics that consume them are at Skill-Based Routing.
What an intent is, and why it differs
An intent is the routing layer's answer to the question "what does this contact want done?" — in a travel service a new booking, a change to an existing one, a cancellation, help using a self-service tool, a complaint; in an insurer a claim, a policy amendment, a coverage query; in a utility a service activation, a billing dispute, an outage report. Every channel classifies arriving work by intent, and every heritage brand in a merged estate did so independently, which produces three kinds of divergence.[1]
- By channel. A voice channel classifies intent from a menu selection or a speech classifier; a chat channel from a natural-language classifier; an email channel from a subject line or a form field. The same customer need is assigned different labels by different classifiers, and the labels are rarely mapped to one another.
- By brand. One heritage defines a new booking as any contact that results in a reservation; another as a contact in which the customer's stated purpose was to book, whether or not a reservation results; a third defines it by product line. An insurer's heritages diverge the same way on what counts as a claim — first notice, a completed form, or an adjuster assignment. Under the same word, three different populations.
- By boundary case. Assistance — a customer-facing contact that creates or changes nothing — sits at the boundary of every taxonomy and is claimed by none of them, which is why the definitional argument over front, middle and back office recurs (see Service Chain Decomposition and Node Sourcing).
The divergence is invisible in ordinary operation because each channel and brand is internally consistent. It becomes visible the moment work is compared, pooled or placed across them.
Why placement depends on it
Placement design — deciding which node, arrangement or handler should take which work — treats the intent label as ground truth. Four things go wrong when it is not.
- Pool comparisons inherit routing noise. If one brand's "change" queue contains contacts another brand would call "assist," the two queues' handle times, quality scores and costs are being compared across different work, and the comparison is a definition difference dressed as a performance difference.
- Node quality becomes uninterpretable. A labor source cannot be compared — only a labor source doing a specified kind of work, on a specified channel, at a specified level of decomposition, on a specified mix of cases (see Comparing Delivery Arrangements). An inconsistent intent label breaks the first element of that key, and misrouted work contaminates the node's score in a direction nobody can see.
- Capacity inputs are wrong at the source. Escalation probability and cost by interaction type are the inputs to any human-versus-automated placement (see The Escalation Tax), and chain-total minutes per resolved case is the effort denominator. If intents are inconsistent, the inputs are inconsistent, and the placement computed on them is precise about the wrong thing.
- Fungibility cannot be delivered. A supply-side definitions program that agrees one gate structure and one skill taxonomy still cannot move work across brands if the work arriving at each brand's gates was classified differently. The pools are interoperable; the demand is not.
The normalization method
The method is a practitioner sequence rather than a tested procedure.[1]
- Inventory the intents as configured. For each channel and each brand, extract the intent set from the classifier, the menu tree or the form — not from the process documentation, which describes the intended taxonomy rather than the deployed one.
- Choose the grain from the decisions, not the catalogue. The canonical taxonomy is as fine as the placement and staffing decisions that differ, and no finer; the test is developed below.
- Map every deployed intent to a canonical one. The mapping is many-to-one and is itself a governed artefact with an owner and a version.
- Define the boundary cases explicitly. Assistance, partial changes, and contacts with multiple intents are the cases every heritage resolved differently; the canonical taxonomy states the rule for each.
- Measure classification agreement. Where two channels or two classifiers label the same contact population — once both label sets have been projected through the step-3 mapping into the canonical taxonomy, without which no agreement coefficient is defined — agreement between them is measurable with the inter-coder reliability statistics developed for human coders of text,[2] applied here to production classifiers as an extension of their original use. A low overall coefficient says the definitions have not converged; the per-category confusion matrix locates which ones.
- Publish it as the demand-side half of the definitions register. The canonical intent taxonomy sits beside the gate, skill, pool and state definitions, under the same owner and the same change control.
The grain question
The most consequential decision in the method is the second one. Too fine a taxonomy fragments demand into cells with too few contacts to forecast, staff or measure — cells below the measurement floor described at Sample Size and Detectable Difference in Quality Measurement, created deliberately. Too coarse a taxonomy collapses work that needs different handlers into one label, so that placement cannot discriminate and there is nothing for the Value Routing Model to score. The test is operational: an intent boundary earns its place when some decision — who takes the work, how it is staffed, how it is measured — changes at that boundary.
Failure modes
- Owning the two halves separately. The demand-side taxonomy and the supply-side definitions acquire different owners and different change control, and neither can be finished without the other; the sequencing argument is at Platform Migration as a Definitional Forcing Function.
- Adopting one brand's taxonomy wholesale. The largest heritage's intents become canonical, and the other heritages' work is classified in a vocabulary written for different products.
- Normalizing from documentation. The process manual's taxonomy is agreed while the deployed classifiers continue to label work as before.
- Setting the grain from the product catalog. Hundreds of intents, most of them too sparse to staff, and a routing design that cannot be operated.
- Treating classifier accuracy as taxonomy agreement. A classifier can be highly accurate against its own labels while those labels disagree with the neighbouring channel's.
Maturity Model Position
Intent normalization is a Level 2 to Level 3 discipline on the WFM Labs Maturity Model™: Level 3 automation acts on arriving work by intent, and it acts wrongly if the intent is wrong. It is a hard prerequisite for Level 4 value-based placement and for the containment and self-service success measures that any human-versus-automated decision requires.
See Also
- Platform Migration as a Definitional Forcing Function — the supply-side half of the same program
- Next Generation Routing — the routing discipline that consumes normalized intents
- Skill-Based Routing — the moment-of-assignment decision that assumes the label is already correct
- Service Chain Decomposition and Node Sourcing — where assistance work sits
- Comparing Delivery Arrangements — why comparisons need the same work under the same label
- The Escalation Tax — per-interaction-type escalation probability and cost
