How to craft a comprehensive and inclusive software buying process.
Back in June, my colleague Ryan Neu wrote about how the Covid-19 pandemic has transformed the software buying process for the better. He argued that recession-induced belt tightening has forced CFOs to wrestle software purchasing away from the end user - guaranteeing better contract negotiations and a firmer understanding of how each software product contributes to the company’s bottom line.
But although it's a good thing CFOs now take responsibility for SaaS purchasing, this trend has added new complexities to the process. For CFOs to truly protect long term business interests, they must codify a cross-functional buying process, one that involves the input of the legal and security departments as well as end users of the product.
Typically, this means installing four levels of approval before any SaaS contract can be signed: initial budget approval, security, legal, and final sign-off from finance.
When done poorly, cross-functional purchases can stretch on for months. This not only drives up costs, but also deprives the end user of the software they need. To avoid procurement purgatory, all departments should collaborate and sign off on a formal workflow that lays out in detail how teams will work in tandem to get a software contract across the finish line.
There are five steps I’d recommend for establishing a cross-functional buying process.
Before begin to build out a formal process, you need to establish the information and rules you want governing contract negotiations. I’d divide these rules into two separate categories: brass tacks and non-negotiables.
The "brass tacks" are the basic facts about your company that usually find their way into a contract. These include things like your company’s legal name, mailing address, billing email address, and the designated contract signer. What this does is ensure consistency across all contracts. Something like the company’s name might seem obvious, but the capitalization of certain letters or if you include “LLC” can vary widely from contract to contract if this information isn’t documented.
The non-negotiables are sticking points for each core department where you can't deviate. For instance, the security department may require any software product offer single sign-on, meaning that any potential service that doesn’t carry this feature is a non-starter. The legal department might have requirements around NDAs or CCPA, and the finance department will likely want to establish rules around how multi-year contracts and preferred payment terms to optimize the companies cash position.
What’s the best way to collect all this information? Finance usually leads the charge on collecting it from the other teams and documents these preferences in a centralized, internally available document. (i.e. on the company intranet / wiki). Once you have this information documented and confirmed, stakeholders purchasing software can then forward it to their salesperson at the start of commercial conversations.
At Vendr, we've found that making these requirements / preferences available to sales reps upfront cuts down negotiation cycles, and ensures software purchasing consistency for customers.
Now that the basic rules are set, teams can start collaborating on the actual process / workflow that will make it most efficient.
The best way to kick off this project is to bring together a representative from finance, legal, and security departments. The goal of this meeting? Start plotting out what the approval flow looks like for getting a contract signed at your company. You can also invite some of your most frequent software buyers, if their input on current workflow and areas of efficiency would be beneficial. This meeting should provide everyone with space and opportunity to loosely air out where they think their department should fit into the process and roughly define the most efficient flow.
There are actually two separate contract flows you’ll want to collectively establish: net new purchases and renewals. (And if you ask Security - three, for off-boarding existing vendors. We won't go into depth on this third example in this article.)
Net new purchases involve cases where you're considering entering into an agreement with a SaaS company for the first time. This is typically the most comprehensive process - most teams want to include a step for building a business case and competitive evaluation of solutions in the marketplace prior to getting into commercial negotiations themselves.
Renewals are typically much more straightforward since the groundwork was set during the initial contract negotiation. For instance, since security already ensured its terms were met the first time around, its involvement should be minimal during the renewal negotiations. The same goes for legal, which would typically only need to review any changes to the existing MSA / ToS upon renewal.
This actual approval flow will vary widely from company to company - the most important thing is that each department owns its respective role in the process. Not only will this ensure company-wide buy-in, but it’ll also eliminate many of the inefficiencies that typically crop up during contract negotiations.
Any workflow before you work through it is - by nature - theoretical. It isn’t until you apply the process during actual contract negotiations that departments will identify unexpected the inefficiencies and hurdles that will naturally pop up. There will be edge cases you didn’t account for and exceptions that need to be carved out. You may also find that some terms you thought were dealbreakers weren’t actually dealbreakers after all.
What's important is that the team approaches each software negotiation with an open mind, and the finance department should continue to collect feedback on how the guidelines can be tweaked to better streamline the process. As your company scales and various departments restructure or more requirements are layered in, you’ll discover new questions or cases up that need to be addressed within the guidelines and the process.
Once you've tested and refined the process, it’s then time to educate stakeholders across the entire company about the new guidelines. Why? The end users often have the first point of contact with a sales vendor and are the ones who are typically initiating this process to begin with - either because the vendor reached out to pitch them on a needed solution or because the user identified a need and set out to find a software solution on their own.
Typically, by the time the end user hands the vendor over for review and approval from finance, the two parties have already typically held lengthy discussions on the product’s features and associated costs. This is a good thing, since the stakeholder will be equipped to make a business case to the finance department for why this product fits their needs.
When you have a stakeholder who’s educated on the cross-functional buying process, they'll also be able to prepare the vendor for what lies ahead once they've progressed conversations for internal approval. Armed with that knowledge, the vendor can get ahead of and prepare for what finance, security, and legal will require - cutting down on back-and-forth cycles and ensuring speedier review and approval.
Once you’ve wrangled together your software stack, reversed the spread of shadow IT, and instituted a cross-functional buying process, then you get to reap the benefits of all this labor. You’ll be able to analyze the value added by each product, forecast its spend far into the future, and arm yourself with data as you head into each renewal.
What’s more, you'll have brought employees across all departments together in a way that builds understanding of each team's contribution to the overall cause. When the process is done correctly, each department is able to vocalize their concerns and explain why they're important. In other words - these steps won’t just save you money; they’ll also build a stronger, more empathetic and efficient organization.