What to ask a business automation company before you sign anything

The short version

• A business automation company is three different businesses sold under one name: platform licensing, implementation agency work, and bespoke engineering.
• Most processes are slow because of handoffs between systems, not because any single step is slow.
• The exception cases are the project. A price quoted before anyone has read them is a price for the happy path.
• The useful question is what the automation does when it is not confident, not what it does when it is right.
• Automating a process you are about to redesign is the most reliable way to spend the budget twice.

What does a business automation company actually do?

It removes handoffs. Most business processes are not slow because any single step is slow. They are slow because somebody has to read a value in one system, decide something about it, and type it into another, and that person works office hours. A business automation company builds the software that does the reading, the deciding and the typing. The part that takes the time is not the happy path. It is deciding what the system does when the input is not what the rule expected.

Three kinds of work sit under the label. Integration work moves data between systems that were never designed to talk to each other, so a booking in one place becomes an invoice in another. Decision work replaces a judgement a person was making from a document or a message, which is where AI agents earn their keep and also where they fail quietly. Interface work drives software that has no API at all, by operating its screens the way a user would.

Those three have different failure modes, and that matters more than any difference in the brochure. Integrations break loudly when a field changes. Screen automation breaks loudly when a button moves. Decision automation breaks silently, because a wrong classification looks exactly like a right one until somebody downstream notices. A firm worth hiring will tell you which of the three your process needs, and will not pretend the third carries the same kind of risk as the first two.

What are the three kinds of business automation company?

Platform vendors, implementation agencies, and engineering firms. All three rank for the same search term and they are not substitutes. Knowing which one you are talking to tells you what you will own at the end, which is usually the thing nobody asks about until the first renewal.

Platform vendors sell a licence and a builder. You get a mature product, a certification path for your own staff, and a recurring fee that grows with usage. Implementation agencies sell delivery on top of somebody else's platform, often a low code tool, and they tend to be quick to a first result. Engineering firms write the thing against your systems and hand you the code. The first option is strongest when you have many similar processes and an internal team to run them. The third is strongest when the process is specific to your business and a generic tool would have to be bent to fit it.

The uncomfortable middle is the agency that is really a reseller. There is nothing wrong with reselling, but the incentive is to solve your problem inside the tool they already know, and you should price that in. Ask directly which platform the proposal depends on, and what happens to the automation if you stop paying for it. 'We build on best in class tooling' is an answer that avoids the question.

Which type fits which situation?

How should the first project be scoped?

One process, end to end, with its exceptions written down before anybody quotes a price. End to end matters, because automating the middle three steps of a five step process leaves a person stitching the ends together and the saving vanishes into coordination. The exception list matters more. It is the real specification, and it is usually not written anywhere, because the people running the process hold it in their heads.

Scoping before estimating is not a stylistic preference. A statistical analysis of 1,471 IT projects, published in Harvard Business Review in 2011, compared budgeted against actual cost and found an average overrun of 27%. That evidence is old enough to treat as directional rather than current, and the mechanism it points at has not changed: an estimate made before the awkward cases are known is an estimate of the happy path. In automation work, the awkward cases are most of the work.

So ask for the engagement to be split. A short, paid scoping phase that produces three things: a written exception list, a baseline measurement of how long the process takes and how often it goes wrong today, and a number that would mean stopping. Then a build phase priced against that document. If a firm will not sell the first phase on its own, you are being asked to accept an estimate of work neither of you has looked at.

The baseline is the part teams skip and later regret. Without it, the question 'did this work' has no answer, and six months on the automation is defended or attacked on feeling alone. Count the runs, the minutes per run, and the error rate before anything changes.

What should you ask before signing?

• •Which single process will you automate first, and what does it do today when the input is malformed?
• •What does the automation do when it is not confident: stop, escalate, or guess?
• •Who owns the code, the prompts and the credentials when the engagement ends?
• •What is the per-run cost at ten times our current volume?
• •How will we find out it is wrong, without a person checking every run?
• •What is the rollback, and has it been tested on a busy day rather than a quiet one?
• •Which parts of this are licence fees we keep paying, and which parts are ours?
• •What in this process would you tell us not to automate?

What should an automation company tell you not to automate?

Three things: processes you are about to redesign, processes that run a handful of times a month, and processes where a wrong answer is both expensive and hard to notice. A firm that agrees to all three without comment is selling hours.

The first is the most common waste. If finance is moving to a new system next quarter, automating the current one buys a few months of saving and then a rebuild. The second is arithmetic: a task that runs twice a month and takes twenty minutes cannot repay a build, and the honest advice is a checklist and a calendar reminder. The third is a risk question rather than a cost one. Where a wrong output is expensive and invisible, the right design keeps a person in the loop and uses automation to prepare the decision rather than to make it.

There is a fourth, less obvious one. Do not automate a process whose owner does not want it automated, at least not first. The exception knowledge you need lives with that person, and an engagement that starts adversarially produces a specification with holes in it. Start where somebody is relieved.

Is it cheaper to build in-house or hire an automation company?

It depends on whether the process is permanent and central. Hiring makes sense when automation will be a continuing function with a queue of work behind it, because the second and third builds are far cheaper than the first once somebody knows your systems. Buying makes sense for a first build, for a capability you want to stop thinking about, and for the case where you need a result sooner than you could finish a hiring round.

Do the comparison with real numbers rather than a vendor's. In the US, employer-reported wages for software developers, quality assurance analysts and testers are published by the Bureau of Labor Statistics, with a May 2025 reference period, and that is the figure to put next to a quote. Then add what a salary line hides: recruitment, the months before someone is productive in your stack, and the fact that one person cannot be on call alone.

We cannot settle this with evidence from our own work. We hold no case studies, no named clients and no testimonials, so any claim that we did it faster for somebody else would be invented. The argument above is mechanical, and you can check it against your own hiring costs.

How do you check whether companies like yours are really doing this?

Read the national statistics before the vendor blog. Both the EU and the UK run large surveys on business use of AI with their methods published, and those are the right place to find out whether adoption in your size band and sector is normal or early. A number from a national statistical office tells you where you sit. A number from a vendor tells you what the vendor sells.

Eurostat's figures come from the survey on ICT usage and e-commerce in enterprises, conducted by national statistical authorities in the first months of 2025, covering 157,000 of the EU's 1.53 million enterprises with ten or more employees. The UK Office for National Statistics publishes comparable estimates from its Business Insights and Conditions Survey, with wave 159 fielded between 5 and 28 June 2026, 38,637 businesses responding, a 26.7% response rate, and weighted results. Note what the frames leave out: enterprises below ten employees are outside the Eurostat frame, and 'small' there means ten to forty nine employees.

Vendor-commissioned surveys are not useless, they are narrower, and the difference matters when somebody quotes one at you. The Intuit QuickBooks business solutions report, for instance, is an online survey of 630 owners and executives at US businesses with ten to ninety nine employees, fielded through Pollfish audience pools in August 2024, with averages reported as a weighted median. That is a defined and legitimate frame. It is not a national statistical estimate, and a figure from it should not be repeated as though it were one. Ask any firm quoting a statistic at you which of the two kinds they are holding.