Stuart Totterdell
Technical Director
If you have never commissioned an automation project, you probably do not know what to expect. And that uncertainty is one of the biggest reasons businesses either delay the decision or get burned by the wrong partner.
So let me demystify it. Here is what a good automation project actually looks like - from scoping to delivery - in a mid-market business. No inflated timelines. No hidden complexity. Just the reality of what happens when this work is done properly.
Scope: small and specific
A good automation project does not try to automate the entire business. It targets a single process or a tightly related cluster of processes.
The scope should be expressible in one sentence: "We are applying business automation to the client onboarding workflow from signed contract to first delivery milestone." Or: "We are automating the monthly financial reconciliation between the ERP and the finance system." Or: "We are building an automated supplier management workflow that replaces the current spreadsheet-and-email process."
If the scope cannot be described in a single, clear sentence, it is too broad. Narrow it. The most successful automation projects are the ones that do one thing completely, rather than five things partially.
Timeline: weeks, not months
A well-scoped automation project in a mid-market business should take between four and eight weeks from kickoff to operational delivery. Not four to eight months. Weeks.
Here is how that time typically breaks down:
Week one: discovery and mapping. Sit with the people who run the process. Map every step. Document the data sources, the systems involved, the manual handoffs, the rules, and the exceptions. Agree on what success looks like - specific, measurable outcomes.
Weeks two and three: design and build. Design the automated workflow. Build the data and systems integration between systems. Configure the automation logic - triggers, rules, data transformations, exception handling. This is the technical delivery phase.
Week four: test and refine. Run the automated workflow alongside the existing manual process. Compare the outputs. Catch edge cases. Adjust the rules. Get the team comfortable with the new way of working.
Weeks five to six: go live and handover. Switch to the automated workflow. Monitor closely. Fix anything that surfaces in real operation. Hand over the documentation and training to the team that will own it going forward.
If a partner is quoting you six months for a single process automation, either the scope is too large or the approach is wrong. Push back.
Team: small, senior, embedded
A good automation project does not require a large team. It requires a small team of experienced people who understand both the technology and the operation.
On the delivery side, you typically need two to three people: someone who understands process design and can map the workflow properly, someone who can handle the development and build of the integrations and automation logic, and someone who can manage the project and keep it on track.
On the client side, you need one operational sponsor - a person with authority and knowledge who can make decisions quickly - and access to the people who actually run the process day to day.
That is it. No steering committee. No programme board. No twelve-person delivery team billing hours. If the project needs more than five people in total, it is probably over-scoped.
Cost: proportionate and transparent
Automation projects should be priced against the value they deliver, and the cost should be transparent from the start.
For a typical single-process automation in a mid-market business, you are looking at a fixed-price engagement in the range of thousands to low tens of thousands of pounds - not hundreds of thousands. The exact figure depends on the complexity of the process, the number of systems involved, and the state of the underlying data.
A good partner will give you a fixed price after the discovery phase. If someone cannot tell you what a project will cost until they are halfway through it, that is a warning sign.
The return on investment should be measurable within the first month of operation. If the process was consuming twenty hours per week of manual work and the automation reduces that to two, you can calculate the ROI on day one. Good automation projects pay for themselves within months, not years.
Deliverables: working systems, not documents
At the end of a good automation project, you should have:
A working automated workflow that is live and processing real data in your business. Not a prototype. Not a demo. A production system that your team uses every day.
Documentation that explains how the workflow works, what the rules are, where the data comes from, and how to handle exceptions. This should be practical - not a hundred-page technical specification, but a clear guide that a competent person can follow.
Measurable results. Specific, before-and-after metrics that show what changed. Hours saved. Errors reduced. Cycle time shortened. These are not estimates - they are measurements taken from real operation.
A handover. The team that owns the process should understand how the automation works, what they need to monitor, and who to contact if something needs adjusting. You should not be dependent on the delivery partner for ongoing operation.
What bad looks like (so you can spot it)
A bad automation project looks like this: a long discovery phase that produces a detailed report but no working system. A scope that keeps expanding because the foundations were not assessed upfront. A prototype that works on clean data but breaks on real data. A team that bills by the hour with no fixed price and no clear end date. A deliverable that requires ongoing support from the partner to function.
If any of these sound familiar, or if any of them describe what you are being offered, proceed with caution.
What to demand from a partner
When you are evaluating an automation partner, ask five things:
What is the fixed scope, and can you describe it in one sentence? What is the fixed price? What is the timeline, in weeks? What specific metrics will be different after delivery? And what does handover look like - will my team own this, or will I need you forever?
Good partners will answer all five clearly and confidently. They will not hedge. They will not say "it depends" to every question. They will not propose a discovery phase before they can give you a price.
Automation is not complicated when it is scoped properly and delivered by people who have done it before. The mystery around it is manufactured - usually by partners who benefit from that mystery.
Now you know what good looks like. Demand it.


