What is a business process?
You've probably lived this: a quote goes out with last year's pricing because nobody updated the template, a new hire's first week is spent chasing system access nobody set up in advance, or an invoice sits three weeks in someone's inbox before it gets sent. None of these are one-off accidents. They're a process running exactly the way it always runs, gaps and all, until something forces you to notice.
That's all a business process is: a repeatable sequence of steps with a start, an end, and a series of decisions and handoffs in between, whether or not anyone's ever called it that. Every business runs dozens of these daily:
- A customer enquiry becomes a signed contract
- A completed job becomes a paid invoice
- A new hire's offer letter becomes a fully onboarded employee
- A stocked item becomes a delivered order
Most owners don't think of these as "processes" at all. They're just "how we do things." That informality is fine at a small scale and becomes a real liability as a business grows past the point where one person can hold the whole thing in their head.
What is process improvement?
Process improvement is what happens when you stop treating the gap as normal and start asking why it's there. Not "who forgot this time," but "why does this depend on one person remembering, every single time." It means looking at a process as it actually runs today, identifying where it's slow, error-prone, or unnecessarily complicated, and changing it. It's not a single event; it's a practice of periodically asking "does this still make sense?" as the business, the team, and the tools around it change.
The reason it matters financially is straightforward: every inefficient step is either costing labour time directly, or costing you indirectly through errors, delays, and customer frustration. A process that takes an extra 15 minutes per transaction doesn't feel expensive in the moment. Multiplied across every transaction, every week, for a year, it usually is.
Process improvement vs. workflow optimisation: what's the difference?
If you've ever fixed the paperwork around a problem without fixing the problem itself, you've already bumped into the gap these two terms describe. The terms often get used interchangeably. A useful way to separate them is by scope:
| Process improvement | Workflow optimisation | |
|---|---|---|
| Scope | The process itself: what steps exist, in what order, and why | How the process actually flows through people, systems, and time |
| Typical question | "Should this step even exist?" | "Why does this step take three days when the work itself takes ten minutes?" |
| Typical fix | Remove, merge, or reorder steps | Reduce handoffs, fix approval delays, connect systems |
| When you'd use it | The process itself feels wrong or overbuilt | The process is roughly right, but execution is slow or inconsistent |
In practice, you'll usually do both at once. You can't meaningfully optimise the flow of a process that has unnecessary steps baked into it, and you can't redesign a process without understanding how it currently flows. See how to map a business process for how the two connect in practice.
What does continuous improvement look like for a small business?
"Continuous improvement" carries a lot of manufacturing-floor baggage: Kaizen boards, Six Sigma belts, formal review cadences. None of that is necessary for most SMBs. In practice, continuous improvement for a small business looks like:
- A regular, short check-in (quarterly is usually enough) where you or your team ask "what's the most annoying part of how we do X right now?"
- Treating process changes as reversible experiments, not permanent commitments. Try the change for a month, see if it actually helped.
- Reviewing a process whenever something about the business changes: new hire, new tool, new client type, or a jump in volume. Processes that worked at 5 clients often don't survive 50.
- Capturing the "why" behind a change, not just the new steps, so the next person doesn't quietly revert it because they don't understand the reasoning.
The goal isn't a formal improvement programme. It's making "how we do this" something that gets questioned occasionally, instead of calcifying the moment it's first figured out.
How to improve a business process: a practical approach for SMEs
You don't need a certification to do this well. A simple, repeatable approach:
- Map it as it actually happens. Not the version in the employee handbook; the version that actually ran the last three times. See the workflow mapping guide.
- Find where it sticks. Where does work sit waiting? Where does the same information get typed into more than one place? See how to find process bottlenecks.
- Ask why each step exists. For every step, ask what would break if you removed it. If the honest answer is "nothing," that's a candidate to cut.
- Redesign before you touch any software. Simplify the process itself first. See how to redesign a business process.
- Decide what's worth automating (only after the process itself is as simple as it can reasonably be).
- Set a date to review it again. Processes drift. A six- or twelve-month check-in catches that before it becomes a habit nobody questions.
This is a compressed version of the usual sequence (map, diagnose, redesign, and only then automate), scaled down to something one person can run in an afternoon for a single process.
A simple way to find the real cause, not just the symptom
Step 3 above, asking why each step exists, is easy to stop too early on. A well-known technique for going deeper is to keep asking "why" until the answer stops being another symptom and starts being something you can actually fix, usually five rounds or so, though the exact number doesn't matter:
An invoice went out late. Why? The approver was away. Why does one person's absence stop it? Because only they're authorised to approve. Why only them? Nobody ever set up a backup. Why not? It never came up until it mattered.
The real fix there is a backup approver, not a reminder to check email while on leave. The first answer is almost always a symptom; the useful one is usually two or three "whys" further down.