What a Business Process Automation Scoping Sprint Covers

Every CoBuild engagement at Civic Dialog starts the same way: a scoping sprint. It is short, it has a fixed fee, and it ends with a statement of work that has a number in it. You can stop when it ends and keep everything it produced. Most people do not stop, but the option is the point.

This post explains what happens inside those two to four weeks, because "discovery" is a word consultants use to mean almost anything.

Why scope before building

Automation projects fail in two predictable ways. The first is building the wrong thing: automating a process that runs twice a year, or one that is about to change, or one whose real cost was never the hours but the errors. The second is building the right thing on the wrong foundation: a workflow tool that cannot reach the system where the data actually lives, or a build that assumes clean inputs the process never produces.

Both are cheaper to find on a whiteboard than in production. A sprint is the whiteboard, with a deadline.

The shape of the sprint

Week 1: map the process as it actually runs

Not the process as the manual describes it. The one people do. We sit with the people who touch it, watch a few instances end to end, and draw it: every step, every handoff, every system, every place someone re-types something they already typed somewhere else.

The map also records the exceptions. What happens when the field is blank, when the customer replies to the wrong email, when the approver is on vacation. Exceptions are where automation earns or loses its keep.

Week 2: baseline the hours and the cost

We time at least ten real instances of the process and record who did each one. Your finance lead gives us the fully loaded hourly cost of those people. The result is a number you can defend: this process costs the organization this many hours and this many dollars a year, as of this date.

The baseline is the thing most automation projects never have. It is also what makes the monthly ledger possible later. The measurement method is described in its own post.

Week 3: choose the first build

With the map and the baseline in hand, the options get concrete. Usually there are three.

• Automate inside the tools you already pay for. A CRM workflow, a spreadsheet script, a rule in the inbox. Cheapest, fastest, and right more often than people expect.
• Connect two tools that do not talk. The integration nobody sells: your intake form to your practice management system, your ERP to your quoting spreadsheet.
• Build something with its own home. A portal, a multi-tenant platform, an app your customers log into. Right when the workflow is part of what you sell, or when the volume outgrows the tools.

We pick the first build by a simple rule: the highest baseline cost that can be automated with the least risk. Boring, frequent, and rule-based beats clever every time.

Week 4: write the statement of work

The statement of work names the build, the baseline it will be measured against, what "live" means, who tests it and when, what the monthly agreement covers afterward, and the price. If revenue share is part of the deal, because the build is something you will sell, the terms are in the same document.

Nothing in it is a surprise. Everything in it traces back to the map and the baseline.

What you own if you stop here

The process map, the baseline, the option analysis, and a scope you can hand to anyone. Some clients take the map and automate the first step themselves. Some take the scope to their existing IT vendor. That is a fine outcome. The sprint fee bought a decision, and a decision was made.

What a good first build looks like

It runs often, it follows rules a person can write down, it touches data that already lives somewhere accessible, and its failures are visible. Intake and routing. Approval workflows. Recurring reports. Document processing. These are unglamorous, which is why they are still done by hand in most organizations, and why they pay back.

The ambitious build, the one that reshapes how you serve customers, comes second, funded by the first one's ledger.

After the sprint

If you proceed, the build takes weeks, not months, with a working session each week and working software each week. Your point person tests each release on real records. When it goes live, the log starts, and the first ledger arrives at the end of the first full month. From there, if you want it run for you rather than handed over, the Fractional CAIO agreement covers hosting, monitoring, small changes, and the ledger, month to month.

If some of your people want to build alongside us, the sprint is where we agree who, and the build runs the same way with them at the keyboard. And if you have a whole team that should learn this, the cohort runs a version of the sprint for every participant in its first four weeks.

To talk through a process you have in mind, book a call. Thirty minutes is usually enough to know whether a sprint makes sense.