Vendor Change Control for Routing

Part of the Planning Week chain · previous: Call-Sharing Models and Cost Allocation · next: Activity-Code Consistency Vendor Change Control for Routing is the routing section of a function's standard that governs any change to the allocation or routing of work that touches a partner node: one form, three contract mechanisms each with its own change rule, one log, and the partner's confirmation before the change is live. It matters because a routing change at a partner is also a commercial change, and an estate whose routing changes are made by whoever has the console pays for them at the next invoice and the next renewal. The page produces section S-3.10.2 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. Where vendor governance sits inside a client organization is on Vendor Governance Placement; the rule that the commercial pen and the daily performance conversation are held by different parties is Tier 5 of Vendor Ecosystem Restructuring Agenda; the threshold past which an overseer must know the work from inside is on Specification and the Placement of Vendor Oversight; rate cards, invoice validation and true-ups are on BPO and Vendor Management for WFM. What this page adds is the change record itself and who owns it.

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; 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.

A routing change at a partner is a change-control item

A routing change at a partner is conventionally handled by whoever runs real time, logged afterward if at all. The Standard keeps the log and the confirmation and moves the ownership out of the console. The change-control board, one of the four forums Decision Rights by Planning Horizon names, owns any change to a routing arrangement that touches a partner supply seat (a partner capacity block: one supplier, one body of work, one commercial form). The real-time lead executes inside the arrangement's published bounds and, in an incident, outside them on the emergency path; the board ratifies afterward. The node owner, the owner of the body of work placed at a node and never the operator of the node, decides whether the work moves; the board decides whether the change is safe, priced and confirmed.

Three contract mechanisms determine what a change means:

Mechanism	What the contract fixes	What a change changes	Who confirms
Percentage allocation	A share of a body of work's volume	The share; the partner's staffing basis moves with it	The partner, in writing, before the share moves
Fixed volume per period	A number of contacts per month, allocated per day	The daily allocation or the period total; the second is a commercial amendment	The partner for the daily; the commercial owner for the total
Interval staffing (line adherence)	Posts per interval	The interval profile; a change inside the lock is also a forecast variance under Forecast Lock Process	The partner, and the planner for the book

The change types and the change authority are ITIL's; the dependence of a change's meaning on the contract mechanism follows Ren and Zhou; the separation of the executor from the commercial pen follows the measurement literature.

The form and the log

One form serves every change, and it carries thirteen fields. Ten describe the change itself: submitter; date submitted; date needed; length of the program or change; description; type of change; body of work, function and language; routing criteria; time-of-day routing; multi-destination routing. Three describe why it is allowed: the placement justification (the gate output the change executes, or the incident it responds to); the commercial effect (which mechanism, what moves, the priced difference with its grade); and the confirmation (who at the partner confirmed, when, by what record). The first ten are enough to make the change; the last three are what make it reviewable a year later. The log is append-only; a change is never edited, only superseded by another change that cites it.

The routing design register is the standing record every change updates: one row per arrangement, with the node, the partner, the contact type, the system of record, the language, the share or profile, the effective date, the mechanism, the hours of operation, the termination and transfer-back routes, and the renewal date of the contract that governs it. The register is what the board reads before it approves a change and what the annual certification checks against the platforms' configuration.

The renewal calendar is read as a constraint-relaxation schedule: each contract's renewal date is the date on which its mechanism, its share and its hours become movable at no cost. A change that the mechanism makes expensive today is queued to the renewal rather than forced; a placement decision that needs the change earlier is priced at the difference. Interconnected Workforce Management makes the same reading the test of whether the delivery-partner interface has an owner at all, and Vendor Ecosystem Restructuring Agenda treats the contract inventory as work that renewal dates set their own deadlines for. What this section adds is the column: the renewal date sits on the register row beside the mechanism, where the board reads it before it prices a change.

The ten blocks, filled

Purpose

Ensure that every change to the routing or allocation of work at a partner node is justified, priced, confirmed by the partner and logged before it is live, and that the emergency path exists and is ratified rather than hidden.

Inputs

A gate output or an incident record (interface row: Operations); the arrangement's row in the routing design register; the contract mechanism, the rate card and the renewal date (interface row: Delivery partners; the commercial owner); the current lock for the body of work.

Outputs

The change record with its confirmation; the updated routing design register row; the priced commercial effect to finance and the commercial owner; the configuration instruction to the routing layer, executed under Systems Administration for WFM Platforms.

Roles

The submitter (usually the real-time lead or the placement lead); the change-control board as approver; the partner's oversight owner, at the shared-service vendor team, as the party who obtains the confirmation and holds the commercial pen; the real-time lead as executor; the node owner as the decision owner.

Method

The L1 flow is one page, eleven steps, four decisions.

L1 flow, section S-3.10.2 Vendor change control for routing

#	Step	Owner	Next
1	Submit the form with the placement justification or the incident reference	submitter	2
2	Is this an emergency change during an open incident?	real-time lead	yes → 9 · no → 3
3	Read the arrangement's register row: mechanism, share or profile, renewal date	oversight owner	4
4	Price the commercial effect under the mechanism, with its grade; note whether the renewal calendar makes it free later	oversight owner; finance partner	5
5	Does the change alter the arrangement — its mechanism, its total, its nodes or its share — rather than move inside those?	change-control board	yes → 6 · no → 7
6	Board sitting: approved?	change-control board	approved → 7 · deferred to the renewal → End, queued on the renewal calendar with the price of moving earlier recorded · declined → End, the price recorded and the arrangement unchanged
7	Obtain the partner's written confirmation of the change and its effective date	oversight owner	8
8	Execute the configuration change; update the routing design register; log the record	real-time lead; the administrator	End
9	Execute inside the incident; notify the partner; log within the hour, in the node's local zone, with the incident reference	real-time lead	10
10	Was the emergency change reverted at incident close?	real-time lead	yes → 11 · no → 3
11	Ratify at the board's next sitting; close the record	change-control board	End

The L2 step table runs about thirty rows on the fifteen columns of Process Decomposition (L0–L3) and is produced by the pack. Its job aids are the form, the routing design register layout and the emergency-path checklist.

Metrics

Changes with a confirmation before going live (a proportion); emergency changes ratified within one sitting; changes deferred to a renewal and the price avoided; register rows that match the platform configuration at certification. The first two belong to Level 3; a priced change proposed by the engine belongs to Level 4.

Tools

The routing layer, configured through the annex; the register on the data core; the reporting platform for the log and the renewal calendar; intraday automation for the capacity state that triggers an emergency change.

Controls

No change live without a record; no record without a justification and a confirmation; the emergency path logged within the hour and ratified at the next sitting; the commercial pen held by the shared-service vendor team and never by the executor; the acceptance gate the section passed.

Maturity

Level 1: routing changed by whoever has the console. Level 2: a log per heritage, confirmations by email, the renewal date known to the commercial owner alone. Level 3: one form, one register, one board, the renewal calendar read as a schedule. Level 4: the engine proposes the change with its price; the board approves; the log is a ledger the team writes. Level 5: changes inside published bounds execute on policy; the board sets the bounds.

Node attribute and vendor paragraph

Partner nodes only; a change between two badged nodes is a configuration change under Systems Administration for WFM Platforms and needs no confirmation. The vendor paragraph is the section: the mechanism, the priced effect, the confirmation, the renewal calendar. A partner that holds real-time posts may submit but never approve or execute a change to its own allocation.

Worked example

The chain's function, on the migrating book's chat and email work, hub and partner nodes, ahead of the migration's service break (Wed 8 to Fri 10 Apr 2026). The book's voice work ran on the separate overflow arrangement Call-Sharing Models and Cost Allocation describes; this change is on the percentage-allocation arrangement that covers the written channels. Change CC-001 was submitted Wed 1 Apr 2026 by the real-time lead with the placement justification "relief during the service break; recompute on phase 3," needed Mon 6 Apr, program length one week. The arrangement was percentage allocation, hub to partner, 30 percent [A]; the change raised it to 45 percent [A] for the week. Step 4 priced the effect: about 310 partner hours [E], range 280 to 340, at the rate card, with the renewal date (Thu 31 Dec 2026) too late to help. Step 5 found that the change altered the arrangement's share, and under percentage allocation a share change moves the partner's staffing basis with it, so the change went to the board, which approved it out of cycle against the priced effect. The partner confirmed in writing Thu 2 Apr; the change went live Mon 6 Apr and was reverted Mon 13 Apr, each with a record. On Wed 8 Apr, during the break, the real-time lead made one emergency change (CC-002: the partner's transfer-back route disabled for four hours), logged at 10:40 in the node's local zone with the incident reference, reverted at close, and ratified at the board's sitting on Thu 16 Apr. The hours and shares are the example's.

The artifact this page produces

Section S-3.10.2 on the ten-block template, template SS, and the change record, whose entries are keyed CC-nnn. One filled example row:

ID	Arrangement	Mechanism	Change	Justification	Commercial effect	Confirmed (who, when)	Board	Effective	Reverted
CC-001	the migrating book (chat and email), hub → partner	percentage allocation	30 → 45 percent for one week [A]	relief during the service break (gate output)	about 310 hours [E], 280 to 340, at rate card	the partner's account lead, Thu 2 Apr 2026	approved out of cycle	Mon 6 Apr 2026	Mon 13 Apr 2026

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 a change record with a justification, a priced effect and a confirmation prevents the invoice and renewal disputes an unlogged change produces, and that the emergency path with ratification keeps the log honest under pressure. If a year's log showed disputes arising as often from confirmed changes as from the heritage period's unconfirmed ones, the record would be ceremony; and if emergency changes were routinely not reverted and not ratified, the path would have become the ordinary path and the board would be a fiction. The log and the board's minutes are the observation.

How this connects

• Previous in the chain: Call-Sharing Models and Cost Allocation — the arrangements a change alters
• Next in the chain: Activity-Code Consistency — the other configuration the administrator holds to the Standard
• Executed under: Systems Administration for WFM Platforms (the change-control board as owner of configuration; the release calendar)
• Forum: Decision Rights by Planning Horizon (the change-control board among the four forums)
• Defers to: Vendor Governance Placement (where day-to-day oversight sits, and the conditions under which the default reverses) · Vendor Ecosystem Restructuring Agenda (Tier 5: the commercial pen and the daily conversation held apart) · Specification and the Placement of Vendor Oversight (the threshold past which oversight needs process knowledge) · BPO and Vendor Management for WFM (rate cards, invoice validation, true-ups)

Maturity Model Position

A log and a confirmation are Level 2 on the WFM Labs Maturity Model™; one form, one register, one board and the renewal calendar read as a schedule are the Level 3 section this page defines. 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
• Call-Sharing Models and Cost Allocation
• Systems Administration for WFM Platforms
• Vendor Governance Placement
• Human Gates and Number Grades — the number grades used on this page