Time the answer the customer waited

A customer waited on an answer. Tonight, in this order. Read the duration of that one request, from a log you hold, in a unit you can say out loud. Read the timeout you set for that path. If you did not set one, write that the wait had no bound. If the duration is past the bound you are willing to defend, stop the path that can hold the next person with no ceiling. Do not ask the model whether it was fast. A model that says the answer felt quick has produced another answer, and it has not read the log.

This is the clock on one answer a person already waited through. It is not the five checks that decide which stage of a retrieval pipeline failed. Those checks — indexed, returned, present in the prompt, used, and the right shape — are what to check when a production RAG answer is wrong. A fast wrong answer fails them. A slow right answer can pass all five. It is not, by itself, the record you keep so a later complaint can be reconstructed. What to keep after a wrong AI answer is that record: the input, the output, the model, the tool result. Duration belongs in it. A complete trace that omits the clock still does not tell you how long they waited. And it is not the decision to turn a live feature off because the next answer can hurt someone. When to turn a live AI feature off is that wider rule. A slow answer inside a bound you chose, and that you can show, is not that incident. An answer with no bound is a candidate for it, because you cannot yet say how long the next one may take.

The oldest numbers people reach for are not a chatbot study. Jakob Nielsen, Nielsen Norman Group, 1 January 1993, excerpting chapter 5 of Usability Engineering: "The basic advice regarding response times has been about the same for thirty years," citing Miller 1968 and Card, Robertson, and Mackinlay 1991. Then three limits. "0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result." "1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay." "10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done" (Nielsen, Response Times: The 3 Important Limits). 0.1 is not 1.0 is not 10. Do not average them into "a few seconds." The ten-second line is about attention on a dialogue, and about telling the person when the computer expects to be done. It is not a measured abandonment rate. The page does not print a sample size, because it is not a sample. It is a limit he attributes to human perception, for interaction in general, and he says it had already been stable for decades in 1993.

A chatbot experiment that did measure people found something the ten-second line does not say. Gnewuch, Morana, Adam, and Maedche, in an ECIS 2018 paper, ran an online experiment in a customer-service setting. Participants were told they were talking to a chatbot. The task was help choosing a mobile-phone plan. Two conditions: near-instant responses, and responses with an added dynamic delay. Of 163 people invited, 84 finished the experiment and the questionnaire, a 52% completion rate. Five were discarded for not following the task or for straight-lined answers. The dataset is 79 observations, 25 women and 54 men, mean age 28.835. 44 were in the dynamic-delay condition and 35 in the near-instant condition. The split is unequal because the platform assigned at random and did not account for people who did not finish. Participants were not paid. 43 said they never use chatbots, and 21 said about once a month (Gnewuch et al., Faster is Not Always Better).

The clocks in that paper are specific, and they are easy to smear. Near-instant meant no added delay: the time to send the message, call the language service, and return, "an average of one second," which they also call a network delay of approximately one second. The dynamic delay is additional, calculated from the Flesch-Kincaid grade of the previous message and of the reply. The paper says it calculates a delay D in milliseconds, and prints D(m) = 0.5 × ln(C(m) + 0.5) + 1.5 when complexity is positive, and 0 otherwise. The worked row for a reply of complexity 4.922 is 2,351 ms. Evaluated as printed, that formula at 4.922 is about 2.35, not 2,351. The table's milliseconds match the formula if the formula's result is in seconds and then converted, while the prose calls the unit milliseconds. Quote the table: 2,351 ms for that row, and 4,175 ms for a later pair of messages. Those totals do not include the approximate one-second network delay. The authors write that the result "cannot be regarded as the 'optimal' delay." It is their formula for this experiment. It is not a timeout.

Satisfaction in that paper is not a verdict on speed, and it is not the humanness score. Service-encounter satisfaction is three items on a 7-point Likert scale: the advice, the way the chatbot treated the person, and the overall interaction. The dynamic-delay mean is 5.174 (SD 0.974). The near-instant mean is 4.610 (SD 1.344). The test is Welch's, one-sided, in the direction they predicted: t(60.04) = −2.088, p = 0.021, r = .260. Their post-hoc power for that test is .753. Perceived humanness is a different instrument, a 9-point scale, 5.534 versus 4.457. Social presence, back on a 7-point scale, is 3.695 versus 2.954. Do not quote 5.174 as humanness, and do not quote the humanness gap as satisfaction. One-sided means they did not test the opposite hope. 79 people, one bot, one plan-picking task, many of whom rarely use chatbots. That is the whole claim. It is not your queue, and it is not permission to add delay on purpose while a tool call runs.

The same lead author later found that a short delay does not do one thing to everyone. Gnewuch, Morana, Adam, and Maedche, Business & Information Systems Engineering, published 30 May 2022, ran a lab experiment. 219 people participated. 13 failed attention checks. 6 did not follow the instructions or gave invalid inputs. The analyzed sample is 202 (77 women, 125 men), ages 18 to 41, mean 23.21. Instant responses were as fast as the network allowed, about 200 to 400 ms, 67 people, 33.2%. Delayed responses averaged 2.3 seconds, 135 people, 66.8%, pooling a static delay and a dynamic delay after the authors say they found no difference between those two types. They report a positive association of a delayed response with social presence (b = 0.69, p < 0.05) and then say that positive effect holds only for novices. The conditional effect they print for novices is the same 0.69. It is not a second study. The effect for people who had used a chatbot before is negative (b = −0.51, p < 0.05). The exclusions do not arithmetic-check against the sample they analyze: 219 minus 13 minus 6 is 200, and the paper states the final sample as 202. Quote 202. Do not invent the two missing people, and do not replace their N with 200. Social presence here is not the 2018 satisfaction mean of 5.174. The paper says the 2.3-second delay "was still rather short," so they could not examine an overly long wait, and it points at a possible inverted-U relationship this experiment did not test (Gnewuch et al., Opposing Effects of Response Time in Human–Chatbot Interaction). A lab delay that raises a novice's feeling of social presence, and lowers an experienced user's, is not a finding that a production answer may take as long as the tools require.

What you are allowed to copy is the refusal to treat any of these clocks as your timeout. Nielsen's 10 seconds is a 1993 perceptual limit for keeping attention on a dialogue. The 2018 table's 4,175 ms is one worked example of a formula the authors say is not optimal, on top of about a second of network time, in a sample of 79. The 2022 average of 2.3 seconds is a different experiment, N = 202, and it split by experience. None of them measured a tool-using agent. None of them is the duration in your log. Putting "users tolerate X" on a status page, with X borrowed from any of the three, has mixed three clocks and dropped the denominators. The action that survives the mix is smaller. Read the duration of the request the customer waited on. Read the bound you set. If you never set one, say so.

Write the pair so a person who was not on the call can repeat it. The request, identified by a time and an id you copied from the log, not by "the slow one." The duration, with its unit. The timeout as configured, or the words "no timeout." And whether you stopped the unbounded path. A spinner is not a timeout. A sentence in the interface that says "still working" is the feedback Nielsen describes for a delay past ten seconds. It does not cap the delay. The spend row is a different control on a different page: a missing per-account limit is cap one account and leave the rest up. OWASP lists execution timeouts and third-party spending limits as separate ways an API is vulnerable if the limit is missing. Closing the spend row does not close the clock. Closing the clock does not close the spend. Do both only if both are actually missing, and write which one you did.

A published median is not the pair. The support agent we shipped for a DTC brand answers order status, returns, and product questions, takes actions behind permission guardrails, and escalates to a person. The case page states a median response time under two minutes for that engagement. A median is not the wait one customer just had, and it is not a timeout. It is not Nielsen's 10 seconds, not the 2018 satisfaction mean, and not the 2022 average of 2.3 seconds. Nothing else on that page is a latency study. Do not speak the median as the bound for a different product. If your log cannot show the one request, the case does not fill it in.

There is a version of this where a rescue is the wrong purchase. Nothing is in production, so there is no request to time and no customer who waited. The complaint is that the answer was wrong, not late. Open the pipeline checks, or the citation, before you buy a faster model. You have no log of duration, and the buyer wants a timeout written on a slide. A slide that quotes 10 seconds and has never opened a request is a brochure. Or a customer has already seen another customer's data. A timeout does not close a leak. Or nobody ever named a metric, so "fast enough" has no meaning you could miss. Name the metric before you buy a rebuild.

When the customer has already waited and you cannot read how long, the missing object is specific. A duration on that request, a timeout you can point at, and a path that cannot hold the next person with no ceiling. An AI pilot failed to reach production engagement is for the system that is already in front of customers and cannot yet show those three: audit in the first one to two weeks, finished in 8–12 weeks, scoped after the audit, unpaid if the agreed metric does not move, rollout behind a human-review gate. The pair you wrote tonight — request, duration, bound — is the kind of case the harness has to include, or the next release will be just as fluent and just as unbounded. The harness is AI evaluation and observability. An AI integration sprint lists cost and latency instrumentation per request among its deliverables. That line is the reading. It is not the bound, and a sprint that ships the chart without the timeout has delivered the instrument and skipped the decision. If you do not yet know whether the pilot can be saved, a two-week AI readiness assessment hands you the findings either way. The free production-readiness diagnostic is the short way to see whether you are looking at a wait, a wrong answer, or a system that has not reached a customer. Those are the terms on the site. They are not a promise that every slow answer is a rescue, and they are not a rate. 10 seconds is a 1993 limit. 5.174 is one condition's satisfaction mean on a 7-point scale, N = 79. 2.3 seconds is a different paper's average delay, N = 202. None of them is your latency, and none of them belongs on the invoice.

Before you tell anyone the answer was fast enough, read the duration. Read the timeout. Stop the path that has no bound when you cannot defend the wait. Leave the model out of the grading. A spinner is not a clock, and a clock you never set is not a promise you can keep.