Connecting two apps is not hard. Plenty of people can do it, and the price range for apparently identical work is wide enough to be confusing.
What you’re actually buying is judgement about what to build, and that’s much harder to assess from a quote. These are the questions that tell you what you’re dealing with, and what good answers sound like.
”What would you recommend I don’t automate?”
Ask this first. It’s the most revealing question on the list.
Some of what you described almost certainly isn’t worth automating. It runs four times a year, or the rules change constantly, or it needs judgement at every step. Someone who’s done this work knows that and will say so.
A provider who agrees that everything you mentioned is a great candidate is selling. That’s not automatically disqualifying, but you’re now the one responsible for scoping, and you’re paying them for scoping.
Good answer: picks something out of your own list and explains why it’s a poor fit.
”What does discovery involve, and what do I get?”
Discovery is where the process gets mapped, the decision rules get extracted, and success gets defined. Skipping it is why automation projects fail, and it’s the first thing cut when a quote is being sharpened.
You should get something tangible. A process map, a written set of rules, an agreed measure. Something that stays useful even if you never build anything.
Warning sign: a quote with no discovery at all. That’s a quote priced on the happy path, and the exceptions will arrive later as variations.
”What happens when it breaks?”
Not if. Automations sit between systems you don’t control, and those systems change their interfaces, their formats and their rules without asking you.
The question behind the question is whether they’ve thought about failure at all. What happens when the workflow fails at 2am? Does anyone find out? Does it retry, stop, or quietly skip the record?
Silent failure is the worst outcome, and it’s common. A workflow that stops running and tells nobody looks exactly like a workflow with nothing to do.
Good answer: describes monitoring, alerting and what a failed run looks like from your side.
”What are the ongoing costs, and what changes them?”
Two parts: platform subscriptions and per-use charges. Both are usually modest, and both should be stated before you commit.
The follow-up matters more: what happens if my volume doubles? Some pricing models scale gently and some scale sharply, and the difference only shows up once you’re successful enough to care.
Warning sign: vagueness. Anyone who’s run these before knows the numbers.
”Who maintains this, and on what basis?”
Every automation needs an owner. If it’s you, you need documentation and access. If it’s them, you need to know what that costs and what response time you’re getting.
The failure mode here isn’t dramatic. It’s a build handed over cleanly, working well, and then eight months later something changes, nobody’s clearly responsible, and it quietly stops being used.
Good answer: names the arrangement plainly, whether that’s a support retainer, an hourly basis, or handover with documentation.
”Whose accounts is this built in?”
Underasked and occasionally expensive.
If workflows live in the provider’s platform account, under their subscription, with credentials you’ve never seen, you have a lock-in problem you won’t discover until you try to leave.
Build in your accounts where possible. Get access. Get documentation. This is normal and reasonable to ask for, and the answer tells you a lot about how they see the relationship.
”Can you show me something that went wrong?”
Everyone has a portfolio of successes. Fewer will talk about the project that overran, the automation that got abandoned, or the thing they’d build differently now.
You’re not looking for confession. You’re checking whether they’ve been doing this long enough to have scars, and whether they’re honest about them. Someone who’s genuinely delivered a body of work has stories about the ones that didn’t land, and being told one is a good sign.
What matters less than you’d think
Platform allegiance. Whether someone prefers n8n, Make or Zapier says little. The right tool depends on your volume, your complexity and who maintains it. Strong opinions unconnected to those three are a preference, not expertise.
Whether they’re local. Almost all of this work happens remotely. Local can help for on-site discovery in a hands-on business, but it’s a convenience rather than a requirement.
How impressive the demo is. Demos run the happy path. Ask what happens when the customer replies with an attachment instead of text, or the address is wrong, or the payment is short. That’s where the actual engineering lives.
The underlying test
Everything above reduces to one thing: do they care more about your process or their tooling?
The work that lasts comes from understanding what you actually do, including the parts that are messy and undocumented and vary by who’s on. The tooling is the easy half, and it’s the half that gets talked about because it’s concrete and demonstrable.
If someone spends the first conversation asking about your business rather than describing their stack, that’s the signal worth weighing most.
Happy to be assessed on exactly these questions. If you’re weighing up options, tell me what you’re trying to fix and I’ll tell you what I’d want to understand before quoting, whether or not you end up working with me.
Frequently asked questions
What should I look for in an automation consultant?
Someone who asks about your process before talking about tools, tells you what not to automate, is specific about ongoing costs and maintenance, and can explain what happens when a workflow fails. Platform expertise matters less than whether they understand the work you're automating.
How much should automation consulting cost?
Enough to include discovery. The cheapest quotes usually assume your process is already understood, which is rarely true, so the difference reappears later as rework. Ask for discovery, build and ongoing costs separately, and be sceptical of anyone who won't break them out.
Should I hire a freelancer or an agency?
Either can work. What matters more is continuity: who fixes this in eight months when a connected tool changes its interface. A freelancer with a clear support arrangement beats an agency where your build gets handed to whoever's free, and the reverse is equally true.
Who owns the automation I pay for?
You should, and it's worth settling in writing before work starts. Ask whether workflows are built in your accounts, whether you get access and documentation, and what happens if you part ways. Automations built inside a provider's account with no handover are a genuine lock-in risk.
What are the warning signs of a bad automation provider?
Quoting before understanding the process, agreeing that everything you mentioned is a great candidate, vagueness about running costs, no answer on maintenance, and demos that only ever show the happy path. Any one is worth a follow-up question; several together is a pattern.
Wondering what this would look like in your business? A short chat is usually enough to tell.
Let’s chat