Set up ticket pipelines and routing

Tickets in HubSpot are records of service, support, or success enquiries. If deals track your revenue pipeline, tickets track your delivery pipeline. Every post-sale process (onboarding, support, renewals, customer success) runs through ticket pipelines.

The structure is straightforward: ticket properties hold the data, ticket records live inside ticket stages, and the combination of all stages forms a ticket pipeline. You can have multiple pipelines for different purposes: one for onboarding, one for support, one for customer success escalations.

Where most teams go wrong is treating tickets as a generic inbox. They create one pipeline with three stages (New, In progress, Closed) and wonder why they can't track anything meaningful. Your pipeline stages should represent milestones, not open-ended states. "Kickoff completed" tells everyone exactly where an account stands. "In progress" tells you nothing.

Design your onboarding pipeline

Go to Settings > Data Management > Objects > Tickets > Pipelines. If you don't have an onboarding pipeline yet, click "Create pipeline" and name it.

Your stages should map to the actual milestones in your onboarding process. Here's a structure that works for many B2B businesses:

Open statuses: New > Kickoff scheduled > Kickoff completed > Project created > One-month check-in > 50% complete > Handoff call booked > Handoff call completed

Closed statuses: Onboarding complete

You can reorder stages by drag and drop. Every stage must be marked as either "Open" or "Closed", which controls how HubSpot counts active vs resolved tickets in reports.

The naming convention matters: use completed or created (past tense) for statuses that represent finished milestones, and scheduled or booked for statuses that represent upcoming ones. This makes it immediately clear when someone glances at the pipeline whether a milestone is done or pending.

Add conditional status properties

Conditional status properties are requirements that must be filled before a ticket can move to a specific stage. They're your data quality enforcement.

To set them up: in your pipeline settings, click "Edit properties" next to any stage. Select a ticket property and mark it as "Required". Now, when a rep drags a ticket to that stage, they'll be prompted to fill in that field.

Common examples:

Onboarding complete stage: require the "Service manager" field so you know who takes over post-onboarding.

Closed resolved stage: require the "Resolution" field so you have a record of how the issue was addressed.

Handoff call completed stage: require "Next steps" so there's documentation of what was agreed.

You can use any default or custom ticket property as a conditional requirement. If you need properties specific to your onboarding process, create them first under Settings > Data Management > Properties (select "Tickets" as the object).

Design a customer success pipeline

Alongside your onboarding pipeline, you'll likely need a customer success (CS) pipeline for managing at-risk accounts and escalations. This is a separate pipeline with its own set of stages:

At risk > Immediate action > Recovery in progress > Closed resolved > Closed churned

Both "Closed resolved" and "Closed churned" should be marked as closed statuses. For "Closed resolved", add a conditional status property requiring the "Resolution" field, so reps must document how the situation was addressed before closing the ticket.

This pipeline connects to health scores and automated escalation (covered in later articles). The key idea: when a customer's health score drops below a threshold, a workflow creates a ticket in this CS pipeline at the "At risk" stage, and it appears in the rep's workspace immediately.

Route tickets with workflows

Ticket routing determines who handles what. For onboarding tickets created from the sales-to-service handoff, routing happens in the deal or ticket workflow (covered in the previous article).

For support or CS tickets that come in through forms, email, or automation, you need separate routing logic. Create a ticket-based workflow with an enrollment trigger based on the pipeline and status (e.g. Status is "New" in your support pipeline, AND Ticket owner is unknown).

Your routing options:

Round-robin rotation: distribute tickets equally across team members. Simplest option, works when all reps handle all types.

Property-based branching: use an if/then branch based on product type, region, or company size to route to specialised reps.

Team-based rotation: rotate amongst a HubSpot team rather than individual users. Requires your teams to be configured under Settings > Users & Teams.

Understand ticket properties

HubSpot comes with default ticket properties (status, priority, source, category, etc.), but you'll likely need custom properties for your specific processes.

Go to Settings > Data Management > Properties, then filter by "Tickets" to see everything available. Default properties created by HubSpot are listed alongside custom properties created by your team.

Common custom properties for service teams: onboarding type, product purchased, service tier, escalation reason, health score at time of ticket creation. Create these before you build your pipelines so they're available for conditional status properties and workflow branches.

Your ticket pipelines are the operational backbone of your service programme. Every interaction with a customer post-sale should have a corresponding ticket in the right pipeline, at the right stage, with the right owner.

Start with two pipelines: onboarding and customer success. Keep stages based on milestones, enforce data quality with conditional properties, and automate routing so no ticket sits unassigned. As your processes mature, you can add pipelines for support, renewals, or upsell motions.

The test: can a manager glance at your pipelines and immediately know the status of every active customer engagement? If yes, your structure is working.