CCST IT Support study materials
CCST IT Support study resources

Three Tickets, One Technician

CCST IT Support · Put your knowledge to work in context.

All case studies

Three Tickets, One Technician

You are the only technician on shift at a 220-employee site. At 09:10 three tickets land within four minutes. (A) The CFO's laptop will not connect to the conference-room projector; she presents to the board at 10:00. (B) A warehouse supervisor reports that the handheld scanners used for receiving have not synced for 25 minutes, and a truck is waiting at the dock. (C) An accounts-payable clerk says her mouse 'feels slow' and asks for a replacement. Your ticketing system has no severity field configured. The SLA document says P1 = 1-hour response, P2 = 4-hour response, P3 = next business day, and there is no backup technician until 13:00. The site has 14 handheld scanners, all syncing through one gateway, and 40 people work in receiving.

1. Rank the three tickets and state which one you start on. Justify the ranking using impact, urgency, and available workaround, not the words the users used.

Read the worked answer

Score each ticket on three axes instead of accepting the user's urgency.

  • Impact – how many people and which business process are blocked. B blocks 40 receiving staff and a physical truck; A blocks one person; C blocks nothing.
  • Urgency – how soon the consequence lands. A has a hard 10:00 deadline; B's cost accrues per minute the dock is idle; C has no deadline.
  • Workaround – does an alternative exist while you work the problem? A has several (HDMI cable straight into the laptop, a spare laptop, borrow a projector). B has only manual paper receiving, which is slow and error-prone at 14 scanners.

Order: B, then A, then C. Start on B because a stopped dock with a waiting truck is the only ticket where the cost compounds continuously and the workaround is poor. Immediately after triage on B, spend five minutes on A - a projector issue is frequently a cable or input-source problem, and five minutes that eliminates a board-level embarrassment is worth it. C is deferred without touching hardware until you confirm the mouse actually needs replacing; "slow pointer" is often a dirty sensor or a full disk, and swapping the device would mask the real cause.

Because the tool has no severity field, write your reasoning into the ticket text so the priority decision is auditable later.

2. Fifteen minutes into ticket B you have not resolved it. What do you do, and what exactly goes into the escalation?

Read the worked answer

First establish scope, because it decides who you escalate to: is one scanner failing or all 14? Check whether a single device can be pinged or re-authenticated, then look at the shared gateway or sync service status page. If one scanner fails it is a device problem you own. If all 14 fail simultaneously, the fault is above the device - gateway, service, DHCP, or network credentials - and it belongs to an owner you probably are not.

Escalate at the 15-minute mark rather than waiting for the 1-hour SLA, because the SLA measures response, not resolution, and the dock is idle the whole time.

The escalation must contain, in this order: the affected function and count (all receiving scanners, 14 devices, 40 staff blocked); the start time and the fact that it began without a change you made; what you already tested and the result of each test; the business cost (truck waiting at dock, receipt process stopped); the workaround in place (supervisor starting manual paper receiving); what you need from the other team; and how to reach you. Then notify the warehouse supervisor directly - the person who needs to start the manual process should hear it from a human, not discover it from a ticket comment.

3. The next morning your manager asks why a mouse ticket was still open at 17:00. What process recommendation do you make, and what is the smallest change that would have prevented the dispute?

Read the worked answer

The dispute exists because priority was negotiated verbally and invisibly. The fix is not a new tool - it is making the criteria explicit and shared.

Recommend a three-tier impact definition tied to a workaround test: blocked with no workaround, degraded with workaround, and cosmetic. Anyone, including users, can then classify by answering two questions. Publish the definitions where users submit tickets so priority is not a private judgement.

On the specific ticket, the honest answer is that C was correctly deferred and the record should say so, with a timestamp and a reason ("device not yet inspected; no work blockage reported; scheduled next business day per P3"). A deferred ticket with a documented reason is defensible; an untouched ticket looks like neglect.

Smallest effective change: add a mandatory free-text field labelled "business impact" to the ticket form and require the technician to record the assigned tier at triage. That costs no licensing and converts every priority decision into a reviewable one - which is the actual root cause of the 17:00 conversation.