We work hard to create a cache of content to guide you on your journey to managing multiple SaaS vendors, and save money along the way. Today we’re going to step out of academia and look at what a real-life SaaS vendor management scenario look like with Cindy Reeder, formerly the Senior Product Manager of Salesforce and Marketo at Yodle.
You might remember Cindy from our previous post on creating an optimization plan for SaaS usage, where she shared a fantastic end result, but we wanted to get a little deeper in a separate post and show you how she actually got there.
“Prior to our last contract renewal with Salesforce, we put together a utilization model based on usage of different types of licenses that aligned best with the access needs of each group. Business leaders were asked to justify all individuals associated with a Salesforce license. In the end, this model was used to determine final license count and type for our renewal contract.
So here’s the actual use case from Cindy:
The initial impetus for creating the utilization model was an upcoming contract renewal. “Being a cost-conscious company, we wanted to ensure we had specific insight into what we were signing up for,” said Reeder.
Top leadership from Yodle’s varied business units were included in the process for oversight and review purposes, with a heavy emphasis on the finance and legal departments. The general managers had final approval on the number of licenses allocated to their respective business units.
In order to create the model, Reeder pulled data from multiple sources. She started with Salesforce, to get the current state of license allocation down to the user level. Business units also provided hiring projections for the upcoming year, so Reeder could develop a projected gross plan.
“There’s always been a close eye on license allocation,” said Reeder. “Business units are responsible for budgeting Salesforce costs. However, we had to do some reconciliation - what the business units expected did not always work in reality. We worked with them on any discrepancies.”
Another component surfaced during this process: the idea of shared services, where licenses were shared across teams. API access is a common example. These types of licenses were allocated differently because all business units benefit from usage.
In looking at all these factors, what did Reeder hope to achieve? Not just adjustment of the license count, but optimization of the license type. “When we decided on this model, the vast majority of the licenses were full Salesforce licenses. We were really doing an experiment to understand usage, and to see if some groups could dial down to a community license and still meet their usage needs.”
The difference between a full Salesforce license and a community license is simple: access to different types of Salesforce objects. A full Salesforce license can access a wider variety of those objects, where a community license has a more restricted view.
So as part of the exercise, Reeder created a proof of concept for the various business units, to see if the community license worked for those groups. With the resulting data, she was able to present several options to the Yodle executive team - for consideration from a cost perspective.
After the CEO’s review and decision period on the recommended options, Yodle was able to convert roughly 15% of their full Salesforce licenses to community licenses. “It made a big difference in our annual contract,” said Reeder.
Reeder’s utilization model was no small feat. Reeder estimates that both she and the program management team spent about 30% of their time working on the model, over a period of several weeks. This included building a Microsoft Excel data model including a number of advanced functions and calculations.
But there is an upside: the work she put into the model can be used in the future. “In subsequent years, all we have to do is pull a fresh user data set from Salesforce and the model will automatically populate.”
Do you have a SaaS vendor management story to share? Drop us a line at email@example.com.