How consultants actually use AI for clients

The gap between how this work is demonstrated and how it is done is wide, and the demonstrated version is more impressive.

Almost all real delivery falls into five patterns. None of them are exciting and all of them pay.

Pattern one: reply instantly to something that arrives

An inquiry, a message, a form submission. Something comes in and a real response goes out immediately rather than whenever a human notices.

This is the most commonly built pattern in the field and the reason is simple: the value of a response decays fast, most businesses respond in hours, and software responds in seconds. No cleverness required.

The engineering is not in the reply. It is in knowing when to stop replying and fetch a person.

Pattern two: hold a short conversation to a defined end

Beyond a single response, a brief exchange with a purpose: establish what the person needs, check a couple of details, confirm an appointment, put it on a calendar.

The whole difficulty is the boundary. The system needs to know what it is allowed to conclude, what it must never state, and which situations require handover. That boundary work is most of the build and none of the demo.

Pattern three: move information between systems that do not talk

The least glamorous and possibly the most valuable, because somebody in your company is currently doing it by hand and they know it.

Information enters in one place and has to appear in another, in a different shape, with a decision about what happens when the two disagree about who a customer is.

Most of the effort here is reconciliation, not intelligence. The interesting AI part is small; the plumbing is the project. This is also the pattern where cost estimates go wrong, because nobody knows how bad the data is until they open it.

Pattern four: work a list nobody has time for

Outbound rather than reactive. Customers due for something, quotes with no follow-up, renewals approaching, people who went quiet.

The reason this pays is that the comparison is against nothing happening at all. Nobody is doing it badly; nobody is doing it. Every business has a list like this and it is never anybody's most urgent task, so it stays undone indefinitely.

Personalization from your own records is what makes it work, and restraint is what stops it becoming spam.

Pattern five: extract structure from mess

Documents, transcripts, notes, forms. Pulling out the specific fields somebody needs so a person is not reading forty pages to find four numbers.

Genuinely good at this, and the thing to watch is verification: the pattern works when a human checks the output, or when being occasionally wrong is cheap. Where an error creates an obligation, it needs review.

What the toolkit looks like

Also mundane. A model provider, an automation platform to orchestrate the steps, whatever systems you already run, and a lot of configuration: prompts, rules, thresholds, escalation conditions, the list of things the system must never do.

That configuration is the product. It is also the thing most often withheld as proprietary, which is worth understanding: it means the thing running your operation is not yours. Why to require it in readable form.

Very little of this is novel software. Anybody claiming a breakthrough architecture is usually assembling the same components as everybody else, and the differentiation is in the judgment about what to build and the care taken over failure cases.

What consultants use AI for on their own side

Worth being transparent about, since clients rarely ask.

Interview transcripts summarized, documents drafted faster, code written with assistance, patterns spotted across the material collected during discovery. It makes the work quicker and it does not make the judgment better.

The diagnosis itself is not automatable, because the useful findings come from noticing what somebody did not say and asking a follow-up nobody scripted.

The part that separates good from bad

Not the model, not the platform. Two things:

Whether somebody correctly identified which process to attack, which is a business judgment rather than a technical one. Prioritization.

And whether the failure paths were designed and tested before it touched a customer. Escalation, handover, the case nobody anticipated, what happens at three in the morning.

Both are invisible in a demonstration, which is why demonstrations are a poor way to choose a supplier and a working session is better.

Our own build work concentrates on the first two patterns, which is what Orelle is, and the diagnostic side exists to work out whether those are even the right patterns for your operation. Sometimes they are not. How that runs.