Async Process Handover: Built for the 22:00 Reader
“She cannot ask you anything. She runs the process at 22:00 tonight.”
A handover-doc builder with a simulation ending: ten process elements, six structure cards (ONE-LINER, IF-THEN, WORKED EXAMPLE, FAILURE GALLERY, CONTACT PATH, NONE) priced against a 15-point budget — then the Friday-night test runs minute-by-minute, itemizing every guess your gaps produced.
The Audience
Anyone handing over a process — across teams, timezones, or out the door.
Responsibilities
Element-taxonomy design · structure-matching logic · minute-by-minute simulation — documentation as an empathy test.
The Build
Document design · simulation narrative · scoring logic · AI-assisted drafting (disclosed)
How I used AI in this case
AI drafted handover-document fragments and simulation narrative variants; the element taxonomy, the structure-matching logic and the minute-by-minute scoring were designed by me. Edited, verified and disclosed.
The build itself, not a video about it — open it, make the calls, and read what each one costs.
The Handover — Primary Build
The full builder: ten elements, five structures, Friday-night simulation, debrief
3D night corridor
A Bengaluru office corridor at 22:04 IST in the monsoon. Give each meeting room a structure within the budget and run Friday night: sensor lights follow Priya, rooms that answer light up, and her phone torch finds the gaps. Select a question mark to rebuild that room and replay.
Scene-by-Scene Storyboard & UI Spec
Scene plan: ten elements, five structures, simulation beats, before build. Full branching dialogue, distractor rationales, and visual system tokens.
Why conventional training failed the operational reality
The Friday-night test is merciless because it is realistic. Where the document's structure matches the element's failure mode, the reader proceeds; where it doesn't, she guesses — and the guesses are itemized:
Both failure modes come from the same root: optimizing for writing effort instead of the reader's 22:00.
Core diagnostic finding
In this fictional brief the handover documents were not short; they were undifferentiated. Every element got the same prose, so the conditions that decide whether a run fails (the deadline, the exceptions, the verification gate) read like background. The writer optimised for writing effort, not for a reader who cannot ask.
Documentation as empathy
Illustrative premise: Priya opens the doc. The Amsterdam office closed half an hour ago; nobody there is reachable until Monday.
Design Constraint → Build Rule: The Friday-night test runs minute-by-minute and itemizes every guess your gaps produced — the scoring had to narrate confusion fairly, not punish abstractly.
Five structures, priced honestly
Illustrative premise: elements left unstructured become guesses logged with low confidence
Design Constraint → Build Rule: ONE-LINER, IF-THEN, WORKED EXAMPLE, FAILURE GALLERY, CONTACT PATH, NONE: pricing each against the 15-point budget encodes the real maintenance cost of documentation.
The test must sting precisely
Design premise: a guess the reader makes at 23:00 IST is invisible until next week’s reconciliation, so the replay has to show it where it happens
Design Constraint → Build Rule: Every gap in the doc maps to a specific wrong turn in the simulation — no generic failure messages, only consequences you authored by omission.
Write for the reader who cannot ask you
Performance problem
In this fictional firm, the weekly enrolment process moves to a colleague in Bengaluru who runs it on Friday nights. Previous handovers produced silent errors (sponsored seats in the batch, a missed lock time) that surfaced weeks later as invoice problems.
Learners and context
Process owners in a global learning-administration team who hand work over across time zones, roles or when they leave. Competent in the process, rarely trained in writing for someone else. A 10-minute builder they can redo before a real handover.
Is training the answer? Not on its own
- A weekend duty contact. If nobody can be reached on Friday nights, even a perfect document leaves the reader alone with surprises. Recommended: a named duty coordinator with hours in IST.
- Process design. A batch window that ends at 00:30 IST puts the hardest step at the end of the reader’s evening. Moving the window is a process decision, not a documentation one.
- Template and review. A shared handover template with the six structures, and a five-minute read-through by someone in the receiving time zone before the first run.
Alignment: every objective has practice, evidence, feedback and a route back to the job
| Objective | Practice | Assessment | Feedback | Transfer |
|---|---|---|---|---|
| LO1 Match each element to the structure that fits its failure mode | Ten elements, six cards | Best 2, acceptable 1, otherwise 0 | Per-element explanation in the replay | Handover template with the six structures (proposed) |
| LO2 Prioritise rich structures inside a budget | 15-point budget equal to the best answer’s cost | Over budget fails the run | Budget meter; rich-everywhere costs 30 | “Where are the clicks?” check before writing |
| LO3 State times and conditions so a reader in another zone can act alone | Deadline, exceptions, verification as gates; replay with IST/CET clock | Any of the three guessed = critical | Correct DST arithmetic in the feedback | Read-through by a colleague in the receiving zone (proposed) |
Evidence register: what is real, what is invented
- Fictional premise Vanleeuw & Partners, Priya and the invoice errors.
- Design decision Card costs, the 15-point budget and the 16 / 20 pass mark.
- Illustrative values Clock times are computed, not invented: IST is UTC+5:30 all year; Amsterdam is UTC+1 (CET) or UTC+2 (CEST).
- Not measured Whether documents written after the builder produce fewer errors. Earlier targets on this page (“≥75% pass by second attempt”) were targets, not results.
Measurable Performance Objectives
Three objectives. The earlier LO2 said “five cards” and listed four; the card set is now six and named in full.
Match each process element to the structure that fits how it fails: one-liner, IF-THEN, worked example, failure gallery or contact path.
Evidence in the build: the card per element (2 / 1 / 0), ten elements.
Spend a fixed clarity budget where a cold reader needs it most.
Evidence in the build: the 15-point budget; overspending fails the run.
Write the deadline, the exceptions and the verification step so that a reader in another time zone can act on them alone.
Evidence in the build: the critical-gap rule and the replay clock.
Why This Modality Won (Trade-Off Analysis)
Before committing to the final architecture, we evaluated and rejected lower-transfer alternatives against the workplace constraints:
What every team does. Rejected because the meeting dies with the leaver's last day and the doc survives it — the async reality is that the colleague in Bengaluru executes at 22:00 against the document alone. The simulation reproduces exactly that condition.
Consistent and auditable. Rejected because a fixed template lets writers fill every box with equal weight — the wall-of-text in compliance form. The budget forces the prioritization: deadline logic and exceptions get the rich structures; the glossary gets pointers.
A handover-doc builder with a simulation ending: ten process elements, six structure cards (ONE-LINER, IF-THEN, WORKED EXAMPLE, FAILURE GALLERY, CONTACT PATH, NONE) priced against a 15-point budget — then the Friday-night test runs minute-by-minute, itemizing every guess your gaps produced.
Why a budget
Triage is the skill
Unlimited space produces walls of text. A budget equal to the cost of the best answer means every overspend has to be paid for elsewhere, which is exactly the judgment a good handover needs.
Why a replay
Consequences you authored by omission
The replay shows each gap as a moment where the reader guesses, with a real timestamp. Rebuild-and-replay turns the debrief into a second attempt instead of a score.
Why 3D here
A document is a route
Each element is a room on Priya’s corridor. Dark rooms and question marks sit where she gets stuck, and the budget is visible as how much light the corridor can afford.
Production Sequence & Traceable Artifacts
The stages below show how the artifacts depend on each other. In this fictional case one designer produced all of them.
What would tell us it worked
A proposed plan. Nothing below has been measured.
| Question | Measure / instrument | When | What we would do with the answer |
|---|---|---|---|
| Do writers match structures? | Per-element card choices and replay attempts needed to pass | Pilot with 8 process owners | If most need three or more replays, add a worked example of a good handover |
| Do real handovers improve? | Receiving colleague rates the next real handover: could they run it without asking? (yes / with questions / no) | Next three real handovers | Pair with the template; without it the builder alone is unlikely to change documents |
| Do silent errors drop? | Reconciliation anomalies traced to handover gaps | One quarter | Small numbers; review cases individually rather than as a rate |
Instructional Design Takeaway
“Why this form wins: the problem is writing for someone who cannot ask you, so the solution simulates exactly that reader — every element left NONE or mismatched to its failure mode becomes an itemized guess at 22:04.”
The handover failed the moment the leaver's calendar emptied: documents were either comprehensive walls of text (everything rich, nothing prioritized) or bullets plus 'ask me if unclear'. The proposal was a handover-doc builder with a Friday-night test: ten process elements, five structure cards priced against a clarity budget — then a minute-by-minute simulation of a colleague executing the process at 22:00, well outside Netherlands office hours, who cannot ask you anything.
Transparent Portfolio Scope
Honest limitation: ten fixed elements and a scripted reader. Real handovers involve judgment about what to include at all; the builder trains structure choice once the elements are known.