Business process improvement projects can range from around £500 to £5,000, depending on what needs doing. That is a broad range, so it helps to understand what sits behind the price. Reviewing one awkward process and recommending changes is a different job from redesigning several connected processes, configuring systems and helping a team introduce them.
You may only need to pay for the assessment. If the answer is to remove unnecessary steps, clarify responsibilities or use your existing tools differently, there may be no additional software or external implementation costs. Your team will still need time to make the changes, but improving a process does not automatically mean buying something.
What are you actually paying for?
Before recommending a change, we want to understand what happens now, what you need to happen and the gap between the two. “We want to be more efficient” is a starting point, but we need to get underneath it. Are customers waiting too long? Is information being entered three times? Does everything stop when one particular person is away?
We also need to agree what a good outcome looks like. That might be getting an authorised access request completed without repeatedly copying information, while retaining the right checks and a clear record of approval. Or it could be making sure every enquiry has an owner and a next step, so following up no longer depends on somebody remembering.
You are paying for the time and experience needed to examine the detail, question what is happening and work out a practical way forward with the people involved. The result might be a clearer process, agreed responsibilities and a prioritised set of changes. Putting those changes into practice can be included in the project or treated as a separate stage.
What does that look like in practice?
Take a process for managing access to a shared business hub. Hundreds of organisations use it, with several potential users in each organisation. The hub contains sensitive information, so making sure the right people receive the right access matters.
A request arrives by email with a signed PDF form. One department receives it and enters information into another system to request access. The team responsible for granting access then emails a second team. Before suggesting a solution, we would want to understand what each team does, what they check and why the request needs to pass between them.
Why is there an emailed form as well as a separate system entry? Is the same information being copied? Where is approval recorded? Who needs to know that access has been granted? We would also need to understand how the access team completes its part, rather than assuming it is manual or that a step is unnecessary.
The outcome we want is straightforward: authorised people receive the correct access, the request can be tracked and the necessary approval is recorded. Once that is clear, we can assess whether every step helps achieve it and where there is room to simplify.
Why does each step happen?
One exercise we use is to map the process with good old-fashioned Post-it notes. Give us a clear wall or a big table and we can start getting what happens out of people’s heads. Every activity gets its own note, including the little things people often leave out: downloading an attachment, saving it in a folder, copying information into a spreadsheet or emailing somebody to say it has been done.
It can look like a lot of detail, but those small activities matter when they happen repeatedly. They also help us see the whole process, including the work between the more obvious stages. What looks like “request access” on a flowchart might involve several people, two forms and a fair amount of copying and chasing.
First, we identify the steps needed for a legal or accreditation requirement and move those up a level. We need to understand the requirement properly, because it may specify a check or a record without requiring the exact method currently being used. For everything else, our question is: why? Why do you fill that form in? Why does it go to that person? Why do you keep another copy? Does anybody use the information?
There are often good answers. A step might prevent an error, support a decision or add value for the customer. But sometimes we get to “we’ve always done it that way”, and that deserves a closer look. Perhaps the activity was introduced to solve a problem five years ago, or someone wanted a report they no longer read. The process has moved on, but the old step is still there.
People may be carrying out those activities diligently. They have simply never had the opportunity to question them. Looking at the process together gives us space to do that without treating it as somebody’s mistake.
What happens once we know what is needed?
Once we understand why each step exists, we can decide what to keep, simplify or remove. Then we look at the remaining work. Is the right person doing it? Could it be delegated? Could part of it be automated? Are there exceptions or decisions that still need someone’s attention?
The order matters. There is little benefit in automating a task that does not need to happen. Equally, a check that protects a customer should not disappear simply because it takes time. We need to understand its purpose and find a proportionate way to fulfil it.
Sometimes we finish with fewer Post-it notes and a much clearer process, using the systems the business already has. Other times, the review reveals a genuine need for changes to software, integrations or the way work is allocated. The assessment helps establish which of those is justified.
What makes one project cost more than another?
The price depends on the amount of investigation and implementation involved. A focused process handled by one or two people may be relatively straightforward to review. Work crossing several departments can take longer because we need to understand different responsibilities, examine exceptions and agree changes with everyone affected.
The scope grows further if the project includes cleaning data, configuring software, building integrations, testing, training or supporting a changeover. Those activities should be clear in the proposal, along with what your team will need to contribute. Someone will usually need to answer questions, make decisions and check that the proposed process reflects what the business needs.
That is why it helps to separate assessment, recommendations and implementation when discussing the price. You should know what you will receive, what is included in the fee and whether further work would need a separate agreement.
How do you judge whether it is worth the cost?
Start by looking at the problem in practical terms. How often does the process happen? How much time does it take? Where do delays, mistakes or repeated requests occur? What does the customer experience while the work moves between people? You do not need perfect figures, but following a few real examples can give you a useful starting point.
Then compare the proposed work with the improvement you need. If a review identifies changes you can make internally, that may be enough. If implementation needs outside support, you should have a clearer understanding of what is involved before committing to it.
A sensible process improvement project has a defined problem, an agreed outcome and a scope you can understand. The price follows from that. Sometimes the most useful result is discovering how much of the work you can stop doing.