What is a ticketing system?
Every call, email, chat message or portal request becomes a ticket with a unique number, a timestamp, a requester and an owner. The ticket is the single record of the problem: what the user reported, what each technician did, who has it now and how it ended. Common products include ServiceNow, Jira Service Management, Zendesk and Freshservice, and many remote monitoring and management (RMM) platforms include ticketing too. The exam does not test specific products. It tests what a good ticket contains and how it is handled.
What goes in a ticket
| Field | What to record | Why it matters |
|---|---|---|
| User information | Name, contact method, department or location, requester vs affected user | Reaches the right person and shows scope |
| Device information | Device type, hostname, asset tag or serial number, OS and version, wired, Wi-Fi or VPN | Makes sure you troubleshoot the right endpoint and links it to inventory and warranty |
| Issue description | Symptoms, start time, what changed, exact error text, steps to reproduce, impact | Lets another technician verify the problem |
| Category | Hardware, software, network, account, printer, mobile, with subcategories | Routes the ticket to the right queue and feeds reports |
| Severity and priority | How large the impact is (one user, a team, the whole company) and how urgent | Decides what gets worked first |
| Escalation level | Which tier or team owns the ticket now | Shows the handoff history |
| Status | New, in progress, waiting on user, escalated, resolved, closed | Keeps the queue accurate |
Keep secrets out of tickets. Never record passwords, one-time codes or full card or Social Security numbers. If you verified a caller's identity, note that you verified it and how, not the values used.
Writing clear notes
A ticket needs clear, concise writing in three places:
- Problem description: facts, not opinions. "Since this morning's restart, the laptop cannot open any network share over Wi-Fi; wired works; error says Windows cannot access the share" beats "network broken, urgent."
- Progress notes: timestamped entries with the action taken, the result, the next step and who the ticket is waiting on.
- Resolution: the root cause (marked as confirmed or suspected), the exact fix, how you verified it and any follow-up. A note that says only "fixed" helps no one.
The ticket life cycle
- Intake: the request is logged with a timestamp and requester.
- Triage: a technician sets category, severity and priority.
- Assignment: one person or queue owns it.
- Troubleshooting: each test and result is recorded.
- Escalation if needed, keeping the same ticket.
- Resolution: the fix is applied and verified with the user.
- Closure: final notes are written, and a knowledge base article is created or updated when the fix is reusable.
Beyond a single ticket
Ticket data reveals patterns. A cluster of tickets for one laptop model, one site or one update points to a shared cause. Managers measure first response and resolution times against service-level agreements (SLAs). Linking tickets to the asset inventory and the knowledge base means a technician starts with device history and known fixes instead of a blank page. Closed tickets also form an audit trail when someone later asks who changed what and when.
Ticketing system on the CompTIA A+ exam
Core 2 (220-1202) objective 4.1 covers ticketing systems and documentation. Know what belongs in a ticket: user and device information, a description of the issue, categories, severity and escalation levels. Also know that written communication is tested in three places: describing the problem, recording progress and documenting the resolution. If a question asks what a technician should do when a new request arrives, think "open or update a ticket." If it asks which note is most useful, pick the one with specific, factual detail. If a ticket keeps bouncing between teams, think missing information or the wrong category.