Customer support request or issue
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. The tension is that a ticket is two things at once. To the person who raised it, it is a problem waiting to be solved. To the product team, it is a data point about where the product is failing, and most organisations are far better at the first reading than the second.
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.
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 articleKnowledge Base ArticleContent & KnowledgeA knowledge base articleView reference → 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.
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
Type-specific fields on BaseNode
ticket_typestringClassification of the ticket
severityobjectImpact 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_sentimentstringDetected sentiment of the customer's message
signal_channelstringChannel through which the signal was received
signal_urgencystringPerceived 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
5 phases — initial: opened
5 edge types connected to this entity.
product_supports_via_support_ticketservice_blueprint_contains_support_ticket