Choosing an AI automation partner comes down to six questions, and none of them are about the technology. The businesses that end up with software they never use almost always skipped the same steps: they bought a general capability instead of a specific outcome, they never established what the thing would cost to keep running, and nobody agreed what "working" meant before the build started.
This is a guide to avoiding that. It is written from the vendor side, which is a bias worth stating up front, but the failure modes below are ones we have watched happen to businesses before they came to us, and a few we have caused ourselves.
What should I look for in an AI automation partner?
Look for someone who narrows the work before quoting it. Every project that goes badly starts with a scope that sounds exciting and means nothing specific: "AI for our operations", "an agent that handles customer questions", "automate the back office". None of those can be built, tested, or judged, because none of them define what done looks like.
A good partner will push you toward a single workflow that is measurably costing your team hours every week, and will resist starting anywhere else. That is not a lack of ambition. It is the only way to find out whether the approach works on your systems and your data before either side commits real money.
The second thing to look for is someone who will talk you out of work. If you bring three ideas and hear enthusiasm for all three, you are not being evaluated, you are being sold to. Some workflows are not worth automating yet, usually because the volume is too low, the process changes too often, or the underlying system has no way in. A partner who says so is giving you the assessment you are paying for.
The six questions
Ask these before anyone writes code. The answers tell you more than any case study.
1. What exactly are you automating, and how will we know it worked?
You want a specific workflow and a specific measure. "Reduce time spent on policy comparison from three hours to twenty minutes per account" is a scope. "Improve efficiency with AI" is a slogan. If the answer cannot be measured, there is no way to tell success from an expensive demo.
2. What is the ongoing cost, not just the build?
Every AI system has a running cost: hosting, model and API usage, monitoring, and the work of keeping it correct as your process changes. A quote that covers only the build is describing half the commitment. Ask for the monthly figure before you sign, and ask what makes it go up.
3. What happens when the AI is wrong?
This is the question that separates people who have shipped AI systems from people who have demoed them. Models are wrong sometimes. The design question is what the system does about it: whether a human reviews before anything is committed, whether the output is checkable against the source, and whether there is an audit trail if someone later asks why a decision was made. If the answer is that the model is very accurate, that is not an answer.
4. Do my systems actually have a way in?
The single largest variable in cost is whether the software you already run exposes an API. Systems with modern, documented APIs are straightforward. Systems without one need a different and much more expensive approach. Anyone quoting before they have looked at your stack is guessing, and the guess will be revised upward later.
5. Who owns what gets built?
Get this in writing before the build, not at the end. Who owns the code, who owns the data, whose infrastructure it runs on, and what happens if you stop working together. These are cheap questions to answer early and expensive ones to litigate late.
6. What is the smallest version of this we could ship?
If there is no answer, the scope is still too broad. A first project should be small enough to be live in weeks and specific enough to prove or disprove the approach. Everything after that is easier to plan because it is planned against evidence rather than a pitch.
Should I hire a consultant or build it in-house?
Build in-house when the workflow is genuinely core to what you sell and you already have engineers with capacity. The knowledge compounds, and something central to your product should not sit with an outside party.
Hire out when the work is operational rather than differentiating, when you need it live in weeks rather than quarters, or when doing it internally would mean hiring for it. That last case is where the money is usually lost: taking on a permanent salary for what turns out to be eight weeks of work, then finding the person has nothing comparable to do afterwards.
There is a middle path that suits most small businesses. Have it built, insist on owning the code and the data, and keep a support arrangement for the maintenance. You get the speed of hiring out without the dependency of never being able to leave.
What does this cost?
Enough varies by scope that a single number would mislead most people reading this, but the shape should be consistent across any partner worth using: a fixed cost for the build, quoted against a defined scope so it does not drift while the work happens, and a flat monthly fee for keeping it running.
What moves the build number, roughly in order of weight: how many workflows are in scope, whether your systems have usable APIs, how much human judgement the system has to replicate, and whether regulated data is involved. What moves the monthly number is volume, because model and API costs scale with use.
Be wary of hourly billing without a cap. It rewards the wrong thing, and it moves all the risk of a scope that grows onto you. We publish how we structure engagements and what moves the number, and any partner should be able to explain theirs as plainly.
The failure mode nobody warns you about
The most common bad outcome is not a project that fails. It is a project that succeeds and then quietly stops being used.
This happens when the automation was built around a process rather than around the people doing it. The system works, the demo was impressive, and three months later the team has gone back to the spreadsheet because the new thing needed one more click, or did not handle the exception that comes up every Thursday, or nobody was shown how it fitted into the rest of their day.
The defence is unglamorous: pick a workflow whose owner actually wants it fixed, involve that person during the build rather than at handover, and check in after launch when the novelty has worn off. Ask any prospective partner what they do after go-live. If the engagement ends at delivery, the risk of the thing being shelved sits entirely with you.
Key Takeaways
- Scope before price. A quote given before anyone has looked at your systems will be revised upward.
- Insist on a specific workflow and a specific measure of success. General capability is not a scope.
- Ask for the ongoing monthly cost, not just the build cost, and ask what makes it rise.
- "What happens when the AI is wrong" is the question that identifies people who have shipped rather than demoed.
- A partner who talks you out of some of your ideas is doing the job you hired them for.
- Agree ownership of code, data and infrastructure in writing before the build starts.
- The most common bad outcome is not failure. It is a working system that quietly goes unused, which is a design and adoption problem rather than a technical one.