One of the best practices in software development is to have the engineer write the unit test before they write the code for the feature they are developing. This forces the engineer to think about the end product and all the different ways it can break. Thinking about the end result first leads to more comprehensive design and robust implementation. This is a best practice RevOps should modify and adopt. Before investing in any process, data, or technology, RevOps should first think about how to measure the ROI and make the instrumentation to measure that ROI part of the project requirement.
Why bother measuring?
There are three good reasons why you should make this part of your RevOps standard operating procedure (SOP):
- Since Q2 of 2022, companies have become much more disciplined in mandating concrete ROI on any spending, especially in sales and marketing, due to a dubious history of shiny-toy spending history. If you can’t come up with a concrete way to measure the ROI, it’s unlikely that you can get the project approved, so stop wasting your time.
- Too many companies still don’t know how to do ROI correctly. Management may ask you to build a business case with ROI to justify the purchase, but they are happy to accept an ROI model that is completely theoretical and difficult to measure. This may help you get the initial purchase through, but a year later when the CFO asks for proof of value in order to review the budget, if you haven’t measured ROI, your renewal may not happen and you just wasted another year of your time.
- RevOps in general really sucks at demonstrating the value it brings to the organization. RevOps tends to think like IT folks, and consider its achievements in terms of projects. For RevOps to elevate its value in the organization, it has to behave like sales, making everything measurable. There is no reason why RevOps cannot quantify everything it does, if not in monetary terms, at least in operational terms like speed and quality.
How to operationalize measurement?
To include this best practice in your RevOps SOP you need a framework. Here is a simple one to get you started.
What story are you trying to tell?
In every company, there are always people who are much better at getting what they want approved. These are the people who know how to tell a good story. A story is ROI with a narrative; thus, a good story has to be backed up with good ROI. So when you’re asked to build a business case with ROI, don’t just dive in and start crunching the numbers; first, figure out what story you’re presenting to your management and peers, then, decide what ROI is needed to bolster your narrative. The story and the narrative give the reasons why others should care. You may need different stories and narratives for different stakeholders you are selling to—and yes, you’re selling. The best salespeople are often great storytellers.
What can you measure?
Once you have developed a story with an ROI model, you need to figure out whether your ROI can be measured. ROI can be measured in three different dimensions:
- Financial ROI is the best type of ROI. The story ends with a concrete dollar amount in either gain in the top line or savings to the bottom line. This usually requires your project to have a very direct link to either revenue or cost. For example:A new event that generates a specific number of opportunities and closed business.A manual process, currently outsourced to an agency, that is automated.
- Operational ROI is your second-best option if direct financial ROI is not available. Operational ROI measures the improvement in speed, effort, throughput, and quality, which can be translated into financial ROI using a model. It’s one degree removed from the top line and the bottom line but usually more readily measurable. For example:A new automated list-loading process that cuts the follow-up time from in-person events from 5 days to 1 day.A new data vendor that improves mobile phone number coverage in the CRM database from 30% to 60%.
- Qualitative ROI is the least persuasive type of ROI and the hardest to sell, and should never be used on its own. Qualitative ROI are things that are either impossible to measure or too subjective to measure. The good news is that most projects can be measured in terms of operational ROI; even things like employee job satisfaction can be quantified with a survey. Qualitative ROI can be a nice supplemental ROI to add richness to your story, but if you can’t come up with anything but qualitative ROI, you should seriously question the value of your project or get some help to develop an operational ROI angle.
How can you measure?
You can do a great job building your ROI model and know exactly how you will demonstrate the ROI using both financial and operational metrics, only to find out that your metrics cannot be easily measured. So before you finalize your ROI model, do the homework to figure out exactly how you will measure down to the smallest technical details, because that’s where the gotchas usually exist. Here are the most common challenges you will run into:
- Does the data exist? Just because you think the data should be available doesn’t mean it is. Find out if the specific data you need for your metrics is available from the technology or vendor you use.
- Is the data granular enough? Often, the applications you use make summary data available in dashboards, which may not have the granularity you need to support your custom metrics.?
- Is the data accessible? Determine whether you have access to the data you need and how easy it is to get your hands on the data. For example, is the data available through API? Can the data be made available through a data feed or a periodic file dump? Do you have to manually download the data from the user interface? Is the data only available in a PDF report?
- Is historical data available? Most applications do a poor job capturing history simply because it is a very expensive feature to build. Historical data can be event-based or time-based. Translating from one to the other can be tricky.
- Is the data compliant? There are many compliance mandates such as GDPR, HIPAA, and PCI-DSS that can prevent you from accessing the data you need in the format you need. If you are not allowed to have full access to the data, will redacted, anonymized, or summarized data be good enough??
What do you need to measure?
With a good ROI model in place and knowing exactly what data you need, where they are coming from, and how you can get your hands on them, the next step is to execute on the measurement. While this can be done using a manual process, you will need automation technology if you have any kind of scale to your business. A flexible and scalable data platform is key to be able to measure ROI in a manageable and timely manner. Here are the key capabilities you should look for.
- Data storage - You will need a place to store all the raw and calculated data for your metrics, especially historical and snapshot data. There are many options here, including file system, RDBMS, No-SQL, and data warehouse. If you have existing infrastructure you can leverage and have the expertise to use them, by all means use what’s available to you. If you need to get something new, think hard about the technical skill set you have and whether you want to get into this level of technical detail, or choose a platform that makes storage transparent and a non-issue.
- Data quality - Raw data often are not in good enough shape for you to reliably link and aggregate the data for trustworthy calculations. You may have to fix typos, derive or enrich missing data, map and create missing links, standardize, or remove duplicates. Having strong data quality features in your data platform is pretty much mandatory.
- Data transformation - Raw data come in many different formats. You need to transform and unify the data before you can use them. Transformation can be simple re-mapping to full blown Reg-Ex style manipulation. If you’re technical, your IT team probably already has ETL tools in house you can use. If that’s too technical for you, look for a no-code data platform.
- Instrumentation - Data you need is often not readily available. You may need to capture or generate the data you need from what is available. For example, you may need to calculate what has changed between two snapshot data sets, or you may have to use a webhook to grab the data you need from a form. A good data platform should allow you to create these instrumentation mechanisms to capture or generate the data you need that’s not readily available.
- Computation - Metrics are by definition summary and calculation of more granular data. You will need a very flexible data platform that can take the raw data you have and perform the mapping, aggregation, permutation, and mathematical calculations you need to calculate your metrics. If you don’t have SQL or Python programming skills, you should look for a no-code data platform.
Why should your team care?
This sounds like a lot of work, but if you want executives to take RevOps seriously, you need to be a master at building and measuring ROI. In fact, most GTM functions are so bad at this that RevOps should take the leadership role to operationalize this as a center of excellence. When done right, you can help the organization to:
- be data-driven in all its investment decisions.
- not waste time and resources on projects that get canceled later.
- quantify your value-add to the business.
- protect its budget.
- have a repeatable process to set priorities.
I don’t know any CxO that would not want to have these capabilities yesterday.
