Most founders ask what tools a consultant uses and roughly what it will cost. Those are not the wrong questions, but they are not the useful ones either. The useful questions are about what happens after the build: when something breaks, how scope gets controlled, and what support looks like in month three. I have been on the receiving end of those questions, and I notice immediately when someone has been through a bad automation project before. This is what I would ask if I were comparing consultants.
Ask what happens when it breaks
This is the question I wish every new client asked me, and almost none do. Everything automated breaks eventually. An API changes, a login expires, data arrives in a shape nobody planned for. The question is not whether it will happen. The question is who notices, how fast, and what the fallback is while it gets fixed.
A system that fails loudly and falls back to a person is safe. A system that fails quietly is the dangerous one, because the business keeps trusting it after it has stopped working. I have seen this happen, and it is harder to fix than a loud failure because nobody realised the problem was there. If a consultant cannot answer this question clearly, my read is that they have not built many things that have run for long.
A consultant who has actually run things in production can tell you three things before the project starts: their monitoring approach, their expected response time, and what the human fallback is while a fix goes in. If those are not defined upfront, they tend not to appear after the build ends either.
Ask how they handle scope
One of my worst early projects was not technically difficult. The client kept adding requests in the middle of the build, and the launch kept slipping. Nothing was wrong with the requests. The problem was that nothing was in use yet, so every idea felt urgent and nobody could tell which ones actually mattered. I did not have a clear process to handle that at the time, and the client did not know they needed one.
Now I agree on one small first version before building anything else. New requests go on a list for after it is live. Once people are actually using the first version, the list usually shrinks, because real use answers questions that meetings cannot. I learned this by having it go wrong first.
When I am talking to someone comparing consultants, I suggest they ask: how do you prevent scope from growing during the build, and what happens to new ideas that come up mid-project? A consultant who has dealt with this has a direct and specific answer. One who has not will say something vague about staying flexible.
Ask what ongoing support looks like
I prefer monthly engagements to one-off projects, and that preference comes from experience rather than convenience. Automations need looking after. APIs change, logins expire, volumes grow. A system nobody maintains quietly stops working. The first version is also never the last: real use shows what needs to change, usually within weeks of going live.
A monthly engagement lets those changes happen instead of leaving the client with a system tuned for how they worked on day one. One-off project work is where most automation starts to decay. The handover happens, the consultant moves on, and six months later something quietly breaks or the workflow no longer matches how the team actually operates.
I am not saying every consultant needs to offer ongoing support. But a client should know before they sign what the plan is for month two, month six, month twelve. If the answer is that the consultant hands it over and you are on your own from there, that is useful information to have upfront rather than after the build ends. Ask directly and see how specific the answer is.
Ask what the first month after go-live usually looks like
This question reveals whether a consultant has actually watched a team adopt something new, or whether they delivered the build and left. In my experience, a month after something goes live, a few things reliably happen. The team stops doing the repetitive part and spends that time on customers instead. They come back with the next process they want automated, because the first one proved it was possible. They start trusting the numbers, because reports arrive on time and look the same every day, and decisions get faster as a result.
But some staff take longer to adjust than others and need retraining. That is normal, and planning for it is part of the job, not a sign that anything went wrong. A consultant who treats adoption as someone else's problem will not have a good answer here. I ask this question of myself after every go-live, because the answer usually shows me what the next thing to fix is.
A good answer includes the retraining part, not just the wins. If everything in the answer is positive, that is a sign the consultant is describing what they hope happens rather than what they have seen happen.
When I talk to founders who ask all four of these questions carefully, it usually means they have either been through a difficult automation project before or they have thought seriously about what they are buying. Either way, the conversation gets more useful immediately. We are both starting from the same place: an understanding of what it takes to keep an automated system running in production, rather than what it looks like on the day of the demo.
