Latency-Objection Brief

AI Sales Engineering · v1.1 · Last verified 31 August 2026

Answer a latency objection by working out which of the three objections it is, setting the right baseline, showing where the milliseconds go, and committing to a P95 at their peak concurrency. Never to an average.

For the moment a buyer says "it feels slow" or "what happens at scale". The goal is to answer with numbers and architecture rather than reassurance, and to commit to something in writing you can actually hold.

Applies to any AI product with a human waiting on the other end. The pipeline stages differ by modality and section 3 covers each, but the argument structure is the same whether you sell a copilot, an agent, a RAG platform or an API.

1. What are they actually objecting to?

"Too slow" is almost never about the average. Three different objections hide inside it and they need different answers:

Table: The three objections hiding inside "too slow" and what fixes each. Source: AI Sales Engineering practitioner template, v1.1, August 2026.

Ask which one it is before answering. Answering the wrong one costs you the room.

Perceived latency beats measured latency, and this is the single most useful thing in this brief. A 900ms response that starts streaming at 200ms feels faster than a 600ms response delivered as one block at 600ms. People measure the gap before something happens, not total duration. Time to first token, time to first audio, first row rendered, a spinner that names the step it is on. If your product streams and the competitor's does not, demo that difference rather than quoting numbers.

2. What should they be comparing against?

Buyers instinctively compare AI response time to an instant local action. That is the wrong baseline and it is usually your whole argument.

Ask what the task costs them today, end to end:

• Support and service: what is current speed-to-answer, and abandonment at peak? Frequently minutes, plus menu depth or queue time before that.
• Knowledge and search: how long does someone spend finding the answer, or asking a colleague who is in a meeting?
• Coding and internal copilots: how long does the equivalent manual step take, including context switching?
• Document and back-office work: what is the current turnaround, in hours or days?
• Analyst and research workflows: how long to assemble the same answer by hand?

"Two seconds versus the four minutes it takes now" is a different conversation from "two seconds versus instant". Get them to say the current number out loud and the objection usually resolves itself.

Where this argument does NOT work, and say so rather than pushing: genuinely interactive, in-the-flow-of-work cases where the user is waiting mid-thought. Inline code completion, live conversation, anything replacing an instant UI action. There the bar really is human-reflex speed and you should concede it, then talk architecture instead.

3. Where do the milliseconds actually go?

Into recognition, inference, tool calls and synthesis, and in agentic products into step count above all. Find your modality below. Budgets are typical ranges, not measurements.

Conversational voice. Hardest constraint, everything is real time.

Table: Typical latency budget for conversational voice, by pipeline stage. Source: AI Sales Engineering practitioner template, v1.1, August 2026. Typical industry ranges, not measurements.

Chat, copilots and assistants. Perceived speed is almost entirely first token.

Table: Typical latency budget for chat, copilots and assistants, by pipeline stage. Source: AI Sales Engineering practitioner template, v1.1, August 2026. Typical industry ranges, not measurements.

Agentic and multi-step workflows. Where latency genuinely explodes.

Table: Typical latency budget for agentic and multi-step workflows, by pipeline stage. Source: AI Sales Engineering practitioner template, v1.1, August 2026. Typical industry ranges, not measurements.

Ten steps at two seconds is twenty seconds, and no model choice fixes an orchestration problem. If you sell agents, this row is your conversation. Move the discussion to asynchronous patterns and progress visibility rather than defending the total.

Batch and document processing. Usually the wrong question entirely.

Throughput and cost per document matter, latency rarely does. Redirect: "What is the SLA on the output, and what is the volume at peak?"

The tool-call rows are where real deployments die. Inference is bounded and improving. A lookup against a customer's system of record can take four seconds on a bad day and nothing in your stack fixes it. Ask early what gets called at runtime and what its P95 is. If they do not know, that is a finding worth surfacing. It is usually not your problem to own, but it is your problem to expose before the POC does it for you.

4. What should you commit to in writing?

A P95 at their expected peak concurrency, with the measurement method written next to the number. Never an average, and never a figure spanning systems you do not control. Say the quiet part in the room, because their engineers will find it anyway.

• Quote P95 at their expected peak concurrency, not benchmarks from an idle system. Ask for their peak concurrent figure and their seasonal multiplier.
• Commit to a P95 SLO, never an average. An average commitment is either meaningless or a trap. Know your P99 even if you will not commit to it, because that is where the complaints come from.
• Regional deployment affects latency and residency together. Say which region terminates the request and where inference runs. These are often different and buyers assume they are the same.
• Put the measurement method in the contract next to the number. "P95 measured at our edge over a rolling 7-day window, excluding client-side network" is defensible. "Under one second" is not.
• Name what degrades first under load and what the fallback is. A product with a documented degradation path reads as engineered. One without reads as untested.

What to refuse: a latency commitment spanning systems you do not control. Say so plainly and offer to measure at the boundary instead. Buyers respect the line and it protects the renewal.

5. What do you do when the objection lands live?

Stop arguing and measure it in the room, against their real task on their network. Pick the version that fits what you sell.

• Interactive products: run it in the room against their real task, on their network, and let them interrupt or redirect it mid-flight. Recovery speed is what "responsive" actually means.
• Anything replacing a manual process: have someone on their side do the task the current way while the product does it. The gap is the argument, and it needs no slide.
• Agentic products: show the progress trace. Watching it work is what makes twenty seconds acceptable, and hiding it is what makes eight seconds feel broken.

Then ask them to time their current process honestly, in the room.

This move also fails honestly. If your product genuinely is slow for their case, you find out in front of the buyer rather than in week six of a POC with your name on it.

Before you use this

Every number here is a typical industry range, not a measurement from your stack. Replace them with your own and mark which are measured versus modelled. A buyer's architect will ask, and "our measured P95 over the last 30 days" is a different conversation from "typical industry figures".

Sources, and what is not verified here

Last verified: 31 August 2026.

What this is: a practitioner template written by Lewis Crook from enterprise voice and agent deployments, not a benchmark study.

Not verified here: every millisecond range in section 3 is a typical industry band rather than a measurement, and none of it is attributed to a named vendor or a published benchmark. Measure your own stack before you quote anything from this page to a buyer.

Corrections welcome, and they get credited.