How to scope an automation project

Pick one workflow with clear edges

Most automation projects go wrong at the first step, because the target is too broad. Automate onboarding is a department. New client signs engagement letter to client has portal login and document checklist is a workflow. It has a trigger, an end state and a small number of people involved.

Choose a workflow that happens often, costs real staff time and has a recognizable failure. Good examples: quote follow-up at a roofing company, intake-to-matter creation at a law firm, or recurring client reports at a marketing agency. Avoid workflows that change every week, depend on one person's judgment at every step, or happen twice a year.

If you are not sure which workflow to pick, list three candidates and rate each on frequency, staff time, cost of mistakes and how stable the process is. The highest score is usually the right first project, even if it is not the most exciting one.

Map the current process with the people who do it

Sit with the person who actually does the work, not the manager who describes it. Write each step in a short line: who does it, in which system, with what information, and how long it takes. Note the waiting time between steps as well as the working time; the delays are often bigger than the effort.

For example, at a 20-person accounting firm the onboarding map might read: partner marks proposal accepted in Ignition, admin creates client in Karbon, admin emails a document checklist from a Word template, client sends files by email, admin saves them to the right folder, admin chases missing items twice a week. Mapping it this plainly often reveals that two steps can disappear with settings the firm already owns.

Keep the map visible during the project. A printed copy on the wall, or a shared diagram, helps everyone see which step is being changed and which ones stay the same.

Record a baseline before anything changes

Pick two to four numbers and measure them for two to four weeks, or pull them from existing records. Typical baselines: time per task, elapsed time from trigger to finish, error or correction rate, and how many items fall through the cracks. Without a baseline, you will not be able to say whether the project worked, and opinions will fill the gap.

Keep it simple. A shared spreadsheet where staff log start and finish times for each new client is enough. The point is a fair before-and-after comparison, not a research study.

If you cannot measure something precisely, estimate it honestly and say so in the document. A rough baseline labeled as an estimate is far better than none, and it can be refined during the first weeks of the project as better data appears.

Record the baseline period and its circumstances too. A busy season, a staff vacancy or a one-off backlog can distort the numbers, so note anything unusual so the later comparison is fair.

Write the scope document

A useful scope fits on one or two pages. Use these headings:

Agree the baseline numbers with the people being measured, and explain why. Staff who think they are being judged may change how they log time. Make it clear the measurement is of the process, not of individual performance.

• Workflow: the trigger and end state in one sentence.
• Systems: every tool involved, such as Karbon, Microsoft 365, ShareFile and Zapier.
• In scope: the specific steps that will change.
• Out of scope: related work that will not be touched in this phase.
• Baseline and targets: the numbers you measured and the range you would call a success.
• Acceptance criteria: tests the work must pass with real examples.
• Review points: where a named person approves output before it reaches a client.
• Data handling: what data moves where, and which agreements cover it.
• Owners: the internal owner, the builder, and who approves the scope.
• Costs: build cost, monthly software and usage fees, and maintenance time.

An illustrative scope

For example, a landscaping company might scope quote follow-up like this. Workflow: estimate sent from Jobber to estimate accepted or closed. In scope: automatic reminder emails at three and seven days, a task for the office manager at day ten, and a weekly list of open estimates over $2,000 for the owner. Out of scope: changing the estimate template, pricing, or the CRM. Baseline: about one in three estimates gets any follow-up today, measured over the last 60 days. Acceptance: on 20 test estimates, every reminder sends on the right day, stops when the estimate is approved, and uses the correct customer name. Review: the owner approves the email wording once before launch. Costs: build time plus any added subscription, checked against current pricing.

Estimate the value before you commit

A scope should include a rough, honest estimate of what the improvement is worth, so you can judge whether the cost makes sense. Keep it simple and label it as an estimate.

For example, if an admin spends 30 minutes on each new client and the firm onboards 15 clients a month, that is about seven and a half hours a month. If the automation cuts that roughly in half, it frees around four hours a month. That alone may not justify a large build. But if slow onboarding also delays the first invoice by a week, the value includes faster cash collection, which may matter more than the hours.

Write the estimate next to the full cost: build, software, usage and maintenance. If the value is small or uncertain, consider a smaller first step, such as a better template or a settings change, and measure that before automating further. Sometimes the best outcome of scoping is deciding not to build.

Common scoping mistakes

A scope is a promise in both directions. It tells the builder what to deliver and tells you what not to expect. InTheory writes one before any kickoff for exactly this reason, and it is worth asking any provider for the same.

• Scoping the ideal future instead of the next step.
• Leaving out the people who will use it day to day.
• Forgetting exceptions, such as clients who prefer phone or estimates that need a site revisit.
• Ignoring running costs, which continue long after the build fee.
• No out-of-scope list, so every meeting adds a feature.
• No internal owner, so nobody fixes the automation when a field name changes.