What clients actually mean when they ask for AI.

“We want to add AI to this” is now one of the most common things a client says to an agency, and it is not a requirement. It is a budget, an expectation and a vague sense that something is possible, handed over as though it were a specification.

The useful response is not enthusiasm and it is not scepticism. It is translation. Behind almost every request of this shape there is a specific, boring, buildable job, and finding it takes one conversation.

The request is never really about the technology.

Clients rarely want a model. They want a person to stop doing something, or they want a decision made faster, or they have watched a competitor announce something and do not want to look behind.

The first question is not which model. It is what someone is doing by hand today that they would rather not be doing. If the answer is “nothing, we just think we should have AI”, that is worth knowing early, because a project with no underlying task will not produce anything the client values regardless of how well it is built.

Five jobs account for most of it.

Once you ask what a person currently does, nearly every request resolves into one of these.

Classification. Deciding what something is. Which category this enquiry belongs to, whether this message is a complaint, which team should receive this ticket.

Extraction. Pulling structured fields out of unstructured input. Values from an invoice, a date from an email, requirements from a brief.

Drafting. Producing text a person will review. A reply, a summary, a description, a first version of something.

Summarising. Compressing something long into something short, for a person who will act on it.

Decision support. Presenting a recommendation with a reason, where a human still decides.

Notice what is not on that list. None of these is “the AI runs the business”. All of them are a step inside a workflow, with defined input and defined output, and that is what makes them buildable.

Half of these are rules wearing a costume.

A meaningful proportion of AI requests describe work a model should not do, because a rule does it better, cheaper and predictably.

What the client asks for	What it usually is
AI that routes leads to the right salesperson	A lookup table on territory or service line
AI that spots high-value enquiries	A threshold on a field they already collect
AI that knows when to follow up	A schedule with a check for a booked meeting
AI that reads our forms	A form with the right fields on it
AI that flags duplicate customers	A match on a normalised email or domain

None of that is a reason to be dismissive. The client has correctly identified a job that should be automated. They have just assumed the mechanism, because the mechanism is what they have been reading about.

Saying so is good work and clients generally respond well to it. A rule that costs less, runs instantly and behaves identically every time is an easy thing to prefer once someone explains the trade.

The question that separates them.

There is a reliable test. Ask whether a competent new employee could be given written instructions that let them do the task correctly every time.

If yes, it is a rule. Write the rule.

If the instructions would inevitably say “use your judgement” or “it depends on the wording”, then the input is genuinely unstructured and a model is doing something a rule cannot. Classifying free text, reading a document whose layout varies by supplier, drafting a reply that responds to what was actually written: these are model problems.

The distinction is not about difficulty. It is about whether the input has a fixed shape.

Most real answers use both.

The best version of these systems is usually not a choice between rule and model. It is a rule handling the clear cases and a model handling the remainder.

If eighty percent of enquiries can be categorised by a keyword or a form field, categorise them that way. Send the rest to the model. The client gets faster and cheaper processing on the bulk of the volume, and the model’s failure modes only ever affect the ambiguous minority.

This also gives you somewhere honest to put uncertainty. A model that is unsure should be able to say so and route to a person, rather than being forced into a category to keep the pipeline moving.

What it costs to choose wrong.

Using a model where a rule would do is not neutral. It adds latency to every record, cost that scales with volume, and non-determinism to a step that used to be predictable. It also makes the system harder to test, because the same input may not produce the same output twice.

Using a rule where a model was needed fails differently and more visibly. The rule works on the examples it was written against and breaks on the first input phrased unexpectedly, and it keeps breaking silently because a rule that finds no match usually returns nothing rather than raising a problem.

Both are recoverable. Neither is free.

Write the scope in terms of the decision.

Once the job is identified, the scope stops being about AI and becomes writable.

Name the decision being made. State the input, and whether it is structured or not. List the possible outputs explicitly, as a fixed set rather than as an open question. Say what happens when the system is not confident, because “route it to a person” is a real requirement and it needs a queue somebody owns. Say who checks the output and how they disagree with it. And say what accuracy would be acceptable, in terms the client would recognise.

That last one matters. A client who has not thought about it will assume perfection. A conversation about what an eighty-five percent correct classification looks like in their business, and who catches the rest, is much easier before the build than after.

Say what it will not do.

The gap between what clients expect from a model and what one does is where these projects lose trust, and it closes with one honest paragraph in the proposal.

A model will not know anything about their business that it was not given. It will not stay correct if the input changes shape. It will be wrong sometimes, and the system needs somewhere for wrong to go. And it will not remove the person entirely, because someone still owns the queue, checks the exceptions and answers for the output.

Clients accept all of that readily when it is said early. They accept none of it when it is discovered in week six.

The useful position.

Automation is an operations problem before it is a model problem. The value in these projects is almost never the model call itself, which is a few lines of configuration. It is in knowing which decision to automate, what to do when the answer is uncertain, and how the result reaches someone who can act on it.

If a client has asked your agency for AI and you would like the request translated into something you can price, send us what they said in their own words. We will tell you what the underlying job is, whether it needs a model at all and what building it would involve. Send it here.