Most people who enquire about automation have been burned by a software project before. Not a catastrophic one. A normal one: it took longer than expected, it cost more than expected, and the thing that arrived solved a slightly different problem than the one they described in the first meeting.
So the useful thing is not a pitch. It is a plain account of what happens, in what order, and where the decisions sit.
Four steps: audit, map, build, handoff. The first two exist to make sure the third one is worth doing, and the fourth exists to make sure you are not dependent on us afterwards.
Here is what each one actually involves.
Step one: audit
The audit answers one question. Where does the repetitive work actually live?
Not where you think it lives. Where it lives. Those are different, and the gap is the whole reason this step exists. Every business has a story it tells about its own bottlenecks, and that story is usually about the loudest problem rather than the most expensive one.
What this looks like in practice is following real work through the business end to end. One client from first enquiry to first invoice. One matter from open to close. Not a workshop where people describe the process from memory, an actual trace of what happened to an actual piece of work.
Two things reliably come out of this:
- A count nobody expected. The number of systems a single client's details get typed into. The number of times a person checks something manually because they do not trust the automatic version.
- A different bottleneck than the stated one. The thing that was described as the problem in the first conversation is often a symptom of something one step upstream.
The audit is deliberately cheap and deliberately early, because its most valuable possible outcome is discovering that you do not need the project. That happens. It is a good result, and it is a lot cheaper to find here than in month three.
Step two: map
The map answers the second question. What should run itself, and what should still land on your desk?
This is the step that gets skipped in most software projects, and it is the one that determines whether you end up with a system you trust.
Every task in the process gets sorted into one of two piles. Things that are mechanical, repetitive, and have a right answer: those can run unattended. Things that involve judgment, a relationship, money above a threshold, or an exception: those get routed to a person, with the context needed to decide already assembled.
The sorting is done with you, not for you, because the line sits in a different place in every business. One firm is comfortable with automatic scheduling for existing clients and wants every new client call booked by a human. Another is the reverse. Neither is wrong. Both need to be stated out loud before anything gets built.
What the map protects you from
The failure mode this prevents is the one that makes people distrust automation permanently: a system that quietly did something consequential without asking.
Once a task is on the "still lands on your desk" side of the map, that is a commitment in the build. It is not a setting that drifts. An automation that touches money, or a client relationship, or an irreversible change, stops and waits for a person. Everything mechanical runs without interrupting anyone, because there is no reason to ask permission to do something with one right answer.
At the end of the map you have a document that says, in plain language, what the system will do on its own and what it will bring to you. That document is what gets priced. Which means the number comes before the work, not after.
Step three: build
The build is the part people imagine is the whole project. It is usually the most predictable part, precisely because of the two steps in front of it.
The system gets built around the answers from the map, not around a template. In practice that means the shape of the thing follows how the business already works, rather than requiring the business to reorganise itself around a piece of software. There is a version of this work that involves telling a firm to change its process to match the tool. That is a legitimate approach and it is not this one.
Work is shown in progress rather than revealed at the end. The point is not ceremony, it is that the cheapest moment to discover a misunderstanding is before the thing depending on it is built.
Step four: handoff
At the end, you get the logins, the data, and the accounts. All of it, in your name.
This one is worth stating plainly because it is the step where the industry tends to be vague. The systems are yours. The data is yours and it is exportable. The accounts are registered to your business, not to us, which means you can hand them to somebody else, or bring the work in house, or leave it running untouched.
Support afterwards is available. It is optional and it is never required to keep the system working. A system that stops functioning when the person who built it stops being paid is not a handoff, it is a subscription with extra steps.
The two places a project should be allowed to stop
Worth naming these, because a process with no exits is a sales funnel rather than a method.
| After | The question | Stopping here is a good outcome when |
|---|---|---|
| Audit | Is there enough repetitive work to be worth automating? | The real bottleneck turns out to be a hiring or pricing decision, not a systems one |
| Map | Is the scoped number worth the benefit? | The honest estimate is higher than the problem costs you today |
Both of those are cheap stops, and both happen before the expensive step. That ordering is not an accident. It is the entire reason the first two steps exist as separate stages rather than as a paragraph inside a proposal.
What to take away
If you are evaluating anyone to do this kind of work, three questions are worth asking, regardless of who you ask them of:
- Ask what happens before the build. If the answer moves straight to building, the discovery cost has not been removed, it has been moved into the build where it is more expensive.
- Ask where the line is between automatic and approved. A good answer names specific tasks on each side. A vague answer means the line will get drawn later by whoever is writing the code that day.
- Ask what you own at the end. Logins, data, and accounts, in your name, is a clear answer. Anything less specific is worth pressing on.
Four steps, no surprises. The AI does the busywork. You still make the calls.