1 The SITUATION & SBAR Frameworks
You can use the SITUATION framework for incident updates, escalations and handovers alike:
Some organisations instead use the shorter, healthcare-derived SBAR framework — Situation, Background, Assessment, Recommendation:
Situation:
Production users cannot authenticate.
Background:
Issue started after firewall maintenance.
Assessment:
Authentication servers are healthy, but application servers cannot
connect to them on TCP 443.
Recommendation:
Network team should validate the new firewall rules.Both frameworks are doing the same underlying job as the five questions from Lesson 1 — they just give you a fixed order to fill in under pressure, when it's easy to forget a piece.
2 Common Mistakes & the Pre-Send Checklist
The most common communication mistakes, in no particular order: too little information ("it doesn't work"), too much irrelevant information (ten pages of logs with no explanation), no timestamps, no timezone, no clear next action, speculation presented as fact, blaming other teams, excessive jargon, ignoring the business impact, and failing to document decisions.
Before sending an important technical message, run it against this checklist:
- Is the issue clearly explained, and have I explained the impact?
- Have I included timestamps and the timezone?
- Have I separated facts from assumptions, and provided evidence?
- Have I explained what has already been tested?
- Is there a clear next action, and does every action have an owner?
- Have I removed passwords or sensitive credentials?
- Is the message suitable for the audience? Could someone unfamiliar with the incident understand it?
3 Ticket Quality: Two Versions of the Same Problem
The value of everything in this module shows up most clearly in something as ordinary as a support ticket. Compare:
Ticket A: "VPN broken. User can't connect. Please investigate."
Ticket B lists the user, device, location, VPN client version, start time, exact error, confirms internet/DNS/MFA all work, notes the VPN gateway is responding, flags a password change that morning, and suggests validating cached VPN credentials as the next step.
Which ticket gets resolved faster, and why?
Reveal the answer
Ticket B, by a wide margin — not because it's longer, but because every line either rules something out or points at the likely cause. Whoever picks up Ticket A has to start from zero: ask what VPN client, ask what error, ask what's already been tried. Whoever picks up Ticket B can go straight to testing the cached-credentials hypothesis. This is the entire module in miniature: a ticket, an escalation, and an executive update are all the same exercise — reduce the reader's uncertainty as much as you can before they even ask a question.
4 Practice: Rewrite, Bridge, Escalate, Explain, Document, Handover, Brief
Work through each of these the way you would a real assignment — draft your own answer before revealing the model version.
Exercise 1 — Rewrite the Email
Rewrite this professionally: "Hi, We checked and the system looks fine. It's probably your network. Please investigate. Thanks."
Draft your rewrite, then compare.
Reveal a model answer
Hello,
We reviewed the authentication service and confirmed that all nodes
are currently healthy.
Requests from the application servers do not appear in the
authentication logs, which suggests that the connection may be
interrupted before reaching the service.
Could your network team please verify connectivity from the
application servers to the authentication endpoint on TCP 443?
A packet capture from the application server during a failed request
would also help confirm where the connection stops.
Kind regards,
Technical SupportExercise 2 — Run an Incident Bridge
At 09:00 UTC, users report they cannot access a banking application. Application, Network, Database, IAM and SOC teams are available.
Using Lesson 3's structure, what are the steps you'd take running this bridge from start to close?
Reveal a model answer
Declare the incident and state impact in one sentence; assign investigation tasks to each team by name (not "does anyone have ideas?"); maintain a running action-log timeline as findings come in; provide management updates at a fixed interval even with no new finding; coordinate teams so only one is actively testing a given hypothesis at a time; periodically summarise what's been ruled out; and once resolved, summarise findings and formally close the incident with a final update.
Exercise 3 — Write an Engineering Escalation
MFA push notifications fail for Android users but work for iPhone users.
Using Lesson 3's escalation package structure, what fields would you fill in?
Reveal a model answer
Affected versions and app builds for both platforms; environment (auth service version, MDM/device management in use); reproduction steps; logs from both a failing Android attempt and a working iPhone attempt; timestamps; device information (OS version, push token registration status); expected vs. actual behaviour; and tests already completed (e.g. confirmed push provider connectivity, confirmed the token registers correctly, ruled out a network-side block). The Android-vs-iPhone split itself is the single most useful piece of evidence in the whole package — it immediately narrows the investigation to something platform-specific in push delivery or token registration.
Exercise 4 — Explain OAuth to Four Audiences
Explain OAuth to: a junior IT technician, a developer, a project manager, and a senior executive.
How would each explanation differ in depth?
Reveal a model answer
Junior technician: "OAuth lets an app get permission to act on your behalf without ever seeing your password — it gets a temporary token instead." Developer: "The client redirects to the authorization server, the user authenticates and consents, and the client receives an access token (and optionally a refresh token) to present to the resource server on each request." Project manager: "OAuth is the standard method our applications use to let users log in securely without each application having to store passwords itself." Executive: "OAuth is an industry-standard way of proving who a user is without passing their password around between systems — it reduces the risk of a password being exposed if any one system is compromised." Same protocol, four completely different appropriate depths.
Exercise 5 — Write a Handover
You're handing off a partially-investigated incident at 16:30 UTC to another support region.
What must the handover include so the next region can continue immediately, per Lesson 4's structure?
Reveal a model answer
Issue, impact, timeline, findings so far, actions completed, actions outstanding, customer expectations already set (including the timestamp of the last customer update), and the time of the next promised update. Anything explicitly risky — like "do not restart both authentication nodes simultaneously" from Lesson 4's example — needs to be called out prominently, not buried in a paragraph.
Exercise 6 — Executive Translation
Technical finding: "Java application thread pool is exhausted because LDAP authentication requests are waiting 30 seconds for responses from Domain Controller DC03 after a routing change."
Convert this into an executive-level update.
Reveal a model answer
"Users are experiencing intermittent login failures because one of the authentication paths is responding too slowly following a network change. The network and identity teams are working to restore normal service." Every implementation detail (thread pools, LDAP, DC03) is gone; impact, cause category, and ownership survive.
Exercise 7 — Write a Knowledge Base Article
You've just resolved: DNS resolves an old server IP after a migration.
Using Lesson 4's KB structure, what would you write?
Reveal a model answer
Symptoms: Client machines connect to the pre-migration IP address after the DNS record was updated. Environment: Windows and Linux clients using local DNS caching. Cause: Client-side DNS cache retained the old record past its TTL, or a local hosts-file entry overrides DNS entirely. Resolution: Flush the local DNS cache — ipconfig /flushdns on Windows, resolvectl flush-caches on modern Linux (legacy distributions may use a different caching service). Verification: nslookup/Resolve-DnsName returns the new IP. Additional notes: If flushing the cache doesn't help, check authoritative DNS, recursive DNS, TTL, hosts files, load balancers and proxy caching before assuming the migration itself failed.
5 Final Principle
Technical communication is not about using complicated language. The goal is to transfer understanding. A strong IT professional should be able to take something complicated — TCP, DNS, Kerberos, SAML, OAuth, PKI, API authentication, firewalls, databases, cloud infrastructure — and explain what is happening, why it matters, what the evidence shows, and what needs to happen next.
The best engineers do more than solve problems. They make complicated situations understandable. That skill becomes increasingly valuable as you move from Help Desk to Support Engineer to Systems/Network Engineer to Security Engineer to Senior Engineer to Technical Lead to Architect to Engineering Manager to Director. At senior levels, your ability to communicate technical information can become just as important as your ability to understand the technology itself.
Module 17 Complete
By completing this module you should now be able to write professional customer emails; communicate clearly during technical incidents; run structured troubleshooting bridge calls; prepare strong technical escalations; communicate with developers and engineers; write useful Knowledge Base articles; explain complex technologies in simple language; communicate differently with technical and non-technical audiences; provide executive-level incident updates; perform effective global support handovers; document technical investigations; separate facts from assumptions; communicate risk professionally; maintain clear incident timelines; communicate effectively across global teams; avoid exposing sensitive information; and write messages that clearly define ownership and next actions.
Mark this lesson complete to close out Module 17, and continue to Module 18 – Ticket Management.