Wiki:Packs/Departure–Arrival Assumptions Grid
From WFM Labs
| Pack | |
|---|---|
| ID | CP-WFM-022
|
| Name | Departure–Arrival Assumptions Grid |
| Domain | WFM |
| Blocks | 1 instruction + 7 reference |
| Workbook | template · example |
| Report examples | readout · sponsor slides |
| Version | 1.1 |
| Source | Departure–Arrival Assumptions Grid · The Assumption Register · The Migration Health Pack · Migration Archetypes · Migration Modeling Readiness |
A deployable Claude project setup for building and maintaining a departure–arrival assumptions grid for one service migration: the side-by-side record of how the work behaves today and how it will behave after the move, with every difference called, graded, owned and tied to the number it changes. The project fills a spreadsheet workbook whose register, bridge, sensitivity ranking and one-page summary are formulas, so the work in the project is confined to the cells people type in. It can build the whole grid in one pass from unstructured material, raise the clarifying questions each row's owner needs to answer, and write the sponsor readout and slides. The method is described at Departure–Arrival Assumptions Grid. Copy Block 1 into a project's custom instructions; save Blocks 2–8 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.
When to use it
Use this pack for each migration from the moment its archetype is declared until it is live and stable: to build the first grid in one pass from whatever material already exists, to raise and track the questions each row's owner must answer, to turn call notes and transcripts into proposed grid rows, to prepare and record the working session in which the departure and arrival leads fill the grid together, to keep the change log as directions change, and to produce the readout and slides a sponsor reads. It complements Wiki:Packs/Migration Portfolio Review (CP-WFM-021), which reviews every migration on the horizon weekly; this pack works one migration in depth and produces the inputs that review reads.
How to deploy
- Download the blank workbook and save a copy per migration where the team works on it (a shared drive that opens it in the browser is enough). The worked example shows every sheet populated.
- Create a Claude project named for the migration, in an account where code execution and file creation are turned on (the project reads and writes the workbook with code). Copy Block 1 into its custom instructions, and save Blocks 2–8 under the filenames in their headings as project knowledge.
- Open each conversation by uploading the current workbook, plus whatever is new: call notes, a transcript, a photo of a whiteboard grid, an email. The project carries no state between conversations; the workbook is the state.
- Ask for what you need: a full build from a pile of material, proposed rows from one new note, the clarifying questions by person, answers applied, the session pack, the weekly refresh, or the readout and sponsor slides. Review the proposed changes, then ask for the updated workbook and open it in the spreadsheet application, which recalculates the computed sheets.
Block 1 — project instructions
# Departure–arrival assumptions grid — project instructions
You maintain the **departure–arrival assumptions grid** for one service migration: how the work
behaves at the point of departure (today) and at arrival (after the move), every difference called,
graded, owned and tied to the number it changes. The uploaded workbook is the state. Its Dashboard,
Register, Panels and One-pager sheets are formulas; you only ever write input cells.
## Modes and routing
| Asked to… | Mode | Open |
|---|---|---|
| Turn a pile of material into the grid | Full build | `full-build-routine.md`, then `question-bank.md` |
| List what to ask, by person | Clarify | `question-bank.md` |
| Apply answers that came back | Answer intake | `session-runbook.md` |
| Add notes from one call; run the session; weekly refresh | Update | `session-runbook.md` |
| Produce the readout or sponsor slides | Report | `readout-report.md` |
| Call or size a difference; which rows are mandatory | (any) | `grid-method.md` |
| Rank, bridge, change-log lines | (any) | `register-and-panels.md` |
| Read or write the workbook | (any) | `workbook-map.md`, always, before touching the file |
## Disciplines
1. Declare the archetype first: at most one of A lift and shift, B platform, C experience; D
(ownership/location) may accompany one of them or stand alone. It sets the mandatory rows.
2. Departure values are the departing operation's own data, migrating markets, pre-migration
months. Flag a platform norm or whole-account average before using it.
3. Every value cites its source; never invent a number. Conflicting sources are reported, not
reconciled. Open rows get a range, or an owner, a date and a question.
4. Acceptable vs Watch: does it move contacts per transaction, handle time or supply? Problem: can
the work land? Unknown: is a value held?
5. Grade each row by its weaker value: Established, Inferred, Asserted, Open. Quoted = Asserted.
6. Every change of direction is a dated Change log line; every answer closes its question.
7. Write only the input cells in `workbook-map.md`; never formulas, computed columns or row order.
8. Owners are roles or initials as the user gives them; add no names.
9. Report numbers are recomputed with the rules, never retyped.
No workbook uploaded? Ask for it; never build one from scratch.
## Output
- **Proposed changes first**: grid #, field, old → new, source. Wait for confirmation unless told
to apply directly.
- **Then the workbook**, as a dated .xlsx, with a summary: rows changed, calls by count, mandatory
rows still empty, open questions by owner, and the expected bridge and top five computed by hand
(the file recalculates only when opened in a spreadsheet application).
- Unknown is a complete answer: "not yet known; owner X; by date Y".
Source: Wiki:Packs/Departure–Arrival Assumptions Grid (CP-WFM-022) v1.1
Block 2 — grid-method.md
# The grid: method
## The row
| Field | Holds | Rule |
|---|---|---|
| Characteristic | One thing about how the work is done | One row per characteristic, not per system |
| Point of departure | Value today | Departing operation's own data, migrating markets, pre-migration months |
| Point of arrival | Value after the move | Written by the arriving side |
| Call | Same · Acceptable · Watch · Problem · Unknown | See below |
| Drives | What it moves | One of the eleven in `workbook-map.md` |
| Phase | Phase or cohort the effect applies to | Blank = steady state |
| FTE central / low / high | Effect on the requirement | Central builds the bridge; low/high rank the row |
| Evidence | Established · Inferred · Asserted · Open | Grade of the weaker of the two values |
| Owner, date | One role or person; the target date to close it (not the date it was said) | Required on every Watch, Problem and Unknown row |
## Calling a difference
- **Same**: no difference. Recorded so the absence is a finding.
- **Acceptable**: different, but changes no number. Example: a chat timeout from 10 to 15 minutes
where abandoned sessions are not counted again as contacts (if they are, it is a Watch).
- **Watch**: changes a number. Carries a central FTE effect and a range, or an open question
asking for them; the evidence grade says how firm it is. A confirmed effect stays Watch with a
stronger grade.
- **Problem**: the work cannot land as planned unless someone acts, whatever its FTE effect
(a language the arrival side does not cover).
- **Unknown**: a value is not held. Owner and date instead of a number.
Three different tests: Acceptable vs Watch = does it move contacts per transaction, handle time or
supply? Problem = can the work land? Unknown = is a value held?
## Evidence rules
- **Examples are not values.** A figure offered as an illustration ("say 45%", "for example 70/30",
"whatever, 400 seconds") is not held: leave the cell empty, note "example only" with its citation,
and raise a question. A call drafted on an example drops to Unknown until a real value arrives.
- **Independence.** A note, whiteboard or slide produced in the same meeting as a transcript is not
a second source: it corroborates nothing. Cite both; count one.
- **One source can conflict with itself.** Two different values from the same source are a
conflict, handled like any other.
- **Coded quotes.** Where names must be coded, substitute the code inside the quote in brackets
("[CLIENT-A] are using their own chat"); the quote is otherwise verbatim.
## Archetypes and mandatory rows
A, B and C are mutually exclusive: declare at most one. D (ownership or location) may accompany
any of them, or stand alone. Mandatory rows by archetype:
| Mandatory row | A | B | C | D |
|---|---|---|---|---|
| Contact rate and its denominator; transaction volume | ● | ● | ● | ● |
| Market or country split (what moves, when) | ● | ● | ● | ● |
| Channel split, current and expected (chat, voice, email shares) | ● | ● | ● | |
| Seasonality and weekly profile | ● | ● | ● | ● |
| Handle-time definition, and baseline by channel and country | ● | ● | ● | ● |
| Handle-time penalty at cutover, and decay by phase | | ● | ● | |
| Synchronicity, timeout, entry points | | | ● | |
| Training length, nesting, proficiency | ● | ● | ● | ● |
| Shrinkage | ● | ● | ● | ● |
| Eligibility, notice periods, transfer law | | | | ● |
| Knowledge lost with departing staff | | | | ● |
When tools and principles change together with what the customer meets, declare C: C usually
carries the agent's tools with it. D applies when the people or sites doing the work change
(another employer, site or country); regrouping the same people (one pool into in-country teams)
is a pooling difference on the grid, not D. Also always required: the archetype itself, and laying the incoming plan against the outgoing plan
before go-live. With C declared, 16 of the 36 catalog rows are mandatory. Mandatory is a floor:
add any other row the migration makes load-bearing.
## The catalog (36 rows, eight groups; mandatory letters in brackets)
- **Setting the table**: archetype (recorded on Set the table, so not a mandatory row); what moves and when [ABCD]; operating model, pooled
vs in-country; language model; servicing model; tools and platform.
- **Demand**: transaction volume and definition [ABCD]; contacts per transaction by country
[ABCD]; seasonality and profile [ABCD]; adoption ramp; self-service and deflection; contact
conversion and re-contacts.
- **Chat**: usage share [ABC]; sync or async [C]; timeout and abandonment [C]; concurrency modeled
vs achieved; languages; bot element; service level and hours.
- **Voice**: usage share [ABC]; IVR and routing; entry points and identification [C]; service
level and hours.
- **Email**: usage share and turnaround [ABC].
- **Handle time**: definition [ABCD]; baseline by channel and country [ABCD]; cutover penalty
and decay by phase [BC]; tenure, proficiency and knowledge loss [D].
- **Supply**: shrinkage [ABCD]; training, nesting, proficiency [ABCD]; delivered capacity and
plannable occupancy; attrition and backfill; eligibility, notice and transfer law [D].
- **Governance**: who has told the client what changes; incoming plan against outgoing [ABCD];
buffer for other clients in the same wave.
## Stop rule and limits
Top twenty to thirty characteristics; past about ten per channel, rows rarely change any number
[estimated]. The grid records the state of knowledge when the model is built; without the change
log it ages silently. It does not replace a requirement model: it supplies and explains its inputs.
Block 3 — register-and-panels.md
# From grid to register and panels
## Register
Every row called Watch, Problem or Unknown is on the register. Rank:
score = |FTE high − FTE low| × weight(evidence)
weight: Open 1.0 · Asserted 0.8 · Inferred 0.5 · Established 0.2 · blank 1.0 [estimated]
Highest score is R1. Rows without both low and high follow all scored rows, in grid order. Ties
keep grid order. The weights are a convention, not a measurement: apply them unchanged, so that a
wide range on a stated figure always outranks the same range on a measured one. R-numbers are
positions, not identities; they change as rows are sized. Refer to a row by its grid # in the
change log.
What the score is for: deciding what to confirm first. A high-scoring row is either worth
measuring (to narrow the range) or worth evidencing (to raise the grade). Say which, per row.
## Panel 1: bridge, departure baseline to plan
Each grid row with a central FTE effect adds to one bridge step, by its Drives value:
| Drives | Step |
|---|---|
| Volume shape | season |
| Pooling | mix |
| CPT / volume | CPT |
| AHT, Concurrency | AHT |
| Shrinkage | shrink |
| Supply timing | timing |
| Service level, Abandonment | SL |
| Attrition | attrition |
| Several, anything else | other |
Order: baseline → season → mix → CPT → AHT → shrink → timing → SL → attrition → other → plan.
Plan = baseline + sum of all central effects. A step can be negative. No baseline, no bridge:
say so rather than drawing one from zero. The baseline is the departing operation's own
history for the migrating markets, pre-migration months only.
## Panel 2: tornado
The top five scored register rows, each drawn from its low (left of zero) to its high (right).
Low and high are swings against the plan, not absolute values.
## Worked example
Baseline 104. Central effects: seasonality +8 (season), operating model +4 (mix), contacts per
transaction +10 (CPT), phase-one handle time +6 (AHT). Bridge: 104 → 112 → 116 → 126 → 132.
| Row | Range | Grade | Score | Rank |
|---|---|---|---|---|
| Contacts per transaction | −10 / +12 | Asserted | 22 × 0.8 = 17.6 | R1 |
| Chat usage share | −4 / +14 | Asserted | 18 × 0.8 = 14.4 | R2 |
| Shrinkage in training | −8 / +9 | Asserted | 17 × 0.8 = 13.6 | R3 |
| Handle time by phase | −9 / +9 | Inferred | 18 × 0.5 = 9 | R4 |
| Training length | −12 / +4 | Established | 16 × 0.2 = 3.2 | R5 |
| Seasonality | −2 / +3 | Inferred | 5 × 0.5 = 2.5 | R6 |
| Service-level target | −1 / +2 | Established | 3 × 0.2 = 0.6 | R7 |
Then R8–R11 unscored, in grid order: operating model (#3), how chat behaves (#14), languages (#17),
client told (#34).
Handle time has a wider range than shrinkage but ranks below it: stronger evidence.
## Change log line
| Field | Example |
|---|---|
| Date | 2026-11-02 (the day it was said, not the day it was logged) |
| Grid # | 14 |
| What changed (from → to) | Chat modeled as synchronous → runs asynchronously |
| Said by | Arrival lead |
| Evidence | Asserted |
| FTE change | +3 |
| Model updated? | Yes · No · In progress |
Log a line when a value, a call, a grade or a direction changes; not for typo fixes. A re-grade made
on review rather than said by anyone is logged as said by the reviewer (for example, the modeler). Update the
grid row in the same pass, so the register and panels match the log. A change log with no lines
after the first session means the grid has stopped being maintained: say so in the weekly refresh.
Block 4 — workbook-map.md
# Workbook map
Sheets: Guide · Dashboard · Set the table · Grid · Register · Questions · Change log · Panels · One-pager · Lists.
**Input cells are listed below. Everything else is a formula or a label: never write it.**
## Set the table (inputs in column C)
| Cell | Field |
|---|---|
| C3 | Migration or program |
| C4, C5, C6, C7 | Archetype A, B, C, D: "Yes" or "No". At most one of C4–C6 is Yes; C7 (D) may be Yes with one of them or alone. D4 warns if two of A–C are Yes |
| C8 | From → to |
| C9 | Markets, phases and dates |
| C10 | Departure baseline, FTE (a number) |
| C11 | Where the baseline comes from |
| C13–C18 | Approach: CPT rate/denominator/source; country level?; departure data; channel split; seasonality; not modeled and why |
## Grid (rows 4–63; grid # = row − 3; inputs in columns B–P)
| Col | Field | Values |
|---|---|---|
| A | # | Pre-filled 1–60. Do not change |
| B | Group | Setting the table, Demand, Chat, Voice, Email, Handle time, Supply, Governance |
| C | Characteristic | Text. A row with C empty is ignored by the register, bridge and one-pager |
| D, E | Point of departure, point of arrival | Text |
| F | Call | Same, Acceptable, Watch, Problem, Unknown (exact spelling) |
| G | Drives | CPT / volume, Volume shape, AHT, Concurrency, Shrinkage, Pooling, Attrition, Supply timing, Service level, Abandonment, Several |
| H | Phase | Text |
| I, J, K | FTE central, low, high | Numbers, or empty. Never text |
| L | Evidence | Established, Inferred, Asserted, Open |
| M, N | Owner, date | Text; date as YYYY-MM-DD |
| O | Notes | Text |
| P | Mandatory for | Letters, e.g. ABC |
| Q–Z | Computed | **Never write** |
New characteristic: use the first row where C is empty. Do not insert or delete rows, and never
clear C on a catalog row (the mandatory check would silently lose it). To retire a
row, set its call to Acceptable or Same, clear I, J and K, and say why in Notes; a number left in I
still counts in the bridge.
## Questions (rows 4–153; inputs in A, B and D–K)
| Col | Field | Values |
|---|---|---|
| A | Q# | Pre-filled Q1–Q150. Keep |
| B | Grid # | A number: the row the question closes |
| C | Characteristic | Computed from B. **Never write** |
| D | To | The row's owner: departure lead, arrival lead, operations lead, sponsor, modeler (other roles allowed) |
| E | Question | One ask. A row with E empty is ignored |
| F | Why it matters | What it closes or moves |
| G | Raised | YYYY-MM-DD |
| H | Status | Open, Asked, Answered, Closed |
| I, J, K | Answer, answered by, date answered | Text; date as YYYY-MM-DD |
New question: the first row where E is empty. Close a question only after its answer is applied to
the grid and a change-log line is written.
## Change log (rows 4–203; inputs in A–G)
A date · B grid # (number) · C what changed · D said by · E evidence · F FTE change (number) ·
G model updated? (Yes, No, In progress). Append at the first empty row.
## Reading and writing (Python, openpyxl)
```python
from openpyxl import load_workbook
wb = load_workbook("grid.xlsx") # NOT data_only=True: that drops the formulas on save
g = wb["Grid"]
rows = [{"n": r - 3, "char": g[f"C{r}"].value, "call": g[f"F{r}"].value}
for r in range(4, 64) if g[f"C{r}"].value]
g["I4"] = 12 # numbers as numbers, never "12"
log = wb["Change log"] # append at the first empty row (never ws.append: it writes below row 203)
r = next(r for r in range(4, 204) if all(log.cell(r, c).value in (None, "") for c in range(1, 8)))
for c, v in enumerate(["2026-11-02", 14, "Chat modeled as synchronous → runs asynchronously",
"Arrival lead", "Asserted", 3, "Yes"], 1):
log.cell(r, c, v)
wb.save("grid-2026-11-02.xlsx")
```
Dashboard, Register, Panels, One-pager and Lists are computed: never write them. Computed cells
hold no stored values until a spreadsheet application opens and recalculates the file, so `data_only=True` returns None for them. Compute the expected bridge and ranking yourself
with the rules in `register-and-panels.md`, and state them in the reply.
Block 5 — session-runbook.md
# Session runbook
## No workbook uploaded
Ask for the current workbook before anything else. Do not build one from scratch: the template
carries formulas, validation and charts that a fresh file will not. If none exists yet, point to
the blank template on the pack page and help fill Set the table first.
## Notes or a transcript → proposed rows
1. Find each statement about how the work behaves on either side. Ignore opinions about people.
2. Map it to a catalog characteristic (`grid-method.md`); create a new one only if none fits.
3. Fill what was actually said: departure value, arrival value, phase. Leave the rest empty.
4. Propose a call and a Drives value, and say why in one line.
5. Grade the row by its weaker value: Asserted if someone said it, Established only with a named
source and definition, Inferred if derived by a stated method, Open if no value is held.
Questions raised and not answered become Unknown rows and Questions-sheet rows, addressed to
the person who should answer.
6. Propose a change-log line wherever the material changes an existing row's value, call or grade.
7. Output the proposal table (grid #, field, old → new, source line). Do not write the file yet.
Watch for the statements that matter most and are easiest to miss: a channel that will behave
differently (synchronous vs asynchronous), a language or market the arriving side does not cover,
a phase whose handle time will differ from steady state, and any sign that the client has not been
told what will change. A decision reversed in a later meeting is a change-log line, not a new row.
A photo of a hand-drawn grid: transcribe it row by row, mark illegible cells as illegible rather
than guessing, and map its rows to the catalog.
## Answers that came back
1. Match each reply to its Q# (or, if it has none, to the grid row it answers); quote the reply.
2. Propose the row change it implies: value, call, grade (a written reply from the owner is
Asserted; a reply with an export or a named source and definition is Established), range,
owner or date. A reply that answers only part of a question leaves the question Asked.
3. Propose a change-log line for every value, call or grade that moves.
4. Set the question to Answered, with the answer, who gave it and the date.
5. After the write is confirmed, set it to Closed. A reply that raises a new question becomes a
new Questions-sheet row, not an edit of the old one.
## The one-hour working session
Before: list the mandatory rows still empty, by owner; the open rows with no range; and the
Unknowns past their date. Send it to the departure and arrival leads in advance.
1. 10 min: agree groups; cut or add characteristics (stop rule: top 20–30).
2. 30 min: walk the grid. The departure lead reads departure, the arrival lead reads arrival; the
room agrees each call. Every Unknown leaves with an owner and a date.
3. 10 min: give each Watch, Problem and Unknown row a first range where one exists.
4. 10 min: agree who refreshes weekly until go-live, and the one-pager's audience.
After: proposal table → confirmed by a lead → workbook → change-log line "Session held".
## Weekly refresh
Ask for: new evidence by row; Unknowns past their date; rows whose call should change. Write the
grid, append the log, and report:
- how the bridge moved (old plan → new plan, which steps changed);
- how the ranking moved (rows entering or leaving the top five);
- mandatory rows still empty, by owner;
- Unknowns past their date.
A week with no change is reported as such; it is still a refresh.
## One-pager
Header (name, archetype, from → to, phases) · how the number was built (the baseline and its
source, then the six approach questions: contact rate and denominator, country split, departure data
held, channel split, seasonality, what was deliberately not modeled) · Problem and Watch rows ·
unknowns with owners · bridge · top five. The workbook's One-pager sheet produces it on
recalculation; print it one page wide. The full grid is the appendix.
## Limits
The project reads what it is given. It cannot see the operation, cannot recalculate the workbook,
and cannot confirm a value that nobody has measured. It can make the state of knowledge legible.
Block 6 — full-build-routine.md
# Full build: from a pile of material to a complete grid
Use this when the material arrives all at once: a first build or a rebuild. For one new note,
`session-runbook.md` is enough. The output is a proposal; the workbook is written after confirmation.
## 1. Inventory the sources
List every item uploaded before reading any of it for content.
| Id | Type | Date | Speakers or author (roles) | Covers |
|---|---|---|---|---|
Date is when it was said or written, not uploaded; if none, write "undated" and treat it as older
than every dated source. Speakers by role. An unreadable item is still listed, marked "unreadable".
## 2. Declare or propose the archetype
Use the archetype the user declared. If none, propose one with its evidence: at most one of A lift
and shift, B platform change, C experience change; D ownership or location change alone or with
one of them. Example: "Proposed C: [S2: "Chat at arrival goes asynchronous"]." The archetype fixes the mandatory rows
(`grid-method.md`); confirm it before step 9 reports gaps against it.
## 3. Build the evidence table, source by source
Read one source at a time, start to finish. Write one line per statement about how the work
behaves on either side; ignore opinions about people. Save the table to `evidence.csv` with code
after each source and reload it for later steps. Past about 40 proposed rows, deliver by group.
| E# | Source | Side | Grid # | Claim | Quote or line |
|---|---|---|---|---|---|
Side is D, A or both. Grid # is the catalog row (1–36), or "new" (step 6). Quotes are verbatim,
fifteen words at most; for a photo or slide, cite the place ("whiteboard, arrival column, line 3").
This is the chunking strategy: carry the table forward, not the source text. If a source must be
re-read, re-read it for one grid # at a time.
## 4. Walk the catalog and fill the rows
Walk the 36 rows in catalog order, not source order, so no unmentioned row is skipped. For each row, gather its evidence lines and propose:
- **Departure and arrival values**, in the source's terms. Each carries its citation in Notes as
`[S#: "short quote"]`.
- **Call**, by the three tests in `grid-method.md`.
- **Drives**: the catalog default unless the evidence says otherwise; say why if changed.
- **FTE central, low, high**: only where a source gives the number or a stated method derives it.
Write the method in Notes. Otherwise leave empty.
- **Grade**, by the weaker value: said by someone = Asserted; a named report with a definition =
Established; derived by a stated method = Inferred; no value held = Open.
- **Owner and date**: the role able to close it; the date if a source gives one, otherwise a question.
A row with no evidence stays empty; never fill it from general knowledge or a norm.
## 5. Detect conflicts; never reconcile silently
A conflict is two sources giving different values for the same side of the same row, neither
acknowledging the other. Number each one (C1, C2…): grid #, side, both values with citations and
dates. Do not pick the newer source, the more senior speaker or the more plausible value. Write
"Conflict, see C#" on that side, call the row Unknown and grade it Open: no agreed value is held.
## 6. Capture characteristics not in the catalog
A claim that fits none of the 36 rows becomes a proposed new row at the first empty grid # (37
onward): group, characteristic, Drives, and one line on why it is load-bearing. If it fits a
catalog row loosely, map it there and say so.
## 7. Reversals become change-log lines
A reversal is one source or role changing its own position ("we had planned six weeks; it is now
four"). Propose a change-log line (`register-and-panels.md`): date said, grid #, from → to, said
by, evidence, FTE change if given, model updated No. The row holds the latest value; the log holds
the history.
## 8. Generate the questions
Raise one per trigger in `question-bank.md` (gap, conflict, weak row in the top five, open row with
no range, empty mandatory row, Unknown past its date), using its wording and send-ready format.
Each question becomes a row on the Questions sheet with status Open, its grid #, its owner in To, and why it
matters (`workbook-map.md`); the send-ready list in the reply is drawn from those rows.
## 9. Self-check
- Every filled cell has a `[S#: "…"]` citation or a stated method in Notes.
- No number appears that is not in a source or derived by a stated method.
- Ranges appear only where a source gives them or a stated method derives them.
- Every Watch, Problem and Unknown row has an owner, and a date or a question.
- Mandatory rows for the declared archetype still empty are listed by number and name.
- No person's name appears that the user has not used.
Report a failed check; do not fix it quietly.
## 10. Output
Archetype (declared, or proposed with evidence) · proposal table (grid #, field, old → new,
source) · gap summary (empty mandatory rows by owner, open rows with no range, rows with no
evidence) · conflicts · proposed new rows and change-log lines · questions grouped by owner. Write
the workbook only after confirmation (`workbook-map.md`).
## Worked example
Archetype C declared; departure baseline 104 FTE.
- **S1**, transcript, 2026-09-28, departure lead: "Contacts per transaction run about 0.31 across
the migrating countries, from our last twelve months. Chat today is live; customers stay in the
window. We cover EU and Asian languages."
- **S2**, email, 2026-10-01, arrival lead: "Chat at arrival goes asynchronous. We support EU
languages only. Training was planned at six weeks; we've cut it to four. Expect about 0.34
contacts per transaction with the new entry points. We'll also send proactive status messages,
which nobody does today."
- **S3**, whiteboard photo, 2026-10-02: arrival column reads "chat: sync".
Evidence table (claim column omitted):
| E# | Src | Side | Grid # | Quote |
|---|---|---|---|---|
| E1 | S1 | D | 8 | "about 0.31 … our last twelve months" |
| E2 | S2 | A | 8 | "about 0.34 … new entry points" |
| E3 | S1 | D | 14 | "customers stay in the window" |
| E4 | S2 | A | 14 | "Chat at arrival goes asynchronous" |
| E5 | S3 | A | 14 | arrival column, "chat: sync" |
| E6 | S1, S2 | both | 17 | "EU and Asian" / "EU languages only" |
| E7 | S2 | A | 30 | "we've cut it to four" |
| E8 | S2 | both | new | "nobody does today" |
Proposed rows:
| # | Departure | Arrival | Call | FTE central | Grade |
|---|---|---|---|---|---|
| 8 | 0.31 | 0.34 | Watch | +10 | Asserted |
| 14 | Synchronous | Conflict, see C1 | Unknown | – | Open |
| 17 | EU + Asia | EU only | Problem | – | Asserted |
| 30 | – | 4 weeks | Unknown | – | Open |
| 37 new | None | Proactive messages | Watch | – | Asserted |
Row 8's central effect is a stated method: if the requirement scales with contacts,
104 × (0.34 ÷ 0.31 − 1) = 104 × 0.097 = +10. Pooling makes real growth somewhat less than
proportional [estimated]. No source gives a range, so a question asks for one. The 0.31 is a total, not
by country, so the mandatory row is only partly filled. Row 30 holds an arrival value but no
departure value, so it is Unknown and Open until the departure lead supplies one; the cut from six
to four weeks is a change-log line: 2026-10-01, #30, arrival training 6 → 4 weeks, arrival lead,
Asserted, FTE blank, model updated No. C1 is S2 (asynchronous, 1 October) against S3 (synchronous,
2 October). Thirteen of the sixteen mandatory rows for C have no evidence; they are listed by
owner.
Questions (extract):
**Arrival lead**
1. #14: The 1 October email says chat at arrival is asynchronous; the 2 October whiteboard reads
"sync". Which runs at go-live? It sets handle time and concurrency.
2. #8: What is the 0.34 based on, and what low and high would you put on it? It drives the CPT
step, now +10 FTE.
**Departure lead**
3. #8: Can the 0.31 be split by migrating country, from the same twelve months? The row is
mandatory and sets the CPT step.
## Limits
The routine finds what the material says, not what is true. A value said once by one person stays
Asserted however often it is repeated in later material that copies it.
Block 7 — question-bank.md
# Question bank
One question per side for every catalog row, and what the answer changes. Adapt the wording to the
source that raised it. Departure questions go to the departure lead, arrival questions to the arrival
lead; supply rows (29–33) to the operations lead; rows 1, 34 and 36 may go to the sponsor.
## Setting the table
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 1 | Beyond the move itself, does anything change for customers or agents? | Which changes: platform, experience, owner, location? | Archetype; mandatory rows |
| 2 | Which markets and populations move, at what volume? | Which phases go live when, with which markets? | Phase field; supply timing |
| 3 | Pooled follow-the-sun or in-country? Hours covered? | Pooled or in-country? Hours? | Pooling: mix step |
| 4 | Which languages, routed how? | English-only or language-based routing? | Pooling; Problem if a language has nowhere to land |
| 5 | Dedicated, designated or shared agents? | Same question at arrival | Pooling; occupancy |
| 6 | Which tools does one transaction touch? | Which tools replace them? | AHT |
## Demand
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 7 | How is a transaction counted; monthly volume, migrating markets? | Same definition? Expected volume? | CPT denominator; CPT step |
| 8 | Contacts per transaction by country, own pre-migration months? | Expected rate by country, and why? | CPT step |
| 9 | Seasonal, weekly and daily shape, migrating markets? | Does it hold? New peaks at go-live? | Season step |
| 10 | Which user groups move first, and their size? | Share of users moved per phase? | CPT by phase; timing |
| 11 | Self-service and bot containment today? | Expected deflection, and its evidence? | CPT step |
| 12 | How often does deferred email become a call; re-contact rate? | Will conversion or re-contacts change? | CPT; channel mix |
## Chat
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 13 | Chat share of contacts, by country? | Expected share; is chat the default? | CPT step; channel mix |
| 14 | Synchronous or asynchronous today? | Which at go-live? | AHT; concurrency; call |
| 15 | Timeout; are abandoned sessions re-counted? | Timeout; re-counted? | Acceptable vs Watch; abandonment |
| 16 | Concurrency planned vs achieved? | Concurrency planned, and offered? | AHT step |
| 17 | Which chat languages? | Which from day one? | Problem if not covered |
| 18 | Bot in front of chat? Containment? | Bot at arrival? Containment? | CPT step |
| 19 | Service level target and hours? | Target and hours? | SL step |
## Voice
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 20 | Voice share of contacts, by country? | Expected share? | CPT step; channel mix |
| 21 | IVR menus, skills, overflow? | Routing design at arrival? | AHT; pooling |
| 22 | Entry points; identification and security time? | New entry points; security time? | AHT; CPT if entry points add contacts |
| 23 | Service level target and hours? | Target and hours? | SL step |
## Email
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 24 | Email share and turnaround target? | Share and target? | CPT step; timing of work |
## Handle time
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 25 | Elapsed or agent work? Concurrency inside? | Same definition? | Whether AHT values compare at all |
| 26 | AHT by channel and country, own history? | Expected AHT by channel and country? | AHT step |
| 27 | Handle time in past cutovers, and decay? | Phase-one AHT vs steady state; how long? | Phase field; AHT step |
| 28 | Tenure profile of agents not moving? | Tenure of arriving agents; knowledge lost? | AHT; proficiency |
## Supply
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 29 | Shrinkage, steady state and in training? | Expected, in training and after? | Shrink step |
| 30 | Training, nesting, ramp length? | Planned length and ramp? | Timing step |
| 31 | Heads to productive hours; occupancy? | Plannable occupancy? | Pooling; delivered FTE |
| 32 | Attrition; backfill lead time? | Expected attrition; backfill time? | Attrition step |
| 33 | Who is eligible to move; notice periods? | Transfer law; start dates? | Timing; Problem if staff cannot land |
## Governance
| # | Ask departure | Ask arrival | Answer changes |
|---|---|---|---|
| 34 | Has the client been told what changes? | What will the client be told, and when? | CPT; Unknown → owner and date |
| 35 | Outgoing plan, by week? | Incoming plan, by week? | Other step; weeks uncovered between the two plans |
| 36 | Other clients leaving in the same wave? | Buffer held for them? | Timing step |
## Phrasing a good question
- **Specific.** Ask for a value, a split or a date, not "any thoughts on chat?".
- **Carries its source.** Quote what prompted it: "The 1 October email says…".
- **Names its row and its effect.** "#8, the CPT step, now +10 FTE."
- **One ask.** Two unknowns are two questions.
- **Addressed to the row's owner**: departure lead, arrival lead, operations lead or sponsor.
Copy the modeler on the consolidated list.
Weak: "Can we discuss chat?" Strong: "#14: The email says asynchronous; the whiteboard says
synchronous. Which runs at go-live? It sets handle time."
## When to raise one
| Trigger | Example |
|---|---|
| Gap: a value is not held | #30 departure training length |
| Conflict between sources | #14 async vs sync |
| Asserted or weaker row in the top five | #8, Asserted, score 17.6 |
| Open row with no range | #34 client told |
| Mandatory row still empty | #26 for every archetype |
| Unknown past its date | Any row with date before today |
## Send-ready format
Group by person; number continuously; lead each question with its grid #. Paste as is. Address a
question to whoever holds that side's value (the departure lead for departure values, the arrival
lead for arrival values), even when the row's owner is someone else; the owner and the modeler
are copied. Use the roles the team actually has; where a role does not exist, address the nearest
one and say so. A full build can raise forty questions or more: lead each person's list with the
ten that move the plan most (top-five rows, Problems, empty mandatory rows), and put the rest in
an appendix to the same message.
```
Arrival lead
1. #14: The 1 Oct email says chat at arrival is asynchronous; the 2 Oct whiteboard
reads "sync". Which runs at go-live? It sets handle time and concurrency.
2. #8: What is the 0.34 contacts per transaction based on, and what low and high
would you put on it? It drives the CPT step (+10 FTE).
Departure lead
3. #8: Can the 0.31 be split by migrating country, same twelve months?
cc: modeler
```
## Tracking
Every question lives on the workbook's Questions sheet, one row each: Q#, the grid # it closes, To
(the row's owner), the question, why it matters, the date raised, and a status of Open, Asked,
Answered or Closed. A question is Open when written, Asked once sent, Answered when a reply comes
back, and Closed only after the answer has been applied: the grid row updated and a change-log line
written. A question is overdue when its row's date has passed and it is not yet Answered. The
Dashboard counts questions by owner and status, so the send-ready list and the record never drift.
Block 8 — readout-report.md
# Readout and sponsor slides
Two reports generated with code from the uploaded workbook: a Word readout (python-docx) and three
sponsor slides (python-pptx). The visual target is the two example files on the pack page,
`WFM-Departure-Arrival-Readout-Example.docx` and `WFM-Departure-Arrival-Sponsor-Example.pptx`.
## Numbers: recompute, never retype
Read the input cells with openpyxl (`workbook-map.md`): Set the table C3–C18, Grid B–P, Questions
A–K, Change log A–G. Computed cells are empty until a spreadsheet application recalculates the file, so compute
everything with the rules in `register-and-panels.md`:
- **Plan** = baseline (C10) + sum of all central effects. No baseline, no readout: say so.
- **Bridge** steps by Drives, in the stated order.
- **Register** score = |high − low| × weight; top five by score.
- **Range, one at a time** = plan + the most negative low among the top five, to plan + the most
positive high among them: what a single assumption breaking could do.
- **Range, all five together** = plan + the sum of the top five lows, to plan + the sum of their
highs: what happens if every one of them broke the same way. State both, labeled; never combine
them into one figure, and never present either as a probability.
- **What moves it most** = R1: plan + its low to plan + its high.
Every page and slide carries "As of YYYY-MM-DD": the date the user gives, else the date in the
workbook filename, else today, stated as such. Print a number only once it is computed, and keep
the computation in the code so a rerun reproduces it.
## Word readout (3–5 pages)
1. **Headline.** Plan, ranges, what moves it, then the counts. Example: "The plan is 132 FTE
against a departure baseline of 104 (+28). Taken one at a time, the five most uncertain
assumptions move it by −12 to +14 FTE; if all five broke the same way, by −43 to +48. The one to
confirm first is contacts per transaction (R1, −10 / +12, Asserted)."
2. **How the number was built.** The baseline, its value and its source (C10, C11); then the six
approach questions (C13–C18) as a two-column table, question and answer. An empty answer prints
as "Not stated".
3. **Bridge and ranking.** The bridge as a waterfall (baseline, each step, plan) and the tornado of
the top five. A table under each gives the exact figures.
4. **Problems, unknowns and actions.** Every Problem row: characteristic, departure → arrival, FTE effect or
"not sized", owner, date, and the next action: the open question on that row, an action agreed
in the workbook or conversation, or "Action not yet agreed". A Problem with no FTE effect is
still listed. Then every Unknown row with owner, date and "overdue" where the date has passed.
5. **Top five open assumptions.** Rank, characteristic, range, grade, score, owner, and what would
close it: the open question on that row, or else measure (narrow the range) or evidence (raise
the grade).
6. **Open questions by owner.** Every question on the Questions sheet with status Open or Asked,
grouped by its To column, each with its Q#, grid row, status and why it matters.
7. **What changed since the last readout.** Change-log lines dated after the previous readout,
whose date the user gives; if not given, all lines, and say so. A period with no lines is
reported as "No changes logged".
8. **Appendix: the full grid.** Every row with a characteristic, columns #, group, characteristic,
departure, arrival, call, drives, central, low, high, grade, owner, date. Landscape section.
### Example headline figures
| Item | Value |
|---|---|
| Baseline | 104 |
| Bridge | 104 → 112 season → 116 mix → 126 CPT → 132 AHT |
| Plan | 132 |
| Range, one at a time | 120 to 146 (−12 training length; +14 chat usage share) |
| Range, all five together | 89 to 180 (−43 / +48) |
| Top five scores | 17.6 · 14.4 · 13.6 · 9 · 3.2 |
| R1 swing | Contacts per transaction, 122 to 144 |
## Sponsor slides (3, 16:9)
Set `prs.slide_width = Inches(13.333)`, `prs.slide_height = Inches(7.5)` unless a template is used.
Each title is a sentence that states the finding, not a topic.
1. **Outlook and the bridge.** Title such as "Plan 132 FTE against a 104 baseline; contacts per
transaction moves it most". Bridge chart on the left two-thirds; on the right, the change from
baseline, the call counts, the most uncertain assumption with its range, and open questions and
empty mandatory rows.
2. **Why the plan holds, and where it may not.** Title such as "3 problems need action; the plan
rests most on contacts per transaction". Left: every Problem and Watch row (never
truncated; if more than twelve, the Problems first and "+N more in the readout"). Right: the
tornado of the top five, each bar labeled with its grade.
3. **Asks and decisions.** Title such as "13 questions are open and 2 values are not yet held".
Every Unknown row with owner and date; open questions grouped by owner, shortened to one line;
decisions needed from the sponsor (any Problem whose action needs one). Overdue items marked.
## Charts
Draw with matplotlib at 200 dpi and insert the PNG into both files.
- **Bridge**: waterfall. Baseline and plan as full bars; each step floats from the running total,
up or down. Label each bar with its signed value; omit steps whose sum is zero. The axis may start
above zero so that small steps stay visible, provided the axis is labeled "axis from N".
- **Tornado**: one horizontal bar per top-five row, low to the left of zero, high to the right,
ordered R1 at the top. Label with R#, characteristic and grade. Low and high are swings against
the plan, not absolute values.
- Neutral colors; increases and decreases in two distinguishable colors; no 3-D, no gradients.
## Template
If a corporate .docx or .pptx template is uploaded to the project, open it
(`Document("template.docx")`, `Presentation("template.pptx")`), use its styles and layouts, and
remove its sample content before adding pages or slides. Otherwise use a plain layout: default
styles with one sans-serif font and one accent color for headings, page numbers and the as-of date in the footer.
## Self-check before returning files
- Plan equals baseline plus the sum of the bridge steps.
- Top five order and scores match the register rule.
- Every Unknown and Problem row in the workbook appears in the readout.
- Every FTE figure that appears is shown with its range or marked "no range yet".
- Every row in the top five and the appendix shows its grade.
- No person's name appears that the user has not used; owners are roles or initials as given.
Reopen both files with python-docx and python-pptx and read back the headline and the top five to
confirm they match the computation. Return both files with dated names, plus the headline numbers
in the reply.
## What the reports must not do
- **Hide Unknowns.** An Unknown row is shown with its owner and date, however small it looks.
- **Show a single number without its range.** The plan never appears alone.
- **Present Asserted values as Established.** The grade travels with the value everywhere,
including on charts.
- **Smooth the change log.** A reversal is reported as a reversal.
- **Invent actions or owners.** An action not in the workbook or the conversation is written as
"Action not yet agreed".
## Limits
The reports read the workbook; they do not check it. If the conversation contradicts a cell, the
reports use the cell and flag the difference. Neither range is a confidence interval: the one-at-a-time
range understates joint movement, and the all-five range overstates it when the rows are
independent. Rows that move together, such as contacts per transaction and chat share, are why both
are shown.
Usage notes
- The workbook is the state. Upload the current copy at the start of every conversation, and keep the dated copies the project returns; the change log inside the file is the history.
- Proposals before writes. Material from calls is ambiguous, and a proposal table lets the people who were there correct it before it becomes a row.
- The project cannot recalculate the file. The register, panels and one-pager update when the workbook is opened in a spreadsheet application. The project states the expected bridge and ranking in its reply so the two can be compared.
- Formulas use only long-standing functions. The workbook behaves the same in a browser-based spreadsheet, a desktop application and shared editing, and contains no macros.
- The bridge axis starts at zero. A chart axis cannot follow a cell, so small steps on a large baseline look small; the exact figures are in the table beside the chart.
- A full build is a first draft, not a finished grid. It fills only what the material states, cites every value, and turns the rest into questions. Large inputs are processed one source at a time into an evidence table before any row is filled, which keeps a mid-sized model reliable over long material.
- Questions are tracked in the workbook. The send-ready list in a reply is drawn from the Questions sheet, and a question is closed only when its answer has been applied to the grid and logged.
- The report examples are the visual target. The readout and the sponsor slides on this page were generated from the example workbook by the same rules the project follows; a corporate template uploaded to the project replaces their plain layout.
- Drift. The blocks derive from the articles in the Source field. When one of them changes materially, regenerate the affected block and increment the version.
Change history
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-10-06 | First publication. Four reference blocks and a two-file workbook (template and worked example), derived from Departure–Arrival Assumptions Grid, The Assumption Register and The Migration Health Pack. |
| 1.1 | 2026-10-06 | Adds three blocks (the full-build routine, the question bank, the readout and sponsor-slide specification), four modes in Block 1, and the Questions and Dashboard sheets to the workbook; adds a worked readout and sponsor slides as downloads. |
