The Essence
The Ticket is the reactive response container — a customer has a question, encounters an issue, needs help, and the Ticket captures that need and tracks it to resolution. Tickets are inherently customer-initiated. They don't represent planned work; they represent unplanned needs.
When someone raises their hand for help, a Ticket gives that request structure, routing, accountability, and visibility until it's resolved. Good Ticket architecture makes support efficient; poor Ticket architecture lets customer needs fall through cracks.
"Tickets are reactive. If work is planned, it's not a Ticket. Tickets capture what you didn't expect."
The Hard Line: Tickets Are Reactive
A critical architectural boundary
Tickets are for help desk. Period.
Tickets Should Always Be:
- Customer-initiated — Someone asked for help
- Reactive — Responding to an emerging need
- Resolution-focused — Goal is to answer/fix/resolve
- Temporary — Tickets close when resolved
Tickets Should NOT Be Used For:
- Project management — Use Projects for planned work
- Proactive task tracking — Use Projects or Tasks
- Deliverable management — Use Deliverables
- Internal initiatives — Use Projects
When teams use Tickets for project management, everything breaks:
- Support metrics become meaningless (mixing planned and unplanned work)
- SLAs don't make sense (projects aren't "overdue" the same way)
- Customer support visibility gets polluted
- Help desk efficiency can't be measured
Unified View Contribution
Customer View
Primary contributor. Ticket history reveals support relationship — what questions arise, how quickly they're resolved, what patterns emerge. Ticket volume and sentiment indicate relationship health. A customer who stops submitting Tickets might be self-sufficient — or disengaged.
Team Enablement
Primary contributor. Tickets define what support teams must address. Queue management, routing, SLAs, and resolution tracking all depend on clean Ticket architecture. Without proper Ticket structure, support teams can't measure or improve.
Business Context
Supporting contributor. Ticket patterns reveal product/service intelligence — common questions, recurring issues, documentation gaps, feature requests. Aggregate Ticket data informs where to invest in improvement.
Revenue View
Supporting contributor. Support burden affects profitability. High Ticket volume may signal service scope issues. Ticket patterns may indicate churn risk or expansion opportunity.
Sarah's Story
Sarah's first Ticket came three weeks into her CVP Implementation:
Ticket: "Signal pipeline not triggering workflow"
- • Source: Portal submission
- • Priority: Medium
- • Category: Technical - Configuration
- • Associated Service: CVP Foundation Support
- • Status: New
Sarah had encountered something unexpected. Her Signal pipeline wasn't advancing records the way she expected. She didn't need project work — she needed help understanding what was happening.
The Ticket captured her question and routed it appropriately. Within two hours, Ryan acknowledged and asked clarifying questions. Investigation identified a configuration issue. Ryan provided the fix plus an explanation. Sarah confirmed it was working. Total time to resolution: 4 hours. Her Ticket became a learning moment — the issue was documented so others wouldn't hit the same problem.
Later in her engagement, Sarah's Tickets evolved:
- Month 2: "How do I create a saved view for Hand Raiser contacts?" (Question)
- Month 3: "Dashboard not showing correct counts" (Issue)
- Month 4: "Can we add a custom property to track [X]?" (Request — converted to Deliverable)
- Month 6: No Tickets — Sarah had learned the system
The Ticket history told a story: early-stage questions, mid-stage troubleshooting, eventual self-sufficiency. This pattern is healthy. It indicates capability transfer succeeding.
In her portal, Sarah could see her Ticket history — all past Tickets with status and resolution, open Tickets with progress updates, knowledge base articles related to her questions. She never wondered "did they get my message?" The Ticket gave visibility both ways.
What It Holds
Request Capture
Categorization
Priority
Status and Pipeline
Assignment and Ownership
Resolution Documentation
SLA Tracking
What It Connects To
Primary Associations
Who submitted this Ticket. The requester whose need you're addressing.
The organization with this need. Provides context for appropriate handling.
What Service does this Ticket relate to? Service context shapes expectations.
What Product is involved? Enables proper categorization and routing.
If Ticket addressed in a session. Sometimes the best resolution is a conversation.
Knowledge base articles used in resolution. Connects support to documentation.
Contact-to-Ticket Labels
Submitted the Ticket
Experiencing the issue
Receives updates
Ticket-to-Object Labels
Organization context
Service context
Product involved
KB article used
Work created from request
If sales-related
Common Patterns
The Question Pattern
- Ticket created: "How do I [X]?"
- Route to support queue
- Agent provides answer (or link to documentation)
- Customer confirms understanding
- Ticket closed
- If common question: Update knowledge base
The Issue Pattern
- Ticket created: "[X] is broken / not working"
- Route to technical queue
- Agent investigates and identifies root cause
- Fix applied OR workaround provided
- Customer confirms resolution
- Ticket closed
- If bug: Create internal issue for product team
The Request Pattern
- Ticket created: "Can we add [X] feature / configuration?"
- Evaluate: Is this within Service scope?
- If yes: Convert to Deliverable or add to Project
- If no: Scope expansion conversation
- Ticket closed (work tracked elsewhere)
The Request Pattern is critical: Tickets capture the request, but planned work should move to appropriate objects. Don't leave project work in Ticket form.
The Escalation Pattern
- Ticket in queue exceeds SLA threshold
- OR Ticket priority is "Urgent"
- OR Customer explicitly escalates
Then: Notify manager, priority handling, customer communication about escalation, track escalation in Ticket history.
The Knowledge Capture Pattern
- Ticket resolved
- Evaluate: Is this a common scenario?
- If yes: Create/update knowledge base article
- Associate Listing to Ticket
- Tag Ticket with relevant topics
Every resolved Ticket is potential documentation. The support team isn't just answering questions — they're building institutional knowledge.
Value-First vs. Industrial-Age
| ✗ Traditional Thinking | ✓ Value-First Thinking |
|---|---|
| Tickets = Problems to minimize | Tickets = Engagement opportunities |
| Goal: Reduce Ticket volume | Goal: Ensure every need is captured |
| Tickets measure support cost | Tickets measure relationship health |
| Close Tickets fast (speed over quality) | Resolve needs completely (quality over speed) |
| Tickets are internal operations | Tickets are visible to customers |
| Support is reactive only | Support patterns inform proactive improvement |
Why This Shift Matters
When Tickets are just problem tracking, support becomes adversarial. The goal is to minimize tickets, deflect questions, close fast. Customers feel like burdens.
When Tickets are engagement opportunities, support becomes relationship-building. Every question is a chance to demonstrate value. Every issue is a chance to prove responsiveness. Ticket patterns reveal how to serve customers better. Support becomes competitive advantage.
Ticket vs. Project vs. Deliverable
| Object | Initiated By | Nature | Purpose |
|---|---|---|---|
| Ticket | Customer | Reactive | Answer questions, resolve issues |
| Project | Team | Proactive | Organize planned work |
| Deliverable | Order/Project | Planned | Track specific promised outputs |
The principle: If the work was planned → Not a Ticket. If you're tracking it against a commitment → Not a Ticket. If it's proactive improvement → Not a Ticket. Tickets are for "a customer needs help with something right now."
In Practice
Implementation details and configuration
What You'll See in HubSpot
Tickets live in Service Hub. Each Ticket has:
- Left sidebar: Ticket properties, status, priority, SLA status
- Middle column: Conversation thread (customer + internal), activity
- Right sidebar: Associations to Contact, Company, Service, etc.
The Ticket queue provides agent workspace with filtering, sorting, and bulk actions.
Key Properties
Key Properties
Native HubSpot Properties
| Property | Type | Purpose |
|---|---|---|
subject Native | Text | Ticket title/summary |
content Native | Rich Text | Full description of the request |
hs_ticket_priority Native | Enumeration | Low, Medium, High, Urgent |
hs_pipeline Native | Pipeline | Ticket type/workflow |
hs_pipeline_stage Native | Stage | Current status in resolution process |
hs_ticket_category Native | Enumeration | Question, Issue, Request, Feedback |
source_type Native | Enumeration | Email, Chat, Portal, Phone |
hubspot_owner_id Native | User | Assigned agent responsible for resolution |
time_to_first_response Native | Number | SLA metric: First response time |
time_to_close Native | Number | SLA metric: Total resolution time |
Value-First Custom Properties
| Property | Type | Purpose |
|---|---|---|
vf_request_type | Enumeration | Question, How-To, Issue, Bug, Request, Feedback |
vf_product_area | Enumeration | Which area of your offering is involved |
vf_resolution_type | Enumeration | Answered, Fixed, Workaround, Escalated, Out of Scope |
vf_knowledge_article_created | Boolean | Did this spawn KB content? |
vf_customer_sentiment | Enumeration | Positive, Neutral, Frustrated, Escalated |
vf_root_cause | Enumeration | User Error, Configuration, Bug, Documentation Gap, Feature Gap |
Standard Support Pipeline
New
Awaiting triage and categorization
Ticket received
Categorized and routed to appropriate queue
Portal Experience
In the My Value Path Portal, Sarah sees her Tickets:
My Support
- Submit new question/issue
- View open Tickets with status
- View Ticket history
- Access knowledge base
- Chat/conversation access
Ticket Detail
- Full conversation thread
- Status and next steps
- Related knowledge articles
- Resolution summary (when complete)
"Sarah never wonders 'did they get my message?' or 'what's happening with my issue?' Ticket visibility builds trust that her needs are being addressed."
See It In Action
Experience in the Value Path Simulator
Key Moment: Notice how Tickets are clearly reactive — customer-initiated needs — while Projects and Deliverables handle planned work. The separation enables accurate support metrics and appropriate work management.