Three Mistakes to Avoid when Making a RevOps Software Purchase Decision

No matter what Revenue Operations (RevOps) issue you are looking to fix, there’s probably a software solution out there that promises to solve that exact problem. There’s also a good chance there’s a salesperson already in your inbox inviting you to a Webinar about how that particular software was used for your exact use case.

As you navigate through the sales speak, pricing models, and canned demos, I wanted to share some lessons I’ve learned and mistakes that I’ve made over the last decade of RevOps software purchasing decisions.

MISTAKE #1:
Don’t Be Short-Sighted in Your Analysis

I’ve worked at and consulted for many growing organizations over the years, and they all share one characteristic: constant change. As a company grows, it changes both organizationally and strategically.

The problems that you’ll be solving in three months will be QUITE different than the problems you're solving today. If you buy a specific point solution for every one of these one-off issues, you'll quickly have a very bloated martech or sales tech stack that's impossible to manage.

Also, software salespeople love to point to ease of implementation (“just like flipping a switch”), but that doesn’t begin to account for all the necessary maintenance. You’ll often need to customize the solution, manage users, troubleshoot, and stay up to date on each new release and updated functionality.

If you're doing this for dozens of applications in your marketing or sales tech stack, you'll need multiple full-time employees fully dedicated to off-the-shelf application maintenance. Dedicating resources to learning and understanding the ecosystem of RevOps software is a necessity, and it’s a much more cost-efficient process if you have your team focused on three software solutions that solve ten business problems versus ten solutions to solve those same ten problems. If your purchased tools can do more, you’ll need fewer individual pieces of software and fewer FTEs to support, resulting in real MONEY saved.

You need a tech stack that can adapt to your rapidly evolving environment. When looking at a new RevOps software solution, I always try to look past the immediate pain and challenge the solution to provide additional value.

There’s often a short-sightedness that plagues software purchase decisions by focusing on how quickly you can go live for a single use case without considering the breadth and depth of the solution. There are times, of course, when you need a singular tool to solve a singular problem; but you should view this as an exception and justify it accordingly.

MISTAKE #2:
Avoid Introducing Unnecessary Variables

It’s especially important to make sure that RevOps software solutions are available where the users live and think. This may seem like an obvious statement, and most people would make sure that if their users are in Salesforce, they’ll need to purchase solutions that also work within Salesforce infrastructure. But based on my experience, I like to take this a step further.

In addition to thinking about your end users, consider where your data and logic owners live and make sure that you can also align with them.

Let me elaborate with an example: I was once involved in a lead and account routing project where we had to build complex logic to assign all our existing and net new leads and accounts to our sales team. The routing rules were well-defined but were constantly adjusted as the sales team changed.

Because we'd picked an adaptable RevOps software solution, the platform was able to use inputs from Salesforce (for the accounts/leads) and Excel (for the parameters of the routing rules) and build logic to map the accounts/leads based on the routing rules and export that mapped data back to Salesforce.

This enabled us to offboard all the administrative maintenance of the rules to SalesOps—those who were closest to it—in the tool where they spent most of their time (Excel), which let our team focus on the more complex core functionality.

MISTAKE #3:
Not Putting Process First

Young, under-manned companies (and specifically RevOps groups) often find themselves with large impactful problems and minimal time/resources to solve them. It’s easy to find some RevOps software that promises to solve your problems, and it’s even easier to throw money at a martech application or the sales tech stack than to actually understand the root cause of the issue. After implementing the solution, you’ll often find that the problem hasn’t gone away (and you’ve introduced a new problem: Tech Debt!)

As a consultant at Hyperscayle and previously at Accenture, I’ve run into so many instances where companies have a long list of martech and sales tech stack applications, managed packages, and integrations that are no longer used or relevant and are just convoluting their systems of record. What once was viewed as a quick solution soon turns into another problem that is not as easy to solve.

Before buying a new RevOps solution, you need to make sure that there is an associated business process, and that you are buying software to support that business process (not in spite of the business process).

THE BOTTOM LINE:
Buy RevOps Software for all the Right Reasons

When looking for RevOps software solutions, it can be an overwhelming experience where you have to juggle differing functionalities and pricing models.

Regardless of the problems you are looking to solve, make sure you think about long-term value, envision how your users will interact with the tool, and define your process FIRST.

Avoid these common mistakes and you’re much more likely to succeed!