By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Revenue Operations
Flash Icon Decorative

5 Best Practices for Purchasing Software

Scribbles 2

Inserting yourself into the middle of purchasing RevTech tools can be awkward. Too often, RevOps is viewed as an unnecessary slow-down to the process. However, any savvy head of operations knows that steering technology purchases can save the company a lot of money. 

In fact, CIO Drive reports that nearly a third (29%) of software is underutilized or unused in organizations, and Zylo reports the average company wastes over $17M on unused software per year. 

With so many companies “right-sizing” (AKA layoffs), think of how many salaries would be saved if that waste is cut!

While many go-to-market people are looking for the next tool to solve all their problems, chances are high that your company already has software that fits the bill. If RevOps is given access to the purchasing process, they can ensure the technology can do what you need it to, integrates with your system of record, and doesn’t fall short of the automated miracle the purchaser is looking for.

Here are some core steps to take to avoid SaaS waste.

What Does the Company Already Have?

The first thing I do as a RevOps professional when I walk into a new company is research its technology stack. I want to know which CRM and marketing automation system they have, and then - assuming there isn’t a thorough record of go-to-market SaaS - I’m doing an audit of accounts payable and credit card statements to build a definitive list of software vendors.

SaaS purchases are better consolidated in larger organizations. In small startups, it’s every manager for themselves regarding tool purchases, so credit card reviews are necessary. It’s all too common for people to forget to cancel free trials or that they signed up for a point solution – so don’t rely on what people think they purchased.

Once I have a list, I can research what the tools do and flag any feature overlap. Then I’ll interview business leaders and end users to determine how each tool is used and why overlap exists. Finally, I’ll create a visual of the systems on a slide. 

The visual serves multiple purposes, my favorite being a great way to shock business leaders into centralizing SaaS purchases.

What Problem Do You Hope This Tool Solves?

People don’t purchase SaaS to burn capital as quickly as possible. They hope the software solves a problem. 

SaaS marketers are clever. They understand that people are emotional decision-makers looking for a quick fix to something painful to them. Our team leads are susceptible to vendor claims that their tool is the silver bullet that solves X, Y, and Z. 

Our job in revenue operations is to: 

  • Learn whether the problem can actually be solved with software (this takes time and experience)
  • What the level of effort is to implement the tool
  • Whether the tool integrates with core systems
  • How much effort will go into managing the tool
  • Whether the stakeholder has a realistic understanding of what it will take to stand up and manage the tool long term and the resources to do so
  • Determine whether there is a plan to get the most out of the tool

Our goal is only to purchase tools that solve more problems than they create. 

It’s critical to understand what problem the purchaser is trying to solve. Is it a significant problem? How many people are impacted by the problem? How much time is wasted on this problem? Is there a current solution? Why does this solution fall short? What’s the delta between the current fix and the ideal state?

It’s also essential to refer to your tech stack map and determine if a tool you’re paying for already solves the problem. Once you find overlap, it will be important to know whether the stakeholder didn’t bring up said tool because they didn’t think it existed or because it didn’t solve their problem.

What Is the Current Process?

It’s vital to dig in and understand why the problem your stakeholder is trying to solve exists by inspecting the current process. It’s not uncommon for the problem to be caused by another tool 😱 and it may be solved by bringing in a better tool or purchasing an add-on to your current solution.

Potentially inefficient processes often include:

  • Work that changes hands across teams or departments
  • Automations or integrations that frequently break
  • Tedious, manual routing that could be solved with better automation
  • Disparate data sources that are hard to analyze
  • Repetitive communication over Slack or email 

If you’re facing a significant issue, it may be worth using your smartphone’s stopwatch function and time the impacted users trying to navigate the solution. Calculating the cost of forcing expensive resources to grind through the current workaround is a compelling argument to keep in your back pocket. 

If finance tries to block the purchase, your stakeholder will thank you.

Understanding waste caused by the current process also will help you understand if amending or improving the current process incrementally will be worth the effort over purchasing a solution that obliterates the issue.

Why Does the Current Process Fall Short?

Another critical factor that must be considered is precisely why the stakeholder is motivated to find a fix for their problem. For example, suppose they’re trying to solve an administrative issue they face alone. In that case, their project may be deprioritized while your company implements essential contracting software that account executives and account managers will use.

I’ve also seen managers ask for tools to monitor and prompt their employees to do specific tasks – because they liked being the “fun parent” and not a “nag.” 🙄 Avoiding managerial work isn’t a good reason to buy a tool, but you’ll admittedly need to be more delicate than I have been writing this paragraph when pushing back. Determining how other managers solve the problem and getting their input on whether a fix would benefit them is the more politically correct way to go about it.

If the current process falls short because of the time the team wastes or the cross-functional friction introduced, it’s a good candidate for kicking off a purchasing project. If one person is tired of performing an administrative task, they may need to suffer through their fix a bit longer.

Does It Check Our Requirements Boxes?

Most large companies have a purchasing department with rigorous checklists and requirements. Understanding these requirements can reduce the time a vendor is stuck with purchasing. For example, suppose I know purchasing will want legal to review the contract, needs some security documentation, never approves auto-renewals, and always wants Net 30 payments by invoice. In that case, I can work with the vendor to reduce the back-and-forth that nearly always happens during a SaaS sales process.

If you don’t have a purchasing department, here’s a short list of frequently requested items I’ve used in the past:

  • Integrates with the team’s system of record
  • Net 30 (or whatever your accounting team requests) Payment Terms
  • SOC 2 Compliant
  • GDPR Compliant (if applicable)
  • Auto-renewal clause
  • Auto-increase upon renewal
  • Meets user requirements
  • Meets analytics requirements
  • Allows API or other access for data warehouse OR is entirely integrated with the system of record
  • Resources available to implement the system
  • Have resources to manage the system
  • Plan in place to train end users
  • Plan in place to monitor usage
  • Plan in place to monitor output

If you train the team and manage the system after implementation, you’ll want to keep track of the number of hours spent on the tool. This will help your management team understand the impact of future tool purchases on RevOps.

Know When to Say When

Spending time on a tool purchase can be very frustrating when you know your CRM or marketing automation system can handle the problem the stakeholders are trying to solve. However, if you’ve already tried putting a fix in place and the impacted team resisted adoption, it’s probably because the fix wasn’t what they needed. 

It’s important to read the room during a software purchase review and realize when you’re outnumbered. If enough senior management team members have been sold on the need for the tool, you’ll be forced to implement it whether you think it’s a good idea or not.

I’ve even seen tools purchased simply because the team hated working in the core system and wanted anything else to look at while they did their data entry. I’ve learned to embrace whatever helps me get the data my company needs in the system it uses. 

As long as you’ve tried to minimize waste and ensured the software does what they need it to do, you’ve done an excellent job.

Looking for more great content? Check out our blog and join the community.

Related posts

Join the Co-op!

scribbles 7 birds
Tail Spin Animation