The first time I was the sole administrator for a CRM instance, I was lucky.
We hired a team of experts who conducted detailed requirements gathering, and they took the time to explain why they chose when to customize and why they chose not to customize.
It was a tremendously valuable learning experience that I looked back to many times in my career.
Particularly when I walked into a startup that didn't understand the ramifications of trusting an implementation to a newly minted administrator. All too often, young companies only decide to invest in an experienced administrator when their sales team revolts and stops using their CRM. In this case, it was my job to make it usable again.
These experiences reinforced my gratitude for having guides during that first implementation. I hope that by sharing this knowledge, you can avoid making a decision that will cause you pain down the road or reverse a less than ideal configuration in an org you're managing today.
Note: Many of these recommendations are CRM agnostic, but all assume you are in a B2B organization or a B2C organization with a long and complex sales cycle. Those who use Hubspot will need to sub out the term "opportunity" with "deal." I will do my best to note when I'm speaking to a Salesforce-specific set of features.
If you walk away from this article and retain one piece of information, let it be this:
If you don't prioritize usability, your data will be garbage.
I've worked in multiple companies where the executive attitude was that salespeople were paid a base salary to do data entry.
B***s***.
A salesperson's base salary is not compensation for using a system that barfs validation rules every time they try to save.
As an administrator, it's our responsibility to advocate for the end user because the more complicated the system is to use, the lower our data quality will be.
Case in point. I worked for a company, and the CEO wanted sales representatives to answer a list of fifteen questions in depth about the product to optimize development. He didn't look at the data or ask the product team what they wanted to know, and no one thought through the user experience.
The result was a bunch of sales reps who hated to use their CRM and randomly selected checkboxes and filled out "-" in text fields just to get to the next stage.
The product team didn't use the data because they couldn't make sense of it and the sales team complained about the CRM every opportunity they got.
You are the gatekeeper. Watch your validation, custom field, and required field count. If the process or layout gets overwhelming, it's time to do some housekeeping.
There are metrics every business demands. These data points inform the sales strategy and help the C-Suite communicate to the board. Your list of requirements should hold common metrics at the top of your list:
These metrics help the business understand how many salespeople they need to have on staff to attain a specific number, what the typical customer fit is, and growth trends. Each metric should have a clearly defined definition and reporting standard used across business units. For example, a New Logo is a location (which may be a division of a larger organization that has purchased from us that has a distinct set of decision-makers) that has never purchase a product from our company. The New Logo Date is the Close Date of the original Opportunity.
Other data points are beneficial to businesses trying to understand the effectiveness of their sales team—opportunity stage velocity, stage loss, stage progression probability, and pushes.
You'll need to think through whether or not you allow salespeople to move both forward and backward with their Opportunity Stages. Your decision will inform whether you snapshot Stages at the date they first pass a stage or the last time they reach a Stage. Strictly relying on Opportunity Stage history is fine if you have a customer data platform or data warehouse/lake, but it is a pain if you're trying to run reports in your CRM.
Do you allow salespeople to skip Stages? If so, you'll need to decide whether you capture when a Stage is passed in addition to attained or if you document the stage is skipped.
Do you audit the Close Date to match when the contract is actually received? If not, you should. Using the date the opportunity reaches Closed Won status can complicate reporting. Having a reliable Close Date means a lower probability that people analyzing the data will choose the wrong field.
You may want to add a push counter to document how many times an opportunity close date is pushed to the future before closing. Just make sure you don't also count when someone changes the date to be sooner, like when a deal closes before the end of the month, and the close data is adjusted.
People will also want to understand where your pipeline is coming from. Anyone in B2B understands calculating this is very complicated. It's rare a deal results from a single person's efforts. It takes Sales, Marketing, Channel Sales, and Customer Success to win a deal, yet we like to capture a single Source. For more details on Campaign best practices, check out this article.
In general, it's a good idea to lock down your opportunity once it's Closed Won. This can be achieved through page layout assignments, permission sets, or validation rules, which allow you to exclude specific profiles from the logic (such as your operations crew who needs to perform closing actions).
It's also a best practice to lock down your Amount field after a particular stage to be driven by products associated with a primary Quote.
Most CPQ tools will do this for you, but if you don't have a CPQ tool, you'll need to put a validation rule in place. If you don't use products or CPQ, it may be a good idea to have a stage just before Closed Won (like Pending Review or Contract In) that locks your fields from editing by the majority of users. Then, have your deal desk verify details like Close Date, Amount, etc., before updating the Opportunity to Closed Won.
A lot of companies decide their CRM is their "System of Truth." This is something we can debate, but let's save the debate for another day.
Suppose your executive team is open to your revenue "Truth" to be tied to an object other than opportunities. In that case, I recommend that your revenue number tie out to service contract data or objects that record payments that tie out to your accounting system. Opportunities are typically used to indicate amounts associated with sales commissions and only should be adjusted if an event impacts commission. For example, if a person cancels within 30 days and the account executive is eligible for a clawback, it may be worth updating the Opportunity to Closed Lost.
If your executive team insists that your opportunity amounts tie out to bookings, you'll need to define a process for cancellations and partial payments.
I recommend that you retain your original opportunity information. Your sales assigned opportunities should reflect the original contract agreement. An opportunity of type "Correction" (or some other obvious label) should be used to document the delta between what was promised and what was received.
This does not mean that you book a correction for a cancellation at the end of the contract term. In that case, your renewal (which is ideally automatically generated) is marked Closed Lost, your Account Type or Status is moved to "Customer - Inactive" (or similar), and you have a Churn datestamp at the end of the contract.
Corrections should be used where a customer refuses to honor their contract and does not remit payment.
Any time a new customer is obligated to a contract term, the money associated with their agreement should be related to a Closed Won opportunity.
The exception to this is a soft agreement that involves quarterly payments, especially if there is a high occurrence of cancellations mid-year. In this case, the earliest opportunity should be associated with the Amount guaranteed by the contract (the first quarter). Subsequent quarters should be assigned to a CSM or AM to manage as renewals.
Otherwise, if an amount is not guaranteed and requires an additional contract, that is a renewal.
Traditionally, most organizations I've worked with used the Type field or Record Type to differentiate between Expansions and Renewals. This works just fine if you're in an organization with separate teams handing expansions and renewals (which was the case).
The traditional process isn't optimal when you have a single team managing both the renewal and expansion processes.
This results in either forcing the team to manage two opportunities for what, from their point of view, is a single sales motion or having your Ops team split out opportunities after the contract has been received.
Why create extra work for people when you can manage the type on the product level? Before you tell me you lose visibility into the type (which was my initial thought), this pivot will require you to run your Type segmented reports differently (Product reports vs. Opportunity reports). You won't lose visibility, and (Bonus!) you'll gain a bunch of time back.
For this to work well, you'll need to allow for quoting both Renewals and Expansions on a single opportunity and keep your SKUs as simple as possible. Which brings us to...
Once I started using Sales Paths in Salesforce, I wished they'd rolled them out years ago. Sales Paths allow up to five fields to be up-leveled during each stage of your process. So if you have a qualification process that's well defined or you need contract details specified before onboarding, Sales Paths are great. It also gives you a little extra ammunition when you push back on an over cumbersome process — "Sorry Boss, we're out of fields!"
As someone who was an administrator back in the Goldmine days (it was terrible) and managed many deals through Excel "quotes," CPQ seemed like a magical fix.
And it can be great.
Just don't go crazy with the required fields and SKUs.
I've seen organizations that didn't put a Term field (or contract duration or whatever you want to call it) on the product line level, and that resulted in SKUs for every possible contract duration. Which seemed okay at the time, but then they started allowing contract co-terms for Expansions. And then they had to manage renewals. And the SKU count exploded.
Make calculations as passive as possible, calculate term dates for your salespeople, bundle products if it makes sense, and make creating multiple variations of the quotes as simple as possible.
For example, suppose you offer lower rates on longer contract agreements (say, a one-year subscription costs 15% more per month than a three-year subscription). In that case, your sales team will naturally want to quote multiple configurations so the client can see the savings for themselves. Make life easier on everyone by automatically allowing people to toggle primary quotes and change the Amount associated with the opportunity. It's worth the development time.
No one wants to ask for approval for every little thing. This is why automated approvals are so great. They allow salespeople to create automatically approved quotes when they play within pre-defined ranges and elevate an approval request to the right tier of management when they step out of bounds.
But.
Don't let your Finance team go crazy when you define the rules. Start with Discounts and Net Payment Terms as your two approval variables. Don't allow people to change contract specifications in other areas without working directly with the deal desk.
If you roll out approvals with five different rules to work through, your sales team will stage a protest.
----------------------
In short, keep it simple, look at the requirements of tools you want to buy down the road, and keep the long-term goals of the company in mind before creating new objects and fields. The closer to standard functionality you remain, the easier life will be.
