Confirming They Understood Without a Quiz
Friday, 15:40, at Stonebridge Insurance. Ravi has spent ten minutes at Megan's desk in claims, moving her e-mail over to the new sign-in. He has explained it as he went. The old password stops working tonight, and the new one is the one she set this morning. The first time she signs in on Monday her phone will show a prompt that she needs to approve. Megan has nodded throughout. "Does that make sense?" Ravi asks. "Yes, got it, thanks." He closes the ticket on the way back to the desk. Monday, 08:15, a new ticket from Megan: "The thing you did on Friday hasn't worked, I can't get in." Her phone had shown the prompt. She had pressed "deny", because a message asking whether it was really her had seemed like exactly the sort of thing she had been warned about.
Nothing Ravi did was wrong, and nothing Megan did was unreasonable. He explained; she listened; he asked whether it made sense; she said yes, and meant it. The one step she needed to do on Monday had been described to her. She had understood it to mean something else. The question Ravi asked at the end was incapable of finding that out. Confirming understanding is checking that the listener can do the next thing, in a way that does not feel like a test. The quiz is the way that does feel like a test ("so, tell me what I just said"). Adults resent it, so the desk avoids it, and falls back on a question that always gets a yes. This article is part of our Explaining Technical Things to Non-Technical People series. This article is about the check that would have saved Megan's Monday.
It covers why "does that make sense?" always gets a yes, and the polite nod and its cousins. Then come the teach-back hidden inside a question and the follow-up question that reveals a gap. Next come listening to the answer, writing it down for them, and confirming on the phone and in writing, where there is no face to watch. The article ends with a short war story and the confirmation phrases to copy, in that order.
Why "Does That Make Sense?" Always Gets a Yes
"Does that make sense?" is a question about the listener, asked in front of the explainer, and the only comfortable answer is yes. Saying no means saying that you did not follow, which is a small admission in front of someone who clearly did. Most people would rather nod and work it out later. The question is not testing understanding. It is testing whether the listener is willing to look slow, and nearly everyone passes that test the same way. Ravi did not get a lie from Megan. He got the answer his question was built to produce.
There is a second reason the yes is honest and still useless: the listener often does not know that they have misunderstood. Megan had a clear picture of Monday morning. It contained a prompt on her phone and her declining it, because declining strange prompts is what careful people do. Her picture was complete and confident and wrong. No question of the form "do you understand?" can find that, because from the inside, misunderstanding feels exactly like understanding. The only thing that distinguishes them is what the listener does next.
That is the whole principle of this article. A confirmation that asks about comprehension gets a report of a feeling. A confirmation that asks about action gets a plan, and a plan can be checked against what you meant. Every technique below is a way of getting the listener to show you their plan without feeling examined. The plan is where the gap lives, and the gap is yours to fix, not theirs. Nobody has ever failed to understand on purpose.
The Polite Nod and Its Cousins
The polite nod is the listener's signal that they are following, or wish to be seen to be following. It is the same nod in both cases. Its cousins include "right", "okay", "sure", "great", and a "thanks" that arrives a beat too early. They include eyes that drift back to the screen while you are still talking. They also include the listener repeating your last word back to you with a rising tone. None of these is dishonest. Each is a person being courteous while a stranger talks at their desk. The courtesy is the problem, because it covers everything from full understanding to none at all.
Learn to read the nod as a request rather than a report. The nod is the listener saying "please keep going, I am not going to interrupt you". That is useful: it tells you the pace is bearable. What it does not say is whether anything has arrived. The two signals worth more than the nod are the question and the pause. A listener who asks "wait, which password?" has just shown you that they are building a picture and found a gap in it. That is the best possible news. A listener who pauses after you stop talking is doing the same thing silently. Give the pause two seconds. Technicians fill it with more explanation, and the more explanation is what buries the question.
When you see the nod and nothing else, do not ask whether it made sense, and do not say it again more slowly. Repeating an explanation to someone who has nodded at it tells them you did not believe their nod, which is true and unkind. Change the question instead, from one about their understanding to one about what they will do. The next section covers that question. Ravi could have asked it in the time it took to say "does that make sense?". (It is three words longer. It is worth the three words.)
The Teach-Back Inside a Question
A teach-back is asking the listener to say the next step in their own words, and done badly it is the quiz. "So, can you tell me what you're going to do on Monday?" is a reasonable question that, at 15:40 on a Friday from a visiting technician, lands as an examination. The fix is to put the teach-back inside a question that is about you, not them. "So I can write the note properly, what's the first thing you'll do when you sign in on Monday?" is the same question with the weight moved. Now Megan is helping Ravi with his paperwork. The way she helps is by describing her plan. Her plan includes pressing "deny", and Ravi hears it on Friday instead of Monday.
The framing is the whole technique. Any reason that makes the question about your needs will do. It could be "so I can write it down" or "so I know whether I've explained it in the right order". It could be "so I can tell my colleague who's covering Monday" or "so I can check I haven't missed a step". All are true, which matters, because the listener can tell a pretext from a reason. The desk does need the note written properly. The question asks the listener to supply the material for it, and the material is their plan, which is exactly what you needed to check.
The question should name a moment, not a concept. "What will you do first on Monday?" gives the listener a scene to walk into, and people describe scenes in steps. "What do you understand about the new sign-in?" gives them a subject, and people describe subjects in generalities, usually borrowed from the explainer's own words. The teach-back works when it produces the listener's words, because their words carry their picture, and the picture is what you are checking. Your words coming back are a sign of memory, not of understanding, and they can be perfectly accurate while the picture behind them is wrong.
| The quiz version | The teach-back inside a question | What the answer shows you |
|---|---|---|
| "Does that make sense?" | "So I can write the note right, what will you do first on Monday morning?" | Their plan for the first step, in their words |
| "Can you repeat that back to me?" | "If Priya asks you what changed, what will you tell her?" | Whether they can explain it to someone else, which is the real test |
| "Do you know what to do if it happens again?" | "Say it does the same thing on Wednesday; what's the first thing you'd try?" | Whether the fallback step landed, or they will ring the desk |
| "Are you clear on the new password rules?" | "When your phone asks for the password tonight, which one are you going to give it?" | Whether old and new are straight in their head |
| "Any questions?" | "What part of this would you want written down?" | Which step they are least sure of, without them having to say so |
| "You've got it, right?" | "I think I explained the approval bit badly; how did it come across?" | Their picture of the one step you are most worried about |
The last row is the one for the step you suspect did not land. Owning the doubt yourself ("I think I explained that badly") makes it safe for the listener to say that they are not sure. That is because you have already said that any gap is your doing. It is also usually true. A step that did not land was, by definition, not explained in a way that worked for this listener. Saying so costs you nothing and buys you the answer.
The Follow-Up Question That Reveals a Gap
The teach-back checks the step. The follow-up checks the picture behind it, by asking about the moment one step beyond the one you explained. "And if your phone doesn't buzz at all, what then?" "And if it asks you twice?" "And if it's Priya's laptop and not yours?" A listener who has the right picture can answer a question you did not prepare them for, because the picture generates the answer. A listener who has memorised the step cannot, and says "then I'd ring you", which is an honest answer and a sign that the picture is thin.
Choose the scenario that is most likely to actually happen, not the most interesting one. The desk knows which it is, because the desk has seen the tickets. For the new sign-in, it is the prompt arriving when the listener is not expecting it. So the question is "what if the prompt comes up while you're in a meeting on Tuesday?" One scenario is enough. Two starts to feel like a test again, and three is one. The follow-up is a single question asked lightly. Its answer tells you whether to stop or to go back and explain the picture rather than the step.
The follow-up is also where an analogy shows its edge. Suppose you explained the prompt as "the phone asking 'is this really you?' like a bouncer checking a face against a list". In that case, the follow-up "what if it asks when you're not signing in?" will reveal whether the listener has reasoned past the edge of the comparison. They may have reached "then the bouncer's confused and I should say yes to be helpful". That is the one answer that must not stand. Where a comparison stops, and how to say so, is in Analogies That Work, and When to Drop Them. The follow-up question is how you find out whether the stopping sentence was heard.
Listening to the Answer
The answer to a teach-back comes in four kinds, and each tells you what to do next. The right action in the listener's own words is success: stop, thank them, and write it down for them. Your own words parroted back accurately is memory, not understanding: ask the follow-up, because the picture has not been tested. The wrong action, confidently described, is a gap in your explanation: fix the explanation, not the listener. And a question from the listener is the best of the four, because it is the listener finding their own gap. All you have to do is answer it.
When the answer shows a gap, change the explanation rather than repeating it. Megan's "I'd press deny, because it's asking if it's really me and that's suspicious" is not a failure of attention. It is a correct inference from an explanation that did not say the one thing it needed to. The prompt is expected, and approving it is the point. Ravi's second attempt should be a different sentence, not the first one louder: "That prompt is the system checking with you, and on Monday the right answer is to approve it, because it will be you. Any other day, when you haven't just signed in, deny it and tell us." The three-sentence shape for an explanation, which makes the second attempt easier to build, is in The Three-Sentence Explanation.
Never let the listener feel that the gap was theirs, even when they say so. "Sorry, I'm hopeless with this" is a sentence technicians hear every week. The reply that works is "no, I explained it in the wrong order; let me do it the other way round", followed by doing exactly that. It is nearly always true, which is why it works. The listener relaxes. The second explanation lands on someone who is no longer braced. The desk has not spent a minute teaching an adult that they are bad at computers. That lesson is taught too often already, and it comes back as tickets that say "I didn't want to bother you".
Writing It Down for Them
The spoken confirmation lasts as long as the conversation; the written one lasts until Monday. Before you leave the desk, or in the minute after a phone call, write the next steps into the ticket reply in the listener's words, in order. Include the one "if this, then that" line that the follow-up question was about, and send it. Three or four lines. "Monday morning: 1. Sign in with the password you set today. 2. Your phone will show a prompt asking if it's you; press Approve. 3. If no prompt appears within a minute, reply to this message and I'll sort it before nine." Megan reads that at 08:14 on Monday with the phone in her hand, and the prompt is no longer a surprise.
Write it in their words, not yours, because the written line is the teach-back made permanent. If Megan said "the buzz on my phone", the note says "the buzz on your phone (the approval prompt)", and she recognises her own description. If the note says "complete the MFA challenge" (MFA being multi-factor authentication, a phrase Megan has never heard), it is a new explanation, delivered in writing with nobody there to ask about it. It has to be understood from scratch on a Monday morning. The written version should contain nothing the listener did not already confirm they understood in the conversation. Its job is to remind, not to teach.
Send it to the ticket, not to a chat or a scrap of paper. The ticket is where the listener's Monday reply will land, with the steps above it. If you run QuerySolv, the public reply on the ticket is that written version. In that setup, the internal note beside it is your own record of what you checked and what you were unsure of. Both stay on the same ticket. That way, when Megan replies on Monday the technician who picks it up sees Friday's steps and Friday's doubt together. In any tool the principle holds: the written confirmation lives where the follow-up will arrive. A note on a sticky pad lives under a coffee cup.
Confirming on the Phone and in Writing
On the phone there is no nod to misread, which is a kind of mercy, and no face to tell you the listener has drifted. The teach-back inside a question becomes the only tool, and it is used more often: after each step rather than at the end. "Go ahead and do that now, and tell me what you see" is the phone version. It confirms the step by having the listener perform it while you listen. A listener who says "it's asking me something about a code" has just shown you both their screen and their picture of it. Make them do, not describe, whenever the thing can be done on the call.
In writing, the confirmation is the requester's reply, and the trick is to ask for a reply that cannot be given without having done the thing. "Let me know if that works" invites "thanks!", which is the written nod, and silence, which is the written nothing. "Reply with the name of the first folder you open once you're in, and I'll close this off" cannot be answered without signing in, so the reply is the confirmation. One specific, small, verifiable thing. Silence is never confirmation. It is a requester who has not tried yet, or has tried and failed and given up. The two look identical from the desk. What to do when the reply does not come, and how long to wait, is in User Confirmation Without Chasing Forever.
Written confirmation also scales in a way the conversation does not. If the same steps go out to twenty people, the twenty replies tell you which step did not land for anyone. In that case, that is the step the written instructions explain badly, not the twenty people. Fix the instructions. Teaching requesters without lecturing them, which is where this leads when the same gap appears in ticket after ticket, is in Training Users Without Lecturing. For this article, the point is that every reply that comes back wrong is a free report on your own explanation.
Remember: a question about understanding gets a feeling; a question about action gets a plan. Ask what they will do, framed as help to you. Listen for their words rather than yours, and ask one step beyond. Fix any gap by changing your explanation. Write the steps down on the ticket before you leave.
A Short War Story: The Label Printer at Acme
Bastian, on the desk at Acme, installed a new label printer in the despatch bay. He showed Lena, the despatch supervisor, how to change the roll when it ran out. The steps were to open the side, drop the new roll in with the labels feeding from underneath, and close the side. The printer pulls the leader through itself. Lena nodded at each step, said "lovely, thanks", and Bastian asked "all clear?" and she said "all clear". Three weeks later, at four on the Friday before a bank holiday, the roll ran out mid-batch. Lena opened the side and dropped the roll in with the labels feeding from the top. That was because it was how the old printer had worked and nothing in the demonstration had stuck to the contrary. She pulled the leader through the cutter by hand. That jammed it so thoroughly that the supplier's engineer had to come out on the Tuesday. Sixty-one parcels missed the courier. The courier's cut-off could not be moved, and the customer complaints took a member of the sales team most of the following Wednesday. Bastian's lesson, written on the desk's whiteboard and never rubbed off, was that "all clear" is a courtesy and not a confirmation. His lesson also said that the only confirmation worth having is the listener doing the thing, in words or in fact, while the technician is still standing there to see it go wrong.
The Confirmation Phrases
The phrases below are the template for this article. They are the questions and lines that check understanding without turning it into a test, grouped by the moment they are used. Read them aloud once so they are in your own voice, then adapt the wording. A borrowed phrase said stiffly sounds like a script and a script sounds like a quiz. The underscores are for the step, the person or the time in the ticket in front of you.
CONFIRMATION PHRASES — CHECKING WITHOUT A QUIZ
Use one from each group that applies; never all of them.
OPENING THE CHECK (make it about your needs, which are real)
"So I can write the note properly, ..."
"So I know I've put this in the right order, ..."
"So I can tell ________, who's covering on Monday, ..."
"I think I explained the ________ part badly; how did it come across?"
THE TEACH-BACK (name a moment, not a concept)
"... what's the first thing you'll do when ________?"
"... when ________ asks you what changed, what will you tell them?"
"... which password will you give it when it asks tonight?"
"... what part of this would you want written down?"
ONE STEP BEYOND (one scenario, the likeliest one)
"And if ________ doesn't happen at all, what then?"
"Say it does the same thing on ________; what would you try first?"
"And if it's ________'s machine rather than yours?"
WHEN THE ANSWER SHOWS A GAP (the gap is yours)
"No, that's me; I said it in the wrong order. Let me do it the other way."
"I left out the important bit: ________."
"That's exactly what it sounds like, and it isn't. Here's the difference: ________."
ON THE PHONE (do, don't describe)
"Go ahead and do that now, and tell me what you see."
"Read me what's on the screen, word for word."
"Before I go: what will you do if ________ comes up again?"
THE WRITTEN LINE (sent to the ticket before leaving the desk)
"Here's what we agreed, for ________ morning:
1. ________
2. ________
3. If ________, reply to this message and I'll ________ by ________."
IN WRITING (ask for a reply that proves the step was done)
"Reply with the name of the first ________ you open once you're in,
and I'll close this off."
"Once you've ________, send me the number it shows and I'll check it
from this end."
Ravi uses the first group's last line now, at the end of every sign-in migration. About one time in five the answer tells him something he needs to fix before he leaves the desk. The written line goes to the ticket before he is back at his own. Megan's Monday ticket was resolved at 08:20 by approving the prompt she had denied. Her teach-back answer was "oh, so I say yes to it on Monday and no to it any other time". That went into the desk's instructions for everyone else, word for word, because it was better than the version the desk had written.
Frequently Asked Questions
Won't asking people to repeat the steps feel condescending?
What if there is no time to confirm every explanation?
The user keeps saying "yes, yes" and clearly wants me to leave. What then?
How do I confirm understanding over e-mail or chat?
What should I do when the teach-back shows they got it wrong?
Is a knowledge base article a substitute for confirming in person?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
