Before You Automate, Prototype It First
Most automation projects go wrong because assumptions weren't tested before implementation started. Here's how prototyping a process first saves time, money, and avoidable mistakes.
Before You Automate, Prototype It First
Business process automation is one of the most valuable investments a growing business can make. It reduces manual work, removes human error, speeds up operations, and frees your team to focus on things that actually require human judgement.
It's also one of the most common sources of expensive, avoidable waste.
Not because automation doesn't work. It does. But because most businesses automate the wrong thing, in the wrong way, based on assumptions about how their processes work that turn out to be incorrect once implementation starts.
The fix is straightforward: before you automate a process, prototype it first.
Why automation projects go wrong
The businesses that struggle most with automation projects share a common pattern. They identify a process that seems like a good candidate for automation, get a quote from an agency or software vendor, approve the budget, and start implementation, all before anyone has tested whether the process can actually be captured in a digital workflow the way they imagine.
The problems surface during implementation. The process turns out to be more complicated than it looked. Edge cases that weren't considered become blockers. The people who actually do the work day-to-day know things about how it really operates that never made it into the brief. The software needs to connect to systems that don't connect easily. What looked like a straightforward automation becomes a complex, expensive project that takes twice as long and costs significantly more than the original quote.
HM Treasury tells its own departments to assume software projects cost more than the first estimate. Its Green Book guidance on optimism bias sets the upper adjustment for developing software and systems at 200% on capital cost and 54% on duration, and tells appraisers to start at that upper bound rather than work up to it. Process automation projects are no exception.
The root cause in most cases is the same: assumptions that weren't tested before implementation began.
What you're actually testing when you prototype a process
A process automation prototype tests four things:
Can the process be captured digitally? Not every process that looks automatable actually is. Some processes depend on human judgement, contextual knowledge, or physical interactions that can't easily be replicated in software. A prototype surfaces this early, before you've paid an agency to build an automation that can't do what you need it to do.
Do the people who use the process actually engage with the digital version? Automation only works if the people it's designed for use it. A prototype tests whether your team finds the digital version intuitive and whether it fits naturally into how they actually work, not how you think they work.
What are the edge cases? Every process has exceptions: the situations that don't follow the standard flow. A prototype surfaces these before implementation, when they're cheap to accommodate. Discovered during a full build, edge cases are expensive. Discovered after launch, they're operationally disruptive.
Does the automation actually solve the problem? Sometimes the problem a business is trying to solve with automation turns out to have a different root cause than originally identified. A prototype makes this visible before significant budget is committed to a solution to the wrong problem.
What a process automation prototype looks like
A working prototype for a business process is a real, functional digital tool, not a flowchart, not a diagram, not a presentation. The people who currently do the process manually can actually use it to do it digitally.
It's built tightly around the core process being tested. Supporting features, integrations, and edge case handling are deliberately deferred: the prototype tests whether the core concept works, not whether everything is production-ready.
In practice, this might look like:
- A working digital version of an invoicing or approval workflow your team currently handles manually
- A functional intake system that captures and routes customer requests in the way you intend to automate
- A real tool that replicates a data entry or reporting process so you can see how staff actually interact with a digital version
The goal is evidence. Does the process translate to digital? Do people use it as expected? What did you learn that you didn't know before?
The prototype-first approach to automation
The sequence most businesses follow is: identify process → get quotes → approve budget → implement.
The prototype-first sequence is: identify process → prototype it → evaluate evidence → implement with confidence.
The difference in outcome is significant.
You know it works before you pay for it A prototype tells you whether the automation is feasible, whether your team will use it, and whether it solves the actual problem, before you've committed the implementation budget. If there's a fundamental problem with the concept, you find out at prototype cost, not full build cost.
Your brief to the implementation agency is dramatically better Agencies quote based on what you tell them. If what you tell them is based on assumptions about how your process works, the quote is based on those assumptions too. A prototype replaces assumptions with evidence: what actually happened when real people used a real digital version of the process. That produces a brief an agency can actually build to accurately.
Edge cases are documented before implementation starts The prototype surfaces the exceptions and complications that weren't in the original brief. By the time you go to implementation, you know what they are and can address them in the spec rather than discovering them mid-build.
Stakeholder approval is easier Getting budget approved for a full automation build is harder than getting budget approved for a prototype. And a successful prototype makes the case for the full build far more compellingly than a slide deck. It's proof the concept works, not a claim that it will.
What process automation prototyping costs
A working prototype for a business process starts from £750 for a straightforward single-process workflow. More complex processes (those involving multiple steps, different user roles, or data that needs to be structured) typically range from £1,500 to £2,500.
| Process complexity | Prototype cost | Typical automation build | Saving if you avoid one wrong turn |
|---|---|---|---|
| Simple single workflow | £750 – £1,000 | £10,000 – £30,000 | Significant |
| Multi-step process | £1,500 – £2,500 | £25,000 – £60,000 | Very significant |
| Complex multi-role process | £2,500 – £4,000+ | £50,000 – £150,000 | Substantial |
The prototype doesn't need to prevent many problems to pay for itself. If a £1,500 prototype surfaces a fundamental issue with a process you were about to spend £30,000 automating, the return on that £1,500 is considerable.
Not sure what your prototype would cost? Get an instant estimate based on your specific process. Takes about two minutes.
For Northern Ireland businesses: funding the automation
Northern Ireland businesses automating their processes have access to the Digital Transformation Flexible Fund (DTFF): capital grants of £5,000 to £20,000 covering up to 70% of eligible project costs. Process automation is explicitly listed as an eligible investment type.
The prototype fits naturally into this model. Prototype the process first to validate the concept and strengthen your DTFF application. Then use the grant to fund up to 70% of the full automation build.
A business prototyping and then building a £25,000 process automation with DTFF support would contribute around £7,500 of their own money, with the grant covering the rest. The prototype at £1,500 is the investment that makes the application competitive and the build successful.
Check current DTFF call status at nibusinessinfo.co.uk or dtff.co.uk.
Common automation candidates worth prototyping first
Not sure if your process is a good candidate for prototyping? These are the types of processes where a prototype consistently surfaces valuable evidence before implementation:
Approval and sign-off workflows Processes where documents, requests, or decisions move between people for review and approval. Often more complicated in practice than they look on paper. Prototype to understand the real flow before automating it.
Customer intake and routing Processes that capture information from customers or leads and route it to the right person or team. The edge cases (the requests that don't fit the standard categories) are almost always more numerous than expected.
Reporting and data consolidation Processes where information from multiple sources gets compiled into reports or dashboards. The data rarely comes in the consistent format the automation assumes. A prototype surfaces this before integration work begins.
Invoice and payment processing Financial workflows where errors are expensive. A prototype tests the process logic and exception handling before the automation handles real money.
Onboarding and compliance processes Processes with regulatory or compliance implications where getting it wrong has consequences. Prototype to validate the digital version before it goes into production.
After the prototype
A validated automation prototype becomes the foundation for everything that follows.
Partner Match: we connect you with the right development or automation partner for your project. They receive a tested, validated brief and can quote and build accurately from day one.
Guided Build: for businesses that want Bluprint actively involved through the implementation process, ensuring what gets built matches what the prototype validated.
Full Partnership: for larger automation projects or businesses with multiple processes to transform, with Bluprint supporting the complete journey.
The prototype isn't a cost you leave behind. It's the thing that makes the implementation that follows faster, cheaper, and more likely to work.
Ready to prototype your process?
A Bluprint Prototype Sprint delivers a working digital version of your process in five working days, real enough to test with your team, fast enough to do before your next budget conversation.
Talk to Blu about your process →