Book a Demo

The Process Isn’t Broken – It Was Never Built Properly

by Sep 9, 2025Process Improvement

Some processes don’t break – they just slowly disintegrate.

They start as a quick fix. A form emailed around. A spreadsheet someone made “just for now.” A few manual steps thrown in to help things move faster. No one expects these temporary solutions to last forever, but somehow they do.

Over time, those quick fixes harden into business-as-usual. Before you know it, that same spreadsheet is now a crucial system. That email chain has become an approval workflow. And the process is no longer functional, it’s just habitual.

This is especially common in local government. With stretched resources and constant policy changes, teams are often forced to improvise. A new form gets added to meet a one-off reporting requirement. A manual step is introduced to catch a system quirk. None of these decisions are wrong, they’re just reactive.

But when these workarounds pile up, they don’t just clutter your workflows. They become the workflow. And that’s when the real trouble starts.

When bad becomes normal

The result? Teams stuck in a process that no one really understands, but everyone follows because “that’s how we do it.”

These processes are often slow, confusing, and frustrating – not because someone broke them, but because they were never properly built in the first place.

Across councils in New Zealand and Australia, this is more common than you might think. It’s not a sign of failure — it’s just the reality of how many workflows evolve. And the good news? If something was never properly built, you can rebuild it. But first, you have to recognise the signs.

What “built on the fly” really looks like

It usually starts when there’s no clear owner. The original process designer might have moved on, and now everyone’s just guessing. Three different teams might each have their own version of how it’s supposed to work. Or the process is so heavily dependent on one legacy system that no one dares to update it. Add to that a reliance on email threads, attachments, and the knowledge in people’s heads, and the risk grows.

Here’s what this might look like:

  • No one can find the current version of the process map

  • A step that used to be manual still is – even though it’s no longer necessary

  • Teams are relying on reminders in inboxes instead of automated routing

  • There’s a whole spreadsheet tracking the workflow, but no visibility across teams

  • The person who actually runs the process wasn’t consulted when it was built

Why it happens more often than you think

In public sector teams, the pressure to move quickly is constant. Regulations shift. Funding deadlines loom. A team needs a process now, not in six months. So we build what we can with what we’ve got. That usually means a form here, a spreadsheet there, a few email instructions, and a lot of goodwill.

Technology plays a role too. Many councils are still working with legacy systems that weren’t built for today’s needs. When those systems can’t adapt, people fill the gaps manually. That works – until it doesn’t.

Another reason this happens is that process ownership is often unclear. If no one is responsible for the end-to-end workflow, then there’s no one to raise the red flag when things get messy. Everyone owns a little piece, and no one owns the big picture.

The hidden costs

These Frankenstein workflows can run under the radar for years – until something breaks. And when it does, the cost is real.

  • Productivity drops: Staff spend more time managing the process than doing the actual work

  • Errors increase: Duplicate data entry and manual handovers make mistakes more likely

  • Morale dips: Clunky workflows suggest that inefficiency is just part of the job

  • Compliance risks rise: It’s hard to meet standards when no one knows what the process actually is

So, how do you fix something that was never properly built?

Start by stepping back. Don’t just fix the symptom – interrogate the structure. What is this process actually trying to achieve? Who needs to be involved? What happens when something goes wrong?

Redesign the process from the outcome backward. Think about what success looks like and work in reverse. Strip out the fluff. If a step doesn’t serve a clear purpose, it goes.

Crucially, involve the people who use the process daily. They’ll know where the friction lives, what workarounds have emerged, and which steps exist purely because “they always have.”

Then choose tools that can evolve with you. You don’t need a massive transformation program – just a platform that makes it easy to build, test, and adapt workflows as things change. Look for no-code tools that empower frontline staff to own and improve their own processes.

And finally, assign clear ownership. Every process should have someone responsible for its health. Not just to maintain it, but to continuously ask: Is this still working? Can it be better?

TL;DR

If your team keeps saying “this process is broken,” maybe they’re right. But maybe it was never really built properly to begin with.

That’s not a failure, it’s an opportunity.

Because once you know what’s not working, you can finally build the process your team actually needs.

And when that happens, everything flows better – for your staff, your systems, and your community.