Call Us
.png)
What Good Services can teach us about building better business systems.
There’s a particular kind of business frustration we all recognise.
Ask three people how to complete the same task, and you get three different answers: one has a spreadsheet; another has a shortcut they learnt from Karen; the third confidently tells you, “Oh, we don’t use that system anymore.”
That is usually the point where someone in the leadership team declares: “We need a process for this.”
And they’re probably right… but there’s a catch.
In trying to create consistency, businesses often make one of three mistakes: they write enormous SOPs nobody uses, they make their processes so rigid that they fall apart on contact with real life, or they give responsibility for creating the system to the wrong person, usually the boss, an Ops Manager with seventeen other jobs, or an external consultant (yes, I am infact advising a consultant is the wrong person for this job… more on that below).
The result is usually quite a bit of frustration and not nearly as much systemisation as everyone hoped.
A good friend and business partner of ours, Tommy, recently gave us Lou Downe’s Good Services. It’s a book about service design, not operational business systems, but within about five minutes I was dog-earing pages like a lunatic because so many of the principles apply equally well to the way businesses design their own operations.
The book asks a very practical question: what makes a service genuinely good for the person trying to use it?
That same question should sit at the heart of any good Business System.
So, are you guilty of any of these mistakes?
This is one of the easiest traps to fall into because SOPs are wonderfully tangible: You can see them, name them, number them…put them in folders, add your logo, give them version control if you are feeling especially fancy.
They create the warm sensation that systemisation is occurring. But what is actually occurring is simply document creation.
We have all seen businesses where the SOP library resembles the instruction manual that comes with a new washing machine.
Back to the leaders who said, “We need better systems”. Six months later, 37 procedures sit in SharePoint, three versions of the same checklist, and one spectacular 64-page SOP last updated by Brenda, who left the business in 2024.
The issue is not that SOPs are bad; they can be incredibly useful in fact. The issue is treating the documentation as the outcome.
One of the principles in Good Services is that a service should allow someone to complete the task they came to do. Another is that it should not require prior knowledge simply to navigate it.
That translates beautifully into operational systems. For example, the purpose of building an incident management system is to make sure the right information gets captured, the right people know what is happening, decisions happen quickly enough, risks are managed, and nobody is standing in the kitchen saying, “I thought Sarah dealt with that”. A beautifully formatted SOP on its own will not give you that.
A good business system is much more like a well-designed kitchen than a recipe book: the recipe matters, of course, but where the ingredients live, who is responsible for stocking them, which equipment is available, what happens when something runs out, how people know an order is ready, and who makes the call when the oven decides today is its final day on earth matters more.
Sometimes a good system will have an SOP. Sometimes SOP is useless while a checklist, workflow, dashboard, template or decision tree are just what’s needed.
So instead of asking, “Have we documented the process?”, a better question is: “Could the person responsible reliably achieve the outcome without needing to find the one human being who knows the secret handshake?”
That is a much better test of whether you actually have a system.
This is where businesses often overcorrect.
After living with chaos for long enough, the temptation is to remove every possible variation: Step 1, Step 2, Step 3, absolutely-do-not-deviate-from-Step-4. The process is documented, everyone has been trained, and for a glorious moment it looks like the business has finally been systemised...
Then a client does something unexpected, the software gets updated, or a staff member encounters a situation nobody anticipated. Suddenly the beautiful process doesn't work, and someone throws their hands in the air and says, “See? You can’t systemise our business. Every situation is different.”
But variation isn't evidence that systemisation is impossible. It usually means the system has been designed too narrowly.
One of my favourite principles from Good Services is that good services should be consistent, not uniform. That distinction is gold, particularly in healthcare and human services where, inconveniently, humans have a habit of not behaving like identical units coming off a production line.
Consistency means agreeing on the things that should remain dependable: the outcome we are trying to achieve, the standards that matter, the information we need, who owns what and how important decisions get made. Uniformity is trying to make every person and every situation travel through exactly the same pathway, regardless of what is happening around them.
Good systems need structure, but they also need joints. Think of the difference between a steel beam and a skeleton. A steel beam is strong, but rigid. A skeleton combines strength and structure to allow movement.
Your processes should work the same way. There can be a standard pathway without pretending it will cover every scenario. Good systems include decision points, known exceptions and escalation pathways, and make it clear where people can use judgement rather than forcing them to choose between blindly following the process or abandoning it altogether.
When you next design a system, make sure it won’t break when reality inevitably colours outside the lines.
Another common mistake is deciding that systemisation belongs to whoever has enough authority, spare capacity or enthusiasm to take it on. The founder starts writing SOPs, the Operations Manager gets tasked with “documenting everything”, or an external consultant interviews the team and eventually returns carrying The Sacred Process Manual™.
The problem isn't that these key people shouldn't be involved. After all, leadership should set expectations and boundaries, and external expertise can be enormously useful in helping a team see, design and improve its systems (spoiler: that’s exactly what we do at Via!). Problems do tend to appear when the people doing the work are treated as just passengers in the process.
The person closest to the work knows things that someone sitting three organisational layers above it simply cannot see. They know which fields everyone skips, and why, where the unofficial workaround lives and which step technically exists but hasn't been followed since 2023 because everyone agreed it was pointless.
But involving people in the design is only half of it. Once the system exists, someone needs to own it, and by ownership I don't mean having their name in the “Process Owner” column of a spreadsheet nobody looks at. I mean being responsible for whether the system still works, whether people can use it, whether recurring problems are being noticed and whether it evolves as the business changes.
An external expert can help you design the kitchen, but it’s the person who actually cooks in it who will notice that everyone keeps walking across the room to get the salt - and they should be given the authority and ownership to do something about it.
That is the difference between documenting a process for your team and building a system your team can actually own.
Businesses often approach systemisation as though they are trying to laminate the organisation. Map the process, document it, train everyone, lock it down and admire your beautifully preserved way of working.
Except businesses never stay still long enough to be laminated.
People change, roles shift, customers want different things, regulations evolve, software gets updated, and the team learns better ways of doing things. A process that was perfectly sensible twelve months ago can slowly become the operational equivalent of that drawer in your kitchen full of cables for devices you no longer own. Nobody quite knows why it's still there, but everyone is slightly afraid to throw it away.
This is why the Good Services principle of consistency without uniformity is my favourite in the entire book. A good system needs enough structure that people aren't reinventing the wheel every morning, and enough flexibility to evolve with the business.
Designing for change means deciding how the system itself gets maintained. Who notices when it is no longer working? How does the team raise friction? Who can change it? When should it be reviewed? Those mechanisms are just as much a part of the system as the original process.
Think of your systems less like concrete and more like scaffolding. They should give the business structure, support and safety, while still being adjustable as the thing you're building changes.
When someone doesn't follow a process, our instinct is often to assume the person is the problem. They need more training, another reminder or perhaps a slightly stern Teams message pointing them towards the SOP.
Sometimes that's exactly what is needed. But when people repeatedly create the same workaround, encounter the same exception, skip the same step or ask the same question, it is worth getting curious before getting annoyed.
Like smoke coming from under the door, it’s a signal that the system you've designed and the reality your team is experiencing might have drifted apart.
Sometimes the answer will be training or clearer accountability. Sometimes the technology is creating unnecessary work. Sometimes the process needs to change. And occasionally, the workaround your team invented is better than the official process, and your system needs to catch up with them.
Good systems give your people enough structure to work consistently, enough flexibility to use their judgement, and enough ownership to keep improving how the work gets done.
If your processes are gathering dust, constantly being worked around or falling apart at the first exception, don’t assume systemisation doesn’t work. Get curious about what the friction is trying to tell you.
Take the FREE Systems Scorecard to see where friction is creeping in, and what to focus on first.
