Home › Topics › Soft Skills for Technicians › Patience

Patience Without Condescension: Keeping the Voice Level

Thursday, 15:50, at Acme. Sam is on a screen share with Gordon from purchasing, who needs to approve a purchase order before the supplier's cut-off at four. The approve button has moved since an update on Tuesday. "Click the green tick, top right." Gordon clicks a green tick in the toolbar of his mail program, which is also top right. "No, in the finance window. The green tick." Gordon clicks the finance window's title bar, then a green icon that opens the help pages, then the tick on a different order. He then minimises the window by accident, finds it again and clicks the help icon a second time. Six clicks. Sam has taken five calls about this button since lunch, and the queue is at twenty-two. He can hear his own voice getting slower and more carefully enunciated, the way people talk to a child who is about to drop something. Gordon can hear it too. Gordon is a purchasing manager with thirty years in the trade, and he has just stopped clicking anything at all.

Patience, on a help desk, is keeping your voice, your pace and your words level while somebody takes longer than you would. And condescension is what leaks out when you do not: the sigh, the slowed speech, the "just", the explanation repeated louder. The two are not opposites, which is the difficulty. A technician can be endlessly patient and still condescending, waiting kindly while making it perfectly clear that they are waiting. Patience without condescension is the harder thing. It means taking the time the user needs while behaving as though it is the normal amount of time, because for them it is. This article is part of our Soft Skills for Technicians series. And it is about the second of the four skills, the one that is tested most on the sixth call of the afternoon.

It covers patience as a skill rather than a temperament, condescension and where it leaks from, and the voice that stays level. Then come the explanation that does not sigh, the user who clicks the wrong thing six times, and what to do. Next are managing your own frustration in the moment, the reset between calls, and where patience ends. A short war story and the patience reset card to copy come last, in that order.

Patience Is a Skill, Not a Temperament

Nobody is patient by nature on the sixth identical call of an afternoon, and the technicians who seem to be are doing something on purpose. Patience on a desk is a behaviour performed under load, and like any behaviour it can be described, practised and got wrong. Describing it is the first step, because "be more patient" is advice nobody can act on. "Keep the second explanation at the same pace as the first" is a thing a person can do on Thursday at ten to four.

The reason patience matters more on a help desk than almost anywhere else is that the user's main fear in the room is not the fault. It is looking stupid. Gordon does not mind that the button moved. He minds that a younger man is watching him fail to find it, and every slowed syllable confirms what he fears is being thought. A user who feels stupid stops trying, stops volunteering what they see, and in the end stops ringing. That is the point at which the desk loses them to a colleague or to a workaround. Patience is not a courtesy. It is the thing that keeps the user in the conversation long enough to be helped.

It is also the skill that is most plainly about the technician rather than the user, and that is uncomfortable to admit. The user did nothing to deserve the sigh. The sigh was about the queue, the five earlier calls, the update that moved the button and the fact that it is nearly four o'clock. Gordon got the sigh because he happened to be the sixth. Patience is the discipline of not making the sixth person pay for the first five.

Condescension and Where It Leaks From

Condescension almost never arrives as an insult; it leaks out through small channels the technician does not notice and the user notices instantly. The audible breath before an answer. The voice that slows and rises slightly on the second explanation, as though volume were the problem. The word "just", as in "just click the tick", which tells the user that the thing they cannot do is trivial. "Simply." "All you need to do is." "As I said." "Like I mentioned." The over-explanation of something they did not ask about, which says "I assume you do not know this either". The hand that takes the mouse without asking. The small laugh.

Each of these feels harmless from the technician's side because none of them is unkind in intent. "Just click the tick" is meant to reassure: it is easy, do not worry. What the user hears is: it is easy, and you cannot do it. The gap between what was meant and what was heard is where every complaint about a condescending desk comes from. Closing it is mostly a matter of removing a dozen words and one breath from the technician's repertoire. The table below lists the usual leaks, what the user hears, and the replacement. Nothing in it is hard. All of it is habit.

What leaks outWhat the user hearsSay or do instead
"Just click the tick"This is trivial and you are failing at it"Click the tick, top right of the finance window, next to the order number"
"As I said" / "like I mentioned"You were not listening the first timeSay it again in different words, as if for the first time
The slowed, louder second explanationThey think I am slowSame pace as the first; change the route, not the volume
The audible breath or pause before answeringI am exhausting themBreathe before you unmute, not after
"Simply" / "all you need to do is"Anyone could do thisDrop the word; the instruction works without it
Taking the mouse or the keyboardThey have given up on me doing it"Would it help if I drive for a minute? Say the word and I will hand it back"
Explaining what they did not askThey assume I know nothingAnswer the question asked; offer the rest: "want me to show you why?"
"Did you restart it?" as the first questionThey have a list and I am on it"Tell me what you see on the screen right now"

Read the left column aloud and notice how many of them you say in a normal week. I say three of them, still, after a long time at this, and the one I cannot shake is "just". It is the most natural word in the language for a technician, because to the technician everything on the list genuinely is "just" a click. That is precisely why it has to go.

The Voice That Stays Level

The level voice is the one that sounds the same on the sixth attempt as on the first. And it is built from three things: pace, pitch and vocabulary. Pace is the easiest to control and the first to slip; the second explanation gets slower, which is meant as help and lands as judgement. Keep the second explanation at the speed of the first. Pitch rises when people are frustrated and the user hears it before they hear the words; keep it where it was when you said hello. Vocabulary is the list above, and the fix is to delete rather than add.

The line I use silently when I feel the voice start to change is "sixth time for me, first time for him". It is true, and it is the whole situation in seven words. Gordon has never seen the new button. He is not slow; he is new to this, in the way everyone is new to everything once. The technician's five earlier calls are not his concern and should not be audible in the sixth. Say the line, let the voice settle, and carry on at the original pace. It takes two seconds and the user never knows it happened. (The line also works for the fifteenth time. It gets a little harder to believe.)

The written voice has the same three leaks in different clothes. "As per my previous e-mail" is the written sigh. "Again," at the start of a sentence is the slowed voice. A reply that is longer than the first reply, restating every step in bold, is the louder explanation. The written patience test is simple: would this reply read the same if it were the first one you had sent? If not, rewrite it until it would. Writing clearly under pressure later in this series is the fuller treatment of the reply. Here the point is only that the sigh is just as audible in text.

The Explanation That Does Not Sigh

When the first explanation did not work, the second must be different rather than louder, and that is the single most useful rule in this article. The same words, slower, are the same words. If "the green tick, top right" did not land, the second attempt changes the route entirely. "Look at the row with the order number on it. Go right along that row until you hit the edge of the window. What is the last thing you see there?" A different route gives the user a new chance to succeed. The same route, slower, gives them a new chance to fail, with an audience.

The question "what do you see?" is the most patient sentence a technician can say. It moves the work of describing from the technician to the user's own screen. It assumes nothing about layout, which matters, because the user's screen is very often not what the technician pictures. There may be a different window size, a toolbar someone customised, a second monitor, a mail program open on top. Half of the sixth clicks in the world are caused by the technician describing a screen they cannot see. Confirming they understood without a quiz covers the check at the end of an explanation. "What do you see?" is the check at the start, and it prevents most of the need for the other.

Analogies and plain words have their own series, in Explaining Technical Things to Non-Technical People, and this article leans on it rather than repeating it. The one point to carry over is that an explanation delivered with a sigh is not an explanation. It is a verdict with instructions attached, and the user will remember the verdict and forget the instructions. The content can be perfect. The breath before it undoes it.

The User Who Clicks the Wrong Thing Six Times

The user who clicks the wrong thing six times is not clumsy, and understanding why it happens is most of staying level while it does. The screen is not the one the technician is picturing, so "top right" points at the wrong top right. The cursor is small, the hand is being watched, and watched hands get worse. The instruction assumed a layout, a window, a toolbar that is not there. Fear narrows attention, so the user is looking at the one thing they last clicked rather than the whole screen. And after the third wrong click, the user is no longer trying to find the button. They are trying to make the call end, which produces faster, wilder clicks. None of this is about ability. It is what happens to anyone being watched while they fail.

What to do about it is a short list, and it starts with stopping the clicking. "Hold on, do not click anything for a second; let us both look at the screen." Then ask what they see, and let them describe it in their own words. Then name the target by its appearance and its position relative to something they have already named, not by its function. "The green tick, in the same row as the order number, right at the end" is three landmarks; "the approve button" is none. Give one click per instruction and wait for "done" before the next. If after two different routes it is still not landing, offer to drive, with consent, for one step. Hand back the moment the step is done. Never take the mouse. Never, if you are at the desk, reach for the keyboard. The hand moving towards the keyboard is the loudest sigh there is.

When it is over, and the order is approved, say what the update did. "The button moved on Tuesday; it caught out most of purchasing and it is not your fault." One sentence restores the user's standing with themselves, and it is true, which is why it works. The update moved the button. Gordon did not move the update. Somebody in a vendor's release meeting did, and they are not on the call to apologise, so the technician does it for them.

Managing Your Own Frustration in the Moment

The frustration is real and pretending otherwise does not help. So the first move is to be honest with yourself about what it is about. It is almost never about the person on the call. It is about the queue, the five previous calls, the vendor that moved the button without telling anyone, and the clock. Naming that silently, "I am annoyed at the update, not at Gordon", separates the feeling from the person who is about to receive it. The voice follows the naming more often than not.

The physical side is unglamorous and it works. Unclench the jaw, which has clenched; drop the shoulders, which have risen; take one slow breath while the user is talking rather than while you are. Take the hands off the keyboard, because hands on the keyboard during a user's attempt are hands that want to take over. If there is a mute button, use it for the breath, not for the comment. The comment, the one about the sixth call, does not get said on mute either. The mute button has failed more technicians than any other control on the phone.

The ticket is not a place to put the frustration, and this is where a lot of desks go wrong quietly. "User unable to follow basic instructions" in an internal note feels like a private vent. It is a permanent record that the user's manager, a future colleague, or the user themselves under a records request may one day read. What never to write in a ticket has the full list. The short version is that the note describes what happened and what was done, never what the technician thought of the person. A tool may keep an internal note separate from the public reply, as QuerySolv does. That separation protects the user from seeing working notes, not the technician from writing something unkind. The event history remembers who wrote it.

The note can, though, hold the useful version of the frustration. "Fifth call today about the moved approve button; suggest a notice to purchasing and a knowledge base article" is the same feeling. It is aimed at the system instead of the person. It is also the sentence that gets the button problem fixed, which is the only thing that will actually reduce the number of these calls. Frustration pointed at the user changes nothing. Frustration pointed at the cause becomes a problem record.

The Reset Between Calls

The reset is thirty seconds between one contact and the next, and it is where patience is restored or quietly used up. Finish the note. Stand up, or at least look at something that is not a screen, for the length of a slow breath. Drink some water. Say, silently or not, that the next person has not met the previous five. Then take the next call. Thirty seconds, six or eight times an hour, is less time than one bad call costs. It is the difference between a technician who is level at four o'clock and one who was level at nine.

The reset is also the moment to notice when the morning has gone wrong. The third reset in a row may not work: the breath does not settle anything and the next call already feels like an imposition. That is information. In that case, the honest response is to swap with a colleague for an hour, take the ticket that needs no phone, or tell the desk lead. Sustainable pacing in the burnout series is about designing the day so that this happens less. Here the point is that a failed reset is a signal to act on, not a weakness to push through. Pushing through produces the sixth call.

The honest edge is that some desks leave no gap between calls at all. On those desks the patience problem is a rota problem wearing a different coat. A technician who takes forty calls back to back with no thirty seconds between them is not short of patience. They are short of thirty seconds, and no amount of coaching replaces the half-minute. If the reset is impossible, the thing to fix is the schedule, and the article on the manager's side of that is the manager's responsibilities. Coaching a technician to be patient on a desk that allows no reset is asking them to fill a bucket with a hole in it.

Where Patience Ends

Patience is owed to the person who is struggling, and it is not owed to the person who is abusive. The two are not hard to tell apart once the distinction is stated. Slow is not hostile. Frightened is not hostile. Frustrated and sharp with it, for a minute, after an hour of not being able to work, is not hostile either. And the first sixty seconds with a frustrated user is the article for that minute. Patience covers all of those, and most of what feels like a difficult user is one of them.

Hostility is a different thing: insults, threats, language aimed at the technician as a person rather than at the situation. That is not a patience problem and it is not met with more patience. It is met with a boundary, a named procedure and a manager, and abuse is not a ticket owns that conversation entirely. A desk that tells its technicians to be patient with everything has told them to absorb abuse. And that desk will lose its most patient people first. Patience is a skill, and a skill has a scope.

Remember: the second explanation must be different, not louder or slower. Ask what the user sees, name the target by landmarks, give one click per instruction, and never take the mouse. Sixth time for you; first time for them.

A Short War Story: The Sixth Call at Northgate Retail

At Northgate Retail a technician called Jon had answered the same question about the new till login screen from five store managers in one morning. The sixth, a manager called Fiona from the flagship store, e-mailed to say the steps still did not work. He replied with the same steps a fourth time under the opening line "As I have already explained in my previous three e-mails". Fiona had been following the steps exactly on a till whose screen was a different size from the one in his instructions. She forwarded the thread to the regional manager with the words "this is how head office talks to us". The complaint cost the desk lead most of a day. It cost Jon two months off store support while the stores were persuaded to use the desk again. It cost the flagship store a morning of trading on one till. That was because the actual problem, the screen size, was found only when a second technician asked Fiona what she could see. The sentence Jon wrote was true, and that was never the point. The desk added one line to its ticket standard the next week. A reply that begins with how many times you have already said it is not a reply.

The Patience Reset Card

The card below is meant to be printed small and kept where a technician can see it between calls. It has three lines before the contact, a short list for during it, and the thirty-second reset after. It is not a script and it does not tell anyone how to feel. It lists the behaviours that keep the voice level, because those can be done on purpose on the sixth call. That is the only time they are needed. A new technician reads it every call for a fortnight. An experienced one reads it on the bad afternoons, which is what it is for.

THE PATIENCE RESET CARD — POCKET SIZE
BEFORE YOU ANSWER
  [ ] One slow breath, before unmuting, not after
  [ ] "Sixth time for me, first time for them"
  [ ] Hands off the keyboard

DURING THE CALL
  [ ] Repeat the problem back in their words
  [ ] "Tell me what you see on the screen right now"
  [ ] Name targets by look and position, not by function
  [ ] One click per instruction; wait for "done"
  [ ] Second explanation: different route, same pace, same volume
  [ ] No "just", "simply", "as I said", "again"
  [ ] Driving only with consent, one step, then hand it back
  [ ] After the fix: say what caused it, and that it was not their fault

THE THIRTY-SECOND RESET
  [ ] Finish the note: what happened, what was done, nothing about the person
  [ ] Stand, or look away from the screen, for one breath
  [ ] Water
  [ ] Three failed resets in a row: swap, take a no-phone ticket, or tell the lead

NOT COVERED BY THIS CARD
  Insults, threats, or language aimed at you as a person: stop, use the
  desk's abuse procedure, and involve the lead. Patience is for people
  who are struggling, not for people who are abusive.

Sam, at Acme, got there on his own at the seventh click. He heard his own voice and said nothing for a second. Then he said, "Gordon, stop clicking for a moment; I have been describing the wrong screen. Tell me what you can see." Gordon described a mail window on top of a finance window. The approve button was behind it. Thirty seconds later the order was approved. Sam said that the update had moved the button on Tuesday and had caught out most of purchasing, which was true. Gordon said, "You should have said that at the start," which was also true. Sam wrote "sixth call about the moved button; suggest a notice and an article" in the note. He stood up and drank some water before the next one.

Frequently Asked Questions

Is it really condescending to say "just click the button"?
To the technician it is reassurance. To a user who has failed to click the button three times it says the thing they cannot do is trivial. The instruction works without the word, so remove it. The same goes for "simply" and "all you need to do is". None of them adds information, and all of them add a judgement the user is listening for.
What do I do when a user keeps clicking the wrong thing on a screen share?
Stop the clicking first: "hold on, do not click anything for a moment". Ask what they see and let them describe it, because the screen is usually not the one you are picturing. Then name the target by appearance and position relative to something they named, give one click per instruction, and wait for "done". If two different routes fail, offer to drive for one step with their consent, then hand control back.
Should the second explanation be slower so they can follow?
No. Slower and louder is the same explanation with a judgement added, and the user hears the judgement. Keep the pace and volume of the first attempt and change the route instead. Use different landmarks, a different starting point, or "what do you see?" to let them lead. If the first route failed, the problem was the route, not the speed.
How do I stay patient when it is the sixth identical call of the day?
Say to yourself "sixth time for me, first time for them", because it is true and it separates the frustration from the person. Take one slow breath before you unmute and keep your hands off the keyboard. And put the frustration in the ticket as a note about the cause, such as a suggested notice or article, rather than about the user. Then take thirty seconds before the next call.
Can I write that a user struggled in the internal note?
Write what happened and what was done: "screen share; approve button was behind the mail window; approved; told user about Tuesday's update". Do not write an opinion of the user's ability. Internal notes are hidden from the requester, not from their manager, a future colleague, or a records request. The history records who wrote them. A note about the cause is useful; a note about the person is a liability.
Where does patience stop and a difficult-user procedure start?
Patience covers slow, frightened, confused and briefly sharp users, which is nearly everyone. It stops at insults, threats and language aimed at you as a person. That is not a patience problem and is not met with more patience. It is met with a boundary, the desk's abuse procedure and a manager, which this library covers in the de-escalation series.

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.