Session 1: How Support Works
What an IT support function actually is: how work arrives, how it gets triaged and prioritised, what a ticket is for, what service levels really mean — and what separates support people who get trusted from those who get worked around.
Learning objectives
By the end of this session you will be able to do each of these without prompting.
- Explain what a helpdesk does and why it exists as a function rather than a favour
- Triage incoming problems and assign priority using a defensible method
- Write tickets that are useful to the next person, not just to you
- Understand service levels and what they genuinely commit you to
- Describe what good support looks like from the user's side of the desk
The taught content
The job you are preparing for, and the company we will work with
This course runs around one engagement, because support is learned by doing it rather than by describing it. The scenario is real and common: a freight-forwarding company in Apapa with forty-five staff across two offices, Windows machines of mixed ages, a couple of servers in a cupboard, four network printers, a business-critical customs software package that nobody fully understands, and — critically — no IT documentation of any kind. Until now, problems have been handled by whoever was nearest and knew most.
You have just been hired as the company's first dedicated support person. That is the most common entry point into this career in Nigeria, and it is harder than joining an established helpdesk, because there is no queue to join, no playbook to follow, and no colleague to ask. Everything you build in this course — the triage method, the ticket habit, the playbook — is what makes that position survivable.
The deliverable is a support playbook covering the ten most common faults, with diagnostic steps, fixes and escalation rules. That document is not coursework; it is the artefact a real helpdesk runs on, and it is the thing you can show an employer that proves you understand the job rather than merely wanting it.
Why support exists as a function, and what happens without one
Before there is a support function, there is an unofficial IT person — somebody who happened to be good with computers and gradually acquired everyone else's problems on top of their actual job. Every Nigerian office has one. It looks like a favour and it is actually an unmanaged risk: the person has no time allocated, no record of what they changed, and no authority to say no.
The consequences are predictable and worth understanding, because you will see them on day one. Nobody knows what was changed, so faults recur and nobody can trace them. Work is invisible, so it is never prioritised — the person doing it is judged on their real job while carrying an unmeasured second one. And the knowledge lives in one head, so when that person leaves, everything they knew leaves with them. That last point is why your playbook matters commercially, not just academically.
A support function exists to change all three. Work arrives through one channel, gets recorded, gets prioritised against business impact, and gets documented so the next person can repeat it. That is the entire purpose: not to fix computers, but to make fixing computers predictable, visible and independent of any individual. Hold that framing, because it explains every process decision in this session.
How work arrives, and why one channel matters more than any tool
In an organisation without support, problems arrive by WhatsApp, a shout across the room, a phone call, and somebody walking to your desk — simultaneously, with no order and no record. The single most valuable change you can make in your first month is not a tool; it is establishing that requests come through one place. Everything else follows from that.
This is harder than it sounds, because the informal channels are more convenient for the user and you will be under pressure to keep accepting them. The professional answer is not to refuse people but to redirect consistently and kindly: acknowledge the problem, then say you are logging it so it is not lost and so it can be prioritised fairly. Within a few weeks the habit forms. The channel is not bureaucracy; it is what makes your work visible and your promises keepable.
The practical minimum is small. You do not need expensive software — a shared mailbox, a simple ticketing system, or even a structured spreadsheet will do at this scale. What you need is that every request has a record: who reported it, what the problem is, when it arrived, what was done, and when it was resolved. That record is what turns support from a series of favours into a function that can be measured, staffed and improved.
Triage and priority: impact against urgency, decided in the first two minutes
Triage is the quick assessment that decides what order things get handled in, and it is the highest-leverage skill in this session. The method that works is two questions, not one. What is the impact — how many people are affected, and how badly? How urgent is it — is work stopped now, or merely inconvenient? A problem affecting one person completely is different from a problem mildly annoying forty people, and neither is automatically the higher priority.
That gives four practical bands. Critical: business-stopping for many people — the network is down, the customs software will not open, the server is unreachable. High: one person cannot work at all, or a system is degraded for many. Medium: work is possible but impaired — a printer is down and another is available. Low: cosmetic, a request, or something that can wait. Note that a senior manager's personal inconvenience is not automatically critical; priority follows business impact, and the moment you let rank set priority you lose the ability to defend any other decision you make.
Then the part beginners consistently get wrong: the loudest request is not the most important one. Somebody who walks to your desk and stands there has expressed urgency, not impact. Meanwhile a silently failing backup is affecting nobody today and will affect everybody next month. Triage on impact, respond on urgency, and record both — that combination is what makes your queue defensible when somebody asks why their problem was not first.
Tickets: what they are actually for, and what makes one useful
A ticket is not paperwork. It is the memory of the support function — the record that lets somebody other than you pick up a problem, that lets you spot a recurring fault, and that lets you prove what you did. A support person who keeps no tickets is personally effective and organisationally invisible, and when they leave, everything they knew leaves too.
A useful ticket has a predictable shape. Who reported it and how to reach them. What the problem is, in the user's own words first — their description is evidence, even when it is wrong, because 'the internet keeps cutting' and 'the printer says offline' point in different directions. When it started and whether anything changed. What you found, including the things you ruled out, because negative results are information. What you changed, specifically. And how it was confirmed fixed, ideally by the user rather than by you.
The habit that most distinguishes professionals is recording what did not work. Beginners write what they did; experienced people write what they tried and eliminated. That difference is worth hours to the next person, because it prevents them repeating your dead ends. Write the ticket as though the next reader is you in six months with no memory of the job — because frequently it is.
Service levels, and what good support actually looks like to a user
A service level is a commitment about response and resolution time, usually expressed per priority band — for example, critical problems responded to within fifteen minutes, high within two hours, medium within one working day. Two things matter about them. First, response is not resolution: responding means somebody has acknowledged and started, not that it is fixed, and confusing the two produces broken promises. Second, a service level you cannot meet is worse than none, because it converts an honest delay into a failure against a stated commitment.
Set them from your actual capacity, then measure against them. At this company, with one support person and forty-five staff, realistic figures might be fifteen minutes for critical, four hours for high, one working day for medium and three days for low. Publish them, and — this is the part that builds trust — tell people when you are going to miss one, before you miss it. A user who is told at 10am that their problem will be tomorrow is annoyed; a user told at 5pm that it will be tomorrow is angry.
Then what good support looks like from the other side of the desk, because it is not primarily technical. Users remember whether you listened before typing, whether you explained what you were doing, whether you came back when you said you would, and whether you treated the problem as real even when the cause was trivial. Technical skill gets the fault fixed; these behaviours get you trusted, and trusted support people are given the information that makes the next diagnosis faster. That loop is the actual job.
Instructor demonstration
We stand up the support function for the freight company from nothing: one intake channel, a triage method, a ticket format, published service levels — and we work a live morning queue against it.
- 01
Survey what support currently looks like
Ask five staff members how they currently get help. You will hear WhatsApp, shouting, and the name of whoever used to fix things. Record it verbatim — this is the baseline you are replacing, and it is evidence for why the change matters.
- 02
Count the machines and users before setting any targets
Forty-five staff, two offices, and a rough machine count. You cannot set realistic service levels without knowing the population you serve, and setting them from a guess is how support people burn out in month two.
- 03
Choose one intake channel and set it up
A shared email address is the lowest-friction starting point in a Nigerian office, because everyone already has email and it creates a record automatically. Whatever you choose, it must produce a written record with a timestamp.
- 04
Announce it without making it feel like a barrier
Send one short message: here is where to send problems, here is what happens next, here is roughly how long each priority takes. Frame it as 'so nothing gets lost', never as 'stop messaging me personally'. The framing determines whether people comply.
- 05
Define the four priority bands in writing
Critical, high, medium, low — each with a plain-language definition and two examples from this company. Examples matter more than definitions, because 'business-stopping' means different things to different people until you show them.
- 06
Set service levels from real capacity, not ambition
Fifteen minutes to respond on critical, four hours on high, one working day on medium, three days on low. Write them down. A level you cannot meet converts an honest delay into a broken promise.
- 07
Distinguish response from resolution explicitly
State it in the published levels: response means acknowledged and started; resolution means fixed and confirmed. Confusing the two is the most common way support people over-promise on day one.
- 08
Build the ticket format
Six fields: who and how to reach them; what the problem is in the user's words; when it started and what changed; what you found including what you ruled out; what you changed; how it was confirmed fixed. Keep it short enough that you will actually fill it in.
- 09
Work the first incoming request end to end
A user reports the customs software will not open. Log it before investigating — this is the discipline, and skipping it 'just this once' is how the habit never forms.
- 10
Triage it out loud against the bands
One person, cannot work at all, business-critical software: **high**, not critical, because the company is still operating. Say the reasoning out loud. Priority decisions you cannot explain are decisions you cannot defend later.
- 11
Record the user's own words before your interpretation
Write 'it just closes when I click Open' rather than 'application crashes'. Their phrasing is evidence — 'closes' and 'freezes' and 'shows an error' point at different causes, and your paraphrase destroys that distinction.
- 12
Note what you ruled out, not only what you did
Checked disk space, fine. Checked the licence, valid. Tried a second user account, works. Each eliminated possibility is information the next person will otherwise waste time rediscovering.
- 13
Record the actual change you made
Not 'fixed it' — write the specific change: rebuilt the user's software profile, or reinstalled the print driver, or whatever it was. Vague notes are worthless to anyone else and to future you.
- 14
Confirm with the user and record their confirmation
Ask them to do the thing that failed, in front of you or on a call. A fix you have not had the user verify is a fix you are assuming, and roughly one in five will come back.
- 15
Work a second, competing request and prioritise between them
A manager reports their own laptop is slow while the customs software fault is open. Explain, without offence, why the manager's laptop is medium and the shared software is high. **This conversation is the job**, and practising it here is the point.
- 16
Handle a request that arrives by WhatsApp anyway
Somebody messages you directly. Respond helpfully, then log it in the channel and tell them you have done so. Redirecting consistently and kindly for a few weeks is what establishes the habit — refusing people establishes nothing except resentment.
- 17
Close the day by reviewing the queue
Look at what came in, what was resolved, what is open, and whether any service level was missed. If one will be missed, notify the affected user **before** it is missed. That single habit does more for your reputation than any amount of technical skill.
- 18
Start the playbook document
Open the file that will become the deliverable. Add the first fault you resolved today, with its symptoms, diagnostic steps, fix and escalation rule. Ten faults over three weeks is the target, and you build it from real tickets rather than from imagination.
Guided practice
Stand up a support function and run one real day against it
For a real organisation — your workplace, a family business, or the lab — establish one intake channel, a triage method, a ticket format and published service levels, then work a day's requests through them.
- 01Ask five people how they currently get technical help and record their answers verbatim as your baseline.
- 02Count the users and devices you would be supporting, and note which systems are business-critical.
- 03Choose one intake channel that automatically produces a timestamped written record.
- 04Announce it framed as 'so nothing gets lost', not as a restriction on contacting you.
- 05Write four priority bands with plain-language definitions and two real examples each.
- 06Set response and resolution service levels derived from your actual capacity, not from ambition.
- 07State explicitly that response is not resolution in the published levels.
- 08Build a six-field ticket format short enough that you will genuinely use it.
- 09Log at least three real requests before investigating any of them.
- 10Triage each out loud against the bands and write the reasoning in the ticket.
- 11Record each user's own words before your own interpretation of the problem.
- 12Record what you ruled out, not only what you did.
- 13Record the specific change you made, never just 'fixed'.
- 14Confirm each fix with the user and note their confirmation in the ticket.
- 15Handle at least one request that bypasses your channel, redirecting it kindly.
- 16Review the queue at day end and notify anyone whose service level you will miss, before you miss it.
- 17Add every fault you resolved to the playbook document with symptoms, steps, fix and escalation rule.
The standard we hold you to
A baseline record of how support currently happens; one intake channel established and announced without framing it as a barrier; four priority bands with real examples; service levels set from real capacity with response distinguished from resolution; a six-field ticket format; at least three requests logged before investigation, each triaged with written reasoning, the user's own words preserved, ruled-out findings recorded, the specific change documented, and user confirmation noted; one bypassing request redirected kindly; a day-end queue review with proactive notification of any missed level; and the playbook started from real tickets.
Common mistakes and how to fix them
Accepting requests through every channel simultaneously
Fix: Establish one intake channel and redirect consistently and kindly. Without it your work has no record, no order, and no visibility — and none of it can be measured or handed over.
Letting seniority set priority
Fix: Priority follows business impact. The moment rank decides the queue, you cannot defend any other prioritisation you make, and the function stops being fair.
Treating the loudest request as the most important
Fix: Somebody standing at your desk has expressed urgency, not impact. A silently failing backup affects nobody today and everybody next month. Triage on impact, respond on urgency.
Promising resolution times you cannot meet
Fix: Set service levels from actual capacity and publish the distinction between response and resolution. An honest delay communicated early is survivable; a broken commitment is not.
Investigating before logging
Fix: Log first, every time, including the urgent ones. Skipping it 'just this once' is how the record never exists, and the record is the entire function.
Writing tickets that only record what you did
Fix: Record what you ruled out as well. Negative results save the next person hours, and vague notes like 'fixed it' are worthless to anyone else and to future you.
Paraphrasing the user's description
Fix: Preserve their words. 'It closes' and 'it freezes' and 'it shows an error' point at different causes, and your interpretation destroys evidence before you have used it.
Declaring a fix without user confirmation
Fix: Have the user perform the action that failed, and record their confirmation. Roughly one in five unconfirmed fixes comes back, and it comes back with less goodwill.
Expert notes
The habits that separate someone who can do this from someone who does it well.
- The intake channel is the single highest-leverage change you can make, and it costs nothing. Everything else — prioritisation, service levels, measurement, handover — depends on there being one record of what arrived. Establish it in your first month and the rest becomes possible.
- Record what did not work. This one habit separates experienced support people from beginners more reliably than any technical skill, because it prevents the next person repeating your dead ends and it makes recurring faults visible across tickets.
- Priority must follow business impact rather than rank, and you must be able to explain each decision out loud. The first time you defer a manager's laptop in favour of a shared system is uncomfortable; being able to state the reasoning calmly is what earns you the right to make the next one.
- Proactive communication about a missed deadline is worth more than technical brilliance. Telling a user at 10am that their problem will be resolved tomorrow is a minor annoyance; telling them at 5pm is a breach of trust. Same outcome, completely different relationship.
Key terms
- Helpdesk
- The single point of contact for technical problems. Its purpose is to make support predictable, visible and independent of any individual.
- Triage
- The quick assessment that decides handling order, based on impact — how many people and how badly — against urgency, which is whether work is stopped now.
- Impact versus urgency
- Impact is the scale of the effect; urgency is how quickly it must be addressed. A problem can be high in one and low in the other, and both must be assessed.
- Ticket
- The written record of a request: who, what, when, what was found, what was changed, and how it was confirmed. The memory of the support function.
- Service level
- A published commitment about response and resolution time per priority band. A level you cannot meet is worse than having none.
- Response versus resolution
- Response means acknowledged and started; resolution means fixed and confirmed. Confusing them is the most common way support people over-promise.
- Intake channel
- The one agreed route through which requests arrive. Without it there is no record, no fair ordering, and no way to measure or hand over the work.
- Support playbook
- A written reference covering common faults with diagnostic steps, fixes and escalation rules, so support does not depend on one person's memory.
Homework before the next session
Establish one intake channel for a real organisation
Set it up, announce it framed as protection against losing requests rather than as a restriction, and record the baseline of how support happened before. Note any resistance you met and how you handled it.
Write your priority bands and service levels
Four bands with plain-language definitions and two real examples each, plus response and resolution targets derived from your actual capacity. Include the explicit statement that response is not resolution.
Log three real tickets properly
Each with the user's own words preserved, triage reasoning written, ruled-out findings recorded, the specific change documented, and user confirmation noted. These become your first three playbook entries.
Describe good support from the user's side
Half a page on what a user actually remembers about a support interaction, and which of those things are technical. Written for somebody about to start their first support job.
Assessment rubric
How this session is marked. The certificate for IT Support is awarded on the deliverable, not on attendance.
| Criterion | Passing | Excellent |
|---|---|---|
| Understanding of the function | Can explain what a helpdesk does. | Explains why support exists as a function rather than a favour, and can name the specific risks of the unofficial-IT-person model. |
| Triage quality | Can assign a priority. | Assesses impact against urgency separately, resists rank and volume as priority drivers, and can defend every decision out loud with reference to the published bands. |
| Ticket discipline | Tickets were written. | User's own words preserved, ruled-out findings recorded, specific changes documented rather than 'fixed', and user confirmation captured in every ticket. |
| Service level realism | Targets were set. | Derived from actual capacity, response distinguished from resolution, and proactive notification given before any level is missed. |
| Professional judgement | Requests were handled politely. | Bypassing requests redirected kindly rather than refused, the loudest request resisted when impact was lower, and trust-building behaviour treated as part of the technical work. |
Session questions
Do I need expensive ticketing software to start?+
No. At forty-five users a shared mailbox or a structured spreadsheet is enough, because what matters is that a timestamped written record exists. Move to a proper system when volume makes the spreadsheet hard to search.
People keep messaging me on WhatsApp. Should I refuse them?+
Refusing builds resentment and teaches nothing. Respond helpfully, log it in the channel, and tell them you have done so. Consistent kind redirection for a few weeks establishes the habit; a hard refusal does not.
A senior manager's problem is not critical. How do I say that?+
State the published band and the reasoning calmly: the shared system affects everyone's ability to clear customs, so it is high, and their laptop is medium. Defensible rules protect you — improvising under pressure does not.
What if I miss a service level?+
Tell the user before it is missed, not after. Explain what is holding it up and give a revised time. An honest early update is a minor annoyance; discovering it at the end of the day is a breach of trust.
Is support a real career or a dead end?+
It is the standard entry point into IT, and the people who progress are the ones who document. A support playbook, clean tickets and a habit of recording what you ruled out are exactly the evidence that gets you moved onto infrastructure, security or systems work.
This session is part of
IT Support
3 weeks · 6 sessions · ₦40,000 · you leave with a support playbook