Level 6 · In practice

6.2Recurring problems (playbook)

Goal: have a “symptom → causes → actions” playbook for common incidents.

Estimated time: 12 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

Diagnose: a symptom = likely causes = a sequence of actions — you don’t fix things at random.
Order: from simple to complex (physical, IP, DNS), one change at a time, otherwise you no longer know what fixed what.
Root: a ticket that keeps coming back isn’t eight incidents, it’s ONE underlying problem to treat at the root.

Sofiane’s thread — the table taped next to the screen

Sofiane keeps this playbook next to his support screen in Algiers. Verdict after a quarter: three lines served him the most — “I have no more Internet,” the printer not found and the locked account. For each, he ended up applying the sequence (symptom, causes, actions) instead of trying random fixes.

Observed symptom, verified causes, actions in order: the reflex fits in three beats.

One reflex per symptom

Most tickets are great classics. Linking each symptom to its likely causes and to a sequence of actions saves precious time, especially in N1 support.

From simple to complex

You test the simplest layer first (cable, power, IP) then climb up (gateway, DNS, service). One change at a time, otherwise you no longer know what fixed what.

Treat the root

The same ticket coming back is not inevitable: it’s an underlying problem (a saturated box, a poorly framed DHCP range, a poorly covered room) to treat at the root.

Symptom	Likely causes	Actions
“I have no more Internet”	169.254 (no DHCP), gateway down, cable/port, or DNS	ipconfig → ping gateway → ping 8.8.8.8 → ping a name → tracert
“The site won’t open” (others do)	DNS, stale cache, or the site really down	test by IP; change/flush DNS; try from another network
“Printer not found”	off/off-network, IP changed, share/driver	check power/network; DHCP reservation; reinstall the driver
“Network drive disconnected”	server/share unavailable, permissions, session	ping the server; check share + rights (group); reconnect
“It’s slow”	insufficient RAM, HDD disk, saturated network, software	task manager; RAM/SSD; test throughput; isolate the app
“Account locked / password forgotten”	forgotten, lockout, lost MFA	reset; unlock; re-enroll MFA

Common misinterpretation: “the table replaces diagnosis.” No. The playbook gives likely causes, not a verdict: observe the symptom, verify the cause (DHCP, gateway, DNS, share, resources), then apply the targeted action.

Text version of the diagram (SEO / screen readers / translation): 1) Name the observed symptom (“no more Internet,” site unreachable, printer not found, drive disconnected, slowness, locked account). 2) Draw on the table’s likely causes without concluding on your own (DHCP, gateway, DNS, IP, share, permissions, resources). 3) Apply the actions in order, from simple to complex (ping gateway → ping 8.8.8.8 → ping a name → tracert). 4) Fix at the root (a ticket that returns = an underlying problem: reserve IPs, frame the DHCP range, cover the room). Lesson: a recurring error calls for a setting, not random fixes.

Script ready to say — diagnosing without improvising (30 s)

“My symptom: [no more Internet / printer not found / slow]. I check the likely cause from the playbook (DHCP, gateway, DNS, resources), apply the targeted action and confirm with proof.”

The reflex fits in three beats: symptom, cause, action.

Script ready to say — separating network and DNS (30 s)

“I ping the gateway, then 8.8.8.8, then a name. If the IP works and the name doesn’t, it’s a DNS problem; if nothing works, I climb back to the link or the DHCP.”

Always test IP before name.

Copy-paste template — network sequence

ipconfig /all            -- IP? 169.254 = no DHCP
ping            -- local link OK?
ping 8.8.8.8             -- Internet OK?
ping www.example.com     -- DNS OK?
tracert www.example.com  -- where is it blocked?

Copy-paste template — express ticket sheet

Symptom : [what the user sees]
Cause   : [verified, not assumed]
Action  : [one change at a time]
Proof   : [what I retested]
Root?   : [isolated ticket or underlying problem]

Very small business / small budget

No formal table: a symptom, the likely cause, the action and the proof, noted on a sheet.

Algiers SME

Build the local realities into the diagnosis: a single Internet link, outages, heterogeneous hardware, content in French.

Remote / hybrid

Add a screenshot to the diagnosis: at a distance, a written symptom and proof avoid back-and-forth.

Intercultural

Make observations explicit in writing: what seems obvious (which service, which format) isn’t for everyone.

Caution: Generic reminder: the same error coming back isn’t ten incidents — fix the design at the root (DHCP, reservations, coverage) and keep a snapshot of the workstation before any mass repair.

48h challenge — apply it tomorrow

Spot 1 current symptom (no more Internet, printer not found, slowness, locked account), apply the playbook line (named symptom + verified cause + targeted action) and prove it.

Section exit checklist

I can link a symptom to its likely causes.
I verify from simple to complex, one change at a time.
I distinguish an isolated ticket from an underlying problem.

Self-assessment 1-5: diagnosis before correction?systematic proof after correction?

← Previous : Case studies (V3)Next : Best practices & pitfalls (V3) →

Check your understanding

Sofiane sees a workstation at 169.254 and “no more Internet.” Which reflex does the playbook apply?

💡

Reflex: name the symptom, verify the cause, apply the targeted action — and spot the underlying problem behind a ticket that returns.