What Happens in an Operations Assessment: A Walkthrough

If you have never worked with an operations consultancy before, the word "assessment" probably sounds vague. You might picture a stranger walking around your office with a clipboard, or a long questionnaire that ends in a slide deck nobody reads. Neither is close to what actually happens.

An operations assessment, what we call the Assess stage of the Claro Build Framework, is the first and most important part of any engagement. It is where we work out what is actually happening inside your business, as opposed to what everyone assumes is happening. Skip this step, or rush it, and you end up automating a broken process. That just makes the mess move faster.

Here is what the Assess stage looks like in practice, stage by stage, for a typical engagement.

Step one: the initial conversation and scoping

The first conversation is not a sales pitch. It is us asking questions and listening. What does a normal week look like for you and your team? Where do things go wrong most often? What have you already tried to fix, and why did it not stick?

We are also scoping the size of the problem. A business with five people and one messy onboarding process needs a different depth of assessment to a business with forty people across three departments, each with its own workaround. This conversation tells us roughly where to start looking, not what the answer will be. We do not diagnose anything in this first call. We are too early for that.

Step two: watching how work actually happens

This is the part most business owners do not expect, and it is usually the most revealing. We sit with the people doing the work and watch it happen, in real time, rather than relying on a description of it.

Almost every business has two versions of its own process: the version described in a slide deck or an onboarding document, and the version that actually happens on a Tuesday afternoon when someone is behind on three other things. The gap between those two versions is usually where the money and time are being lost.

We might watch how a new client enquiry actually moves from a form submission to a signed contract. We might watch how a job gets scheduled, rescheduled, and invoiced. We are not there to judge anyone's technique. We are there to see where a task takes four steps because a tool does not talk to another tool, or where someone keeps a private spreadsheet because the official system does not do what they need it to do.

Step three: talking to the people who do the work daily

Shadowing tells us what happens. Interviews tell us why, and what it costs the person doing it. We talk to the people who actually run the process day to day, not only the owner or the manager.

These conversations tend to surface things that never make it into a management meeting. The admin person who re-enters the same client details into three different systems every single day. The technician who has stopped using the booking software because it is faster to text the office directly. The account manager who keeps a mental list of which clients need a manual follow-up because the automated one does not trigger correctly.

People closest to the work usually know exactly where it breaks. They are rarely asked. Part of this step is simply asking, and taking the answer seriously.

This is also where we start to understand the people side of any future build. A system that ignores how a team actually prefers to communicate, or what they have already tried and abandoned, will struggle at the adoption stage no matter how well it is built. Read more on this in our piece on getting a team to actually use a new system.

Step four: identifying the two or three problems that matter most

By this point we usually have a long list of things that are not working well. A long list is not useful on its own. Most businesses we meet already sense that something is wrong in several places. What they need is a clear answer to a harder question: of everything that is broken, what is actually worth fixing first?

We weigh each problem against a few consistent questions. How much time or money does this cost every week, not once but repeatedly? How many people does it affect? Is it a process problem, a training problem, or a tooling problem, because each of those needs a different kind of fix? Would solving it create a foundation for the next fix, or is it a dead end on its own?

This step usually narrows a long list down to two or three problems worth solving first. Not because the other issues do not matter, but because trying to fix everything at once tends to fix nothing well. A business with limited time and budget gets further by solving the highest-value problem properly than by spreading effort across ten smaller ones.

Step five: the output, a prioritised and honest map

The Assess stage ends with a document, not a slide show and not a vague summary. It lays out what we observed, what the people doing the work told us, where the process breaks down, and which two or three problems we recommend tackling first and why.

It is deliberately honest, including about anything we cannot help with, or anything that turns out to be a smaller issue than the client assumed. An assessment that only ever confirms what the client already believed is not worth the time it took. The map should tell you something you did not already know, or confirm what you suspected with enough detail to act on it.

From here, if the client chooses to continue, this map becomes the input for the Design stage, where we work out exactly what needs to be built and how. You can read more about what happens after assessment in our piece on how automation actually gets built once a process is understood.

How long does an assessment take?

We get asked this before every engagement, and we understand why. Business owners want a number so they can plan around it. We do not quote a fixed timeline before we have actually looked, because the honest answer depends on how complex the operation is.

A single process in a five-person business might take considerably less time to assess than three interconnected processes across a forty-person team with several departments and legacy systems that do not talk to each other. Giving the same estimate to both would mean either overcharging the smaller business or underdelivering for the larger one. We would rather scope it properly during the initial conversation and give you a real estimate than a marketing number that does not hold up once we start looking.

What we can say is that the length of the assessment is not a measure of how broken your business is. Some quick assessments turn up a very costly problem. Some longer ones confirm that most of the operation is sound and only one piece needs attention.

Why this stage cannot be skipped

It is tempting to want to jump straight to the exciting part, new software, automated workflows, a shiny dashboard. But every system we have seen fail after being built has failed for the same reason: it automated a process nobody had properly examined first.

The Assess stage takes the guesswork out of what gets built next. It replaces assumptions with evidence gathered from watching the work and listening to the people who do it. That is the entire point of doing it properly, and it is why we treat it as its own distinct stage rather than a quick call before the real work begins.

If you want to see how this plays out across different industries, our case studies walk through completed engagements from Assess through to Sustain. And if you have questions about how an assessment applies to your specific business, our FAQ covers the questions we hear most often.

If you are looking at your own operations and suspect something is costing you more time or money than it should, but you are not sure exactly where, that uncertainty is precisely what an assessment is for.