So your team doesn't like to enter deal information, related contacts, update stages appropriately... I bet you're wondering, should I stage gate?
To "Stage Gate" is to put barriers in the CRM such that an End User (Salesperson) may not progress to the next stage of an Opportunity before they complete specific fields or processes.
The basic rule of thumb is that Sales people will HATE stage gating, but it's necessary for Sales leaders and Revenue Operations to maintain and speak towards pipeline and the quality of the deals. It's a trade off and Sales Leaders have to answer the following...
"Is the following..."
Improved deal forecasting accuracy.
Better alignment between Sales and Marketing.
Greater Scalability and Cross-Team Efficiency.
"... worth..."
Establishing buy-in and overcoming the team's resistance to change.
Defining (with exit/entry criteria) stages.
The Risks
Inadequate training.
Future changes to stages.
Over-reliance on stages and over-homogenization.
This article was written in conjunction with David Weiss of The Sales Collective who navigates the subtleties of how teams react to stage gating from a CRO perspective.
Playing Defense
Validation Rules
The basic method for implementing Stage Gating is to write a validation rule when your record (be it a Case, a Lead, or an Opportunity generally) hits a specific stage or status. You'd use it when a field has dependencies later in the Sales Process and/or you can answer a sentence like "Field X is mandatory for the user to have reached this point in the process."
The WORST part of any salesperson's job, seeing a red pop up or worse when it's not field based and doesn't highlight where on the page there is a "mandatory" field. Respecting that, you'll learn ways to prompt users to the correct fields later in the article. High level takeaways would be:
One validation rule per field.
Locate the validation rule at that field.
Exceptions only around business processes and wizards.
Offense - Reimagining Stage Gating
When thinking about Salesforce Usage, and you are limiting someone when they are progressing a deal you're sending a weird message.
Sales Rep: "Hey SFDC, I want to update this stage to 'Negotiation!' Woohoo!"
SFDC: "Hey Sales Rep, that's great and all... but can this just won't do. Fill in these 10 fields you never use, then I'll think about it."
Sales Rep: "Fine... ugh! Where are those fields again?" (2 minutes) "Ok is this ok?")
SFDC: "Hey Sales Rep, that's great and all... but can this just won't do. Fill in these other 2 fields, then I'll think about it."
Sales Rep: "F*** you!"
You penalize the sales person for updating information that you are requesting all the time, "Update your pipeline!" - Every VP of Sales ever. So how can you start think about avoiding a rep from hitting this type of error and incentivize them to use the CRM, not just satisfy it. It's a project, but it's fun.
Audit required fields and build common definitions across all teams.
Define end user stories (SDR, AE, Marketing) (Deal Types) (Stages).
Define system agreements between teams and HOW information will be used.
Build and Test with end users.
Attention as it goes live, existing data, and adjustment requests.
Salesforce has the ability to act like a functional product like never before, so if you understand the business and dependencies,
Page Layouts
Pay careful attention to which fields are populated and where. This should do the work of accomplishing two things, information for Leadership and information important to the Sales Person. Encouraging the marriage of these two owners may seem impossible at times, but by working with your counterparts and creating page layouts for specific user groups you'll be alright.
Path is also a "fun feature" sort of stuck between these two worlds. You can show a nice UI on the Stage (field) offering a satisfying explosion of confetti when they close the deal... nice... You also have the option of offering several (up to 5) important fields but due to the subsequent effect on the page layout and distribution, I usually leave this blank.
Dynamic forms (released as part of the Winter '23 release) is a game changer. It's possible to create a completely customizable experience based on the user group summarized in one Lightning Record Page layout. Of course you may want to expand based on size of your org, you now have the ability to populate the most important information varying on user profile, record values, etc... Just depends on how thought out your process is, how often it's going to change, and whether your architecture allows you to adjust for all the varying deal types that come your way.
With the reliance on profiles to assign page layouts, we are seeing those disappear in the rear view mirror. Having the ability to provide both User and Deal information on Dynamic forms will allow you to have the lowest level of detail (for those who have made the move to lightning).
Wizards
Wherever I can, especially upon Opportunity creation, I prefer to isolate the user experience within a Wizard which houses all the business logic and automation required for the "behind the scenes" tying of information. A user clicks a button and is brought through a series of screens answering questions they should have the answer to, and only being presented the information necessary. This takes a user from having to remember the 10 things (Opportunity Products, opportunity naming convention, deal type, primary contact, campaign attribution, etc...) to 3 screens of targeted data collection and you get a stream of homogenous perfectly created opportunities.
When we think about stage gating, or at least when I do, it's isolated to the moment when a rep wants to change a 'stage' or a 'status.' I'd offer it's actually the accumulation of fields that naturally would be filled (if found useful) by the Account Executive throughout the lifecycle of this specific deal type. By structuring the activities they need to communicate to other departments, leadership, success you may find that wizards allow you to eliminate the idea of "Stage Gating" all together!
Not sure if you caught it, but I slipped "if found useful" in my definition. Going back to the marriage of Leadership and Salesperson information, you now have the ability within Salesforce to design a product with varying user stories that overlap. Deliver a request or update process that gives the salesperson a resource in exchange asking for information.
Giving information to Sales People
Information and Data is only useful when used and if a Salesperson never receives feedback on necessary fields, or is able to action off of a value, why would they ever care to enter it? Unfortunately at this point you can't require a salesperson to enter something they don't want to... meaning they have to WANT to.
When you require a salesperson to enter information, there is a good reason for it. It helps you predict if it will close, why would that not help a salesperson learn and grow? Show them not only the sales pipeline metrics, but the marketing reports, show them customer success metrics! Show them absolutely everything in a way that assists them to sell.
And what if you can't? If you are completely aligned and hold yourself to a high bar, you should be able to automate it... Whether that's through building a wizard or using Dynamic forms to ensure that your sales layout looks more like a customer service page layout.
Feedback and Attention
Beginning to view Salesforce as a product and the user stories you need to design to changes the amount of interaction and change control that is necessary for your organization.
When designing use your resources. I've never met a Rep without strong opinions, bring them into the process and solve their problems. Removing their barriers is the best way to increase usage and to have the ability to push back when another department needs something from them.
And finally, of course, the more complex your sales process, team communication, deal variation the more time you will need to spend resolving dependencies. If you make a field necessary for a complimentary process, you'll have to remember the wires you've so delicately hung throughout the rafters. For instance, adding a new field will require a new permission structure, Flow update, validation rules AND it's position in the new product you've thoughtfully designed.
Getting the right data is critical to decision making which can be impossibly hard when needing to extract it from a Sales Rep or any other human. From this article, and the one from David Weiss focusing from a CRO perspective, I hope you've learned a few more options before simply requiring fields upon stage movement. If you'd like to learn more or talk through a puzzle, The Sales Nerd specializes in helping companies navigate complex challenges marrying Salesforce+ consulting with a Revenue Operations lens.
Comments