Questions to Ask Your Team Before You Automate Part of Their Job

Most business owners plan an automation project backwards. They decide what to build, brief a developer or consultant, wait for the system to be ready, and then call a meeting to announce it to the people who will actually use it. By the time staff hear about the change, the decisions are already made. All that is left for them to do is comply, or quietly work around the parts that do not fit how the job actually works.

There is a better order of operations, and it starts with a conversation, not a build. Before you automate any part of a role, sit down with the people doing that work and ask them about it. Not to get approval for a decision you have already made. To find out what you do not yet know about the job.

Why announcing a finished system fails twice

Handing a team a finished system produces two separate failures, and they compound each other.

The first is a design failure. Whoever built the system, whether that is an external consultant or an internal manager, has never done the job full time. They know what the process looks like on paper, in the workflow document or the old spreadsheet. They do not know where it actually breaks: the client who always emails instead of using the form, the supplier invoice that never matches the template, the step everyone quietly skips because head office added it two years ago for a reason nobody remembers. Staff know all of this. If nobody asks before the system is built, that knowledge never makes it into the design.

The second is an adoption failure. People trust systems they helped shape more than systems handed to them. This is not about ego or wanting credit. A system built without consultation has to prove itself from zero, while a system built with someone's input already carries some of their trust before it goes live. Skip the conversation and you are asking staff to adopt something on faith, from people who did not think their experience of the job was worth asking about.

Fix the order, and both risks fall away at the same time. That is the case for asking first, not the case for asking nicely.

The questions worth asking

These are not meant as a script to read word for word. They are a starting point for a conversation that should feel like a conversation, ideally one on one or in small groups, not a form sent by email.

What part of this task do you find most tedious?

This is the most direct route to finding what is actually worth automating. Staff can usually tell you within seconds which parts of a task feel like real work and which parts feel like friction: retyping the same figures into two systems, chasing the same three people for sign-off, formatting a report nobody reads closely. Automate the friction first. It is normally the highest return for the lowest resistance.

Where does this actually break down, day to day?

Ask this separately from the tedious question, because the answers are different. Tedious is about effort. Breaking down is about failure: the step where errors creep in, the handoff where information gets lost, the exception the documented process was never built to handle. This is where staff know things nobody wrote down, because they solved the problem themselves months ago and never mentioned it.

What would you do with the time this frees up?

This question does two things. It tests whether the automation is solving a capacity problem worth solving, and it starts to answer the question everyone is quietly asking but rarely says out loud: does this mean I am less needed? An answer like "I would finally get to the client follow-ups I never have time for" tells you the business is understaffed for its ambitions, not overstaffed for its workload. That distinction matters, and we come back to it below.

What worries you about this changing?

Ask this directly, and ask it before anyone volunteers the answer unprompted, because most people will not raise a fear like job security on their own. Some worries will be practical: will I still be able to override this when a client asks for something unusual? Some will be about trust in the technology itself: what happens when it gets something wrong? Some will be personal, and harder to say out loud: does the business still need me if this does part of my job? All three deserve a real answer, not reassurance you cannot back up.

What would make you trust a new system enough to rely on it?

This surfaces the conditions for adoption before you have spent money building anything. Some people need to see it handle an edge case correctly before they believe it works. Some need the ability to check its work for the first few weeks. Some need to know a human is still accountable when it gets something wrong. Build those conditions into the rollout rather than discovering them after go-live, when trust is harder to win back.

What have you built to work around the current process?

Ask this last, because it often produces the most useful answer of the whole conversation. Staff build their own shortcuts: a personal spreadsheet, a shared document nobody signed off on, a habit of checking one extra thing before submitting. These workarounds exist because the official process has a gap. Find them before you automate, or you will automate the gap along with everything else.

Being honest about headcount

It would be comfortable to promise that automation never affects headcount, and untrue. Sometimes a task genuinely needs fewer hours once it is automated, and over time that can mean a business hires less than it otherwise would have, or does not replace a role when someone leaves. Staff are usually sharp enough to sense when that promise is empty, and an empty promise costs more trust than an honest answer.

What we can say, from working across 100+ projects and 60+ businesses in 10 industries, is that this outcome is the exception in the size of business Claro Builds works with, not the rule. Small and medium service businesses are usually understaffed for what they are trying to build, not overstaffed for what they currently do. The owner is doing the job of three people. The one skilled operator is the bottleneck for the whole team's output. In that setting, automation tends to free existing people for the higher value work the business has been putting off, the client relationships, the new service line, the actual thinking, rather than replacing them. That is our experience, not a guarantee about every business or every role.

What this looks like in practice

This conversation should happen during the Assess stage of the Claro Build Framework, before Design starts, not after Build finishes. It is a working input to the design, not a courtesy briefing. What staff say in that conversation should visibly change what gets built, and it helps to tell them so afterwards: this part of the system exists because you flagged it.

This is separate from the handover itself. Once a system is built, the handover process follows the Adoption Standard, a structured 45-minute call plus documentation written as the system is built, so the client and key operators know how to run and maintain what was delivered. That governs the handover only. It is not the same as consulting the wider team before the build, and it is not the same as training an entire team to work alongside a new system, which is a separate, deeper engagement altogether.

Consulting the team first does not remove every concern about automation, and it should not be sold that way. What it does is put real information into the design and put real trust into the rollout, both of which are difficult to add back in once the system already exists. See how this plays out across different roles in our case studies, or check the FAQ for common questions about how we scope a project.

If you are weighing up an automation project and want to think through what to ask your own team before committing to anything, book a discovery call with Claro Builds. We will talk through where your process actually breaks, not just where it looks broken on paper, and help you have the conversation with your team before a single line of the build begins.