Session 6: Support Simulation
The final assessment: live simulated calls with escalating pressure, escalation decisions made against real rules, and completion of the support playbook that is this course's deliverable.
Learning objectives
By the end of this session you will be able to do each of these without prompting.
- Handle live support calls under realistic pressure while keeping method intact
- Make escalation decisions against defined rules rather than under social pressure
- Combine technical diagnosis with the communication skills from session three
- Complete a support playbook that another person could actually run a helpdesk from
- Articulate your own strengths and gaps honestly as you enter the job market
The taught content
Why the last session is a simulation and not a summary
Everything in this course has been practised on faults you knew were coming, in your own time, without anybody watching. The job is not like that. In the job, three problems arrive at once, one user is angry, a manager is asking how long it will take, and you have not seen this particular fault before. The gap between knowing the method and using it under pressure is the thing this session closes.
So the assessment is live. Simulated calls arrive with symptoms described in user language, some deliberately vague, some genuinely urgent, and a few that are not urgent at all but arrive with urgency attached. You triage, diagnose, communicate and document, and you are assessed on method under pressure at least as much as on getting the right answer — because a correct answer reached by guessing is not a skill you can rely on tomorrow.
This is also where the course deliverable is finished: a support playbook covering the ten most common faults, with diagnostic steps, fixes and escalation rules. You have been building it since session one. Today it becomes the complete artefact, and it is the thing that distinguishes you from every other candidate for a first IT job.
Escalation: the decision that separates competent from reckless
Escalation means passing a problem to somebody with more access, more authority or more specialist knowledge. Beginners fear it because it feels like admitting failure; experienced people use it constantly because it is the fastest route to a resolution. Escalating early with good notes is professional. Escalating late, or not at all, is how small problems become incidents.
The rules that make it a decision rather than a feeling are worth writing down, which is why your playbook contains them. Escalate when: the fix is beyond your access or authority — a server change, a firewall rule, a vendor-only repair. When a business-critical system is affected and time is running out — the customs software on a clearance day. When you have made no progress within a defined period, which you set in advance so that pride cannot extend it indefinitely. And when the fault is outside your knowledge entirely, because a specialist will take ten minutes where you would take a day.
Then how to escalate well, which matters as much as when. Never escalate empty-handed: hand over the symptom in the user's words, what you checked, what you ruled out, what you changed, and your current hypothesis. That record is the difference between a colleague picking up in two minutes and starting from zero — and it is the same discipline as ticket writing, applied at the moment it matters most. Escalating with nothing written is not escalation; it is transferring your confusion.
Working under pressure without losing the method
Pressure produces two characteristic failures. The first is abandoning sequence — skipping reproduction, guessing at fixes, changing several things at once. It feels faster and it is slower, because an unattributed fix gets reverted and retried. The second is going silent — heads down, no communication, while the user and the manager both imagine the worst. Silence reads as incompetence even when the work is going well.
The counter to both is the same: narrate the stage you are in. 'I have reproduced it, I am isolating whether it is the profile or the machine, that will take about ten minutes.' That single sentence keeps your own reasoning honest, gives the user an informed wait, and tells a manager that something controlled is happening. It costs fifteen seconds and it changes how the whole interaction is perceived.
Then the queue discipline. When three problems arrive at once, triage before you touch any of them, not after starting the first. The instinct is to begin with whoever spoke loudest or arrived first, which is precisely the wrong ordering. Take two minutes, assign priority by impact, tell each person where they sit in the queue and roughly when you will reach them, and then work in order. An honest queue position is calming; an unexplained wait is not.
The playbook: what makes it a real document rather than coursework
The deliverable is ten faults, and the test of quality is simple: could somebody else run this helpdesk from it without calling you? That standard governs what goes in. For each fault you need the symptoms in the user's language — because that is how it will be reported — the diagnostic steps in order, the specific fix, and the escalation rule saying when to stop and hand it over.
Three things separate a real playbook from a list of fixes. Order matters and is stated: 'check free space first, then startup items, then memory' is a diagnostic procedure, whereas listing three possible causes is not. Negative findings are included: what to check that will probably be fine, because ruling things out is most of diagnosis and the next person needs to know what to eliminate. And escalation is explicit: a fault with no stated hand-off point is a fault someone will struggle with for six hours out of uncertainty about whether they are allowed to ask.
Then the sections that make it an operational document rather than a technical one: the priority bands and service levels from session one, the ticket standard and the identity verification procedure from sessions one and three, and the asset register from session five. Together those mean a new person joining the support function can be productive in days rather than months — which is exactly what a manager is buying when they hire someone who arrives with a playbook.
Entering the job market with something to show
Most candidates for a first IT support job can describe troubleshooting. Very few can show a structured approach, a documentation standard, and a completed playbook. That difference is worth a great deal in an interview, because it converts a claim into evidence — and because it demonstrates the specific quality employers struggle to find in entry-level candidates: the habit of writing things down.
Be honest about the boundary of what this course gives you. You have method, communication skill and documentation discipline, which transfer to any environment. You have not accumulated years of pattern recognition, and you will meet faults you cannot solve. Say so plainly in an interview: it reads as maturity rather than weakness, and it is far more credible than claiming expertise you do not have. What you can promise is that you will diagnose systematically, communicate clearly, and leave everything documented — which is genuinely most of the job.
The natural progression from here runs through the adjacent courses. Computer Networking deepens the infrastructure side, and Cybersecurity builds directly on the identity verification, access control and update discipline you have practised here. Support is the standard entry point into IT precisely because it exposes you to every layer at once, and the people who progress fastest are the ones who documented what they learned along the way.
Instructor demonstration
The final assessment. Simulated calls arrive under time pressure with deliberate vagueness and manufactured urgency; the candidate triages, diagnoses, communicates, escalates and documents, then presents the completed playbook.
- 01
Brief the assessment conditions
Eight calls across ninety minutes, symptoms in user language only, some vague, some genuinely critical, some urgent-sounding but low impact. The client and the manager are both played by the instructor. Method is assessed alongside outcome.
- 02
Establish your queue before taking the first call
Have your ticket format, priority bands and escalation rules open and ready. Under pressure you fall back on what is prepared; improvising a format while handling a call is how notes get lost.
- 03
Take call one: a vague report
'The computer is acting funny.' Do not guess. Ask them to show you, preserve their words, and reproduce before investigating. The first thirty seconds determine whether the next ten minutes are useful.
- 04
Take call two while call one is open, and triage between them
A second problem arrives mid-diagnosis. Assess impact against urgency, decide the order out loud, and tell the first user where they now sit. Resisting the impulse to just finish what you started is the skill being tested.
- 05
Take call three: manufactured urgency on a low-impact problem
A senior person is irritated about something that is genuinely medium priority. Apply the published bands without offence, explain the reasoning, and offer a realistic time. Do not let rank set the queue.
- 06
Narrate your stage throughout
'I have reproduced it, I am isolating profile against machine, about ten minutes.' Fifteen seconds of communication that keeps your reasoning honest, gives the user an informed wait, and shows the manager something controlled is happening.
- 07
Take call four: a business-critical failure
The customs software will not open and a shipment must clear today. This is critical, and the pressure is real. Move fast but do not skip reproduction or isolation — speed without method produces changes you cannot attribute.
- 08
Recognise the escalation point and take it
The fix requires a server change beyond your access. Escalate immediately rather than after an hour of struggling. Knowing the boundary of your access and acting on it quickly is the competence being assessed, not a failure.
- 09
Escalate with a complete handover
Hand over the symptom in the user's words, what you checked, what you ruled out, what you changed, and your hypothesis. Escalating with nothing written is transferring your confusion rather than the problem.
- 10
Keep the user informed after escalating
Escalation is not the end of your responsibility. Tell the user who has it, what happens next and when you will update them. Abandoning the user at the handover is the most common way to lose their trust.
- 11
Take call five: a password reset under social pressure
The caller is in a hurry, is irritated, and presses you to skip verification. Apply the procedure identically to everyone, decline calmly, and escalate if the pressure continues. This is the exact shape of the attack that breaches organisations.
- 12
Take call six: a fault you have not seen before
Nothing in the playbook matches. Fall back to the method: reproduce, isolate by layer, run the three isolating tests, change one thing. The assessment is whether the method holds when recognition fails — which is the situation you will be in regularly.
- 13
Say so when you are stuck
State what you have eliminated and what you are examining next. A partial diagnosis that genuinely narrows the problem is more useful and better assessed than a rushed guess, and it is what a professional actually does.
- 14
Handle the interruption that is not a fault
Somebody asks how to do something rather than reporting a problem. Answer briefly, and note whether it belongs in the knowledge base. Recurring how-to questions are documentation gaps, and spotting them is part of the job.
- 15
Manage the queue honestly at the ninety-minute mark
State what is resolved, what is open, what was escalated, and who will be told what. Proactive notification of anything unfinished matters more than having finished everything, because the latter is not always possible.
- 16
Write every ticket to the standard while it is fresh
Symptom in the user's words, ruled-out findings, environment, specific change, fix or workaround, user confirmation. Written immediately, because accuracy decays within hours and a late note is a reconstruction.
- 17
Review your own performance against the method
For each call, identify which stages you completed and which you skipped under pressure. Name the skips honestly — they are the specific things to work on, and self-assessment accuracy is itself part of professional maturity.
- 18
Complete the playbook's ten fault entries
Each with symptoms in user language, diagnostic steps in a stated order, negative findings to check, the specific fix, and an explicit escalation rule. Add the faults from today, which are the ones you have actually worked under pressure.
- 19
Attach the operational sections
Priority bands and service levels, the ticket standard, the identity verification procedure, the remote session procedure, the asset register and the documentation maintenance routine. These are what let someone else run the function, not just fix faults.
- 20
Present the playbook as though to an employer
Ten minutes: what it is, how it is structured, what it would let a new person do, and where its gaps are. Being clear about the gaps reads as maturity and is far more credible than claiming completeness you do not have.
Guided practice
The final practical: live calls, escalation, and the completed playbook
Work simulated support calls under time pressure with method assessed alongside outcome, make escalation decisions against defined rules, and deliver the complete support playbook.
- 01Prepare your ticket format, priority bands and escalation rules before the first call rather than improvising them under pressure.
- 02Handle at least eight calls across ninety minutes, logging each before investigating.
- 03Take a deliberately vague report and convert it by observation rather than guessing.
- 04Triage between two simultaneous problems and tell the waiting user where they now sit.
- 05Apply the published priority bands to a senior person's low-impact problem without offence.
- 06Narrate your current stage and time estimate on every call.
- 07Handle a business-critical failure quickly without skipping reproduction or isolation.
- 08Recognise the escalation point and escalate immediately rather than after an hour of struggling.
- 09Escalate with a complete handover: symptom, checks, ruled-out findings, changes, hypothesis.
- 10Keep the user informed after escalating, including who has it and when you will update them.
- 11Decline pressure to skip identity verification on a password reset, and escalate if it continues.
- 12Work a fault not covered by your playbook by falling back to the method rather than recognition.
- 13State clearly what you have eliminated when you are stuck, rather than guessing to appear productive.
- 14Answer a how-to question and record it as a knowledge base gap.
- 15Give an honest end-of-session account of what is resolved, open, escalated and pending notification.
- 16Write every ticket to the standard immediately while the detail is fresh.
- 17Review your own performance stage by stage and name honestly which stages you skipped.
- 18Complete ten playbook entries with stated diagnostic order, negative findings and escalation rules.
- 19Attach the operational sections: bands, service levels, ticket standard, verification, remote procedure, asset register, maintenance routine.
- 20Present the playbook and its gaps as though to a prospective employer.
The standard we hold you to
At least eight calls handled under time pressure with every one logged before investigation; triage performed between simultaneous problems using the published bands, including against a senior person's low-impact request; stage narration on every call; a business-critical failure handled quickly without skipping reproduction or isolation; escalation taken promptly at the defined point with a complete written handover and the user kept informed afterwards; pressure to skip identity verification declined and escalated; an unfamiliar fault worked by method rather than recognition; honest self-review naming skipped stages; **a completed playbook of ten faults with stated diagnostic order, negative findings and explicit escalation rules, plus the operational sections** — delivered to the standard that another person could run the helpdesk from it.
Common mistakes and how to fix them
Starting the first call before preparing your queue and format
Fix: Under pressure you fall back on what is prepared. Have the ticket format, priority bands and escalation rules open before you begin, because improvising them mid-call is how notes get lost.
Abandoning the method when the pressure rises
Fix: Skipping reproduction and changing several things at once feels faster and is slower, because an unattributed fix gets reverted and retried. The method is what keeps you moving purposefully.
Going silent while working hard
Fix: Silence reads as incompetence even when the work is going well. Narrate the stage you are in — fifteen seconds that changes how the whole interaction is perceived.
Working in arrival order rather than priority order
Fix: Triage before touching any of them. Beginning with whoever spoke loudest is precisely the wrong ordering, and an honest queue position calms users more than speed does.
Struggling for an hour instead of escalating
Fix: Set the no-progress period in advance so pride cannot extend it. Escalating early with good notes is professional; escalating late is how small problems become incidents.
Escalating without a written handover
Fix: Pass the symptom, what you checked, what you ruled out, what you changed and your hypothesis. Otherwise you are transferring your confusion rather than the problem.
Abandoning the user at the handover
Fix: Tell them who has it, what happens next and when you will update them. Losing a user's trust at the escalation point undoes everything you did well before it.
Claiming completeness you do not have
Fix: Present the playbook with its gaps named. It reads as maturity, it is more credible, and it is far better received than an overstated claim an interviewer can puncture with one question.
Expert notes
The habits that separate someone who can do this from someone who does it well.
- Escalate early and escalate with notes. The fear that escalation looks like failure is exactly backwards: a colleague with your findings resolves in minutes what you would take a day over, and the written handover is the same ticket discipline you have practised all course, applied at the moment it matters most.
- Narrate your stage on every call. It keeps your own reasoning honest, converts an anxious wait into an informed one, and signals to a manager that something controlled is happening. Fifteen seconds of speech, and it changes how the entire interaction is judged.
- Set your no-progress escalation period in advance, in writing. Deciding it in the moment means deciding it while tired, watched and reluctant to admit difficulty — which is precisely when pride extends it by another hour.
- Name your gaps honestly as you enter the job market. You have method, communication skill and documentation discipline; you do not have years of pattern recognition. Saying so reads as maturity, and the promise that you will diagnose systematically and leave everything documented is genuinely most of what an employer is hiring for.
Key terms
- Escalation
- Passing a problem to someone with more access, authority or specialist knowledge. Used early with good notes it is the fastest route to resolution, not an admission of failure.
- Escalation rule
- A written condition triggering hand-off: beyond your access, business-critical with time running out, no progress within a defined period, or outside your knowledge.
- Written handover
- The symptom, checks performed, findings ruled out, changes made and current hypothesis, passed with an escalation. Without it you transfer confusion rather than the problem.
- Stage narration
- Stating the diagnostic stage you are in and roughly how long it will take. Keeps reasoning honest, informs the user, and signals controlled progress to a manager.
- Queue discipline
- Triaging everything before starting anything, then working in priority order and telling each user where they sit. Arrival order and volume are both wrong orderings.
- No-progress period
- A time limit set in advance after which you escalate rather than continue. Deciding it beforehand prevents pride from extending it under pressure.
- Support playbook
- The operational document covering common faults with diagnostic order, fixes and escalation rules, plus bands, ticket standard, verification and asset records.
- Diagnostic order
- A stated sequence of checks for a fault, including what to rule out. A list of possible causes is not a procedure; an ordered set of checks is.
Homework before the next session
Complete the live simulation
At least eight calls in ninety minutes with method assessed alongside outcome: every call logged before investigation, triage between simultaneous problems, stage narration throughout, and honest self-review naming any skipped stages.
Write your escalation rules
The conditions that trigger hand-off, the no-progress period you will hold yourself to, what a complete written handover contains, and how you will keep the user informed after escalating.
Deliver the complete support playbook
Ten faults with symptoms in user language, stated diagnostic order, negative findings, specific fixes and escalation rules; plus priority bands, service levels, ticket standard, identity verification, remote procedure, asset register and maintenance routine.
Present the playbook to a non-technical audience
Ten minutes covering what it is, how it is structured, what it lets a new person do, and where its gaps are. Practise being precise about the boundary of your own knowledge — it is the most credible thing you can do in an interview.
Assessment rubric
How this session is marked. The certificate for IT Support is awarded on the deliverable, not on attendance.
| Criterion | Passing | Excellent |
|---|---|---|
| Method under pressure | Most calls were resolved. | Reproduction and isolation maintained throughout, one change at a time, every call logged before investigation, and skipped stages identified honestly in self-review. |
| Triage and prioritisation | Calls were handled in a reasonable order. | Triage performed before starting work, priority applied by impact against urgency including to a senior person's low-impact request, and each user told where they sit in the queue. |
| Escalation judgement | Escalated when clearly necessary. | Escalated at the defined point without delay, with a complete written handover, and the user kept informed afterwards about who has it and when they will be updated. |
| Communication | Was polite and clear. | Stage narration on every call, no jargon, identity verification held under social pressure, and an honest end-of-session account including anything unfinished. |
| Playbook deliverable | A set of fixes was documented. | Ten faults with stated diagnostic order, negative findings and explicit escalation rules, plus all operational sections — to the standard that another person could run the helpdesk from it. |
Session questions
Does escalating make me look incompetent?+
The opposite. Escalating early with good notes is how experienced people work, because a colleague with your findings resolves in minutes what you would take a day over. Escalating late, or not at all, is what turns small problems into incidents.
What if I get a fault in the assessment that I cannot solve?+
State what you have eliminated and what you are examining next, then escalate with a full handover. A partial diagnosis that genuinely narrows the problem is more useful — and better assessed — than a rushed guess that happens to work.
How do I handle three problems arriving at once?+
Triage before touching any of them. Assign priority by impact, tell each person where they sit and roughly when you will reach them, then work in order. An honest queue position is calming; an unexplained wait is not.
What is actually worth showing an employer from this course?+
The playbook. Most entry-level candidates can describe troubleshooting; almost none can show a structured approach, a documentation standard and a completed operational document. It converts a claim into evidence.
What should I learn next?+
Computer Networking deepens the infrastructure side, and Cybersecurity builds directly on the identity verification, access control and update discipline you have practised here. Support is the entry point to IT because it touches every layer at once.
This session is part of
IT Support
3 weeks · 6 sessions · ₦40,000 · you leave with a support playbook