The Questions to Ask Before You Hire Any Automation Consultant

Hiring an automation consultant is usually a decision made under pressure. A process is breaking, a team is drowning in admin, or a founder has decided this is the year the business stops running on spreadsheets and group chats. Under that pressure, it is easy to hire the most confident pitch instead of the most honest one.

Confidence is cheap. What separates a good automation consultant from a mediocre one shows up in how they answer a small set of specific questions, not in how polished their deck is. This list works whether you ever speak to Claro Builds or not. Use it on anyone.

What is your process before any work begins?

Ask this first, before you talk about tools, timelines, or price. A consultant who answers with a list of software they install has skipped the part of the job that actually matters. A consultant who answers with a process, some version of assessing what is broken, designing a fix, building it, and setting up how it gets sustained after launch, has a method they can defend on a bad day, not just a good one.

A vague answer here usually means the diagnosis and the sale are the same conversation. That is how businesses end up with software bolted onto a process nobody fixed first, which tends to make the mess move faster rather than disappear. Our own version of this is the Claro Build Framework, covered in more detail on the frameworks page, but the point is not which named framework a consultant uses. The point is that they have one, and can walk you through it without reaching for a slide.

What happens after handover, specifically?

This is the question most sales conversations gloss over. Ask exactly what happens once the system is built and working. Is documentation written as part of the build, or promised as a follow-up once things settle down? Is there a structured handover call, or an email with login details and a wave goodbye?

Then ask a second, separate question: is training for the wider team included, or is that a different conversation with a different invoice? These are not the same thing. A proper handover means the people who will run the system day to day understand what was built and why, with documentation they can actually use when the consultant is no longer answering calls. Team-wide training, where a whole department is brought up to speed on new ways of working, is a bigger undertaking and reasonably sits as its own scope. What matters is that the consultant tells you which one you are getting, and does not let the two blur together. You can read more on how we structure this on the FAQ page.

A vague answer here, something like "we'll sort that out at the end," usually means it has not been planned at all. Documentation and handover written as an afterthought are rarely as accurate as documentation written while the system is being built.

Can you show examples of past work, and what changed because of it?

Ask for specifics, not testimonials. A testimonial says a client was happy. A case study says what the process looked like before, what was built, and what measurably changed afterwards: hours saved per week, fewer errors, faster turnaround, a task that used to need three people now needing one. If a consultant cannot point to outcomes like this, either they have not been doing the work long enough to have them, or they have not tracked whether their work actually changed anything.

A vague answer, heavy on feature lists and light on outcomes, tells you the consultant measures success by what got installed, not by what got fixed. You can see how we document this on our case studies page.

What happens if the assessment shows automation isn't the right fit?

This question tends to catch people out, because most consultants are selling builds, and a build they talk you out of is revenue they do not make. Ask it anyway. A consultant worth hiring will have a real answer: sometimes the process itself is the problem, and no amount of software fixes a workflow that was never agreed on in the first place. Sometimes the fix is retraining a role, not automating it. Sometimes the honest recommendation is to wait, because the business is not stable enough yet for automation to hold.

If every assessment a consultant has ever done concludes that yes, you need what they are selling, that is not a good sign. It suggests the diagnosis is designed to arrive at the sale, not the other way around. Related reading on how to tell the difference between a process problem and a technology gap lives on our operations and systems pillar.

Who owns the system and its documentation once it's built?

This is an ownership question, not a technical one, and it matters more than most people realise before they sign anything. Ask who holds the admin logins once the project ends. Ask whether the documentation belongs to your business outright, in a format your own team can open and edit, or whether it lives inside the consultant's own tools and templates.

A consultant who is confident in their work has no reason to make themselves hard to replace. A vague or evasive answer here, anything that keeps critical access or knowledge sitting with the consultant rather than the business, is worth pausing on. The system was built for you. It should be usable, editable, and fully understood by your team without permission from anyone else.

What is the plan for the weeks immediately after launch?

Launch day is rarely where things go wrong. The weeks after are where they go wrong, once the excitement has faded and the team is back to normal workload with a new system layered on top. Ask what support looks like in that specific window. Is there a defined check-in point? Does the consultant expect to hear from you only if something breaks, or do they proactively check that the system is being used the way it was designed to be used?

A vague answer, something like "we're always available if you need us," without a defined structure, usually means there isn't one. Adoption is where builds succeed or quietly fail, and the businesses that get the most out of automation are the ones whose consultant planned for that period rather than treating it as an afterthought once the invoice was paid. This is closely tied to how teams actually take up new systems, which we cover in more depth on our team and people pillar.

None of these questions are complicated, and none of them require you to understand the technology being proposed. They require a consultant to be specific about process, handover, evidence, honesty, ownership, and follow-through. A confident answer is not the same as a good one. Ask for the specifics, and judge the answer on whether it holds up under a second question, not just the first.

If you would rather put these questions to us directly, we would welcome that. We would rather earn the work by answering clearly than by sounding polished.