1.5Communicating effectively with users
The essentials in 30 seconds
- Communication is half of support work: a blocked user is often stressed, listening changes everything.
- Listen → rephrase → explain without jargon: three gestures that save time and build trust.
- Keeping someone informed beats silence, even without a solution: a status with a deadline reassures.
Rolling mini-case — Sofiane calms the user who "no longer has Internet"
Sofiane gets an alarmed message from a user at the SME: "Internet doesn't work, do something!". Instead of rushing at the network, he listens, then rephrases: "If I understand correctly, you can no longer open your emails, is that right?" The user confirms: the real problem is the mail service, not the connection. Sofiane has avoided troubleshooting the wrong system. He then explains without jargon — no "I'll kill the process", but "I'll reset your session" — and gives a status: "I'm looking into it, I'll get back to you before noon". The problem is fixed quickly, and the user feels heard. Sofiane keeps in mind: the initial request is not always the real need, and keeping someone informed reassures as much as fixing.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 1.5.
1. Half of the job
In support, technique is not enough: communication accounts for half the work. A blocked user is often stressed; being able to listen to them, reassure them and speak clearly changes everything — including their perception of the quality of the IT service. Sofiane keeps this in mind in every exchange.
2. Listen, rephrase, explain
Three gestures structure a good exchange: listen without interrupting to understand the real need (often different from the initial request); rephrase to confirm ("if I understand correctly, you can no longer…"); then explain without jargon, in words the user understands. "I'll reset your session" rather than "I'll kill the process". Sofiane always rephrases before acting.
3. Keep informed, even without a solution
A user copes better with waiting than with silence. Giving a status ("I'm looking into it, I'll get back to you before noon") sustains trust. And when you have to say no or "that's not planned", you explain it tactfully rather than with a blunt refusal. Sofiane ends every exchange by announcing the next step and a deadline.
🔎 Concrete example — 🔎 Concrete example — Rephrasing a vague request
A user writes to Sofiane: "Internet doesn't work, do something!"
Listen : what exactly is he doing when "it doesn't work"?
Rephrase : "You can no longer open your emails, is that right?"
Answer : "Yes!" → the real problem = the mail service, not the InternetReading: rephrasing avoided troubleshooting the network when only the mail service was at fault.
Lesson: the initial request is not always the real need; rephrasing saves precious time.
Section vocabulary
- Active listening
- Listening to understand the real need, without interrupting or presuming.
Simple example: Sofiane lets the user finish before rephrasing.
What it is not: cutting them off and assuming the fault from the outset.
Reflex: listen before reacting.
- Rephrasing
- Saying the request back in your own words to confirm you have understood.
Simple example: Sofiane rephrases "the mail service, is that it?" before acting.
What it is not: assuming the problem without checking with the user.
Reflex: rephrase to validate the real need.
- Jargon
- Technical vocabulary that the user cannot understand; to be avoided.
Simple example: Sofiane says "I'll reset your session", not "I'll kill the process".
What it is not: "the issue comes from the TCP/IP layer of the stack".
Reflex: talk about the result, without jargon.
- Status
- Information given on progress, even without a solution.
Simple example: Sofiane announces "I'll get back to you before noon".
What it is not: leaving the user without any news.
Reflex: give a status and a deadline.
- Perceived quality
- The user's feeling about the service, largely linked to communication.
Simple example: Sofiane reassures, and his intervention seems of better quality.
What it is not: a fault fixed but a user left without explanation.
Reflex: communication carries the perceived quality.
In practice — In practice — Translating jargon
- Take three technical sentences you would naturally say.
- Rewrite each one without jargon, as for a non-technical relative.
- Always add a status ("I'll get back to you before…").
- Try the rephrasing on a vague request received recently.
Step-by-step script — run the exchange like Sofiane (5 min)
1) Listen without interrupting and note the user's exact words. 2) Rephrase: "if I understand correctly, you can no longer…?" 3) Confirm the real need (often different from the initial request). 4) Explain without jargon, talking about result and action. 5) Announce a status with a deadline, even if you don't have the solution yet.
Most of the tension comes from the feeling of not being heard or informed — not from the problem itself.
Copy-paste template — my communication triptych
Listen : the user's request, exact words → ___
Rephrase : "if I understand correctly, you can no longer…?"
Explain : without jargon, talking about the result → ___
Status : "I'm looking into it, I'll get back to you before ___"
To ban : "kill the process" → say "I'll reset your session".Vague request
Sofiane rephrases "Internet doesn't work" as "the mail service, is that it?" and targets the right problem.
Angry user
Sofiane lets them express themselves, acknowledges the annoyance, rephrases, then announces the next step and a deadline.
Saying no tactfully
When it's not planned, Sofiane explains calmly rather than refusing bluntly.
Always a status
Even without a solution, Sofiane keeps the user informed of the progress.
✓ Best practices
- Rephrase to validate the real need.
- Ban jargon; talk about the result.
- Keep informed, even without a solution.
✗ Common pitfalls
- Cutting the user off and presuming the problem.
- Drowning them in technical vocabulary.
- Leaving a user without news.
Key takeaways
- Communication makes up half of the perceived quality of support.
- Listen → rephrase → explain without jargon.
- The initial request is not always the real need.
- Keeping informed beats silence, even without a solution.
48h challenge — apply it tomorrow
Take a vague request received recently and apply Sofiane's triptych: a sentence of listening, a rephrasing of the real need, an explanation without jargon, plus a status with a deadline. In one sentence, write the real problem that was hiding behind the initial request.
- I can listen, rephrase and explain without jargon.
- I know how to keep a user informed, even without a solution.
- I validate the real need before acting.
Frequently asked questions
How do you handle an angry user?
Let them express the problem without interrupting, acknowledge the annoyance, rephrase, then announce the next step with a deadline. Most of the tension comes from the feeling of not being heard or informed — not from the problem itself.
Is simplifying talking down to people?
On the contrary: simplifying well means respecting the other person's time and job. You explain the result and the action, not the technical guts, unless the person asks for it.
Which gesture avoids troubleshooting the wrong problem?