AI Automation Consultant: What to Look For

The Word Doing a Lot of Heavy Lifting

Two years ago these people were called integration consultants. The work has changed less than the job title suggests.

That isn't a complaint about the field, and we put AI in our own service description. It's a warning about scoping. A large share of what gets sold as AI automation is deterministic workflow automation with a language model somewhere in the middle, and the model is often the least important part of it. When a consultant leads with the model rather than the workflow, that's worth noticing early.

Where AI Genuinely Earns Its Place

Four categories, and they share a property: the input is messy in a way rules can't fully anticipate.

Reading unstructured text. An email that contains an order number somewhere in a paragraph of complaint. A PDF invoice from a supplier who redesigns their template annually. A voicemail transcript. Regular expressions handle the tidy 80% and fall apart on the rest, and the rest is where the staff time goes.

Classifying by meaning. Sorting inbound messages into billing, technical, or sales when customers don't use any of those words. Keyword rules approximate this and misroute the interesting cases.

Summarising. Turning a twenty-minute call transcript into three bullets and an action. There's no rule-based version of this.

Drafting language. Producing a reply that reads like a person wrote it, given facts supplied by the workflow. Note the ordering there, because it matters more than anything else in this article.

Where It Shouldn't Be Anywhere Near

Anything with a right answer.

Order status, account balance, appointment time, refund amount, delivery date. These are lookups. A model should never be recalling them, generating them, or inferring them from context. The workflow fetches the value from the system that owns it, then hands it to the model as data if a sentence needs writing around it.

Get this backwards and you get an automation that is confidently, fluently wrong, which is worse than one that's obviously broken. A broken workflow gets fixed on Tuesday. A workflow that invents plausible tracking numbers keeps running for months.

The test we apply on every build: if this field were wrong, would a customer notice and would it cost us? If yes, it comes from a lookup with a hard failure path, never from a model.

Questions Worth Asking on the First Call

Five, and the answers separate people quickly.

"Which parts of this actually need a model, and which are just rules?" Anyone good will happily tell you most of it is rules. Someone who insists the whole thing needs AI is either selling a platform or hasn't thought about it.

"Where does the data come from at reply time?" You want to hear about live lookups against your systems. If you hear about training on your documents or a knowledge base snapshot, ask what happens when the underlying record changes an hour later.

"What happens when the model isn't confident?" The correct answer involves escalating to a human. If there isn't a defined path for uncertainty, there isn't a design.

"What can it do without a human approving it?" Sending money, issuing refunds, cancelling bookings, emailing your whole list. All of those should sit behind a person. We have never had a client push back on that limit.

"What does this cost per run at our volume?" Model calls are cheap individually and add up. Somebody should be able to estimate it rather than wave it away.

The Build Pattern That Holds Up

In practice the workflows we deliver are mostly conventional, with the model in one or two specific places.

Take support triage. Message arrives. The workflow pulls the customer record and their recent orders from the systems that own them, deterministically. The model classifies the message and drafts a reply using the retrieved facts. A confidence check decides whether it sends or queues for review. The outcome is logged, and a failed lookup escalates rather than guessing.

Only one step there is AI. The rest is plumbing, error handling and logging, and that's where the reliability lives. A consultant who talks entirely about prompts and never about what happens when your CRM times out is going to hand you something fragile.

We went deeper on the support version of this in AI customer support tools: an honest comparison, and on the general question of whether you need a model at all in do you need an AI agent or just automation.

Signals Worth Walking Away From

A demo on their data rather than yours. Every AI demo works on curated examples. Ask them to run it on a handful of your actual messy inputs, including the awkward ones, before you commit.

"The AI learns your business." Usually means nothing specific. Ask what exactly is stored, where, and what happens when it's wrong.

No mention of failure at any point in the conversation.

Pricing that ignores usage entirely, which suggests they haven't run one at volume.

And agent language applied to something that's plainly a linear workflow. What is an AI agent: marketing term versus reality covers that gap.

What You Should Actually Be Buying

Someone who understands your process well enough to tell you which 10% of it benefits from a model, builds the other 90% properly, and puts hard limits around the part that can be wrong.

That's less exciting than the pitch and it's what still works in eight months.

If you're comparing types of consultant more broadly, what an automation consultant actually does covers the landscape, and what automation consulting actually costs covers pricing.

Book a free 60-minute call and we'll go through your workflow, mark the parts that genuinely need a model, and tell you plainly where AI would add risk rather than value.