The problem with hiring someone to automate a process is that you can't evaluate the work until it's done, and by then you've paid. With a website you can see it; with an internal workflow, you can't.
These six questions take twenty minutes on a call and separate people reasonably well. I'm writing them down even though they'd expose me too, the day I answer one badly.
1. "What happens if this fails on a Tuesday at nine in the morning?"
The most revealing of the six.
A bad answer talks about how it won't fail. A good answer describes a procedure: how anyone finds out it failed, who looks at it, what happens meanwhile so work doesn't stop, and how quickly you get a response.
Processes fail.
What distinguishes a supplier isn't promising they won't — it's having written down what happens when they do.
2. "Whose account does this end up living in?"
If the answer is "mine, to keep it simple for you", you have a future problem. The workflow has to live in your tenant, on your licences, with your users.
This isn't distrust: it's that the day you change supplier, or the day the supplier closes, your process has to keep running without depending on anyone. If it's in their account, it doesn't.
3. "What documentation do I get, and can I see it before the final invoice?"
"I'll document everything" means nothing. Ask to see the format.
Useful documentation names things by their exact identifier — this list, this field, this connection — not by description. The difference is that with identifiers someone else can come in behind and find things; with descriptions, they have to guess.
4. "Where are you going to test it?"
If the answer is "on the live system, carefully", say goodbye politely.
A process that's in production with real orders inside it doesn't get touched without somewhere to test first. Building that parallel environment is work that doesn't show in the result and has to be budgeted — and it's exactly what separates a controlled change from an incident.
5. "What are you NOT going to automate here?"
That one's a trap, deliberately.
Every process has exceptions that cost more to automate than to handle by hand, and decisions that should stay human because they carry consequences.
Anyone who says everything can be automated either hasn't looked at the process or is about to sell you more than you need.
A good answer names two or three specific things and explains why they stay out.
6. "Does anything need to be bought?"
Most companies already pay for Microsoft 365, and that covers the tools where most internal workflows get built. When a new licence is genuinely needed, it has to be said before starting, with the price attached.
Watch out for premium licensing too: some Power Automate connectors require a paid per-user plan. That isn't a problem, but it's a recurring cost that belongs in the quote from the start rather than in the third invoice.
A seventh, just in case
"Can you show me something similar you've done, even with the names removed?"
They don't need to show you a client. It's enough that they can describe a real process with its problem, its solution and what went wrong on the way. Anyone who only tells clean success stories either hasn't done many, or isn't telling you the interesting part.
If you're weighing up automating something and want to put these six to me, write to me. My answers are already published on services, so you have them before the call. And if what you want is to place the budget, here's the breakdown.