Communicating with Users and Customers

Why communication decides how your work is judged

Users rarely see the technical work. They cannot tell whether you found the cause in five minutes or guessed lucky. What they do notice is whether they felt heard, whether they understood what was going on, and whether you came back when you said you would. Two technicians can apply the same fix and leave one user grateful and the other annoyed.

It also affects the technical result. A user who feels rushed leaves out the detail that matters ("it only happens when I am docked"). A user who does not understand your instructions follows them wrongly. And a user who has lost trust in the service desk stops reporting problems and calls a favorite engineer directly, which makes the work invisible.

The service desk side of this, such as tiers, escalation and the life of a ticket, is covered in The Service Desk. This page is about the conversation itself.

Active listening

Active listening means giving the speaker your full attention, letting them finish without interrupting, and then checking your understanding by restating what you heard in your own words. It sounds obvious, but under queue pressure it is the first thing to go: you recognize the first sentence ("my email doesn't work"), stop listening and start typing the solution to a problem the user does not have.

In practice:

• Let them finish. The detail that solves the problem often comes at the end ("…but only since I moved to the new office").
• Restate. "So the billing app starts, but logging in gives a connection error, and your colleagues have the same. Is that right?" If you misunderstood, the user corrects you now instead of after an hour of wrong work.
• Clarify with questions. Open questions first to let the user describe, then closed questions to pin down details. How to ask them well is covered in Asking Good Questions and Gathering Information.
• Take notes while they talk. On the phone, a short "I'm writing this down" explains the silence.

Plain language instead of jargon

Plain language is writing or speaking so that the intended audience can understand it the first time: common words, short sentences, and technical terms only when the listener needs them and knows them. It is not about talking down to people. A finance director is an expert in her own field; she just does not need to know what a DHCP lease is to get back to work.

Your NIC didn't get a lease from the DHCP scope so Windows fell back to
APIPA. I released and renewed and flushed DNS, you should be good now.

Your laptop didn't receive its network address this morning, so it
couldn't reach anything. I've made it request a new one and it's
connected again. If it happens once more, restarting the laptop usually
fixes it, and please let us know so we can look at the cause.

The plain version answers the three questions users actually have: what was wrong, is it fixed, and what should I do if it happens again. A few habits help:

• Expand or avoid acronyms. "VPN" may be fine for a developer, but "the connection you use to work from home" is clearer for most users.
• Describe what the user sees, not what the system does: "the screen that asks for your code", not "the MFA prompt".
• Avoid slang and in-team shorthand ("the box is borked", "PEBKAC"). The second one is also an insult to the user, however common it is in IT humor.
• Watch the listener. If they go quiet or say "OK" in a flat voice, ask what is unclear rather than repeating the same sentence more slowly.

Setting and meeting expectations

Expectation management is telling people, honestly and in advance, what will happen, who will do it and when they will hear from you, and then doing what you said. Most user frustration is not about the problem itself but about uncertainty: not knowing whether anyone is working on it or when it will be over.

We're looking into it and will get back to you asap.

I've passed your ticket INC-20601 to the laptop repair team, because
the screen damage needs a part. They usually reply within one working
day. Until then you can borrow a loan laptop from the IT counter on the
ground floor; bring your badge. I'll check the status tomorrow before
12:00 and let you know either way.

The clear version says who has the ticket and why, gives a realistic time frame, offers an option to keep working, and makes a promise small enough to keep: a status update by a fixed time, not a repair by a fixed time. Then:

• Keep the promise. If tomorrow 12:00 comes and there is no news, send "no news yet, the part is ordered, next update Friday". A missed update damages trust more than a slow fix.
• Offer options when there are any: repair or replacement, a workaround now or a full fix later. Let the user choose what matters to them.
• Document what you did in a form the user can read: what was repaired or replaced, and what they need to do.
• Follow up afterward to check the fix worked, especially for problems that come and go. Resolved is not the same as closed.

Angry users and difficult conversations

People call IT when something is in the way of their work, often at the worst moment: month-end, a customer waiting, the third failure this week. Anger is usually about that situation, not about you, even when it is aimed at you.

De-escalation is the set of techniques for lowering the emotional temperature of a conversation so that it can get back to solving the problem: staying calm, acknowledging the person's situation, not arguing, and steering toward a concrete next step.

User:  This is the third time this week. Your department is useless.
Agent: That's not fair, we have a lot of tickets. And the last two were
       different problems.
User:  I don't care what problem it is!
Agent: Well, if you had restarted like we said...

User:  This is the third time this week. Your department is useless.
Agent: Three times in one week, while you have customers waiting, I
       understand that you're fed up. Let's get you working first.
       What do you see on the screen right now?
User:  The same error as Monday.
Agent: Thank you. I'm adding today's error to your earlier tickets, so
       the team looks at all three together instead of one at a time.
       I'll call you back before 15:00 with what they found.

What the second agent does differently:

• Does not argue or defend. Whether the department is busy is true but irrelevant to the user. Arguing turns a problem into a contest.
• Acknowledges the impact in concrete terms, without agreeing that anyone is useless and without a scripted "I understand your frustration".
• Does not dismiss or judge. No "it's only a small error", no hint that the user caused it.
• Moves to action quickly, with a question the user can answer, and ends with a clear next step.
• Takes the pattern seriously. Three tickets in a week is information. Linking them may lead to a problem record.

Cultural sensitivity

Cultural sensitivity is being aware that people differ in language, customs and expectations, and adjusting how you communicate so that it is respectful and clear to them, without assuming things about a person based on the group they seem to belong to.

In a Dutch IT team that may support colleagues from dozens of countries, in English, Dutch or both, this is very practical:

• Names and forms of address. Use the name the person uses, and ask how to pronounce it if you are unsure. Use professional titles where the person or the organization uses them. In Dutch, start with u unless the culture of the organization or the person makes clear that je is expected.
• Second-language English. For many colleagues and suppliers, English is a second or third language, and for you it may be too. Short sentences and plain words help everyone. Idioms ("let's touch base", "ballpark figure") do not.
• Written tone travels badly. Directness that is normal in one culture reads as rude in another, and politeness formulas can read as vague. In writing, be clear about what you need and friendly in how you ask.
• Time zones and calendars. A supplier's "end of day" or a colleague's public holidays may not match yours. Name the date, time and time zone.

Phone, chat, remote sessions and visits

Each channel has its own small rules, and most of them come down to respecting the user's time and attention.

Avoiding distractions is a form of respect that users notice immediately. Checking your phone while someone explains a problem tells them their problem is not important, whatever you say next.

Discretion and confidential information

Support work gives you a view into people's working lives: their mailbox, a salary letter on the printer, a medical note on the desk, a customer file on screen. Handling that well is part of communication, because users can only be open with you if they trust you.

• Look only at what you need for the ticket. If you see something private by accident, do not comment on it and do not open it further.
• Leave documents on desks and printers where they are; do not read them, move them or mention them.
• Do not tell stories about users or their problems, in the team chat, at lunch or on social media, even without names. Colleagues recognize each other from very little detail.
• If a user's problem involves personal data that may have reached the wrong person, treat it as a possible data breach and escalate at once; see Data breaches.

The wider duties that come with administrator access are covered in Ethics, Privacy and Professional Conduct.