Quantity of Pipeline Stages Best Practices?

Service Hub Tickets & Conversations
1

I’m newer to the Admin side of the platform(end user for a year, recently promoted).

When my company first started using HubSpot as a Service Desk platform we were guided towards a “limited quantity” of Pipeline Statuses.

Because of this we have effectively a secondary property that we use to track “How” an issue was resolved, did we resolve it, did we send them to another department, another company, is it unresolved, etc.

Currently we have 4 pipeline statuses going from “New(open)” → “In Progress(open)” → “Resolved(closed)” or “Unresolved(closed)”

We then have this second property that further details how it was closed

Resolution/Status options:

Product Support Resolved

IDO Resolved

Referred to other Company

Referred to other Department

Customer Unresponsive

Customer Education

Would it be unreasonable to have the options for Resolution/Status just converted to different Closed pipeline stages instead?

3

Hey @mdconnor,

Thanks for posting in the Commuity!

I’d like to tag in some of our experts to see what insight they might be able to share in terms of best practices here! @karstenkoehler, @danmoyle, and @Josh - anything to share with @mdconnor based on your own experiences?

Shane, Senior Community Moderator

4

Hi @mdconnor,

Yes, it would be unreasonable. A lot of people tend to treat pipeline stages like a kanban board, like in Trello, but that’s not what it’s meant to be used for.

A pipeline stage is a status that a record holds. The fact that a ticket is closed is a status, in progress (potentially with nuances “waiting for customer”, “waiting on us”) is too etc.

Why a ticket was closed is a closed reason and I would store it exactly how you are currently doing it. It’s easier to report on, it means that you don’t have to edit your entire pipeline whenever a reason is added or removed and I would generally consider it best practice.

Using dependent properties by ticket status (show reason when ticket is closed), it’s also a great UX, in my opinion.

Best regards

5

Hi @mdconnor,

I wouldn’t say that it’s unreasonable, but I will say that, from my experience, the more common approach is to have a resolution status as a property on a single closed stage vs individual stages for each.

You may have a use case in which the multiple stages are a better fit, and as long as you account for this in reporting, it will work from a functionality perspective.

Josh

6

Welcome to the Community @mdconnor! You’ve got good guidance from @karstenkoehler & @Josh here. I’d also suggest you keep the four lifecycle statuses and retain a separate Resolution outcome property. Your current model is a sound Service Hub design: ticket status should express where the ticket is in its workflow, while the resolution field expresses the final disposition. In my experience, making those six outcomes separate closed statuses is technically valid, but it usually makes the ticket board and operational reporting noisier without representing additional workflow progress. For example, “Customer Education” and “Referred to other Department” are outcomes, not distinct service-desk steps that an agent works through.

I’d also suggest setting your resolution outcome property as a required conditional property when someone moves a ticket to either closed status. You can make properties required by stage/status in the pipeline configuration, so an agent cannot close a ticket without recording the disposition. Hope that helps add to your thought process!

8

Hi @mdconnor — I think your current setup actually makes sense, and I wouldn’t turn all of those resolution options into separate pipeline stages.

One thing that has helped me when designing pipelines in HubSpot is to ask: “Does this represent a step in the work, or does it describe how the work ended?”

In your case, New → In Progress → Resolved/Unresolved describes the journey of the ticket. The other values — Product Support Resolved, IDO Resolved, Customer Education, Customer Unresponsive, Referred to another Department, etc. — describe the outcome.

That distinction becomes pretty useful once you start doing more with Service Hub.

For example, you might eventually want to report on:

  • How long tickets typically remain In Progress

  • How many tickets are resolved vs. unresolved

  • What percentage of tickets end in Customer Education

  • How often tickets are referred to another department

  • Whether certain resolution outcomes are increasing over time

If those outcomes were all pipeline stages, your pipeline would start representing why something happened rather than where the ticket is in the process. It can also make automation and reporting harder to reason about because each new resolution type becomes another stage to manage.

I’d keep the resolution property separate and make it required when a ticket is closed. That way, the agent still has to capture the outcome, but the pipeline stays focused on the actual support workflow.

A simple rule I’d use is:

If the value changes what the team should do next → it probably belongs in the pipeline.

If it simply tells you what happened → it probably belongs in a separate property.

So, for example, “Waiting for Customer” could reasonably be a pipeline status because it changes the current state of the ticket. “Customer Education” is more of an outcome, so I’d keep that as the resolution.

I wouldn’t worry too much about having four stages versus six or eight. The important thing is that each stage has a clear operational meaning for your team and is something you can actually act on.

Your current model sounds pretty clean to me. :+1:

If this helps answer your question, feel free to mark the reply as a solution — it helps other Service Hub users with a similar setup find the answer too!

Thank you
Connected CRM Studio