Business process improvement
We map the process as it actually happens, find where the time and the mistakes go, and redesign it with the people who do the work. You can implement the result yourself, hand it to another vendor, or ask us to build it. All three are normal endings.
Most people do not call a business process consultant because they want a process reviewed. They call because something specific has gone wrong often enough to stop being bad luck.
Jobs get invoiced weeks late. The same information is typed into three systems. An approval sits with someone for four days and nobody can see it sitting there. A job goes out wrong and everyone can name the step where it went wrong, but nobody can explain why that step keeps failing. Growth makes all of it louder — a process that just about held together at forty jobs a month falls apart at eighty.
The usual next move is to go looking for software, because software is the thing you can buy. Sometimes that is right. Often the process itself is the problem, and buying a system to run a broken process gets you a faster broken process and a subscription.
So we start with the work. Not the org chart, not the procedure manual, and not a product demo.
Three different jobs
They get sold as one bundle, which is how businesses end up automating a process nobody ever examined.
Establishing what actually happens today, step by step, including the spreadsheet on the side and the phone call that is not in any procedure. A process mapping consultant is not there to tidy up your documentation. The map exists so everyone can look at the same picture and argue about the right thing.
Deciding what should change: which steps go, who owns what, where a check needs to exist and what evidence the business needs to keep. This is where the value is, and it is mostly decisions rather than technology.
Making a machine do the repetitive parts. It is a good answer once the process is settled and worth repeating, and a bad one before that — automation locks in whatever shape the process is in on the day you automate it.
We do that work too, on the business automation side. It is deliberately a different page, because you do not have to buy it from us, or at all, to get value out of the first two.
How an engagement runs
We take the thing that is actually hurting — late invoicing, rework, the approval that always stalls — and trace it back rather than reviewing the whole business. A scoped engagement produces answers you can act on; a full-business review produces a document.
We talk to the people who touch the work, not only the people who manage it: whoever starts the job, whoever it passes through, whoever gets blamed when it goes wrong, and whoever signs it off. Anyone maintaining their own private spreadsheet is telling you where the system does not work.
We draw the current state and put it in front of the people who described it so they can correct it. Most of the useful arguments happen here, and they are much cheaper here than after something has been built.
Duplication, waiting, unclear ownership, rework and control gaps all become visible on the map. We work through what changes with the people who will live with it, which is the difference between a new process and a new procedure nobody follows.
Before anything changes we agree what better looks like and take a baseline: days from job complete to invoice, jobs needing rework, approvals outstanding at week end. A redesign nobody measures is an opinion.
What you get
Written so another vendor, your internal IT or your own team can act on them without us in the room.
Being straight with you
We sell software. That is exactly why we are explicit about when it is the wrong answer.
If two people each believe the other owns an approval, the fix is deciding who owns it. If a step exists because of one incident years ago that has since been designed out, the fix is removing the step. Buying a system to manage that confusion makes the confusion faster.
Where the redesigned process does need a system, the honest answer is often a product that already exists rather than something we would write. Choosing between them is its own piece of work, and it is what independent software selection is for.
Where it can end
Process discovery, mapping and redesign are things you can buy on their own. The engagement can finish at the recommendation, and plenty of them should. What you receive is written to be picked up by someone else — your internal IT, your existing software vendor, another implementer, or your own people making the changes by hand.
If you want us to carry on and build it, we can, and our fee for the process work does not change based on that decision. If you use someone else and the result drifts from what was agreed, we can review the implementation against the redesign and tell you where it diverged.
Real projects, including the parts that took longer than expected.
AAA runs its week off a scheduling board that moves hundreds of thousands of dollars of work around every Thursday, and sometimes has to rebuild it around an emergency within the hour. The board they run now remembers every move, gates the handover to the crews, and carries the same record from quote to site to payroll.
View the project
AAA's salespeople quote, get approval, and hand work to the crews inside one system, where the quote the customer sees, the number the manager approves and the schedule the crews work are the same record.
View the project
Estimating teams spend most of their working year on jobs they will never win. Impact Plumbing now measures the part of that they can control: how fast a tender gets answered, how long since anyone touched it, and what the company keeps walking away from.
View the projectThis page owns the diagnosis: working out how the work happens now and what should change, whether or not any technology is involved. Once that is settled, removing the repetitive parts is business automation, connecting systems that already exist is systems integration, and getting numbers out of them is reporting and dashboards.
If the redesigned process needs a product you would buy rather than build, that is independent software selection. If you are weighing up where AI belongs in any of it, that is AI advisory. And the full list of what we do is on what we do.
Every business we walk into has two processes running at once. There is the one in the procedure, the induction pack or the quality manual, and there is the one people actually follow. The gap between them is not laziness. It is usually a series of sensible workarounds invented by people solving a real problem in the moment, none of which was ever written back into the procedure.
That gap is where the cost sits. A step that was added to catch one mistake five years ago is still being done by four people every week. A form is filled in twice because the office never trusted the field copy. An approval is chased by phone because nobody can see the queue. None of that appears in the documented process, so none of it gets fixed by rewriting the documented process.
So the first job in any process improvement engagement is not to design anything. It is to establish what actually happens, including the parts nobody would put in writing.
We do that by watching the work and asking the people doing it, in that order. A workshop with managers produces the idealised version very quickly, and it is worth having, but on its own it will send you off to solve a problem that does not exist.
The people who need to be in the room are the ones who touch the work:
Management need to be involved, but a process designed only by people who will not run it daily is the single most common reason a change does not stick. Everyone has watched a new procedure get announced and then quietly ignored. If the people doing the work help design it, that does not happen, and the design is better as well.
We map what we find as we go, in front of the people we are talking to, so they can correct it while it is still cheap to correct. A map nobody has argued with is not finished.
Once the current state is on the wall, the same handful of problems tend to be visible without needing to look hard:
Duplication. The same information entered more than once, usually because two systems do not talk or because one team does not trust another team's data. It is worth knowing which of those two it is, because the fix is completely different.
Delay. Work sitting in a queue nobody can see. Most of the elapsed time in a business process is waiting, not working, and waiting is invisible until you map it.
Unclear ownership. Steps where two people each believe the other is responsible, or where a job only moves because one specific person happens to notice. Both are fragile in the same way.
Rework. Anything done twice because it was wrong the first time. Rework is expensive and it is nearly always caused by a missing check much earlier in the process, not by the person who had to redo it.
Control gaps. Places where the business believes something is being verified and no mechanism actually forces it. These are the ones that matter most in construction and trades, because the evidence has to survive an audit years later.
A good number of the problems we find do not need software at all, and we will say so.
If two people believe they own the same approval, the fix is deciding who owns it. If a step exists because of one incident in 2019 that has since been designed out, the fix is deleting the step. If work stalls because it is nobody's job to look at the queue on a Monday, the fix is making it someone's job. Buying a system to manage the confusion just makes the confusion faster and adds a licence fee.
We are a technology business, so we have an obvious incentive to find a technology answer. That is exactly why we are explicit about it: if the recommendation is a policy change, a role change or removing a step, that is what the report will say, and the engagement can end there.
A redesigned process that nobody measures is an opinion. Before anything changes we agree what would count as better and how it will be observed, using numbers the business can already get: elapsed time from job start to invoice, the proportion of jobs that need rework, how many approvals are outstanding at the end of a week, how long the month-end close takes.
Then we take a baseline. That step gets skipped constantly, and without it there is no way to tell an improvement from a good month. The measure should be one the business will keep watching after we have gone, which usually means it must be easy to produce. A metric that requires someone to compile a spreadsheet every Friday will be abandoned within a quarter.
The documents are written to be handed to someone else. That is deliberate, and it is what makes the advice worth paying for.
Your internal IT team, your existing software vendor, another implementer or your own staff can pick up the process maps, the redesign and the requirements and act on them without us. If you would like us to implement it, we can. If you would rather we did not, nothing about the engagement changes, and the fee does not change either.
Where a client does go elsewhere and the result drifts from what was agreed, we can review the implementation against the redesigned process and tell you where it diverged. That is a much smaller piece of work than the redesign itself.
Tell us how the job runs today. We will tell you whether it is a process problem, a systems problem or neither — and you are under no obligation to have us fix it.
