How do I explain AI to a non-technical client?

Lead with the outcome in their language, not the technology: what changes for their team next Monday. Name a technical term only if they will encounter it elsewhere, translate it once in plain English, then stay in their vocabulary. Answer what it does, what it costs, what happens when it is wrong, and what they must change.

Does using technical jargon make me look more credible?

The research suggests the opposite. Studies of needlessly complex writing found readers rated complex authors as less intelligent, because the effort of processing difficult language gets attributed to weak thinking rather than dense subject matter. Precision earns credibility; complexity for its own sake costs it.

How should I explain AI hallucinations to a client?

Say plainly that the system can produce confident answers that are wrong, then move straight to the controls: what gets checked, by whom, before anything leaves the business, and how you measure the correction rate over time. Buyers are far more unsettled by a vendor who minimises the risk than by the risk itself.

What should an AI demo for non-technical buyers include?

Their own real data rather than a prepared sandbox, something useful happening within about ninety seconds, the output appearing where their team already works, and one deliberate failure showing exactly how errors are caught. Skip architecture diagrams unless someone asks for them.

How do I answer “will AI replace my staff?”

Honestly, and with specifics. In most deployments production tasks shrink while review, exception handling and client relationships grow, and some tasks do genuinely disappear. Naming which is which builds more trust than reassurance, and your buyer's team will judge the rollout on whether you were straight with them.

How do I price an AI project for a sceptical buyer?

Bound the first step as an experiment: one workflow, an agreed metric baselined before you start, a fixed price, and a scheduled go or no-go decision with kill criteria you state yourself. Show the total cost of ownership including next year's running costs, so nothing arrives as a surprise.

What should I do when a client says they already tried AI and it failed?

Ask what they bought, who used it and what was measured. Most failed rollouts were tools adopted without changing a process, without time to learn, and without a baseline, which means the failure diagnoses cleanly and is not a verdict on their judgement. That conversation usually builds more trust than any demo.

Should proposals include technical detail at all?

Yes, but structurally separated. Keep the first page plain enough to be forwarded to a finance director on its own, with the problem, the change, the cost, the requirement and the fallback. Put architecture, models and integration detail in an appendix for the technical reviewer who will ask for it.

Selling AI Without the Jargon: A Practical Playbook

The deal does not die when the buyer says no; it dies quietly around the third mention of retrieval-augmented generation. This playbook covers why jargon costs deals, the four questions non-technical buyers are silently asking, a plain-English translation layer for the terms that come up most, and how to demo, price, and handle objections so your pitch survives the meeting you are not invited to.

✦Key Takeaways

Complex language does not signal expertise; research shows it makes the writer seem less intelligent, because difficulty of processing gets misread as weakness of thinking.
The real damage is downstream: a buyer who cannot repeat your pitch cannot defend your proposal in the internal meeting you are not invited to.
Non-technical buyers ask four silent questions: what does it do for me, what will it cost all in, what happens when it gets something wrong, and what must we change. “How does it work” is rarely one of them.
Build a translation layer once: a fixed plain-English phrase for every term you use often, from hallucination to agent to token, and reuse it consistently.
Demo their data, never your sandbox, and show a deliberate failure. Buyers trust the vendor who shows them the edges.
Price the pilot as an experiment with a decision at the end, not as the first instalment of an inevitable rollout.
Name the risks before the buyer does. The vendor who raises the awkward question owns the answer to it.

There is a specific moment in an AI sales meeting when the deal quietly dies. The buyer is still nodding. They may still ask a polite question at the end. But somewhere around the third mention of retrieval-augmented generation, they stopped following, decided not to admit it, and started planning the rest of their afternoon. Nobody says “I don't understand” in a room full of colleagues. They say “leave it with me”, and you never hear back.

Selling AI without the jargon is not about dumbing anything down. The person signing the contract is buying an outcome, not an architecture, and every unexplained term transfers work from you to them. Do it enough times and they will choose the vendor who made them feel clever instead.

This playbook is for anyone who has to win that person over: agency founders, consultants, sales teams, and the internal champion trying to get a board to fund an AI project. It covers why jargon costs deals, the four questions buyers are actually asking, a translation layer for the terms that come up most, how to demo and price, the objections you will face, and the proposal that closes when you are not in the room.

Why Jargon Loses Deals

Most people use technical language to signal competence. The evidence says it does the opposite. In a series of experiments at Princeton, psychologist Daniel Oppenheimer found that needlessly complex writing made authors seem less intelligent, not more, and the effect held regardless of the underlying quality of the argument. The mechanism is processing fluency: when something is hard to read, the reader’s brain registers the difficulty and, without noticing, attributes it to the author rather than the prose. Say “we leverage a multi-agent orchestration layer” and some part of your buyer concludes that you might not know what you are talking about.

Then there is the curse of knowledge, popularised by Chip and Dan Heath in Made to Stick: once you know something well, you lose the ability to imagine not knowing it. Words like embedding, inference and context window feel like ordinary vocabulary to you and read as noise to a managing director whose expertise is logistics or law.

The commercial damage is not the confusion in the room; it is what happens afterwards. Your buyer is rarely the only decision maker, and has to re-explain your proposal to a finance director, an operations lead, sometimes a board. If they cannot restate your value in two sentences, your pitch does not survive the retelling. You are being judged on a summary given by someone else, from memory, in a meeting you will never see. Speak for that second meeting.

There is a national campaign in the UK devoted to precisely this problem: the Plain English Campaign has spent decades pushing organisations to write documents ordinary people can act on. Their premise applies exactly to AI sales: if the reader has to work to understand you, the failure is yours, not theirs.

What Non-Technical Buyers Are Actually Asking

Sit through enough of these meetings and the same four questions surface, whether or not anyone says them aloud.

What does this actually do for my business? Not what the technology does. What changes on Monday for their team, in their words: quotes out faster, fewer missed enquiries, month-end done in a day.

What will it cost me, all in? Licences, build, your fees, the internal time nobody budgets for, and what it costs to keep running next year.

What happens when it gets something wrong? Not whether it will. They already assume it will. They want to know who catches it, how fast, and what the damage looks like.

What do we have to change? New logins, new habits, retraining, migrations. Most buyers have been burned by a tool that demanded more change than it repaid, a fatigue we wrote about in the era of invisible AI.

Four cards showing the silent questions buyers ask, with a greyed-out fifth card reading how does it work, stamped nobody asked this one — Answer the four. Offer the fifth only if someone asks for it.

Notice which question is missing. “How does it work” is rarely on the list, yet most AI pitches are built almost entirely around answering it. Architecture diagrams, model comparisons, pipeline walkthroughs: these answer a question the buyer did not ask, using words they do not have, while the four they care about go unanswered. If you take one thing from this playbook, take this: answer the four, and offer the fifth only if asked.

The Translation Layer

Do this work once and reuse it forever. Write down every technical term you say often and fix a plain-English phrase for each. Not a definition, a translation: the sentence you would use with a smart person who has never worked in software.

Instead of	Say
Large language model (LLM)	Software that works with language: think of it as a very well-read new starter who is fast, tireless, and occasionally overconfident
Retrieval-augmented generation (RAG)	It looks the answer up in your documents before replying, rather than working from memory
AI agent	Software you give a goal to, instead of a list of steps
Fine-tuning	Training it on your own examples so it sounds like your business
Hallucination	It sometimes gives a confident answer that is wrong, so we check the things that matter
Vector database	A filing cabinet organised by meaning rather than by keyword
Tokens	The unit you are billed in, roughly three quarters of a word
Inference cost	What it costs each time the system does a piece of work
Prompt engineering	Writing clear instructions, the same way you would brief a new hire
Human in the loop	A named person approves the output before it goes anywhere that matters

Two rules make the translation layer work. First, name the term once if the buyer will meet it elsewhere (“some people call this RAG”), then use plain language for the rest of the meeting. Second, be consistent: if you call it a review gate on the call, call it a review gate in the proposal. Buyers building a mental model cannot afford your synonyms. For the terms that genuinely earn a place in a boardroom vocabulary, our AI glossary for executives is a fair thing to send afterwards.

There is a simple discipline for keeping every claim on the buyer's side of the table: the “so what” ladder. Start with the feature, step to the mechanism, land on the outcome, and never stop before the last rung.

Feature: “It uses retrieval over your knowledge base.”
Mechanism: “So it answers from your actual policies, not from the internet.”
Outcome: “So your team stops writing the same email forty times a week, and customers get consistent answers.”

Say the third sentence first. Offer the other two only if they lean in.

Show, Don't Explain

Every minute you spend explaining is a minute the buyer spends deciding whether to trust your explanation. Demonstration collapses that. But most AI demos fail for reasons that have nothing to do with the technology.

Demo their data, not your sandbox. A polished demo on invented data proves only that you can build a demo. Ask for three real documents and a real spreadsheet, ideally messy ones, before the meeting. Watching the system handle their own awkward inputs is worth an hour of slides, and it surfaces the integration problem that would have killed the project in month two.

Keep it to ninety seconds before something useful appears. If nothing valuable has happened in a minute and a half, you are giving a lecture with a cursor.

Show a failure on purpose. Find an input the system handles badly and walk them through what happens next: the flag, the queue, the human who reviews it. Sales instinct says hide the flaw. Buying instinct reads a flawless demo as a sales artefact. The vendor who shows the edges is the one who gets believed about the middle.

Do not make the chat window the product. If your entire demonstration is someone typing into a box, you are asking the buyer to imagine their staff learning to prompt well, which they will correctly predict will not happen evenly. Show the work arriving where they already look: the draft in the inbox, the record already updated, the report already assembled.

Talking About Money Without Projections Nobody Believes

Non-technical buyers have seen enough AI business cases promising a tenfold return to discount all of them. Credibility now comes from restraint.

Start with the cost of the status quo, measured rather than asserted. “You told me two people spend a day a week on this, that is roughly 12,000 pounds a year in salary time, plus the four deals last quarter that went cold while quotes sat unsent.” Numbers a buyer supplied themselves are numbers they will defend to their finance director. Then be specific about what your proposal changes and, crucially, what it does not.

Give the whole cost picture unprompted: build, licences, your ongoing fee, their internal time, and next year’s running cost. Vendors who volunteer the second-year number are rare enough that it lands as integrity. Then price the first step as an experiment with a decision at the end: one workflow, an agreed metric measured before it starts, a scheduled go or no-go, and honest kill criteria. Nothing de-risks a purchase like a clearly marked exit. Our framework for measuring AI ROI sets out how to baseline before you build.

One number to avoid entirely: the industry-average productivity statistic. It belongs to somebody else, and every buyer knows it.

Four common AI objections listed with the honest answer to each, with we tried AI and it did not work highlighted as the best objection — The objection that sounds worst is the one that builds the most trust when handled properly.

The Four Objections, and Honest Answers

“What if it makes things up?” Do not argue with the premise; it is true. “It can produce a confident answer that is wrong. That is why nothing customer-facing goes out without a named person approving it, and why we measure how often the system needs correcting so you can see the trend.” Then show the review step. Buyers relax when oversight is a visible part of the design rather than a reassurance, which is the whole point of keeping a human in the loop.

“Is our data safe?” Answer plainly and in this order: where the data goes, whether it trains anyone’s model, how long it is kept, who can see it, and what happens if you part ways. If an answer is unflattering, say so before they find out. Under UK GDPR they carry the accountability, so vagueness reads as risk transfer.

“Will this replace my team?” The honest answer is usually redistribution rather than replacement: the drafting and keying shrink, the review, exceptions and relationships grow. Say that plainly, including the part where some tasks genuinely disappear. Buyers who suspect you are dodging will assume the worst, and their team will resist the rollout anyway.

“We tried AI and it did not work.” The most valuable objection you will hear. Ask what they tried and what happened. Nine times out of ten they bought a tool without changing a process, gave it to people with no time to learn it, and measured nothing. Diagnosing that failure without blaming their judgement is the strongest trust-building moment available in the entire sale.

Make the Proposal Do the Selling

Your document will be read by people you never meet, so write it for them. Three tests before it goes out.

The read-aloud test: read it out to someone outside the industry. Every sentence that makes you say “well, what that means is...” gets replaced by what you just said.

The one-page test: the first page should be forwardable on its own. What we are solving, what changes, what it costs, what we need from you, and what happens if it does not work. Everything technical goes into an appendix for whoever asks.

The definitions test: every promise has a stated measurement and a date. “Faster response times” is a wish. “Median first response under two hours, measured in your helpdesk, reviewed at week six” is a commitment.

Then name the risks yourself, in your own words, with your mitigations. The vendor who raises the difficult issue owns the framing of it; the vendor who waits for procurement to find it spends the rest of the process defending.

What Not to Do

Do not name-drop models. Which frontier model you use matters to you and almost never to them. It also dates your proposal the moment a new version ships.
Do not say revolutionary, game-changing or transformative. Sales research from firms like Gong, which analyses recorded sales conversations at scale, consistently finds that hype language and vague superlatives correlate with worse outcomes than specific, concrete claims.
Do not whiteboard the architecture unless asked. It is the most common way technically strong teams lose non-technical rooms.
Do not answer “will it work?” with “how it works”. Different questions, and the substitution is the clearest signal that you are selling to yourself.

Conclusion: Clarity Is the Product

Buyers cannot evaluate your model choice, your pipeline design or your prompt architecture. What they can evaluate is whether you understood their business, whether your explanation held together, and whether you told them something inconvenient before they had to ask. Those are the proxies they use for competence, and they are not bad ones: the ability to explain something simply is decent evidence you understand it.

Strip the jargon and something uncomfortable happens, which is exactly why it works. When you cannot hide behind terminology, the quality of your thinking is on display. If your value survives being said in plain English, you have a strong offer. If it does not, better to find out in the meeting than in month three.

If you want a partner who talks to your board the way this article talks to you, AI Native Agency builds and runs AI systems for UK businesses, and explains every one of them in language you can repeat to your finance director.

Frequently Asked Questions

How do I explain AI to a non-technical client?: Lead with the outcome in their language, not the technology: what changes for their team next Monday. Name a technical term only if they will encounter it elsewhere, translate it once in plain English, then stay in their vocabulary. Answer what it does, what it costs, what happens when it is wrong, and what they must change.
Does using technical jargon make me look more credible?: The research suggests the opposite. Studies of needlessly complex writing found readers rated complex authors as less intelligent, because the effort of processing difficult language gets attributed to weak thinking rather than dense subject matter. Precision earns credibility; complexity for its own sake costs it.
How should I explain AI hallucinations to a client?: Say plainly that the system can produce confident answers that are wrong, then move straight to the controls: what gets checked, by whom, before anything leaves the business, and how you measure the correction rate over time. Buyers are far more unsettled by a vendor who minimises the risk than by the risk itself.
What should an AI demo for non-technical buyers include?: Their own real data rather than a prepared sandbox, something useful happening within about ninety seconds, the output appearing where their team already works, and one deliberate failure showing exactly how errors are caught. Skip architecture diagrams unless someone asks for them.
How do I answer “will AI replace my staff?”: Honestly, and with specifics. In most deployments production tasks shrink while review, exception handling and client relationships grow, and some tasks do genuinely disappear. Naming which is which builds more trust than reassurance, and your buyer's team will judge the rollout on whether you were straight with them.
How do I price an AI project for a sceptical buyer?: Bound the first step as an experiment: one workflow, an agreed metric baselined before you start, a fixed price, and a scheduled go or no-go decision with kill criteria you state yourself. Show the total cost of ownership including next year's running costs, so nothing arrives as a surprise.
What should I do when a client says they already tried AI and it failed?: Ask what they bought, who used it and what was measured. Most failed rollouts were tools adopted without changing a process, without time to learn, and without a baseline, which means the failure diagnoses cleanly and is not a verdict on their judgement. That conversation usually builds more trust than any demo.
Should proposals include technical detail at all?: Yes, but structurally separated. Keep the first page plain enough to be forwarded to a finance director on its own, with the problem, the change, the cost, the requirement and the fallback. Put architecture, models and integration detail in an appendix for the technical reviewer who will ask for it.

Selling AI Without the Jargon: A Practical Playbook for Winning Over Non-Technical Buyers