Run a Service Desk That Ranks Requests and Passes Hard Cases to Specialists

## Decide What the Service Desk Covers and Who Owns Each Ticket - State which users, services, request types, hours, and support channels the service desk covers. - Name an accountable owner for the process, an owner for each queue, and a current owner for every open ticket. - Distinguish incidents, service requests, access requests, questions, and security concerns before designing workflows. - Define service objectives for acknowledgement, meaningful response, restoration, resolution, and communication. - Publish exceptions such as planned maintenance, customer waiting time, and approved pauses. - Review the operating model whenever services, staffing, risk, or customer expectations change. ## Take In Requests with the Right Details and Confirm Identity - Accept requests through approved channels and bring them into one system of record. - Capture requester identity, contact method, affected service, symptoms, business impact, start time, and steps already attempted. - Ask for screenshots, logs, or error messages only when useful, and tell the requester how to remove secrets or unrelated personal data. - Acknowledge receipt promptly, but do not treat an automated acknowledgement as the first meaningful response. - Verify identity through an approved method before account recovery, access changes, or disclosure of protected information. - Record missing information as an explicit next action instead of leaving the ticket silently blocked. ## Set Priority from the Size of the Impact and How Urgent It Is - Determine impact from the number of affected users, business criticality, data or safety risk, and breadth of service degradation. - Determine urgency from time sensitivity, deadlines, rate of deterioration, and whether a practical workaround exists. - Assign priority from the combined evidence; do not let the requester's preferred label replace triage. - Define a small priority matrix with organization-approved response and resolution objectives. - Reassess priority when scope, impact, risk, or workaround status changes. - Document the reason for every priority increase or decrease and notify affected owners. ## Sort Tickets into Categories and Send Them to the Right Team - Use a shallow taxonomy that reflects stable services and work types rather than every possible symptom. - Map each category to a default queue, required expertise, approvals, and notification rules. - Route security, privacy, safety, legal, or major-service concerns through their dedicated response paths. - Define which rule wins when a ticket matches several categories, and preserve secondary context with labels. - Monitor unassigned, bounced, and repeatedly recategorized tickets as routing failures. - Change the taxonomy only after reviewing actual ticket patterns and downstream reporting needs. ## Look for the Cause with Low-Risk Checks and Log Every Step - Confirm the reported condition, affected scope, recent changes, dependencies, and available evidence before changing anything. - Start with reversible, low-risk checks and follow approved diagnostic procedures for the affected service. - Obtain the required authorization before privileged access, disruptive tests, configuration changes, or data restoration. - For identity issues, use strong verification rather than relying on the same channel that may be compromised. - Record each action, result, ruled-out cause, and next hypothesis so another agent can continue without repeating work. - Stop and escalate when evidence points to a broader incident, security concern, unsafe action, or missing authority. ## Track Promised Response Times (SLA) and Keep the Requester Updated - Track acknowledgement, response, restoration, resolution, and update commitments separately when the agreement distinguishes them. - Define exactly when each clock starts, pauses, resumes, and stops. - Alert the current owner and queue lead before a commitment is at risk, with enough time for corrective action. - Give requesters useful updates that state current status, known impact, work underway, next checkpoint, and any action needed from them. - Review at-risk work routinely and analyze breaches as process signals, not automatic evidence of individual failure. - Report trends by priority, service, queue, cause, and exception type so leaders can address recurring constraints. ## Pass Hard Cases to Specialist Teams with the Full History - Escalate when standard diagnostics are exhausted, specialist knowledge or elevated permission is required, risk increases, or the SLA threshold is approaching. - Use time-based triggers that reflect the remaining service commitment rather than waiting for the deadline to pass. - Send the receiving team the symptom history, impact, evidence, completed actions, results, ruled-out causes, and recommended next step. - Keep one accountable ticket owner unless the receiving team explicitly accepts ownership. - Escalate to engineering, infrastructure, security, or an external provider only when the issue falls within that team's control. - Define a path for stalled escalations and notify the duty lead when no qualified owner accepts the work. ## Confirm the Problem Is Fixed Before Closing the Ticket - Record what changed, why it resolved the issue, any temporary workaround, and any remaining risk. - Verify service restoration through observable evidence and, when appropriate, confirmation from the requester. - Notify the requester in plain language and include any action, limitation, or follow-up they need to understand. - Apply the final category and resolution code based on the actual cause, not the initial guess. - Close only after required records, approvals, linked work, and communications are complete. - Define a reopen window and route later recurrences according to the organization's policy. ## Turn Solved Tickets into Help Articles Others Can Search - Create or update knowledge when a solution is reusable, an issue recurs, or multiple users could benefit. - Write titles in the language users and agents are likely to search. - Include symptoms, scope, prerequisites, plain-language cause, numbered actions, verification, rollback or escalation conditions, and ownership. - Remove secrets, personal data, temporary identifiers, and environment-specific values before publication. - Link the article to related tickets and services so usage and effectiveness can be measured. - Assign a review date and retire guidance that is unsafe, obsolete, duplicated, or no longer owned. ## Review Problems That Keep Coming Back and Fix the Root Cause - On a fixed cadence, review volume, high-impact work, breaches, reopenings, escalations, repeat contacts, and customer feedback. - Separate immediate resolution from root-cause work and track both when systemic prevention is needed. - Ask what created the issue, what delayed detection or response, and which control could prevent or reduce recurrence. - Turn findings into owned actions with due dates, success measures, and a review checkpoint. - Check whether previous actions changed the relevant outcome instead of closing them on delivery alone. - Update training, routing, diagnostics, knowledge, automation, or capacity based on measured evidence. ## Hand Over Open Tickets When Shifts or On-Call Duty Change - Hand over open high-priority tickets, current owners, next actions, decision deadlines, and known customer commitments. - Include active incidents, planned maintenance, known risks, workarounds, external dependencies, and pending escalations. - Confirm that the incoming person can access the required tools and knows the duty lead and emergency contacts. - Use a live handoff for new, changing, or unstable rotations until the process is consistently reliable. - Record the handoff in the shared system and announce the transfer through the approved team channel. - Treat missing context or access discovered after handoff as a process defect to correct.