The scoping doc
Write the two-page scoping doc for an AI pilot — goal, out of scope, data by date, definition of done, dates, signatures — and keep it off page three.
On this page
A scoping doc is the two pages the customer signs before the first line of code, and it is the document the whole pilot is held to. It turns the discovery statements into a goal with a number, lists what will not be built and why, names the data that has to arrive and by when, states how done will be measured, and says who signs. Two pages is a constraint, not a style: the sponsor reads two pages and forwards them unedited, and anything on page three is unread, unsigned, and later deniable.
The two-pager, worked
The claims-triage pilot's doc, section by section, with the words that go in it.
Goal. One sentence with the number from discovery and the mechanism from the workflow map: "Cut median first-triage time from 11 minutes to 7.7 or less (30%) on the floor's 1,200 claims a day, by surfacing the governing policy clauses inside the handler's claim screen." The 30% is the sponsor's; the 11 and the 1,200 are the floor's; the mechanism is yours. A reader who sees only this line knows what is being attempted and what will count as success.
Out of scope. The longest section, and every line on it is something somebody asked for at the kickoff. The route decision stays with the handler for the whole pilot: the tool drafts a route and the handler signs every one. The reason is in the map, and the sentence here says what would bring it back: "unsigned routes revisited for small motor claims at the run gate, after four weeks of assisted use". No chat surface before the week-6 gate, and then only if handlers ask for one after using the in-screen version in the assisted weeks. No carve-out for commercial lines: they run through the tool, count in the floor's median like every other claim, and are reported on their own line every week, with their own gate. No changes to the intake form or the policy administration system. No fraud scoring.
Data needed, by date, from whom. Three rows. The policy set, 340 pages, as text, from the document system owner, by day 3. One week of triage logs with claim id, open, first-search and route-set timestamps, from the claims system owner, by day 5. For 200 past claims stratified by segment (110 motor, 50 property, 40 commercial), two senior handlers' labels, adjudicated by the champion and owned by the claims QA lead, by the end of week 4 — that is the gold set. Each row names a person, because a row that names a team is a row nobody owns.
Definition of done. Five lines, each with a number and a measurer; the next lesson writes them out. In the doc they take ten lines, and they are the section the customer's QA lead reads most carefully, which is why the QA lead signs.
Dates. Eight weeks from the day the first row of log data lands, not from kickoff. Weeks 1–3: data in, gold set labelled, prototype on the one-off export. Week 4: gold set complete; shadow run starts at 100 claims a day — the tool suggests, the handler does not see it, agreement is measured. Weeks 5–6: shadow at 500 claims a day. Weeks 7–8: assisted, for the segments that pass, on two of the four teams — the handler sees the suggestions, time is measured; handover on the Friday of week 8, all four teams from week 9. Two gates are written in: the gold set signed at the end of week 4, and the per-segment shadow agreement reading at the end of week 6, which decides which segments handlers see in week 7.
Who signs. The VP of Claims as sponsor, the Head of Claims Operations as champion and owner of the floor's time, the claims QA lead as owner of the gold set, the claims system owner as provider of the data, you, and your commercial lead. Six names. The person who declines to sign has told you something; the reason is usually in the out-of-scope section, and it is better found in week 0 than in week 5.
Why the sections are in that order
The doc is a narrative, in the sense Working Backwards gives the word: it reads from the goal to the signatures as an argument, and each section depends on the one before. The goal gives the number. Out of scope says what the number will not be reached by, which is where the sponsor's objections surface. Data by date is what the customer has to do, in writing, so the dates that follow are conditional on it. Definition of done says how the number is measured. The dates say when. The signatures say who agreed. Read in order, the customer finds no section that asks them to accept something the earlier sections did not set up.
Block's Flawless Consulting calls this contracting: an explicit exchange of what each side wants and will give. The scoping doc is the written form of it. The customer wants 30% and will give data by day 5 and a QA lead's time; you want the gold set and will give a working tool and a handover. Resistance to the contract shows up as vagueness — "we'll get you the logs when we can" — and the doc's job is to make the vagueness visible by having a date column with nothing in it.
Page three is where pilots die
The mistake, in the form it usually takes. The engineer writes a thorough document: nine pages, with an architecture section, an integration appendix and a risk register. The sponsor reads the first page, skims the second, signs. In week 5 the sponsor asks why the handlers cannot ask the tool questions, and points at page six, where "handler assistant" appears in a component diagram. The engineer points at page two, where "no chat surface before week 6" is written. Both are right, and the engineer loses, because the sponsor never agreed to page two in any sense that matters — they agreed to a document they had not read.
The fix is not a shorter architecture section; it is a separate one. The scoping doc carries decisions the customer makes — goal, scope, data, done, dates, names. The architecture, the integration plan and the risk register are yours, they live in your design doc, and the scoping doc refers to them in one line. Anything that needs the customer's agreement goes on the two pages where they will see it; anything that does not goes elsewhere. The test for a sentence is whether the sponsor could later say "I did not agree to that" — if so, it is on page one or two or it is nowhere.
What the doc does when things slip
The dates are tied to the first row of data for a reason: data is late more often than it is on time, and a doc dated from kickoff makes every slip the engineer's. The sentence that handles it is written in week 0: "dates move day for day with the data rows above". When the logs arrive on day 12 rather than day 5, the shadow run moves a week and the doc already says so; nobody negotiates it in the moment.
The gates do the same for the build. If a segment's week-6 agreement reading is below the line, the doc says what happens — that segment stays in shadow, its retrieval and the prompt are reworked, and its dates move — rather than leaving it to a meeting where the sponsor wants handlers to see something and you want another week. The doc that anticipates the slip is the one that survives it.
In an interview
The case round often ends with "what would the scoping doc say", and the interviewer is listening for six sections with the numbers in them, in order, and for what you leave out. Give the goal line verbatim with its three numbers, then the out-of-scope list with the reason and the return condition for each item, then the data rows with names and dates. Say that the dates run from the first row of data. Say who signs and why the QA lead is on the list.
The mistake that loses points is a goal with no number, or a definition of done the customer did not write. "Improve triage with AI, measured by handler satisfaction" is the sentence the interviewer is waiting to hear so they can ask how week 8 would be scored; the answer that follows is always a survey, and a survey cannot fail.
Check yourself
1. The claims system owner will not commit to a date for the logs. Do you sign the doc with the data row blank?
No, and the blank row is the finding. Without a date the pilot's clock has no start, so every later date is fiction. Take it to the sponsor as a one-line decision: the pilot starts when the logs land, and the logs land when the system owner is given the time to produce them. If the sponsor cannot get a date from their own system owner, you have learned in week 0 what you would otherwise learn in week 3.
2. The sponsor asks for the architecture diagram to be added "so the board can see what they are paying for". Where does it go?
In your design doc, referred to from the scoping doc in one line, and in a separate one-page board summary if the sponsor wants one. The scoping doc gains nothing from the diagram and loses the property that everything on it is something the customer decided. A sponsor who wants to show the board something is asking for the goal line and the definition of done, which fit on a slide.
3. Week 7 request: commercial's week-6 reading was under the line, and the commercial team lead, who has seen motor and property in assisted use, wants the panel switched on for her handlers now. What does the doc let you say?
That commercial already runs through the tool and is reported on its own line, so the team lead's numbers exist and can be shown today; that the gate is per segment with the reason written down — commercial's search step is 15 minutes, 19 a claim, with a different policy structure, so its reading is its own; and that switching it on under its line is a change to the gate, which the six signatories agree to, not a request handled in a meeting. If commercial's next reading clears the line, it goes into assisted use; if not, the request becomes a second-phase line.