Process Map: requirements checklist¶
The working checklist for a Process Map engagement. Take it into the room.
This page is the template. It improves after every engagement, so it is versioned here rather than copied into a document. The Process Map product record links to this page, and each project uploads its completed instance.
Three pages, three jobs:
| This checklist | What you must come away with |
| Capture form | Where the answers go. Copy it, fill it in, upload it to the project |
| Question bank | Everything worth asking, to draw on. Most engagements use about a third |
Part A capture is one-way
Baseline numbers can only be measured before anything is automated. Miss them and every savings claim afterwards is an estimate against an estimate (OI-007). If a day runs short, cut Part B and keep Part A.
How this is structured¶
| Part | Gather | For every engagement |
|---|---|---|
| A. Findings | Volumes, systems, people, where time goes | Yes |
| B. Product readiness | Technical detail per automation | Only for products you will actually recommend |
Part B is deliberately last. Asking mailbox questions on day one for a product you may not recommend wastes the client's time and yours.
Part A: findings¶
A1. Baseline, and it closes¶
Numbers, not impressions. "A lot" is not a baseline.
| Capture | Feeds |
|---|---|
| Inbound volume per day, by channel | Sizing, and the value model |
| How many need a human response | The addressable portion |
| Current time to first response | The before-state |
| Who handles it, and how long per item | The savings model and its multiplier (OI-009) |
| What currently gets missed or delayed | Often the real sale |
| Rework rate: how often something is redone | The strongest saving, and the least claimed |
Get the multiplier agreed in the room. "We think this takes four minutes each" written down and agreed is what defends the savings figure later. Their number, not ours.
A2. The process, as it actually runs¶
Map what happens, not what the manual says.
| Capture | Why |
|---|---|
| Trigger: what starts the work | Where automation attaches |
| Each step, who does it, how long | The map |
| Every handoff and wait | Waits are usually the biggest loss, and the least visible |
| Decision points, and the rule actually applied | Candidate structured predicates (ADR-0004) |
| Exceptions, and how often they happen | Exception rate decides whether automation is viable at all |
| What happens when the usual person is away | Reveals undocumented dependencies |
Chase the exceptions specifically. A process that is 70% standard and 30% exception is a poor automation candidate however painful it feels, and finding that out here is far cheaper than finding it out mid-build.
A3. Systems¶
| Capture | Why |
|---|---|
| Every system in the process, and its version | Connector scope |
| Which are connected to each other today | The cross-system join is usually the pitch (OI-006) |
| Where data is re-keyed between systems | Direct automation candidates |
| Spreadsheets and shadow systems | Always present, never mentioned unprompted |
| Who administers each system | Whose cooperation the build needs |
| Their own reporting: what exists, what they wish existed | Dashboard scope |
Ask to see the spreadsheets. They are where the real process lives, and nobody volunteers them.
A4. People and approvals¶
| Capture | Why |
|---|---|
| Who would approve automated output | Review app users |
| How quickly they can realistically review | Approval expiry, and the closed_manual rate |
| What happens when that person is unavailable | Fail-closed behaviour |
| Who would resist this, and why | The real delivery risk |
| Their appetite for autonomy, concretely | The autonomy ceiling |
Ask what they would never let a machine do unsupervised. The answer defines the ceiling more usefully than asking what they would allow.
A5. Commercial and constraints¶
| Capture | Why |
|---|---|
| Any compliance obligation on data or retention | Residency tier, retention floor (ADR-0026) |
| Contractual constraints on where data is processed | Inference residency (OI-065) |
| Existing software contracts, and renewal dates | Timing, and displacement opportunities |
| Who signs off spend, and their threshold | Proposal shaping |
| Anything in flight that would collide with a build | Sequencing |
Part B: product readiness¶
Complete only for products you will recommend. Each section is what must be true before that product can be quoted with confidence.
B1. Email triage¶
| Capture | Decides |
|---|---|
| Shared mailbox or personal? | Shared is a product. Personal is a permissions problem |
| Microsoft 365 or Google? | Connector |
| Who else reads and replies to it | Reconciliation, since they may reply first (ADR-0032 §6g) |
| Existing rules, folders and categories | Their implicit taxonomy, already written down for you |
| Walk their last twenty emails and categorise together | The vertical template validated against reality |
| Anything the template does not cover | Their per-client additions (ADR-0005) |
| What "urgent" means to them, concretely | Priority rules |
| Approval surface: review app or mailbox? | Per-tenant mode, one only (ADR-0032 §6h) |
The twenty-email walkthrough is the highest-value hour of the engagement. It validates the taxonomy against reality, surfaces categories you would have missed, and gives you a labelled set for the eval harness. Do it with the person who currently triages, not with the owner.
B2. Any product touching a job or field-service system¶
| Capture | Decides |
|---|---|
| Job system and version | Connector |
| Accounting system | Connector |
| Can they export customers and jobs to file? | Backfill route |
| Do export IDs match the API's IDs? | Whether file backfill works at all |
| Job or reference number format | The pattern is per-client config |
| Roughly how many customers, and open jobs | Backfill duration |
| Rough total historical jobs | Whether backfill is a day or a fortnight |
| API rate limits on their plan | Sync cadence, and backfill schedule |
The ID question is the one that quietly decides the price. If a file export uses different keys from the API, backfilled rows cannot be matched to later updates, and the file route is dead. Confirm it against a real sample rather than accepting an answer.
Backfill is a phase, not a step. Against a 2,000 calls per day cap, thousands of jobs is days of calendar time. Plan it as background work running while the rest is built, rather than discovering it the week before launch.
B3. Document retrieval¶
Only if document_request is expected to be a meaningful share of their volume, which it usually is.
| Capture | Decides |
|---|---|
| Where the last certificate they issued is, shown not described | Everything below. Watch them find it |
| Attached to the job in the system, or filed elsewhere? | Whether retrieval is possible at all |
| If a folder, is it network or local? | Local means unreachable |
| Does the job record have a document type field? | Otherwise a job with a dozen attachments is unpickable |
| Actual file names, seen not described | CoC_J4471.pdf works. scan001.pdf does not |
| Filed by hand, or by something automatic? | Habit-kept conventions break silently |
| Typical attachment count on a finished job | Photos, variations, invoices and certificates, mixed |
Four things must all be true
The document must be in a reachable system, identifiable among the other attachments, reliably linked to the job, and the mail connector must be able to attach files.
The first two fail most often, and either one alone kills it.
document_request is the highest-volume automatable category, and it is nearly worthless without the attachment. "Your certificate is ready, log in and find it" saves nobody anything.
If retrieval is impossible, the fallback is a reply telling the customer it is ready and asking the office to send it. That is a small saving rather than a large one, and it must be priced as the small one.
B4. Any product producing reporting or a dashboard¶
| Capture | Decides |
|---|---|
| Which metrics, named and defined by them | Signed off before the first run (OI-008) |
| What "live" means to them, as a number | Sync cadence (OI-005) |
| Who reads it, and how often | Curated views versus self-serve (OI-030) |
| What their current system already reports | Verify the gap rather than assert it |
After the engagement¶
| Output | Goes to |
|---|---|
| Completed checklist | Uploaded to the project |
| Findings and recommendations | The report, being the paid deliverable |
| Baseline numbers and agreed multiplier | Recorded, because they cannot be recaptured |
| Selected items | A new opportunity and proposal |
| Technical readiness answers | Tenant config at provisioning (configuration reference) |
The report must stand alone
They paid for it, and it has to be worth the money even if they do not proceed. Every number in it should trace to something recorded on the day. A recommendation resting on "we assumed roughly 40 emails a day" is not defensible to someone who paid for the analysis.