Business process improvement: a step-by-step guide for SMEs

Choose a process with a clear customer outcome

Business process improvement changes how work is done so that a useful outcome becomes more reliable, efficient or easier to manage. The process might run from enquiry to quotation, order to delivery, complaint to resolution or completed work to payment. A clear boundary matters because improving one isolated task can simply move the problem somewhere else.

Choose a process that creates a visible business issue. Look for recurring delays, errors, rework, customer frustration or management intervention. Avoid selecting a project only because a new tool makes the task look easy to automate. The starting question is what the customer or next person needs and why the current process fails to provide it consistently.

For an illustrative installation business, the issue might be repeated visits because technicians arrive without complete job information. The process boundary should include sales handover and preparation, not just the technician's time on site. That wider view creates a better chance of addressing the cause rather than pressuring the final person in the chain to work faster.

Map what actually happens today

Bring together people who perform and receive the work. Trace representative cases through the current process, including normal exceptions. Record inputs, steps, decisions, handoffs and outputs. Include waiting for information, approvals and corrections. These parts are often absent from the official process description but dominate the customer's experience.

ASQ's flowchart guidance recommends involving people who do the work and checking the map against reality. Our process-mapping guide provides a practical way to apply that approach. Start with a readable map and add detail where it explains the problem. You do not need a complicated notation to discover that a job moves between three inboxes without a named owner.

In the installation example, the map may reveal that sales records the customer's requirements in free text, scheduling copies only part of the information and technicians discover missing details on arrival. That does not yet prove which change will work, but it identifies the handoff and information standard that deserve investigation before investing in route-planning or productivity software.

Establish a baseline that includes quality

Choose measures that describe the problem and protect against unintended consequences. For the installation process, these could include first-visit completion, missing-information incidents, repeat visits and total time from order to completion. Separate active working time from elapsed time. A process can use little staff time while leaving the customer waiting for days.

Use a representative period or sample and record its limits. Include difficult cases rather than removing them to make the numbers tidy. If demand varies by service, location or customer type, separate those groups where practical. Otherwise a change in work mix can look like an improvement or deterioration in the process itself.

Check definitions with the team. Does a completed job mean the technical work is finished, the customer has accepted it or the invoice has been raised? These are different points. Retain the baseline and calculation method so the post-change comparison uses the same boundary. A precise definition is often more valuable than another dashboard chart built on inconsistent records.

Investigate causes before choosing a solution

Look for recurring patterns in the failed cases. Which information is missing, where should it originate and who can detect the omission? Ask why the current process allows the issue to continue, but verify each explanation. A chain of plausible “why” answers can still be wrong if it is based only on opinion.

Possible causes in the installation example include an unclear intake form, no required readiness check, incentives that reward booking before scope is confirmed, or a system that hides attachments from technicians. Each suggests a different intervention. Training alone will not fix a permission problem, and a better form will not resolve an approval queue if nobody owns the decision.

Distinguish avoidable variation from necessary flexibility. Some customer requirements genuinely differ and need judgement. The objective is not to force every job into an identical path. Define the standard route for predictable work and a clear exception route for cases that need additional review. This usually produces a more usable process than either unlimited improvisation or excessive bureaucracy.

Design a small change and a fair test

Choose the smallest change that tests the main hypothesis. The installation business might introduce a short readiness checklist, a required handover record and a named person who confirms completeness before scheduling. The pilot could cover one service type so the team can understand the effect without changing the entire operation at once.

Agree what success and failure would look like before starting. Measure first-visit completion alongside preparation time and scheduling delay. If the checklist prevents repeat visits but creates an excessive approval backlog, the design needs adjustment. Also record whether people follow the new process and which steps they find difficult.

Give staff the information, access and practice needed to use the change. Explain why it exists and how exceptions should be handled. The SOP guide helps document the tested method. Do not finalise a detailed procedure before observing the pilot; otherwise the document can make an unproven design feel more settled than the evidence justifies.

Evaluate the whole result and the economics

Compare the pilot with the baseline using similar work and a consistent definition. Explain changes in demand, staffing or customer mix that may affect the result. Look at the distribution as well as the average: a lower average completion time can conceal a group of customers still experiencing very long delays.

Translate operational changes into business value carefully. Fewer repeat visits may reduce travel spending and release technician capacity. The released hours are not automatically a cash saving if payroll stays unchanged. They may support additional work, reduce overtime or improve resilience. Identify which benefit will actually occur and avoid counting the same capacity twice.

Use the operational efficiency calculator to compare the current and proposed process, including review time, adoption and recurring costs. Keep modelled benefits separate from observed results. If the pilot does not support the hypothesis, revise it or stop. A small unsuccessful experiment can be valuable when it prevents a much larger investment in the wrong solution.

Make the improved process dependable

When the evidence supports expansion, assign a process owner and define the operating controls. These may include a readiness check, exception report, quality sample or regular review. Update the SOP, train the people who were outside the pilot and remove conflicting instructions. Decide who can change the process in future and how changes will be communicated.

Review performance after the initial enthusiasm fades. Adoption can decline when workload increases or experienced staff return to shortcuts. Ask whether the process remains practical and whether the measure still reflects the customer's outcome. A recurring failure may reveal a design weakness rather than a need for more reminders.

For your first improvement project, write a one-page charter: problem, process boundary, baseline, hypothesis, proposed test, owner and review date. Add a clear stopping rule if quality or service deteriorates. Activ-8 operations consultancy can help map the work, challenge the diagnosis and support implementation. The aim is a process the team can run reliably, with evidence that the change improves the result people actually need.

Keep a short record of the pilot's exceptions. These often provide the most useful learning for rollout: which cases need a different route, which approvals are genuinely necessary and which information can be removed. A process becomes simpler through this evidence, rather than through deleting controls without understanding why they existed.