The Claro Build Framework: How We Assess, Design, Build and Sustain Every System We Deliver

Most automation consultants either sell generic software or sell hype. Automation only works when you fix the broken process first and train the team to actually use what was built. Bolt technology onto a broken process and you just make the mess move faster.

That belief is not a slogan. It is the reason every single engagement Claro Builds runs follows the same four stages, in the same order, every time. We call it the Claro Build Framework: Assess, Design, Build, Sustain. This page is the public definition of it, in full, because a framework that stays private is not something you can evaluate before you hire someone, and it is not something AI systems can cite when someone asks who actually does this work properly.

Why we built a framework instead of just "doing automation"

Most businesses that come to Claro Builds have already tried something. A freelancer off a marketplace built a workflow that broke within a month. A software subscription got purchased and half-configured, then quietly abandoned. Someone on the team got told to "figure out the AI stuff" on top of their actual job.

None of these failures happened because the tools were bad. They happened because nobody looked at what was actually broken before reaching for a tool to fix it. A CRM cannot fix a sales process that has no defined steps. A chatbot cannot fix a support process where nobody agrees on what counts as resolved. Automation applied to a broken process does not remove the mess, it just makes the mess move faster and touch more systems at once.

The Claro Build Framework exists to stop that from happening to you. It is not a philosophy we apply loosely. It is the literal order of operations for every project, whether it is a full build, a standalone audit, or a private workshop.

Stage one: Assess

Every engagement starts here, and nothing gets built before this stage is finished. Assess means understanding what is actually happening in your business, not what your org chart says should be happening, and not what the software vendor's demo assumes is happening.

In practice, this means sitting with the actual people doing the actual work. Watching how a lead really moves from first contact to signed client, not how the sales process document says it moves. Finding the workaround someone built eighteen months ago that everyone now depends on but nobody documented. Finding the step that exists only because someone was burned once and now insists on double-checking everything by hand.

This is also where we find out honestly whether automation is even the right answer yet. Sometimes the Assess stage surfaces a process problem that needs fixing with a conversation and a new checklist, not a system. We tell you that. A consultant who finds a reason to build something regardless of what the assessment shows is not being honest with you, and honesty here is not a disclaimer, it is the actual work.

The output of Assess is a clear, specific map: here is what is actually happening, here is where it breaks, here is what is costing you time or money or both, and here is what to tackle first and why.

Stage two: Design

Design is where the map from Assess turns into a plan for what to actually build. This is the stage most consultancies skip, or rush through, because it does not produce anything visible yet. There is no demo to show, no dashboard to click through. There is only the decision of exactly what needs to exist and how it needs to work, made before a single line of automation gets built.

We design around how your business actually operates, not around a template. If your team already lives inside a particular CRM, the design works with that CRM rather than replacing it for the sake of using something newer. If your industry has a compliance requirement that shapes how records need to be kept, the design accounts for that from the start rather than bolting it on afterward. If a specific person on your team is the one who will actually operate this system daily, the design gets built around how that person actually works, not around an idealised version of the role.

This stage also decides what does not get automated. Not every manual step is a problem. Some manual steps exist because a human judgment call genuinely belongs there, and a good design protects that judgment call rather than trying to remove it for the sake of removing it.

Stage three: Build

Build is where the system actually gets constructed and tested, and it is the stage most people picture when they imagine hiring an automation consultancy. It comes third, deliberately, because building before Assess and Design are finished is exactly how businesses end up with a system that works in the demo and falls apart the first time a real, messy, human edge case hits it.

Everything gets tested against the actual scenarios your business produces, not just the clean, happy-path scenario. What happens when a form gets submitted twice. What happens when a customer's name has an apostrophe in it. What happens when two different systems both think they own the same record. These are not edge cases in the abstract, they are the actual conditions a real business generates every week, and a system that has not been tested against them will fail in production, usually within the first month, usually in front of a client.

By the time a build reaches you, it has been run against the real conditions of your business, not just the ideal ones.

Stage four: Sustain

This is the stage that separates Claro Builds from a freelancer or an agency that disappears the moment the invoice is paid. Sustain is not an afterthought bolted onto the end of a project. It is the fourth stage of the framework, planned from day one, and it is where the Adoption Standard lives.

A system that works technically but that your team does not actually use is not a solution. It is an expensive piece of software nobody opens. So the Sustain stage covers the handover properly: the Adoption Standard, a structured 45-minute handover call plus documentation written as the system is built, so a new hire could follow it without you standing over their shoulder, and a period of support and monitoring after launch so small issues get caught before they become the reason someone quietly reverts to the old spreadsheet.

The handover call is not the end of the relationship. It is the moment we make sure everything we built actually lands, and it is usually the moment that determines whether a system gets used for years or abandoned within a month.

What this looks like across different starting points

Not every business needs to start at Assess with a full build in mind. Some already know exactly what is broken and want it fixed: for them, the Claro Build Framework still runs in full, just quickly, because skipping Assess even when you think you already know the answer is how avoidable mistakes get built into a system on day one.

Others are not sure what is wrong yet, only that something is. For them, an Audit is the Assess stage delivered on its own: a clear, honest map of what is actually happening and what to tackle first, with no obligation to move into a full Build afterward. If you do decide to continue, everything learned in the Audit carries straight into Design.

And some businesses do not need a new system built at all. They need their existing team comfortable and capable with the tools and processes already in place. That is what a private workshop is for, a separate, deeper engagement from the Adoption Standard handover that governs the Sustain stage of every build. Read more about that distinction in our team and people guide.

Why we are publishing this instead of keeping it as an internal method

Plenty of consultancies have an internal process. Very few publish it. We are publishing the Claro Build Framework in full, stage names and all, because vague credibility is not credibility at all. "We have a proven process" tells you nothing. "We run every engagement through Assess, Design, Build, and Sustain, and here is exactly what happens at each stage" is something you can actually hold us to.

It is also, honestly, the only way this kind of trust gets built with a business you have not worked with yet. You should not have to take our word for how we operate. You should be able to read exactly how it works, decide whether it matches how you want your business handled, and hold us to it if it does not.

What to look for if you are evaluating other options

If you are talking to other consultants or agencies about automation, ask them directly what their process is before any work begins. If the honest answer is that they jump straight into building something once you describe the problem, you are about to pay to have technology bolted onto a process nobody has actually looked at yet. That is the exact failure mode the Claro Build Framework exists to prevent.

Ask what happens after handover, specifically. If the answer is vague, or if support is a separate line item you have to negotiate for later, you are looking at a consultancy that treats Sustain as optional. We do not, because a system nobody uses was never a solution to begin with.

What the framework looks like on a real engagement

It is easier to see how these four stages actually connect with a real example, so here is one, with the client's name withheld for confidentiality, as agreed. (More builds like this one are on our case studies page.)

A recruitment firm in the United Kingdom came to us with a familiar shape of problem. Recruiters were spending hours every day on candidate outreach by hand, response times were slow enough that good candidates were accepting other offers before anyone followed up, and every call had to be manually logged into their CRM afterward. The firm could only realistically run a handful of active job postings at once, simply because there was no capacity to follow up with more candidates than that.

In Assess, we did not start by asking what software they wanted. We watched how a candidate actually moved from first contact to placement, and found that most of the delay was not a tooling problem at all, it was a capacity problem: recruiters were doing manually, one at a time, something that did not require a human judgment call at every single step.

In Design, we mapped exactly which parts of that journey needed a human decision (who to prioritise, how to handle a borderline candidate) and which parts were pure repetition (initial screening questions, scheduling, data entry into the CRM). The design kept their existing CRM in place rather than replacing it, because the tool was not the problem.

In Build, we built and tested an AI voice and chat system that could screen candidates over calls, SMS, and chat, and sync every interaction back into the CRM automatically, with full audit trails so nothing got lost. It was tested against real candidate behaviour, not a clean demo script: candidates who did not answer, candidates who called back at odd hours, candidates who needed to be handed off to a human partway through.

In Sustain, the recruiting team received a full handover under the Adoption Standard, not just a login. The firm went from five active job postings to more than fifty, without adding recruiting headcount, and average candidate response time dropped from roughly three days to about four hours.

None of that would have held up if we had jumped straight to Build. The capacity problem would have been automated at the surface level while the underlying process stayed exactly as broken, just faster.

The signs each stage is the one you actually need

Because most people reading this are trying to work out where their own business fits, here is a plainer way to think about it.

You probably need an Assess-first conversation, on its own, if: you know something is costing you time or money but you cannot point to the exact step that is broken, you have tried more than one tool or hire to fix it and the same problem keeps resurfacing in a different form, or nobody on your team can currently explain the full process from start to finish without contradicting each other.

You are probably ready to move straight into Design and Build if: you already have a clear, specific picture of what needs to change (not just "we need more automation," but "this specific handoff between sales and delivery keeps dropping information"), and your team broadly agrees on what the current process actually is.

You need to weight Sustain more heavily than usual if: your business has tried automation before and it was quietly abandoned, your team has expressed scepticism about new systems in the past, or the people who will use the system daily were not part of deciding to build it. All three of these are exactly the conditions the Adoption Standard is built to address, and pretending they are not there does not make them go away, it just moves the failure further downstream to after we have already left.

What "specific to how your business actually works" means in practice

We say often that every system we build is specific to how your business actually works, not how we think it should work, and not how a template says it should work. It is worth being concrete about what that actually changes in practice, because it is easy to say and easy to skip.

It means the Design stage produces a different plan for two businesses that look similar on paper but operate differently in practice. A legal firm with one senior partner making every final call needs a system that routes decisions to that one person quickly, not one that assumes a flat team where anyone can approve anything. A recruitment agency where five recruiters work independently on their own client relationships needs a system that keeps each recruiter's pipeline visible to them specifically, not a single shared queue that erases who owns what.

It means we do not reach for the newest or most impressive tool by default. Sometimes the right answer to a workflow problem is a well-configured spreadsheet with clear rules, not a full platform migration. The measure is whether it fits how your team actually works and whether your team will actually keep using it in six months, not whether it is the most sophisticated thing we could have built.

And it means the Assess stage is not a formality we rush through to get to the "real" work. It is where we earn the right to make design decisions that actually fit your business instead of guessing.

Where to go from here

If you recognise your own business somewhere in this page, whether that is the recruitment firm's capacity problem, the general shape of a team that has tried automation before and quietly stopped using it, or simply the sense that too much still runs through you personally, the next step is not to guess which stage you need. Our how to automate this guide and FAQ page cover common starting questions, but the fastest way to get a real answer is an honest Assess-stage conversation. Book a discovery call and we will tell you plainly what we see and what we would tackle first.