What a Systems Review Should Actually Cover

A business that has already been through a proper operations audit and had systems built is in a different position from one that has never looked at its operations at all. It does not need to start again from zero. What it needs, on a regular basis, is a systems review, and that is a distinct exercise with a distinct purpose.

Confusing the two leads to two different mistakes. Some businesses never revisit their systems after the initial build, and slowly drift out of fit with a process nobody re-examined. Others treat every check-in as though it requires a full audit from scratch, which wastes time re-covering ground that has not actually changed.

How a systems review differs from an operations audit

An operations audit, the Assess stage of the Claro Build Framework, starts from the assumption that little or nothing has been properly mapped yet. It is comprehensive by design, because it has to be. Our piece on what an operations audit actually is covers that process in full.

A systems review starts from the opposite assumption: the business already has systems in place, built for a specific version of the business at a specific point in time. The review's job is to check whether that version still matches reality, not to rebuild the map from nothing. If you are trying to work out which one your business actually needs right now, our piece on audit versus full rebuild walks through that specific decision.

What a proper systems review should actually examine

Whether the business has changed shape since the systems were built

Headcount, client volume, service lines, and geography all shift over time. A system designed for a five-person team handling a handful of active clients a month can quietly become the wrong shape for a team three times that size, long before anyone notices it happening. The review should start by asking what has changed about the business, not just what has changed about the software.

Where workarounds have crept back in

Even a well-built system accumulates small manual patches over time, a spreadsheet someone keeps on the side, a step someone does by hand because the automated version does not quite handle a new exception. Individually these look harmless. Together they are early signs of what we call operations debt, and a review is the moment to catch them before they become permanent fixtures.

Whether the team is actually still using what was built the way it was designed

A system can be technically functional and still quietly abandoned in practice, with the team routing around it because a step no longer fits how they work. This is one of the most common findings in a systems review, and one of the easiest to miss if the review only checks whether the software is still running rather than whether people are still using it properly.

New tools that have been added since the last review

Teams add software between formal reviews, usually to solve an immediate problem, without checking whether it duplicates or conflicts with what already exists. A review is the point to check for overlap, before a business ends up paying for, and manually reconciling between, several tools that are quietly doing the same job.

Whether the handoffs between systems and people still hold up

Systems rarely fail at the centre. They fail at the edges, where one system or person hands work to another. A review should trace those handoff points specifically, not just check that each individual system still functions on its own.

Whether the original assumptions behind the design still hold

Every system is built on a set of assumptions about the business at the time: how many clients pass through it in a typical month, how many people need access, which exceptions were common enough to design for and which were rare enough to leave as manual cases. A review should surface those original assumptions explicitly and check them against the business today. An assumption that was reasonable at the time a system was built can become the exact reason it no longer fits, without the system itself having changed at all.

Who should actually run the review

A systems review can be run internally, and for a stable business making only small changes, that is often enough. The limitation is that the people running the review are usually the same people who have adapted around its weaknesses every day, which makes it genuinely difficult for them to notice what has quietly stopped working. An outside reviewer brings no such blind spot. They can ask a straightforward question, such as why a particular step exists at all, without already knowing the informal answer that has become accepted wisdom inside the team.

How often a business actually needs one

There is no fixed calendar answer that fits every business, because the right interval depends on how quickly the business is changing rather than on the passage of time itself. A business that has added headcount, launched a new service line, or changed a core vendor should treat that change as the trigger for a review, rather than waiting for an anniversary date. A more stable business can go longer between reviews without losing much. The signal worth watching for is any of the signs a business has outgrown its current systems, which is a strong indicator that a review is overdue rather than merely due.

A reasonable default for most growing service businesses is to treat a review as due at least once a year, and to bring it forward whenever a major change happens in between. Waiting much longer than that risks letting several small drifts accumulate at once, which makes the eventual review larger and more time-consuming than it needed to be, and makes it harder to tell which change caused which problem once several have happened together.

What a review should produce

A systems review that is worth doing ends with a specific, prioritised list: what still fits, what needs adjusting, and what has genuinely broken down and needs rebuilding rather than patching. It should not end with a vague sense that things are mostly fine, because that conclusion usually means the review was not specific enough to be useful.

Where the review surfaces something that needs rebuilding rather than adjusting, that work goes back through Design and Build, with Sustain closing the loop the same way it did on the original engagement. A systems review is not a one-time inspection. Treated properly, it is the ongoing maintenance that keeps a built system honest to the business it actually serves, rather than the business it served when the system was first designed.

Businesses that skip this maintenance are not making a single bad decision, they are making the same decision repeatedly by default: to leave a system running unchecked for however long nobody happens to raise a concern about it. That default is rarely a deliberate choice. It is simply what happens when there is no scheduled point at which anyone is asked to look. Building a review into the calendar, even loosely, replaces that default with an actual decision, made on purpose, at a time the business can prepare for rather than react to.