FS Support Center
Knowledge Base
Steps to Working an IT Helpdesk Ticket
Status definitions (use consistently)
- **Open**: Ticket created, not yet triaged/owned.
- **New**: Acknowledged/owned; initial review underway, not actively working yet (or queued).
- **In Process**: Active investigation/troubleshooting in progress.
- **On Hold**: Waiting on user/vendor/other team, or blocked by dependency; include what you’re waiting for and next follow-up time.
- **Solution Proposed**: You believe it’s fixed or you’ve provided steps; awaiting user confirmation/testing.
- **Resolved**: User confirmed fix (or you verified per policy) and work is complete; pending closure rules.
- **Closed**: Finalized for metrics/reporting; no more work expected. Can’t be reopened.
- **Cancelled**: Request no longer needed / created in error / duplicate with clear reference.
Best practice: move statuses promptly so SLA reporting reflects reality (don’t leave tickets “In Process” while waiting on the user).
1) Intake and Receipt (Open → New)
Objective: Ensure tracking + enough detail for anyone to work ticket without back-and-forth. Ensure the request is logged in the system. If a user walks up, create the ticket immediately to ensure tracking, as the help desk should be the single point of contact.
Technician actions in TDX
1. **Create ticket immediately** for walk-ups/calls/emails/internal.
2. Confirm Affected User vs Requestor.
3. Capture minimum required data:
- Device name + asset tag (Windows / iOS version, etc.)
- Location (onsite/remote), network (VPN? Wi‑Fi?)
- App/service affected (M365 app, Windows login, AD resource, local software, printing)
- Exact error text + screenshots
- Start time, frequency, business impact (blocked or degraded)
4. Set initial **Category/Service**
5. Set ticket to **New** and send an acknowledgement to the requestor.
Acknowledgement example
Hi <Name>, I’m assigned to your ticket <ID>. I’m reviewing now and may need <remote session / call / screenshots>. Next update by <time>.
2) Review and Understand (Open → In Process)
Objective: Convert the request into a clear, testable problem statement and success criteria. Read the ticket carefully to understand the issue, as beginners often fix the wrong problem by rushing. Gather information, such as error messages, screenshots, and when the issue started.
Checklist
- Restate the issue in one sentence (avoid vague summaries).
- Identify scope: **single user / multiple users / site-wide**.
- Identify environment: **Windows vs iOS**, on-network vs off-network, VPN, device compliance.
- Check TDX history: repeats for same user/device/service; link if relevant.
Move to **In Process** when You start active troubleshooting or investigation.
3) Prioritize (during Open/In Process)
Objective: Priority aligns to business impact and drives updates. Assess the urgency and impact on business processes to determine the priority level
Practical rubric
- **Department Outage**: many users, core service outage, security incident, exec time-critical.
- **Work Stopped**: user blocked from primary function, limited workaround.
- **Work Impaired**:
- **Working Normally**: minor issue, request, workaround exists.
Document priority changes in the ticket:
- “Priority set to High due to payroll processing blocked for Finance team.”
4) Investigation Workflow (In Process) — Start with “fast disqualifiers”
Objective: Rule out outages, licensing, identity problems, and Intune compliance issues quickly. Acknowledge the ticket to the user. Investigate the issue using the internal knowledge base or other tickets for known solutions.
Order of operations
1. **M365 health / advisories/other tickets** (admin portal) + internal comms for known issues
2. **KB / known solutions** (search by exact error)
3. **Identity checks** (AD, sign-in symptoms, lockouts, password resets)
4. **Device management checks (Intune)** especially for iOS/Windows access failures:
- Enrollment status
- Compliance state
- Conditional Access impact (if applicable in your environment)
5. **Endpoint basics** (time, connectivity, updates, disk space)
5) Troubleshooting + Documentation Standard (In Process)
Objective: Every step is reproducible and useful to the next technician. Troubleshoot the issue and document every step taken in the ticket system. Good notes assist with future issues and keep users informed.
What to record (every ticket)
- **Symptoms + exact error**
- **User/device context** (device name, OS/iOS version, on-site/remote/VPN)
- **Steps attempted** (one change at a time) + result
- **What worked** (and how you validated)
- **User updates** (when/what you told them)
Note style example (good)
- 09:12 — User reports Teams sign-in fails on iPhone; “You can’t get there from here.”
- 09:18 — Checked M365 health: no advisory.
- 09:25 — Intune: device shows Not Compliant (passcode requirement).
- 09:31 — Guided user to set passcode; compliance updated to Compliant.
- 09:40 — User signed into Teams successfully; verified chat and calendar load.
Escalation (If Needed): If the issue cannot be resolved, escalate it to the appropriate team member
6) When to Use “On Hold”
Set **On Hold** when you cannot proceed. Always include:
- What you’re waiting for
- Who owns next action (user/vendor/other team)
- When you will follow up
**On Hold examples**
- “On Hold awaiting user availability for remote session; contacted at 10:05 and 14:10; next follow-up tomorrow 09:00.”
- “On Hold pending Intune compliance re-evaluation (policy updates propagate); recheck at 15:30.”
Avoid: “On hold” with no reason/time—this causes SLA confusion and user frustration.
7) Use “Solution Proposed” correctly (In Process → Solution Proposed)
When to use it
- You applied a fix and need the user to test/confirm, or
- You provided steps and are waiting for the user to perform them.
What to include in the message
- Clear test instructions: “Please try X and confirm Y.”
- A deadline/next touch: “If I don’t hear back by <date/time>, I’ll follow up/resolve per policy.”
Solution Proposed Examples
> I’ve applied/provided the following fix: <summary>.
> Please test by: <steps>.
> If this works, reply and I’ll mark the ticket resolved. If not, tell me what happens (include any error text/screenshots).
8) Resolution and Closing (Solution Proposed → Resolved → Closed)
Confirm with the user that the solution works. Once confirmed, update the ticket to "Resolved" or "Closed," detailing the solution provided
Resolved
Move to **Resolved** when:
- User confirms success
- Technician testing confirms success
Final resolution note should include:
- Resolution summary
- Validation method
- Root cause (if known)
- Preventive note / KB link (if any)
Closed
Move **Resolved → Closed** based on your team’s closure rule (immediate close or after X days). Don’t skip documentation just because you’re closing fast.
Cancelled
Use when:
- Duplicate (include link to the “parent” ticket)
- Created in error
- User states it’s no longer needed
9) Escalation Pack (what needs to be in the ticket)
Before routing/assigning out, ensure the ticket contains:
- One-sentence problem + impact
- User/device details (OS/iOS version, device name)
- Intune compliance/enrollment state (if relevant)
- Exact errors + screenshots
- Steps tried + results
- What you need from them (permissions change, Conditional Access review, backend fix)
Recommended “TDX Ticket Update Cadence” (simple baseline)
- **Department**: acknowledge quickly; updates at least every 30–60 minutes or as your SLA dictates
- ** Division**: acknowledge quickly; updates at least every 60-90 minutes or as your SLA dictates
- **Workgroup**: update same business day; more often if waiting on user
- **Single User**: update within SLA window; set On Hold if waiting
Appendix
Other useful sources of information:
https://www.dissmeyer.com/2013/06/06/good_documentation_in_help_desk_tickets_or_lack_of/
https://mspvendors.com/ticket-documentation-standards-for-msp-technicians-building-a-culture-of-repeatability-and-faster-troubleshooting/
https://www.cbtnuggets.com/blog/career/career-progression/how-to-write-the-perfect-ticket-as-an-it-pro
https://gethelpt.com/articles/the-crucial-role-of-ticket-notes-in-tech-support
FAQs