HubSpot Tickets

A HubSpot ticket is a CRM record, not a mailbox thread. Understanding that difference is most of what makes the rest of Service Hub make sense.

What HubSpot tickets are

In HubSpot, a ticket is a first-class CRM object, sitting alongside contacts and companies. It has properties, associations, an owner, a create date, an audit trail and a place in a pipeline.

It isn't the email. The email is a conversation thread, and the ticket is the record of work built around it, which is the design decision underneath all of HubSpot customer service. That distinction matters because you can have a thread with no ticket (the free conversations inbox, working as a shared mailbox) and, occasionally, a ticket with no thread at all (someone rang, an agent logged it by hand).

Once you internalise that, the rest follows. Views filter properties. Workflows read properties. Reports group by properties. The conversation is the human bit in the middle, and everything operational hangs off the record wrapped around it.

What it connects to

Associations are where HubSpot tickets differ most from a standalone help desk.

Contact. The person who raised it. This is the association that decides whether your reporting is honest, because a ticket attached to a stray duplicate contact vanishes from that customer's history.
Company. Usually inherited from the contact, which is why company assignment rules matter more to support than most people expect.
Conversation. The thread in the inbox, threaded inside the ticket so agents reply in one place.
Other tickets. You can associate tickets with each other, which is manual and useful for genuine parent-child cases like an outage with many reporters.

One thing worth saying plainly: association isn't deduplication. Two tickets can be associated, sit next to each other in a view, and still both be worked separately by two agents. HubSpot won't stop that.

The lifecycle

A ticket moves through stages in a pipeline. HubSpot ships a default pipeline and most teams should use it for a month before changing anything.

The shape almost every support team converges on:

New. Arrived, nobody has looked at it.
Waiting on us. Assigned, in progress, the clock is our problem.
Waiting on customer. We replied, we are blocked. Separating this from the previous stage is the single most valuable thing you can do to your pipeline.
Closed. Resolved, or closed for another reason recorded in a property.

Two stages are technically statuses in HubSpot terms: everything is either open or closed, and stages map to one of those. That mapping drives your reporting and your automation, so check it when you build a custom pipeline rather than discovering it later.

Reopens happen when a customer replies to a closed ticket. Decide deliberately whether that reopens the original or creates a new one, because the two choices produce very different resolution numbers and people rarely notice which they chose. More on the structure in HubSpot ticket pipelines.

Where tickets come from

Four sources, in rough order of volume for most teams.

Connected email channels. A message to your support address creates a ticket, if the channel is configured to do so. Some teams leave that off and wonder why the queue is empty.
Chat and the customer portal.
Forms. A support form that writes straight to ticket properties is the highest quality intake you will ever get, and every extra required field reduces submissions.
Manual and API. Agents logging a call, or another system creating tickets programmatically.

Whichever route it takes, ask the same question of each: how much does the ticket already know about itself at the moment it's created? That answer decides how much triage a human has to do.

What tickets won't do

Useful to know before you design around them.

They don't detect their own duplicates. Nothing compares a new ticket to the open queue. Two agents replying to the same problem is a normal Tuesday.
Merging is two at a time and permanent. From the Actions menu on the record, no undo, no bulk mode.
Deleting isn't archiving. A deleted ticket takes its history with it and your reports change shape. Close things, don't delete them.
Stages aren't categories. If you find yourself adding a stage called "billing", you wanted a property.
FAQ

Frequently asked questions

Is a HubSpot ticket a CRM object?

Yes. The HubSpot ticket object is a standard CRM object like contacts and deals, which is why the HubSpot ticketing system inherits properties, associations, workflows and reporting from the rest of the CRM.

What is the difference between a HubSpot ticket and a conversation?

A conversation is the message thread. A ticket is the CRM record with an owner, status, properties and pipeline stage. A conversation can exist without a ticket, and a ticket can exist without a conversation.

Are tickets available on the free HubSpot tier?

Yes, in a basic form, along with the conversations inbox. Automation, routing, SLAs and the help desk workspace require paid Service Hub seats.

Can one ticket be linked to several contacts?

Yes, a ticket can carry multiple contact associations, which is handy when several people at one company are on the thread. The primary association is still what most reporting keys off.

How many ticket pipelines should we have?

Usually one. Create a second only when the stages genuinely differ. Two pipelines with matching stages were always one pipeline plus a property.

Can you merge two HubSpot tickets?

Yes, from the Actions menu on a ticket record, two records at a time. The merge is permanent and can't be reversed, so check before confirming.

Two records, one problem

The ticket object has no idea another ticket says the same thing. Ticket Merger does that comparison automatically on Zendesk and Freshdesk today, with HubSpot on the roadmap.

Start free trial

14-day free trial. No credit card required.