Tips, Tricks & Best Practices

cjl2016
Participant

Best Practices for Sales Pipelines: To Consolidate or Not to Consolidate

When our company first started with HS, we built individual sales pipelines for each of the 5 verticals we sold into + sales pipelines for pre- and post-sale steps to fulfill orders and ensure successful implementation, as each business line followed different processes and didn't much overlap. Now that we've been able to build synergy between our services/products to offer much more holistic solutions (and now that we're looking at everything through a RevOps lens), I'm recognizing more and more the need to simplify what we have to create a cleaner sales process and to allow for Deals that accommodate multiple solutions and verticals (as opposed to creating 4 deals in 4 pipelines that all have to follow each other with one serving as the "master," followed by them jumping into new sales pipelines after closed won and either being merged or staying separate).
 
What I'd love to know is: does anyone have any suggestions on best practices for this?
  • Should internal processes (pre- and post-sale, like shipping samples, deal registration, product pickups, etc.) be moved to tickets, as opposed to living in the middle of sales pipelines as deal stages (or warranting their own sales pipelines, requiring that deals jump from one pipeline to another almost 100% of the time)?
  • How can I best account for all 5 of our verticals and their variations but in fewer (maybe even one) pipeline? While the internal processes can differ a lot for these verticals, the sales process from the customer's perspective is largely the same. Is simplifying and consolidating the sales pipeline(s) and then having all the internal variations accounted for in tickets the best system or is there something else I'm overlooking?
I'd love any and all feedback, thoughts, suggestions, etc. - thanks in advance!
4 Replies 4
JeremyHong
Contributor | Diamond Partner
Contributor | Diamond Partner

Best Practices for Sales Pipelines: To Consolidate or Not to Consolidate

Tracking, forecasting and reporting across pipelines when deals hop from one to the other can obviously be challenging.

 

Without knowing your full requirements or much about your business, I agree a single pipeline should be possible. You might just be able to create a custom deal property for "Service Line Vertical", which would essentially replace the need for separate pipelines. You can also use conditional property options [beta] with the "Service Line Vertical" field, so that other custom properties only show the values relevant to that service line. That said, custom properties is likely the best way to account for all deal variations within a single pipeline.

 

You mentioned that the process for the client is largely the same - this implies your deal stages could be standardized - for example, Discovery Complete, Needs Assessment Complete, Samples Shipped, Quote Sent, Won.

Each of these deal stages could trigger tickets or tasks, depending on what is required for that deal stage and based on the different variations of your custom properties. This enables you to use workflow logic to create tasks/tickets that are specific to the deal's criteria...eg. if a deal is Service Line = A and [Custom Property] = B, you can control what tickets/tasks are created in each deal stage, and you can create different tickets/tasks for a deal with Service Line = B and [Custom Property] = B

 

We always find process mapping the full revops process with our clients to be extremely helpful in identifying gaps and detailing the flow of leads/opps.

 

Hopefully that helps!

cjl2016
Participant

Best Practices for Sales Pipelines: To Consolidate or Not to Consolidate

Hey Jeremy!

This is incredibly helpful and I really appreciate your being so thorough. I think this is the direction I’m leaning and is what I’m working on building toward. Currently mapping out all of our internal pre- and post-sale processes to determine which need to be moved into their own ticketing pipeline vs. which can be regulated / guided with simple email notifications and task assignments.

Out of curiosity, what have you seen as far as structuring ticketing pipelines for internal processes? More specifically, have you seen more folks building their individual processes step-by-step in multiple ticketing pipelines, which are meant to guide users through each process from start to finish OR are ticketing pipelines more generic so that they can accommodate a wide breadth of possibilities and that gives users flexibility?

Basically, do you see more ticketing pipelines that look like:
Cost Requested > Submitted / Waiting on Vendor > Ready for Pricing > Create Quote > Deal Registration Active
…or something like...
New Support Ticket > Waiting on Contact > Waiting on Us > Closed

The first is walking reps through the steps but can only accommodate that particular process, while the second is not providing much guidance but can accommodate a wide range of issues or needs.

0 Upvotes
JeremyHong
Contributor | Diamond Partner
Contributor | Diamond Partner

Best Practices for Sales Pipelines: To Consolidate or Not to Consolidate

From what I've seen it usually comes down to the business culture and reporting needs, but moreso the latter. 

 

Some might want each step spelled out within the process/HubSpot itself, or they might need the ability to report on how long a ticket sits in a specific ticket status for operational reasons, ie. "Waiting on Vendor". Whereas with the broader statuses, they really just give you the ability to report on how long it takes a rep to respond - this type of ticket automation would likely be more useful for client-facing support rather than internal ops. This is an important distinction, since the two ticket pipelines examples you provided are different types - internal ops vs support.

 

Again, there's usually a bit of nuance to every business and how it likes to do things. However, in terms of deal stages/ticket statuses, in my opinion it's best to start simple and iterate based on any needs you identify. If you need to 'walk reps through the process', you can do so by creating different tickets with relevant Ticket Descriptions - so for Service Line A, create Ticket A with a Ticket Description that outlines the internal steps that need to be completed; for Service Line B create Ticket B, etc. Or, you can create a custom Ticket property, for example - "Onboarding Status = New/In Process/Complete", and each of those options creates tasks for the assigned rep.

0 Upvotes
Crystal_Hopper
Key Advisor

Best Practices for Sales Pipelines: To Consolidate or Not to Consolidate

Hi @cjl2016! Our company has 3 verticals. And our sales people like to track Inside vs. Outside sales, which leads to 6 pipelines! 😫 So I hear you!!!

 

We don't use Tickets, but that's a stellar idea. We use Tasks for small, internal items like sending a packet of info to a potential prospect. So Sales, or anyone who is doing triage on requests, can build a Task and assign it to someone who needs to do a thing and then they can check it off when it is done. I like Tasks because they have their own tab within Contacts and Companies and that creates a quick view of activity that's been done. 

 

Obviously "small" and "internal" tasks have to be defined, documented and communicated so everyone is aware. You don't want to loose the fact that these items are still "sales" and "prospecting" activities. But when a small task doesn't lead to more sales activity, you'll be glad these aren't clogging up your pipelines.

 

Best of luck!

***************************
Did my post solve the questions or challenge? Please mark it as a solution for others to find.