A client came to us last year wanting a custom reporting dashboard. They had a clear picture in their head - charts, filters, exportable tables. They'd even done some rough mockups. It looked like a straightforward build.
We spent a week mapping how data actually moved through their business before we opened a code editor. What we found changed everything. The problem wasn't that they lacked a dashboard. The problem was that the data feeding into any dashboard would have been wrong, because the people entering it were following four different conventions with no shared standard. A beautiful dashboard built on top of bad data would have been an expensive way to show inaccurate numbers faster.
We helped them fix the data entry process first. The dashboard came later, simpler and cheaper than originally planned, and it was actually useful on day one.
That's why we always start with a process audit.
What a process audit actually is
The name sounds like a long, expensive consulting engagement. It isn't.
A process audit is a focused, time-limited exercise - typically one to two weeks - built around structured conversations and direct observation. The goal is to understand how work actually moves through the business: who does what, in what order, with what information, and where things break down.
We map the handoffs. We look at where decisions are made and what information those decisions depend on. We ask where work gets stuck, duplicated, or lost. We look at the tools already in use and how they actually get used versus how they were intended to be used.
No lengthy reports. No frameworks for the sake of frameworks. The output is a clear picture of where the real friction is and what intervention would have the most impact.
What we look for
Every business has its own version of the same problems. We're looking for:
Bottlenecks - steps in a process where work piles up because they depend on one person, one tool, or one decision that can't keep pace with the volume coming in.
Manual steps that exist because nobody questioned them - data being copied from one system to another by hand, approvals being done over WhatsApp because there's no proper workflow, reports being assembled from five different spreadsheets every Monday morning.
Duplicated data - customer information in the CRM, in the accounting system, and in a personal spreadsheet, all slightly different, none of them definitively correct.
Decisions being made blind - managers choosing inventory levels, staffing, or pricing without reliable data to base those decisions on, or with data that arrives too late to be useful.
These aren't exotic problems. They show up in almost every business we work with. The question isn't whether they exist - it's which ones are costing the most and which ones software can actually fix.
What the audit changes
The output of a good process audit rarely confirms the original plan. More often, it changes three things.
First, scope. The thing the client asked for is either too big, too small, or aimed at the wrong target. A client who asked for a full inventory management system might discover that 70% of their pain comes from one specific bottleneck that could be addressed with a much simpler tool. Or they discover that the scope needs to expand because the problem they described is downstream of a bigger structural issue.
Second, order. Even when the original vision is basically right, the sequence in which things get built matters. A process audit reveals which parts of a system are blocking everything else and need to be built first. Building in the wrong order means the later parts never get used because the foundation wasn't right.
Third, approach. Sometimes the audit reveals that the problem doesn't require custom software at all. An existing tool, properly configured and actually adopted, would do the job. That's not a comfortable conclusion when a client came in expecting to commission a build - but it's the honest one, and it saves significant money.
Why most agencies skip it
The answer is straightforward: it delays the start of billable development work.
An agency that earns money by building things has a structural incentive to start building as quickly as possible. The discovery phase - understanding the problem before proposing the solution - is a cost centre that delays revenue.
We think that's a false economy, both for us and for clients. Projects built without proper discovery are more likely to require significant rework, scope changes, and difficult conversations later. That's expensive for the client and damaging to the relationship. We'd rather spend two weeks understanding the problem and build the right thing once.
What it costs you if you skip it
The pattern is consistent: a business identifies a pain point, commissions a software solution, the solution gets built, people try to use it, and it turns out the solution doesn't match how work actually flows. The system requires workarounds. People default back to their old habits. The project is declared finished but the problem isn't solved.
Then comes the rebuild conversation. More money, more time, and now a team that's sceptical because they've been through this once already.
We've inherited enough of these situations to know how they happen. Almost every one of them could have been avoided with a serious process audit at the start. Not a checkbox exercise - a real, honest look at how the business works before deciding what to build.
How we approach it
Every project we take on starts with a process audit. It's not optional and it's not decorative. It's the foundation that everything else is built on.
We schedule structured conversations with the people who actually do the work - not just managers describing how they believe processes work, but the people on the ground who know where the real friction is. We observe workflows where possible. We look at what data exists, where it lives, and how reliable it is.
The output is a clear brief: what the real problem is, what we recommend building, in what order, and why. That brief then guides everything - the scope, the timeline, the architecture.
It's not the most exciting phase of a project. But it's the one that determines whether the project succeeds.
If you're considering a software investment and want to start by understanding the problem properly, get in touch.