Making AI decisions through a business lens

No client has ever woken up wanting a large language model. They woke up with a number that embarrasses them in front of their board, a queue that keeps growing, or a competitor who launched something first. AI is the current fashionable name for “fix this” — which means your first job on any call is translating “we need AI” back into whatever it actually stands for.

Skip that translation and you get a technically correct project that nobody can defend at renewal time, because nobody ever wrote down what it was supposed to change.

What the client is actually buying

Underneath “we need AI” is always one of a short list of outcomes. Naming the right one changes the whole proposal.

Revenue growth shows up as “we want to close more deals” or “we’re losing leads somewhere in the funnel.” It’s real when someone can name today’s conversion rate before anything changes; it’s aspiration when there’s no baseline on record and so no way to prove, later, that the project moved it.

Cost reduction shows up as “this team is too big for what it does.” It’s real when someone can say how many hours a task takes and how often it happens; it’s a guess when the answer is “a lot.”

Faster processes shows up as “approvals take too long.” It’s real when there’s a cycle time on record — three days, eleven days — not a shrug and “forever, it feels like.”

Less manual work shows up as “people are doing the boring part by hand.” It’s real when someone can list the boring part step by step; if the steps have never been written down, the work hasn’t been understood well enough to automate yet.

Lower risk shows up as “we can’t afford another mistake like last quarter’s.” It’s real when there’s an incident count or an error rate attached to “mistake”; it’s marketing when the evidence is a single bad memory.

Better customer experience shows up as “customers are frustrated.” It’s real when there’s a response time or a satisfaction score already being tracked; it’s aspiration when the plan is to make people happier without measuring happy.

Turning “we need AI” into “what problem are you solving”

Reformulating the request is not refusing it. Done well, it sounds like curiosity, not resistance. Four moves that fit inside a normal conversation:

  1. Ask what changes, not what's built
  2. Ask for the number that's currently wrong
  3. Ask who feels it, by name or by role
  4. Separate the request from the shape it arrived in

Move 1 — ask what changes, not what’s built. Client: “We need a chatbot on the website.” You: “What should a visitor be able to do at the end of that conversation that they can’t do today?”

Move 2 — ask for the number that’s currently wrong. Client: “We want to use AI in customer support.” You: “What’s the number this has to move — response time, ticket volume, cost per ticket — and what is it sitting at right now?”

Move 3 — ask who feels it, by name or by role. Client: “AI would really help our sales team.” You: “Who on that team loses the most time to this today, and how do they describe the problem when they’re annoyed about it, not when they’re presenting it to you?”

Move 4 — separate the request from the shape it arrived in. Client: “We need an AI agent that handles this end to end.” You: “What decision does it need to make on its own, and what happens right now when that decision comes up?”

None of these four questions say “no.” All four make the client do the work of defining success, which is work they were going to have to do eventually — just before the invoice instead of at it.

When the problem is real but the shape is wrong

Sometimes the client has correctly identified a real problem and incorrectly picked the technology to fix it — they want a conversational agent for what is actually a scheduled report, or a fully autonomous agent for what is actually three fixed steps that never vary. Saying “that’s the wrong approach” in a room with their own team present makes the request personal and gets you a defensive client, not a corrected one.

The move that works instead: don’t correct the shape, walk the example. Ask them to describe one real case from last week, start to finish, in the order it actually happened. The mismatch surfaces on its own — the room notices, together, that the “agent” they described never actually had a decision to make, or that the “simple chatbot” they asked for needs to search across four systems nobody mentioned. You end up agreeing with the room’s own conclusion instead of overruling the client in front of it.

This is also where naming the right solution class pays for itself — the vocabulary for telling a scheduled job from a genuine agent, or a lookup from a database question, lives in the next chapter’s distinctions, and having it ready is what turns “let’s look at this together” into a five-minute conversation instead of a stalled one.

What “what does success look like” should sound like

Ask this question on every call, and listen for the shape of the answer, not its content.

A good answer is a number, an owner, and a date: “Average first-response time drops from four hours to under one hour by the end of Q3, and the support lead owns that number.” Anyone in the room can check that in ninety days.

A bad answer is an adjective standing in for all three: “faster,” “smarter,” “more efficient,” “seamless.” Adjectives cannot be missed, because nobody agreed on what hitting them would look like — which means they also cannot be failed, and a project that cannot fail on paper is a project nobody is accountable for.

Push for that sentence before the proposal is written, not after the project ships. It is the cheapest correction you will ever make on a deal, and the only one that protects you when someone asks, six months in, whether it worked.

A client opens the call with: "We need a chatbot on the website." What do you ask first?