Salesforce Project Chronicles: Automatic Renewals
My first corporate client was a media company who wanted help building a clever renewals process within Sales Cloud. They had recently gone live with simple Opportunity management. Process Builder didn’t exist in 2010, so it was really the first chance I had to start designing coded solutions. It was a great project that really tested my ability to translate complex requirements into a Salesforce solution.
About the Client
My client sold access to PR and media content through its online media intelligence platform, enabling its clients to monitor and analyse thousands of brands. The sales model was primarily subscription-based, but also offered options such as Pay-as-you-go and Buy Now Use Later. Salesforce managed the pricing for all of these models.
Things have come a long way since, but in 2010, when Phase 2 started:
- Sales people were using Opportunities with Products to track sales
- The Finance team was distrustful of the sales team
- Finance had total control over when an opportunity could be Closed Won
- The Sales team was responsible for creating renewal opportunities.
- Renewals were to be sold at the prior year value with a percentage uplift
- After much manual reporting, Finance was finding that many opportunities were not being renewed at the correct rate; in fact, salespeople were under-selling to secure the renewals
- Build a mechanism that automatically created renewal opportunities. This included:
- Gathering up ALL the products the customer bought during the previous year, across all opportunities
- Consolidating repeated opportunity products sold in the prior year
- Calculating a full-year price for each Product, pro-rata, based on the month the customer subscribed to that Product
- Applying the uplift decided upon for that financial year
- Taking a snapshot of the renewal opportunity (and products) so that Finance could compare the current renewal to the calculated renewal
The Solution: Renewal Opportunities
- Design an Apex class to
- query Prior Year opportunities and Products
- Create a Renewal opportunity, move the close date on by a year and set the Stage to the starting Stage of the renewal sales process
- Take the prior year’s products
- If the same product was sold more than once, consolidate the prices per month
- Take the unit price and uplift it by 10%
- Create new products and relate them to the renewal opportunity
- Create a snapshot opportunity and associated snapshot products (custom objects)
- relate them to the renewal opportunity and its products
How did that even work?
The best way to understand how this coded solution worked is to visualise it. Lets’ take an example. This customer bought from the company four times at various points in 2010:
Here is a breakdown of the products purchased. Note that two of the Products have a 10% discount applied, so the total price may not make sense at first glance:
As you can see, they bought Cross-Sell 1 twice, so technically, this product is renewable for the following year. What would it look like if we pro-rated each prior year’s opportunity product to 12 months, then applied a 10% uplift? Let’s take a look:
So, we have our prices for the renewable Products, but now we need to consolidate Cross-Sell 1. Our renewal Opportunity, therefore, has only 3 products:
So why not just use CPQ for all this, you say? It was 2010. Back then, we didn’t have CPQ, or Flow, or Process Builder: anything complex was done with Apex code.
- This client had a complicated way of calculating renewals
- I was new to designing coded solutions
- Finance didn’t trust their sales department
- Challenging some of the requirements
- Our developer had accepted too much work, so it was difficult to see progression during the build
- When I ran the code for the first time and saw opportunities springing from nowhere
- Pulling out my calculator and seeing the right prices being applied!
- Writing the specification document was great (my colleague and I literally spent the evening working on it)
- This client was very receptive to working with Google docs; they reviewed it, adding comments, then it was an easy sign-off process
- The client partnered with us on the solution design
- Being on site to help with UAT made a great difference to the solution
- I made some new friends
- Building a sample comparison report out of pure curiosity, showing it to their Finance analyst and seeing her face just light up!
- I learnt, for the first time, how important it is to understand the customer’s business model in full
- I watched my colleague, Neil Procter, build a solution diagram in double-quick time, and, despite thinking I’d never be able to do that myself, learnt some great techniques
- Workplace politics can present some challenging constraints to your solution design
- How important it is to check in regularly with your developers – running through the solution with them was an incredibly valuable activity
- Scope creep! Communicating with the project manager when it looks like the client wants something they’ve not technically bought is so important
- I had designed my very first coded solution; this gave me confidence and knowledge I could take into my next project
Changes I Made
- I now try not to push my clients too hard on Salesforce best practice, but to wait till they ask me or vocalise when they give a best practice technique as a requirement
- Running things past my client informally during the build stage, to give them an early view and to gather feedback
- Going on site and “floor-walking” when UAT is going on; this helps testers to become more familiar with Salesforce and means I can answer questions and help them progress