How to scope your first automation: a written checklist

Scope your first automation by picking the process that runs most often and has the fewest judgement calls, mapping what actually happens today rather than what the process document says, deciding what happens to the exceptions before deciding anything else, and writing down what “working” means in a sentence you could hand to someone else to check. Most first automations fail on the third of those. Almost none fail on the technology.

Here is the checklist we work through in a scoping call. It is worth doing before you talk to anyone, including us — it is also a perfectly good document to take to a different vendor.

1. Choose by frequency times rule-density, not by annoyance

The instinct is to automate the task everyone complains about. The task everyone complains about is usually the one requiring judgement, which is the worst candidate.

Score your candidates on two axes: how often it runs, and how much of it is a rule rather than a decision. Something that runs forty times a day and has one clear right answer each time is worth more automated than something that runs weekly and needs someone to think. Copying a field between two systems is the ideal case. Deciding whether to give a customer a refund is not.

2. Map what happens, not what is supposed to happen

Sit with the person who does the job and write down every step, including the ones that are not in any document — the spreadsheet they keep on the side, the WhatsApp message they send to check something, the thing they do differently on Fridays.

Those undocumented steps are where automations break, and they are invisible from a management view of the process. If a map takes an hour and produces surprises, that hour just saved a rebuild.

3. Decide the exception path first

Before anything else: what happens when the automation cannot complete a run?

There are only three acceptable answers — it retries, it escalates to a named person, or it writes to a queue that someone works. “It fails silently” and “it guesses” are not on the list, and a system that does either will cost more than the manual process it replaced, because errors will surface later and further from their cause.

Deciding this first also tends to change the design. An exception path that a human has to work is a cost, and knowing that cost early sometimes narrows the scope in a good way.

4. Write down what done means

One sentence, concrete enough that someone who was not in the room could check it. Not “invoices are processed faster” but “invoices arriving by email are extracted, matched to a PO, and filed, with anything failing a check appearing in a review queue within five minutes”.

This becomes the acceptance criteria. Without it, acceptance is a conversation about feelings, and every change is a dispute.

5. Count the systems, then count them again

Every system an automation touches is an integration, a credential, and a way for the thing to break when that vendor changes something. Two systems is a fortnight of work. Five is a different project.

If the list is long, the useful question is which two would deliver most of the value on their own. Almost always there is a version of the project that is half the scope and most of the benefit, and that is the one to build first.

6. Decide who owns it afterwards

An automation nobody owns rots. Someone needs to hold the credentials, receive the failure alerts, and be able to change a threshold without calling the agency.

Ask any vendor what handover includes. The answer should involve workflow definitions in your possession, credentials in your vault, a runbook, and a walkthrough. If handover means “you keep paying us to touch it”, you have bought a dependency rather than a system.

If you have worked through this and want it turned into a written scope with a fixed price and a delivery window, describe the workflow — a scoping call is free, and the scope it produces is yours whether or not you build it with us.