Departure–Arrival Assumptions Grid
The departure–arrival assumptions grid is a side-by-side record, built before a migration is modeled, of how the workload behaves at its point of departure (the platform, site or owner it leaves) and how it will behave at its point of arrival (the one it lands on). Each characteristic that can move contact volume, handle time or supply gets one row: the departure value, the arrival value, a call on whether the difference matters, what it drives, an effect in FTE with a range, an evidence grade, an owner and a date.
The grid answers the question a sponsor asks on being told that a migration is under control: show me what we know. A requirement is an arithmetic consequence of its assumptions, and the assumptions that sink migration plans are rarely the ones anybody argued about. They are the differences between the two operations that nobody laid side by side: a chat that runs asynchronously at arrival, a language the arriving team does not cover, a client who was never told that its own channel was being switched off. The grid is the place where those differences are written down before the model is built, so that the model's inputs can be traced back to a row someone wrote and a person who owns it.
The grid sits in front of two existing artifacts. Its open rows become rows of The Assumption Register, and its effects feed the first two artifacts of The Migration Health Pack: the bridge from the departure baseline to the plan, and the sensitivity ranking of the unresolved assumptions.
The row
| Field | What it holds | Why it is present |
|---|---|---|
| Characteristic | One thing about how the work is done: contacts per transaction by country, chat synchronicity, timeout, languages supported, routing design, shrinkage during training | The unit of comparison; one row per characteristic, never one per system |
| Point of departure | The value today, from the departing operation's own data for the migrating population | Without it the arrival value has nothing to be compared with |
| Point of arrival | The value the arriving operation will run with | Written by the arriving side, not inferred by the departing one |
| Call | Same · Acceptable · Watch · Problem · Unknown | Separates differences that change a number from differences that do not |
| Drives | What the difference moves: contacts per transaction, volume shape, handle time, concurrency, shrinkage, pooling, attrition, supply timing, service level, abandonment | Ties the row to a line of the requirement calculation |
| Phase | Whether the effect applies to one phase or cohort rather than to the steady state | Phase effects are invisible in a single steady-state number |
| FTE effect | A central estimate, and a low and a high swing around it | The central estimate builds the bridge; the range ranks the row |
| Evidence | Established · Inferred · Asserted · Open, as defined at The Assumption Register | Distinguishes a measured value from a stated one |
| Owner and date | One person able to close the row, and when | An unknown without an owner is a disclaimer |
Calling a difference
Almost every row of a migration's grid differs. That is expected and is not, by itself, a risk. A grid that lists differences without classifying them reads as a list of worries, and a reader cannot tell which of them the plan depends on. The call column does the classifying:
- Same: no difference. Recorded so that the absence of a difference is a finding rather than an omission.
- Acceptable: a difference that does not change any number in the plan. A chat timeout that moves from ten to fifteen minutes is Acceptable where abandoned sessions are not counted again as new contacts; where they are, the same change is a Watch.
- Watch: a difference that changes a number. The row carries its FTE effect and a range, or an open question asking for them, and its evidence grade says how firm the effect is.
- Problem: the work cannot land as planned unless someone acts. A language the departing operation supported and the arriving one does not is a problem whatever its FTE effect, because the work has nowhere to land.
- Unknown: the value on one side or both is not held. The row carries an owner and a date instead of a number.
The calls answer different questions. Acceptable or Watch turns on whether the difference moves contacts per transaction, handle time or supply: if it moves none of them it is Acceptable however large it looks, and if it moves one of them it carries an FTE effect and a range, even rough ones, because a row without them cannot be ranked against the others. Problem turns on whether the work can land at all. Unknown turns on whether a value is held.
One evidence grade covers a row that holds two values. The grade recorded is that of the weaker value, because the difference is only as firm as its least-supported side.
Both sides fill it
The departure value is written by whoever knows the departing operation, and the arrival value by whoever will plan the arriving one. Neither side can complete the grid alone. The departing side does not know which of its habits the arriving platform will remove; the arriving side does not know which of the departing operation's behaviors its own tools will fail to reproduce. A grid filled by one side describes that side's operation twice.
The departure value obeys the baseline rule set out at Migration Modeling Readiness: it is the departing operation's own measured behavior, for the migrating markets only, on pre-migration periods only. Migration Archetypes describes this as the rule most often broken: a platform norm imports the behavior of a different population, and a whole-account average imports the behavior of the markets that are staying.
Clarifying questions
A grid built from existing material leaves three kinds of hole: a value nobody has stated, two sources that state different values, and a value that is stated but weakly supported where it matters most. Each hole becomes a question, and each question is addressed to the person able to close the row it belongs to: the departure lead for a departure value, the arrival lead for an arrival value, the operations lead for supply, and the sponsor for whether the client has been told. A question is worth asking when a mandatory row is empty, when sources conflict, when an Asserted or weaker row sits in the top five of the ranking, when an open row has no range, or when an Unknown has passed its date.
Follow-up is complete rather than ad hoc when the questions come from a bank kept per characteristic, with one question for the departing side and one for the arriving side of every row in the catalog. A meeting's follow-up otherwise reflects what the room happened to discuss; a bank reflects what the grid needs. The bank also fixes what each answer changes, so a good question carries its source, names the row it closes and the number it moves, and asks one thing.
The questions are a tracked list rather than an email that is sent and forgotten. Each carries a status (open, asked, answered or closed) and is closed only when its answer has been applied to the grid and logged, so at any moment the list says what is still owed and by whom. An open question with no owner is the same as an Unknown with no owner: a disclaimer rather than a plan.
Phase considerations
A migration that goes live in phases does not experience its steady-state values from the first day. Handle time is the usual case: the first countries or cohorts to go live may run well above the eventual steady state, because agents, tools and knowledge are all new at once. A plan sized on the steady-state handle time will be short in exactly the weeks when the operation is least able to absorb it, and a phase-one cohort can need more FTE than its share of the volume suggests.
The phase field exists so that these effects are written against the phase they belong to, rather than averaged into a single number that is right for nobody.
Mandatory rows
Which characteristics must appear depends on the migration archetype. Archetypes A, B and C are mutually exclusive; D, an ownership or location change, may accompany any of them or occur alone. The mandatory set follows the table at What the archetype determines:
- Under every archetype: the contact rate and its denominator, the market or country split, seasonality and the weekly profile, the handle-time definition, training and proficiency, and shrinkage.
- A, B and C: the channel split, current and expected.
- B and C: the handle-time penalty at cutover, and its decay.
- C: synchronicity, timeout and entry points.
- D: eligibility, notice periods and transfer law, and knowledge lost with departing staff.
The mandatory set is fixed before the grid is populated rather than negotiated row by row afterwards; the same principle governs the register (see mandatory rows). Mandatory is a floor rather than a list. A practical catalog runs to about thirty-six characteristics across eight groups (setting the table, demand, chat, voice, email, handle time, supply and governance), and the rows beyond the floor, such as languages, routing design or whether the client has been told, are added when the migration makes them load-bearing. Past about ten per channel, rows rarely change any number [estimated]; the stop rule is the top twenty to thirty that do.
From the grid to the register and the pack
The grid is upstream of two artifacts that already have their own definitions.
- Every Watch, Problem and Unknown row becomes a row of the assumption register, with its range, grade and owner. Same and Acceptable rows stay on the grid as facts.
- Central estimates build the bridge. The first artifact of the health pack is a bridge from the departure baseline to the plan. Each step of the bridge is the sum of the central effects of the rows that drive it: contacts per transaction, volume shape, pooling, handle time and so on. A step nobody can trace to a row is a step nobody can defend.
- Ranges rank the open rows. The second artifact ranks the unresolved assumptions by how far they move the answer. A workable ranking multiplies the width of the FTE range by the weakness of the evidence (Open 1.0, Asserted 0.8, Inferred 0.5, Established 0.2), so a wide range on a stated figure outranks a wide range on a measured one. The top of that list is what to go and confirm first.
The weights are a convention rather than a measurement [estimated]; what matters is that one rule is applied to every row and that it penalizes weak evidence.
A worked example
An illustrative migration has a departure baseline of 104 FTE drawn from the client's own pre-migration months. Four rows carry central effects: seasonality (+8), the change from one 24-hour pool to in-country business-hours teams (+4, a loss of pooling), contacts per transaction rising with new entry points (+10), and phase-one handle time above steady state (+6). The bridge runs 104 → 132. The open rows that carry ranges score as follows: contacts per transaction (−10 to +12, Asserted) 17.6; the shift to chat (−4 to +14, Asserted) 14.4; shrinkage in training (−8 to +9, Asserted) 13.6; handle time (−9 to +9, Inferred) 9; training length (−12 to +4, Established) 3.2; seasonality (−2 to +3, Inferred) 2.5; and the service-level target (−1 to +2, Established) 0.6. The first five are the sensitivity ranking. Handle time has a wider range than shrinkage but ranks below it, because its evidence is stronger. The remaining open rows (how chat behaves, languages, the operating model, and whether the client has been told) carry owners and dates rather than ranges, and follow the ranked rows on the register.
The change log
The grid is a point in time: the state of knowledge when the model was first built. What keeps it useful is a dated change log beside it. When a direction changes, such as a channel modeled as synchronous that turns out to run asynchronously, or a client told for the first time that its own chat is being replaced, the change is logged that day: who said it, what changed, the evidence for it, the FTE effect, and whether the model has been updated. Three weeks later, the reason the number is what it is can be read rather than remembered.
A register that records only current values cannot answer the question "why did we change it?", and that is the question a sponsor asks after a plan has moved.
Running it
The grid is built in a working session rather than by correspondence, and the session is preceded by a full-build pass over the material that already exists (transcripts, notes, emails, whiteboard photographs and old slides), which arrives as proposed rows, each citing its source, and a list of questions addressed to their owners, so that the hour is spent agreeing calls rather than discovering values. A practical form is one hour with the departure lead, the arrival lead, a modeler and the owner of the number:
- Ten minutes: agree the groups and the characteristics to cut or add, holding to the stop rule.
- Thirty minutes: walk the grid. The departure lead reads each departure value, the arrival lead reads the arrival value, and the room agrees the call. Anything Unknown gets an owner and a date before the room moves on.
- Ten minutes: move the Watch, Problem and Unknown rows onto the register with a first range where one exists.
- Ten minutes: agree who refreshes the grid weekly until go-live, and the form of the one-page summary.
The one-page summary is the grid's Problem and Watch rows, the unknowns with their owners, the six questions of the modeling approach (the contact rate and its denominator, the country split, the departure data held, the channel split, seasonality, and what was deliberately not modeled), and the first two artifacts of the pack. The full grid is the appendix.
A workbook implementing the grid, register, bridge, ranking and one-page summary as ordinary spreadsheet formulas is available as a blank template and as the worked example above, with a readout and sponsor slides generated from it.
The readout
The sponsor-facing readout is a short document and three slides. The document opens with the plan, its ranges and the assumption that moves it most; explains how the number was built, from the departure baseline and its source through the six questions of the modeling approach; shows the bridge from the baseline to the plan and the ranking of the open assumptions; lists every Problem with its action, the top five open assumptions, and the open questions by owner; and says what has changed since the last readout. The full grid is the appendix. The slides carry the outlook and the bridge, the evidence for and against the plan, and the decisions and answers still needed.
The readout's numbers are derived from the grid each time rather than retyped. A retyped number drifts from its source the first time a row changes, and the readout then defends a plan that the grid no longer supports. Derivation also keeps the grade beside each value, so an Asserted figure cannot reach a sponsor looking like a measured one, an Unknown cannot be left out because it carries no number, and no plan figure appears without its range. Each readout is dated as of the grid it was drawn from. Two ranges are shown rather than one: what any single open assumption could do on its own, and what the five largest could do if all broke the same way. Neither is a confidence interval; the first understates assumptions that move together and the second overstates independent ones, which is why both appear.
Failure modes
- Filled by one side. The arriving side writes both columns from its own assumptions about the departing operation, and the grid confirms the plan it was meant to test.
- Differences listed, not called. Forty rows marked "different" with no call read as risk, and the reader cannot tell which ones the plan depends on.
- Steady state only. Phase effects averaged away, so the plan is short in the first weeks after each go-live.
- No effect on Watch rows. Rows that cannot be ranked are not looked at; a rough range is better than none.
- Built once. The grid is filled for the first model and not revisited, so the change log is empty and the register drifts away from it.
- Untold client. A channel switched off on paper keeps receiving contacts until someone tells the client, and the grid's governance rows exist to ask whether anyone has.
Maturity Model Position
At Level 1–2, differences between departure and arrival are discussed in meetings and held in the heads of the people who attended. At Level 3, a grid exists for each migration, is filled by both sides before the model is built, and feeds a graded register. At Level 4, every open row carries an FTE range, the bridge and the ranking are generated from the grid rather than assembled by hand, and a change log is kept from the first session. At Level 5, grids from completed migrations are compared by archetype, so that the next migration's catalog and its typical effects are drawn from evidence rather than from memory.
Use this with Claude
A ready-to-deploy instruction set, reference files, the workbook and report examples are at Wiki:Packs/Departure–Arrival Assumptions Grid (CP-WFM-022).
