The Microsoft Dynamics CRM Blog
News and views from the Microsoft Dynamics CRM Team

Weighted Revenue

Weighted Revenue

  • Comments 2

For some strange reason the subject of Weighted Revenue has been on my mind lately. Strange in the sense that I don’t own our Opportunity Management feature and I haven’t written an sales pipeline report in a while. Perhaps I’m having flashbacks to an earlier stage in my career where I was obsessed passionate about such calculations.

Opportunities (or Deals if you prefer) have an estimated revenue attribute. This revenue estimation is usually derived be one of two methods: a sum of products to be sold or a guess by the salesperson as to the total deal value. This revenue estimation is then ‘weighted’ based on the success chance of that deal.

Now this is where things can turn a little crazy. Most companies weight the revenue based on the opportunity success %. For example, if you have an opportunity with $150K estimated revenue and a 50% success chance then the weighted revenue will be $75K. This weighted revenue amount for each opportunity is then aggregated by the estimated close date (or estimated payment date). This aggregation is supposed to estimate the amount of revenue which a company will revenue in that timeframe. This approach is what I call ‘simplistic weighting’.

Consider some of the flaws of this approach:

  • No distinction is made between ‘guessed’ revenue and revenue generated from potential line items.
  • Success chance for the opportunity usually relates to a sales cycle stage (for example: Close = 80%).
  • No historical success data is used to calculate the success chance.
  • No historical revenue data is used to calculate the weighting by opportunity characteristics (segment, product combination etc).
  • It does not take into account the historical ability of the salesperson to estimate revenue. Some salespeople can be notorious for sandbagging revenue calculations.
  • Some of the opportunity product line items may not have an equal level of interest by the customer.
  • Often the estimated close date doesn’t represent the actual date/month when revenue will be booked. Sometimes an offset calculation is used – but does it take into account average payment times (for that specific customer, for the customer’s segment etc.).

Improving your weighted revenue calculations is critical to understanding the short to medium term performance of your sales team. It’s important to never use weighted revenue as a performance incentive. You need the flexibility to change your revenue weighting at any time. You should also consider running multiple weighting models in parallel.

You should try and test your revenue weighting model on a regular basis. How accurate was it in predicting the actual revenue which flowed in? Which salespeople did it accurately predict? What were the characteristics of their specific pipelines? What are the effects of a great marketing campaign on your pipeline?

Having a good revenue weighting model is key to having a deep understanding of your companies ‘sales dynamic’. A CRM system has many function (improving customer relationships, increasing sales productivity etc) – but it also must tell you one fundamental data point: How much money are we going to bring in next week/month/quarter/year?

Remember: [Estimated Revenue] * [Close %] just isn’t good enough!

Philip Richardson

  • By a coincidence, a sales director made very similar points to me today, very forcibly.  He is a believer in the principle that the past is a good basis for predicting the future - when it comes to predicting opportunity win probalities based on certain factors. So he's keen on having sales pipelie reports based on weightings derived from past performance in the CRM database per sector, project type etc. A kind of sanity check on salesman- or stage-based weightings.

  • Why can CRM help by calculating this stuff automagically.  There should be a reoport or 2 that shows sales closes by product.

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 2 and 1 and type the answer here:
  • Post