A tracked customer problem with an owner, a status, and a clock, the unit that routes and closes one issue at a time.
A support ticket is the atomic unit of a support request: one captured problem, with an owner, a status, and a clock. It exists to track a single customer issue from the moment it arrives to the moment it closes. It is two things at once: to the person who raised it, a problem waiting to be solved; to the product team, a data point about where the product is failing.
The ticket began as paper. Telephone companies logged customer-reported faults on handwritten cards that recorded the problem, the assigned technician, and the resolution status, which is why the term "trouble ticket" persists (E-SPIN). As mainframe computing spread, IT departments borrowed the same artefact to track system crashes and software faults, and the concept was formalised in the 1980s inside technical call centres.
The discipline hardened with ITIL, the IT service management framework, which separated the ticket into distinct process types: incidentIncidentDevOps & PlatformA production incidentView reference → management to restore service quickly, problem management to eliminate root causesRoot CauseEngineeringAn identified root cause of an issueView reference →, and service request management for routine asks (ManageEngine). That split matters, because one urgent ticket and a hundred tickets about the same cause demand different responses. The first needsNeedUserA user need, pain, desire, or constraintView reference → a fast fix; the second needs an engineer.
The current shift is toward treating tickets in aggregate. Teams now analyse article ratings, escalation patterns, and repeat contacts to find content gaps, and route incoming volume away from human agents through self-service before a ticket is ever opened (Giva). Deflection reframes the ticket as a measurable cost, where the cheapest ticket is the one that never needed to exist.
Dixon et al. provide the research grounding for why deflection matters beyond cost reduction: their large-scale study of service interactions found that high-effort resolution experiences — repeat contacts, transfers, channel switching — drive customer disloyalty far more reliably than any corresponding delight from a smooth resolution. By that measure, a ticket that could have been avoided through a knowledge base articleKnowledge Base ArticleContent & KnowledgeA knowledge base articleView reference → or a proactive notification does not merely represent a saved cost; it represents a loyalty riskRiskComplianceA risk to the product or businessView reference → that did not need to be created.
A B2B analytics product receives roughly 400 tickets a month. A CSAT survey fires on closure, and first-response SLA sits at four working hours. For months the team treats each ticket as an isolated fix. Then a quarterly top-issue analysis groups the backlog by tag, and one cluster stands out: 70 tickets, about 18 per cent of volume, all variations on "my scheduled export didn't run."
Read singly, each was a quick reset and a polite reply. Read together, they describe a defect in the export scheduler. The team files one bugBugProduct SpecificationA defect or unexpected behaviourView reference →, ships a fix, and publishes a knowledge base article for the edge case that remains. Monthly volume drops by 60 tickets. The signal was present in the queue the whole time; it became visible only once the tickets were counted as a set.
Dunford's work on positioningPositioningGo-To-MarketProduct positioning statementView reference → offers a complementary lens on what ticket clusters can reveal. Her argument is that customers interpret a product through the competitive frame and assumptionsAssumptionStrategyA belief taken as true that underpins a strategyView reference → they bring to it — and when that frame is wrong, confusion follows. A cluster of tickets expressing the same misunderstanding of a featureFeatureProduct SpecificationA product capability or featureView reference →'s scope or intent may therefore signal a positioning or onboarding failure as much as a product defect: the expectation the ticket describes was set by how the product was framed, not by the behaviour of the code.
In the Unified Product Graph, a support ticket sits in the Customer Success region. A product connects to it through product_supports_via_support_ticketservice_blueprint_contains_support_ticketsupport_ticket_reveals_needsupport_ticket_reports_bug
Mild inconvenience Notices but works around easily
Negative Unfavourable signal; dissatisfaction or risk.
High Requires prompt attention; address before the next planning checkpoint.
Type-specific fields on BaseNode
ticket_typeenumClassification of the ticket
severityassessmentImpact severity of the issue (1 = cosmetic, 5 = service down)
resolutionstringDescription of how the ticket was resolved
sourcestringWhere the ticket originated (e.g. "email", "in-app", "chat")
signal_sentimentenumDetected sentiment of the customer's message
signal_channelstringChannel through which the signal was received
signal_urgencyenumPerceived urgency of the customer's request
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
6 phases, initial: open · template: INCIDENT
5 edge types connected to this entity.
product_supports_via_support_ticketservice_blueprint_contains_support_ticket