An IT ticket is the record of one request for help from IT. It holds who asked, what broke or what they need, how urgent it is, who owns the work, and every step until it closes. Each call, email, or hallway ask becomes work someone can track.
This guide comes from the team behind SherpaDesk, a helpdesk and professional services automation (PSA) tool a small IT team can run alone.
Key takeaways
Definition
A ticket is one record for one request to IT, kept from the first message to the final close.
One university service desk says tickets are "typically used for expected events that come up in the regular course of business". A password reset, a dead monitor, and a new hire's laptop all qualify. A network rebuild is a project.
The ticket and the IT ticketing system are different things. The ticket is the record. The IT ticketing system is the software that receives requests, stores the records, and routes them to people. In IT, "support ticket" and "trouble ticket" usually mean the same record.
A ticket turns a request into work you can see, sort, and finish. Without an IT ticketing system, requests live in inboxes and memory.
The University of Illinois writes this down: its IT units record every service request in one approved system, whatever channel it came through, along with the work, approvals, and escalations.
As one r/sysadmin member put it: "You can't triage and prioritise stuff that's not in the system." An r/msp member quoted the old rule: "If it's not in a ticket, it didn't happen."
For an MSP, the hours logged on a ticket are the hours you can invoice. The billable hours you never captured are the margin you never made.
The University of Illinois lists the fields its IT units record for every service request. They run from request ID and requester to responsible group, status, and actions taken. Here they are, plus a few working fields.
| Field | What it holds | Filled in by |
|---|---|---|
| Ticket number | A unique ID for replies and calls | The system |
| Requester | Who asked, and how to reach them | Requester, or the technician who took the call |
| Account or site | The client, office, or school | Requester, checked at triage |
| Title and description | What broke or what's needed | Requester |
| Type and category | Incident, request, problem, or change; the technical area | Triage |
| Priority | How soon it needs work | Triage |
| Status | Where it is in the lifecycle | Technician and system |
| Owner | The technician and the responsible group | Triage or a routing rule |
| Dates | Opened, first response, due, resolved, closed | The system |
| Work log | Replies, notes, time entries, approvals | Technician |
| Linked records | The device, related tickets, knowledge base articles | Technician |
| Resolution | What fixed it, for the next technician | Technician |
For the form your users see, copy our ticket template.
Cornell University IT's glossary defines incidents, service requests, problems, and changes. Lists vary: the University of Alaska Anchorage (UAA) service desk names service requests, incidents, change requests, and regular operational tasks.
| Type | What it is | Example | Done when |
|---|---|---|---|
| Incident | An unplanned interruption to a service, or a drop in its quality | Outlook won't open at reception | The service works again |
| Service request | A user's request for an action agreed as part of normal service | Laptop and email for a new hire | The thing asked for is delivered |
| Problem | "A cause, or potential cause, of one or more incidents" | The VPN drops every Monday morning | The cause is removed; a workaround only restores service meanwhile |
| Change | Adding, modifying, or removing anything that could affect services | Replace the firewall on Saturday | The change is in place and checked |
A problem ticket links repeat incidents to one cause. Class and routing come next, in ticket triage.
Ticketing systems name the steps differently, but incidents and service requests usually follow this path.
The request arrives by email, portal, phone, or chat. Ticketing systems give it a number and a timestamp.
Someone sets the type, category, and priority from written levels, such as our incident priority levels.
A dispatcher or a routing rule picks the owner. If tier 1 can't fix it, it moves up a support tier with its history.
The technician logs each step; while it waits on the user or a vendor, the status says so.
The fix goes in and gets written down. When the ticket closes is your team's rule; UW–Madison closes it after a set period in Resolved.
The University of Wisconsin–Madison defines these statuses for incidents and service requests:
| Status | What it means |
|---|---|
| New | Just created, by a technician or through the portal |
| Active | A helpdesk agent or technician is working on it |
| Awaiting customer reply | Waiting on the requester's answer to move on |
| Resolved | The work is done; UW–Madison also resolves incidents when the requester stops replying |
| Closed | At UW–Madison: resolved for a set period, then no longer reopened or edited |
| Cancelled | It can't be resolved or fulfilled |
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
A live walkthrough tailored to your team.
Anyone IT supports can open a ticket: an employee, a client's office manager, a teacher. A technician can also create one for a caller, so a phone request still gets a record. At Saskatchewan Polytechnic, a user submits an online form and the ticket is created in their name.
Then three roles take over. A dispatcher reviews and assigns the ticket, and an agent works with the user to resolve it. Illinois also records a responsible group on every service request, so the owning team stays visible when the ticket changes hands.
On a small team, one person often holds every role. At a three-technician MSP, whoever answers the phone also triages and fixes, and the owner reviews the time before invoicing. In a school, a teacher opens the ticket and a campus technician works it. If your users write to support@, an email ticketing system turns their messages into tickets.
Example: a three-technician MSP supports Harbor Dental, a one-office client.
| Field | Value |
|---|---|
| Requester | Dana Ortiz, office manager, 555-0142 |
| Account | Harbor Dental, Main Street office |
| Title | Front-desk printer offline, can't print claim forms |
| Type and category | Incident · Devices, printers |
| Priority | P3: the back-office printer works |
| Owner | Sam Lee, tier 1 |
| Linked asset | PRN-007, front-desk printer |
| Time logged | 0.5 hours, remote session, billable |
| Resolution | New IP address after Monday's router swap. Added a DHCP reservation, remapped 3 PCs. |
| Status | Closed |
The status history:
Dana had a reply in 19 minutes. The next technician can search "PRN-007" for the fix, and the owner sees 0.5 billable hours.
UAA's service desk lists 7 criteria, and work that meets 3 or more may be a project. Two of them: more than 10 hours of labor, and input from several departments.
One request in a normal week.
Planned work with its own scope.
MSPs meet the edge case as tickets open for months, waiting on the client. One r/msp member's view: "Ideally, honestly, they should be moved to projects even though they are tiny ones."
IT ticketing systems differ less in the ticket than in what surrounds it. Check that the record itself holds up:
Export matters when you leave: ticketing systems hold years of fixes. If you bill clients, also check that time on the ticket reaches an invoice without retyping. For a trial checklist with prices, see our guide to ticketing software.
Work outside the ticketing system. A new IT ticket system is the easy part. As one r/sysadmin member put it: "Having the users actually use it will be the hard part." Answer the walk-up, then open the ticket.
Reply-all loops. Ticketing systems that open a ticket per email can turn a CC chain into one ticket per reply. One r/sysadmin member described it: "Every. Single. Message. Generates. A. Ticket."
Counting tickets. An r/sysadmin member recalled a job where "the primary stat they looked at was purely the number of tickets worked". For replies when a ticket stalls, use our reply templates.
How this works in SherpaDesk
Each ticket carries a status from a fixed list: Open, On Hold, Waiting On Response, Confirmed, UnConfirmed, and Closed. Routing rules send tickets of a class to a technician, and the ticket shows its SLA Due By time.
You can log time against tickets, accounts, projects, and assets. Add Time, a calendar Timesheet, and a Start/Stop timer are the ways in. Unbilled time collects in Ready to Invoice, by the client's contract. Forward support@ to a dropbox address and incoming emails become tickets. You can run it for your own staff or for the clients you support.
A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin. Base Camp is $45 per agent per month ($40 billed annually), the first agent is free, forever, and the trial is 14 days free with no card.
Who this isn't for
Anyone selling event, travel, or airline tickets. Teams that want their own status names: you can't rename the statuses in SherpaDesk, so any other state goes in a custom field.
Use the channel your IT team publishes: a portal form, an email to a support address, or a phone number. Your request lands in the ticketing system with a number; quote it in every follow-up. For the questions a good request answers, use our ticket template.
An IT ticketing system collects requests from email, portals, and calls into one queue. It gives each one an owner and a status and keeps the history after it closes. Teams use it to work by priority, meet response targets, and see where the hours went.
The same software, named for the team that uses it. Helpdesk ticketing systems and IT ticketing systems both hold one record per request; the helpdesk is the people who answer them. For how a helpdesk differs from a service desk, see helpdesk vs service desk.
Resolved means the work is done, but the user can still say the fix didn't hold and the ticket goes back to work. Closed means the record is final. At UW–Madison, that happens after a set period in Resolved. The period, and whether a closed ticket can reopen, is your team's rule. See the statuses table.
Usually, yes: both name the record of one request. If you need to tell faults from asks, use the incident and request types in the types table, not the name.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.