TL;DR
Adding products and pricing to CRM provides valuable digital records that can be used throughout the business. However, it can be challenging due to the complexity of managing multiple price points and variations or combinations of products. It’s important to consider your team’s and any related teams’ views on handling product and pricing data, and to test your model before uploading to CRM. Naming conventions can also be exceptionally useful. ——–
The benefits
It seems like a great idea to add all your products and pricing to CRM, so each Opportunity (or Deal) captures the exact details of what is sold. And to be clear it is a great idea; the value is immense.
Once you can have a digital record of what is sold, you can use that throughout your business. You can pass the details to your provisioning or delivery team and tell finance and billing precisely what to bill and at what rate. You can track discounting by product and by salesperson and use the data to make better decisions long term.
An interesting metric is how many times the products and pricing are updated. Most of your salespeople often sit around an average, with a small number well outside the average. In one instance, the norm at an IT company was three updates to product and price per deal. Two salespeople were closer to ten. On investigation, the sales leader gained feedback from these salespeople’s customers that “they did not listen”. They unsurprisingly also had a low, close rate – good data to surface!
Getting started
Let’s add products and pricing to CRM.
But how hard is it, and what are the challenges? Great question! In general, the more price points you have, the harder it is. This is because if you have a large number of price points, there is just a lot to manage. Note that the key is price points, not products. The number of price points can be massively higher than the number of products. Multiple sell prices per product or many variations or combinations are usually the cause.
If you have a large number of sell prices because of multiple sell prices (different sales channels etc.) or multiple currencies, this is unwieldy to manage in CRM but perfectly
doable. In addition, it can be made easier for your salespeople as you can align price points and currencies to customers and sales teams so that numerous filtering decisions have already been taken when they add products to an ‘Opportunity’.
When you have lots of variations or combinations, it starts to hurt your brain. You have two main options.
- Create a ‘product’ or SKU for every variation or combination that affects the price.
- Don’t build the variations or combinations into the products but leave them as modifiers to add to them.
Which model is best?
Start by doing some maths. Option 1 is a times, times, times problem. The number of price points will increase very quickly. Ultimately it is often better because the amount of thought you need to put into it means you end up with a very tight set of products and pricing. The main downside is the sheer number of price points you create. Sales can need help to select the right one when there are numerous similar options. You may require a custom product filtering tool in your opportunities to help.
Example – Ice cream.
If you have 5 types of cones or cups, 10 ice-cream flavours and 4 topping options then you have (5 x 10 x 4) 200 possible price points. In this example it would be easier to keep them separate.
Talk to your team and related teams – how do the finance system and operational system handle products and pricing? Again, it’s typically easier to do it consistently across the organisation.
How do I know it’s right?
Test, test, test. Create your model and test it on salespeople, finance, and operational people. Often the solution that will work best in your business is a hybrid that is not in a true sense ‘optimal’ but one that meets your specific set of constraints. Refrain from falling into the trap of fighting a holy war over the purity of the model. A joint agreement on a model is a much better predictor of success.
The single product construct problem
Right, so you have your model, it’s all broken out in a spreadsheet, and you are ready to upload to CRM. This piece is super important. In Salesforce and most CRMs, there is only one product construct. Any field required by any product has to be in the construct, which is a limiting factor if you sell lots of different types of products. It can be beneficial to combine data into a description or product name field to help minimise the number of fields. Now I hear you – this could seriously jeopardise your reporting. Here is where naming conventions
come in. A naming convention is a format you apply to the product name/description with a standardised order across all products. Once you have it standardised, you can successfully and accurately report using the ‘Contains’ function to find the data you need knowing that you won’t get any false positives. In addition, a good convention should consider sorting so that scrolling through a list of product names is easy to navigate.
Product naming convention example: Name – Internet NBN Broadband 100Mbps Unlimited Convention – [category] [type] [bandwidth or speed] [billing type]
Pricing Types
Remember to consider once-off pricing and recurring pricing. You can tackle this in numerous ways. You can have a single sell price field and use a ‘price type’ field to differentiate. You can use quantity as the term for Recurring Prices (assuming a standardised period such as months). Or you can pre-bake every product as Total Contract Value (TCV), where if a recurring product can be sold on a 36-month term and it’s $100 per month, it’s $3,6000. How you tackle this should be aligned with the factors we have already discussed and sales and financial reporting. For example, if your business focuses on Monthly Recurring Revenue (MRR), you need monthly pricing in CRM, and likewise, if you are focused on TCV, you should use TCV in CRM.
All right – all your decisions are made, you have a spreadsheet with all your products and pricing, and you are ready to upload to CRM. But be warned, it’s often painful and tedious. Do some googling and read some help articles for your CRM before proceeding.
Good news / Bad news
You have tackled something hard, so give yourself a pat on the back. But don’t rest on your laurels. Inevitably you will have made mistakes, and at some point, you will need to improve your model and revise some of the concepts. So keep checking in with the users and the adjacent teams, and keep your eyes peeled for issues.
Having done this many times for many businesses, the most significant advice I can give you is to keep it simple. Do not over-optimise the first time. Complexity is hard to unwind from, so be very careful of the burden you can create for yourself and your team. If you can design an optimal model, you should simplify it to get started. Trust me; complexity is the killer, so do everything you can to avoid it. If people around you are not questioning if it’s too simplistic a model, then it’s too complex. You can easily add to it in the future.
Stay in Control
Change management is a vital part of rolling out anything new. One of my favourite hacks is to put all the feedback and suggestions in a list (online or somewhere where the impacted staff can see you noting their feedback) and then do nothing for 30 days from the feedback
date. This gives you time to gauge how much of an issue it is. In most cases, if you have done a good job, you will get a burst of initial feedback that dies down quickly and only requires a few, if any, changes. But, on the other hand, if you start tweaking the model on every piece of feedback, you will end up in a horrible place.
