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.
Back Story
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
The Requirements
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
ERD
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:
The products bought over the prior year (across 4 opportunities)
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:
The same products, pro-rated up to 12 months with a 10% uplift on the sales price
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:
Our final set of Products for the renewal opportunity
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.
Key Challenges
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
Key Wins
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!
Key Learnings
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
Gemma
Share post:
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.
Back Story
Things have come a long way since, but in 2010, when Phase 2 started:
The Requirements
The Solution: Renewal Opportunities
ERD
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:
The products bought over the prior year (across 4 opportunities)
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:
The same products, pro-rated up to 12 months with a 10% uplift on the sales price
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:
Our final set of Products for the renewal opportunity
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.
Key Challenges
Key Wins
Key Learnings
Changes I Made
Related