Ticket pipelines work like deal pipelines for support. Each ticket sits in one status at a time, and the status tells the team what needs to happen next. Every status is marked as open or closed, so HubSpot knows which tickets still need work and how long each took to resolve. Portals can have more than one ticket pipeline, depending on the subscription.
Good statuses describe whose turn it is. "Waiting on us" and "waiting on customer" are more useful than "in progress", because they show where the delay is. Separate pipelines make sense when processes are different, such as technical support and billing requests, but too many pipelines make reporting hard.
Tickets get stuck when nobody owns the next step. Tickets without an owner, without a priority, or untouched for days are the usual signs. Another common gap is tickets with no associated contact or company, which means the support history never shows on the customer’s record and account managers miss it.
Review the pipeline every few months. Remove statuses nobody uses, check that closed statuses are marked closed, and build a view of open tickets untouched for a week so the team can clear them.
Example
Riverside Telecom, a fictional internet provider, had a ticket pipeline with eleven statuses, three of which meant the same thing. Tickets often sat in "pending" with no owner. Cutting the pipeline to five statuses based on whose turn it was, and requiring an owner at creation, halved the number of tickets untouched for seven days.