Choosing a Process Automation Company: A Buyer's Checklist

If you've decided to buy process automation rather than build it, the hard part isn't finding companies. It's that four very different kinds of firm all describe themselves the same way, price the work in ways that aren't comparable, and only one of them is right for the size of problem you have.

The four types, in plain terms:

• Global consultancies — process redesign at organizational scale. Excellent at complex, cross-functional, regulated change. Overwhelming for anything smaller.
• Platform implementation partners — certified specialists in one vendor's stack. Deep on that platform, structurally unlikely to tell you a different one fits better.
• Boutique automation firms — 5 to 50 people, platform-agnostic, project-shaped. The right size for most mid-market work and the hardest tier to evaluate.
• Freelancers and small studios — one or two workflows, fast, cheap, and dependent on one person staying reachable.

This is the buyer's side: how to match the tier to the problem, what to fix in the contract before signing, and how to structure the engagement so you're not stuck.

Matching the tier to the problem

That last row is the one to sit with. If you can't name the process, you're not ready to buy. The cheapest way to find out is to instrument one process yourself for two weeks — how often it runs, how long it takes, where it stalls. That data makes you a dramatically better buyer, and it costs nothing but attention.

The five contract terms that actually matter

Most of a proposal is boilerplate. These five decide whether you're buying an asset or a dependency.

1. Where the automations live. In your platform accounts, or theirs? If theirs, ending the relationship means rebuilding everything. This is the single most common way buyers get locked in, and it's usually not mentioned in the proposal at all. Insist on your own tenancy from day one.

2. Who owns the IP. For custom code, "work for hire" language transferring ownership to you should be explicit. Some firms retain rights to reusable components — that can be fine, as long as you know which pieces you'd lose.

3. What happens when a source system changes. Every integration breaks eventually because something upstream changed. Is fixing that in scope, or a new engagement? Get it in writing, with a response time.

4. Documentation as a deliverable, not a courtesy. Named in the contract: process maps, credential inventory, runbooks, and an escalation path. A working automation nobody can explain is a liability the day its author leaves.

5. How you exit. A defined handover: access transfer, a knowledge session, and a period of support afterward. Ask for it at signing, when you have leverage, rather than at the end when you don't.

Pricing models, and what each one rewards

Providers quote differently on purpose. Knowing what a model incentivizes tells you where to watch.

• Time and materials — you pay for hours. Flexible, fair on genuinely unknown scope, and it rewards the provider for taking longer. Cap it.
• Fixed price per workflow — predictable, and it rewards narrow interpretation of scope. Expect change requests, and define "one workflow" precisely before signing.
• Retainer — a monthly block of capacity. Good once you have a real pipeline of work; wasteful before you do.
• Outcome-based — payment tied to a measured result. Rare, appealing, and only workable when the baseline is already instrumented. If you can't currently measure the process, you can't buy this honestly.

Whichever model, get the three-way cost split in writing: their fee, the platform licence, and any model or API usage. Proposals routinely quote only the first. The other two are yours forever, and they're the ones that grow.

Nine questions for the shortlist call

Ask all nine. The pattern of answers is more informative than any single one.

1. Which of these steps are deterministic, and which are model calls?
2. Show me a workflow you built that failed in production. What happened next?
3. Whose accounts will these live in?
4. What's the smallest thing you could put in production in two weeks?
5. What do you do when the source system's API changes?
6. Which platform would you not use for this, and why?
7. What did you talk a client out of automating last year?
8. Who specifically does the work — and are they the people in this meeting?
9. What does handover look like if we part ways in a year?

Question 6 sorts platform partners from agnostic firms honestly. Question 7 is the strongest single signal of production experience — a provider who has never advised against automating something has never seen it go badly. Question 8 catches the pattern where senior people sell and juniors deliver.

Structuring the engagement so it works

Three rules, learned the expensive way by a lot of buyers:

Start with one workflow in production, not a program. A two-week deliverable that runs for real teaches you more about the provider than a six-week discovery phase. It also gives you a natural exit if the fit is wrong.

Insist on a named internal owner. Somebody on your side has to hold context, or you'll be re-buying knowledge you already paid for. This person doesn't need to be technical — they need to be permanent.

Automate the process you have, then improve it. Redesigning and automating simultaneously means when it goes wrong you can't tell which change caused it. Sequence them.

Worth naming a scenario that's become common: the process is already automatable with tools you have, and the provider's real value is that they'll actually do it. That's a legitimate reason to hire — but price it as execution, not transformation. If you want to check whether that's your situation, our rundown of business process automation tools covers what's reachable without a vendor, and AI automation services covers the do-it-yourself path in more detail.

Standards help here too. Processes documented in BPMN are portable between providers and platforms in a way that screenshots and slide decks aren't. Ask for it.

When to skip the vendor

Skip if: you have one or two workflows, both apps are already supported by a mainstream platform, and someone internal has a spare week. Zapier, n8n, and Power Automate genuinely cover a lot of what gets sold as a project — and doing the first one yourself is the best possible preparation for buying the rest.

If the actual blocker is running things rather than choosing them, Taku mirrors an AI workflow someone already got working into your own desktop workspace and runs it there, without the setup step in between. The free app library is a quick way to see whether your process already has a published shape. Taku is in Beta, and the Mac app is available now.

FAQ

What do process automation services include?

Typically discovery, workflow design, building on a platform or in custom code, integration with your systems, testing, and some period of support. What varies most is whether documentation and handover are contractual deliverables or informal favors.

How do I choose between business process automation companies?

Match the tier to your problem size first — freelancer, boutique, platform partner, or consultancy. Then evaluate on production evidence: ask to see a failure and its recovery, and confirm the automations will live in accounts you own.

What should be in the contract?

Account ownership, IP transfer, who fixes breakage when upstream APIs change, documentation as a named deliverable, and a defined exit and handover process.

How much do process automation services cost?

The model matters more than the figure. Get the split between provider fee, platform licence, and usage costs in writing — the last two continue after the engagement ends.

Can I do it without hiring anyone?

Often, if you have one or two workflows on mainstream platforms and someone with a spare week. Doing the first one internally also makes you a much better buyer for the rest.

Key points

• Four tiers of provider exist; matching tier to problem size prevents most bad outcomes.
• If you can't name the process yet, instrument one yourself before buying anything.
• Account ownership and exit terms decide whether you bought an asset or a dependency.
• Get the cost split three ways — provider, platform, usage.
• Ship one workflow to production before committing to a program.