IT Service and Support

Good support follows a repeatable cycle. You will follow a clear support cycle and agree response targets, so every user knows what happens after they report a problem.

• Request logged; priority set; assigned; fixed; closed; reviewed.
• Priority depends on how many people and how much work is stopped.
• Always tell the user what happens next and when.
• Close only when the user agrees.
• Learn the cycle of receive, record, classify, diagnose, fix or escalate, confirm with the user and close, and put it on one page by your desk.
• Agree target times, such as an acknowledgement within 15 minutes and a first reply within 30 minutes, so users know what to expect.
• Keep a notebook of every new fault and the fix that worked.
• Practise explaining a fault to someone who has never used a computer.

Activity. Draw the cycle and give two priority examples.

Standard to meet. Check that the cycle is correct and the examples are sensible.

Common mistake. Jumping to fixes before understanding the fault.

Check yourself. What three questions start every call?

Most faults are solved by good questions. You will open each call with three diagnostic questions and repeat back key facts, which uncovers the real fault faster.

• Ask: what happened, what did you expect, what changed lately.
• Repeat back in your own words.
• Use plain words, no jargon.
• Stay calm and kind.
• Open every call with three questions: what were you trying to do, what happened instead, and what changed recently, and write the answers word for word.
• Use plain words, avoid jargon, and confirm by repeating the key facts back; ask the user to read any error message exactly as shown.
• Learn the shortcuts for screenshots, which help ticket notes.
• Set a standard greeting that is warm and short.

Activity. Role-play three calls with a partner.

Standard to meet. Obtain a clarity rating of 4 of 5 from your partner.

Common mistake. Using jargon with a worried user.

Check yourself. Rewrite one technical sentence in plain words.

A good ticket lets anyone pick up the case. You will write tickets with exact error text, steps to repeat and a priority based on impact, so any colleague can continue the case.

• Fields: who, when, what, steps already tried, priority.
• One issue per ticket.
• Time stamps for open, first reply and close.
• Keep notes short and factual.
• Record who, when, where, device, exact error text, steps to repeat, and what has been tried; keep the title short, such as 'Printer offline, floor 2'.
• Set priority by impact and number of people affected, for example one person with a workaround is low, a whole team unable to work is high.
• Check that every ticket has an owner and a next step.
• Record the time you first reply to each user.

Activity. Create a ticket form and log 10 practice tickets.

Standard to meet. Complete all tickets with times.

Common mistake. A ticket that says only "it's broken".

Check yourself. Is any of your tickets missing a time?

Learn the ten most frequent faults. You will work through an ordered checklist for slow, frozen or failing computers and phones, protecting user files before changing anything.

• No power or screen: check cable, battery, display.
• Slow: storage full, too many programs, updates.
• No sound or camera: device choice and permissions.
• Updates and backups; safe removal of unwanted apps.
• Check power and cables first, then restart, then whether free storage has fallen under 10 percent, then recent updates or new software, then run a simple scan.
• Before changing settings or wiping anything, ask whether the user has recent copies of important files, and note it on the ticket.
• Practise saying 'I do not know yet, but I will find out by three o'clock'.
• Learn how to reset a router safely and tell users what to expect.

Activity. Fix five practice faults and note steps.

Standard to meet. Document five fixes.

Common mistake. Changing settings before backing up.

Check yourself. What do you back up before a fix?

Connection and sign-in problems cause many tickets. You will separate single-account faults from network-wide ones and reset sign-ins safely, resolving many of the most frequent tickets quickly.

• Wi-Fi: forget and rejoin, restart router, check others.
• Decide if the fault is the name lookup (the step that turns a web address into a machine), the cable or the provider.
• Password reset safely: verify identity first.
• Account locked: check cause before unlocking.
• Ask whether other devices or colleagues are affected, test with a wired connection or a phone hotspot, and check whether the problem is one account or the whole network.
• For account problems verify identity first, check lock status and password age, and reset using a one-time method rather than reading passwords aloud.
• Check that backups exist before any risky fix.
• Create a list of the ten most common faults in your setting.

Activity. Fix five network or account scenarios.

Standard to meet. Document the steps with reasoning.

Common mistake. Unlocking accounts without checking who asks.

Check yourself. How do you verify identity?

A guide that works saves the next call. You will write numbered how-to guides and test them on a newcomer, so the next user can solve the same issue without calling.

• Short steps with a picture each.
• Test it on someone who is not technical.
• Put the fix at the top, the cause below.
• Keep a short list of frequent questions.
• Write each guide with a title, who it is for, numbered steps of one action each, a screenshot where helpful and a line saying when to contact support.
• Test the guide with someone who has never seen the task; every question they ask shows a step that needs rewriting.
• Write guides in the same order every time: problem, steps, check.
• Keep a list of trusted tools and never install unknown ones.

Activity. Write and test one guide.

Standard to meet. Test that a tester completes it without help.

Common mistake. Writing a guide without testing it.

Check yourself. Who tested your guide?

What gets measured gets better. You will track volume, reply time, fix time and satisfaction, and use repeat causes to decide where a guide or training would help most.

• First reply time; fix time; first-time fix rate; user rating.
• Group tickets by cause to find repeats.
• Report weekly in one table.
• Set a service promise you can keep.
• Track tickets opened and closed per week, average time to first reply, average time to fix, and a one-question satisfaction score out of five.
• Review the top five repeat causes monthly, and ask whether a guide, a fix or user training would remove each one for good.
• Review rating comments weekly and thank those who praised.
• Hold a short monthly review of repeat problems.

Activity. Compute the four measures for your tickets.

Standard to meet. Calculate all four correctly.

Common mistake. Reporting only averages.

Check yourself. What did your lowest rating say?

Know your limits and pass on cases well. You will recognise when to escalate and hand over complete notes, then use monthly reviews to turn difficult cases into lasting improvements.

• Escalate with full notes and what you tried.
• Fix causes, not just symptoms.
• Thank users and ask for feedback.
• Plan 90 days of learning.
• Escalate when a ticket passes its target time, needs access you do not have, or affects many people, and always hand over the notes and what has been tried.
• Hold a 20-minute monthly review of the hardest tickets and agree one change, such as a new guide or a monitoring alert, for each.
• Keep your own skills list and add one new fix a week.
• Share one lesson with the peer circle each month.

Activity. Write a problem report and a 90-day plan.

Standard to meet. Report names cause, fix and owner.

Common mistake. Escalating without notes.

Check yourself. What goes in your escalation note?

Twenty people lose the network at 10:00.

Question: Priority and first steps?

Model answer: High priority; check shared equipment first, tell users, escalate to the provider with notes.

A user shouts about a lost file.

Question: How do you respond?

Model answer: Stay calm, listen, repeat back, say what you will do and when, and check the recycle bin and backups.

On the slide: L1 Basic · Basics of helping

Notes: Describe what a help desk does and how a user should describe a problem. Notes: write a good request for a broken printer and a poor one, and compare. Standard: the good request has what, where, since when and what was tried.

On the slide: L2 Awareness · Awareness

Notes: Name the main kinds of faults (account, device, network, software) and who should handle each. Notes: sort twenty sample requests into the four kinds. Standard: at least 17 of 20 sorted correctly.

On the slide: L3 Foundation · Foundation

Notes: Take a request, ask the right questions, solve a simple fault and write the ticket. Notes: use sample requests such as a locked account or a slow laptop. Standard: each ticket has the problem, the fix, the time and the user's confirmation.

On the slide: L4 Practitioner · Practitioner

Notes: Handle a queue of requests by priority, keep users informed and escalate with the right detail. Notes: run ten simulated requests with two urgent. Standard: urgent requests first, updates sent on time, escalations complete.

On the slide: L5 Specialist · Specialist

Notes: Run a practice help desk for 20 requests from real or simulated users and report on response times and user ratings. Notes: set targets before you start, such as first reply in 30 minutes. Standard: report shows targets, results, the slowest ticket and a fix.

On the slide: L6 Advanced · Advanced

Notes: Lead a help desk team with a knowledge base, a service target and a monthly review. Notes: add article templates and a repeat-ticket report. Standard: repeat tickets fall month on month, or the report says why not.

On the slide: L7 Super expert · Super expert

Notes: Set the ticket-handling standard (priority, target times, hand-over) and teach the support leads who apply it. Notes: review first-response, resolution and repeat-ticket figures each year.