What Is a Service Ticket?

A service ticket is a logged record of a user-reported issue or request, tracked from the moment it is raised until it is resolved. The ticket gives the problem a number, an owner, and a status, so it cannot evaporate the way hallway reports and forwarded emails do. In IT support the ticket might be “cannot log in”; in equipment management it is “the mixer is leaking oil” - same mechanism, pointed at physical assets.

What a service ticket captures

A useful ticket records, at minimum:

• The reporter - who noticed the problem and can answer follow-up questions.
• The description - what is wrong, in the reporter’s words, ideally with photos taken at the machine.
• The subject - the specific asset affected, linked by its ID, not “one of the drills”.
• A category - damage, missing, needs maintenance, needs replacement - so triage can route it.
• A priority and status - so everyone can see whether it is queued, being worked, or waiting on parts.

The single highest-value habit is lowering the cost of reporting. Faults that take a form, a login, and ten minutes to report get reported on Friday or never; faults that take a photo and two sentences get reported the moment they are seen.

The ticket lifecycle

Tickets move through a small set of states: new, in review while someone triages it, in progress while the fix happens, awaiting parts (or awaiting information) when the work is paused on something external, and finally resolved. A comment thread along the way keeps questions, findings, and decisions attached to the ticket instead of scattered across inboxes. Two details separate working systems from theatre: the waiting states must be honest, because that is where most resolution time hides, and a resolved ticket must say what was actually done - “fixed” is not a record.

Service ticket vs work order

The two overlap and are often conflated. A service ticket records the problem from the user’s side; a work order authorises and tracks the fix from the maintenance side. In a large operation, a ticket is triaged and may spawn one or more work orders, possibly across teams. In a small team, one record plays both roles from report to repair - a perfectly good arrangement, provided the record is tied to the asset and closed with notes rather than just marked done.

Why tickets belong on the asset

A ticket resolves one incident; a ticket history characterises a machine. When every report lands on the asset’s record, the repeat offender that has quietly consumed five tickets this year becomes visible, warranty status can be checked before money is spent on a repair the supplier owes you, and repair-or-replace decisions - whether a tired unit is worth refurbishment or has reached end of life - rest on evidence instead of impressions. For regulated kit such as shared medical equipment, that fault trail is not optional; it is part of demonstrating the device was safe to use. In AMPthilly, scanning the QR label on a faulty item opens its record in the phone browser, where anyone can raise a ticket with photos and a category, and the resolved ticket stays on the asset’s history permanently.

Related terms

• Warranty Tracking - the first check before paying for any ticketed repair
• Useful Life - the planned span a thickening ticket file calls into question
• End of Life (EOL) - where a worsening ticket history should lead
• Refurbishment - the alternative to replacement a ticket history helps justify
• Asset Decommissioning - retiring the asset whose tickets no longer justify repair