Priorities to agree on internally before purchasing software

A SaaS buying agreement is complex yet consists of many areas where negotiation can yield better outcomes. But knowing what you should focus on when undertaking a net new or renewed software purchase isn’t always clear-cut.

Is price the best indicator of value, or are there other considerations? What contract and service level components should you focus on to ensure stability and confidence when purchasing software? The better question might be: What matters to your team from purchase to purchase?

While every deal is different, some aspects of the SaaS buying process bear extra attention. By discussing these points early, you'll know what the team considers mission-critical.

Defining the parameters before negotiation can ensure you get what you need, without false starts or roadblocks. It can make the software buying process far more streamlined, and ensure the stability of your stack and budget over time.

Ready to improve your SaaS buying process? Let us help.

Establish the four “yes’s” for new or renewed software

Creating a consistent software buying process for every purchase will make it easier for everyone, especially the stakeholder requesting a new product or working through a renewal, to know exactly who to go to for alignment and approvals. The four yes’s include:

Department head  

• Identify the department-level approver for every team. We usually see this as head of marketing, head of engineering, head of sales, etc.    
• Stakeholders on each team that want to request new products need to get their department head approval first.
  
 

Finance  

• Determine with the Finance team who should be the go-to approver on budget prior to purchasing. We’ve seen this being the VP of Finance at orgs with up to about 250 employees, FP&A for 250+, and procurement for larger companies.    
• The stakeholder would then know to check with this Finance contact to see if there's enough budget to justify the request.
  
 

Security  

• Talk with your IT/Security/DevOps team to figure out who the security approval should be sent to. Typically this is the Head of Information Security, or the person in charge of the security questionnaire.    
• Once they have the budget, stakeholders would kick the purchase request to security next. It’s important to understand what’s required for the OK from security (i.e. SOC 2 compliance, SSO requirements, who fills out the security questionnaire, lead time, etc.). 
  
 

Legal   

• Lastly, work with the legal team to understand who the approver is for contract reviews and redlining. This may be internal or outsourced General Counsel or an outsourced council.    
• Legal tends to be the biggest bottleneck in the buying process and takes the most time to get through, which is why we suggest waiting until budget and security is approved before a stakeholder approaches legal. It’s also important to understand lead time that Legal requires (i.e. how many weeks of runway do they need).

Timeline for purchasing software?

How much does timing impact the contract? Every scenario is different. In a negotiation for software serving a short-horizon project, time-to-performance may take priority. We know last-minute purchases don’t always yield the best budget outcome, but sometimes it’s unavoidable. When buying software will serve a large opportunity, speed may be worth the extra expense.

We like to think of timelines as having two levers. If you need software asap, that’s fine but expect that you won't get through the proper cycles to get the best commercials. If you have flexibility on timeline, even better. That’s when you can typically go through multiple cycles to push on the best price. It comes down to price vs. time – you can optimize for one or the other

When setting your negotiation priorities, get consensus on the timeline for software implementation. You may find ways to extend the runway, such as bringing the software in at a later stage of a project. That flexibility can save budget without impacting productivity, so be sure to clarify when a solution must be up and running.

What product features are essential?

If your stakeholder has identified a solution and a supplier, it helps to get a clear picture of their vision for software use. What features or security prerequisites have they identified as favorable? How do they envision the tool at work within the organization? These details play an important part in your contract terms, value, and the overall business outcome.

Before entering negotiations, establish the must-have features. Also note those that would be nice to have, if not mission-critical. That way, you may get the extra functionality you desire, and have a place to compromise in favor of other, higher priorities.

Taking this approach when purchasing software can save time and money in negotiation. Your sales rep will be able to provide the best pricing based on what you actually need. From there, the team can plan implementation with a clear understanding of what core and added features will be available to them.

Is budget and pricing in line before you purchase the software?

On its face, “negotiation” seems inextricable from price, but quite often price takes a back seat to other factors. This becomes more likely as the problem complexity or business case increases. Pricing is absolutely a priority, especially if you want Finance to sign off on the deal. But it helps to take a holistic view of the price discussion.

Price is not a single data point, but a component of the business relationship. While setting an acceptable price up front is important, so is ensuring value over time as business needs evolve. Establish what future pricing should look like with your rep, not just for expansion but in case of right-sizing.

Considering future pricing as part of negotiation protects your finance team from surprises down the line. It allows them to create budgets from an informed position. Naturally, the actuals may vary based on different factors. Knowing how volume or service level changes will impact the budget can smooth out some of the road-bumps. 

How are software security needs addressed?

Understanding how the supplier’s security offering aligns with your business need is critical to a smooth negotiation. All the functionality in the world is irrelevant if your security team won’t sign off on the deal. If your security non-negotiables are already outlined through your internal SaaS buying process, great. If not, be sure to establish the security priorities at play in negotiation.

Likely, your security stakeholders will have a list of minimum requirements for encryption, storage, data transfers, etc. By bringing them into the details early, you’re avoiding the potential red flags and show-stoppers that can derail your purchase. And if those red flags do exist, by identifying them early on, you may be able to negotiate with the supplier to remedy them.

What software service and support requirements do you need?

Price is not the only indication of value when negotiating a SaaS contract. Often, it’s not even the primary indicator. The real value of a supplier is the commitment they make to keeping you up and running. When negotiating a net new contract, it’s important to get a full view of the service level promises the supplier makes. Your legal department may have certain requirements for SLAs and other contracts. Bring them into the conversation early.

Service level

Depending on the product, you may value certain components of service over others, and negotiate for them in your contracts. SLAs are more than just the promise of service; they are your guarantee of safe harbor when the going gets tough. Some components of an SLA to prioritize in your negotiation include:

 
• Uptime guarantees: One of the most important aspects of your service level agreement is the stated uptime for the software. (The definition of downtime for contract purposes is also important.) If uptime falls short, there should be remedies negotiated in advance to compensate.
 
• Maintenance: How will maintenance be conducted, and what impact will it have on usability or data access?
 
• Data availability and deletion: Some components of the SLA survive the software use itself. Prioritizing the actions after offboarding is just as important as those that occur during the contract term. Data availability post-cancellation, deletion of identifying customer data, and transition assistance are all worth considering when planning a negotiation.
 
• Recourse: What rights and recourse do you have in the event of a failure of the above terms. Spelling out acceptable remedies allows a measure of control when the unexpected happens.

Support

When you need help, knowing when and how you'll receive it is key. Be sure to examine your support clauses, and prioritize the support you receive. Ensure there is a path to get the help you need, when you need it, and deal with any limitations in the support structure before closing.

What about software term, cancellation, and auto-renewal clauses?

The beginning of a contract is the most important time to consider its end. Even in straightforward purchases, when you buy software, it’s important for IT and Finance to understand how future decisions will affect budgets and the tech stack.

Auto-renewal

While more contracts are adding automatic renewal clauses every month, this practice isn’t always in your best interest. In fact, best practice is to remove auto-renewal whenever possible and push for a rate lock. In other words, you have the option to renew the software at the same rate.

The good news is, these terms aren’t untouchable. Negotiating out of auto-renewal is a priority if your technical needs or usage are subject to change. You may also want an out if this is a net new contract with an unproven vendor.

Also, take note of the cancellation performance period. Negotiating a solid contract is one half of maintaining a handle on spend; keeping track of your negotiated terms is the other.

Term

Depending on the product and business need, term will play a role in price and contract negotiations. While you might consider a longer term for long lasting projects or needs, doing so requires attention to exit clauses.

Be sure to set term parameters  (if not already a part of your standard legal requirements) and what conditions must be present in an early exit clause.

We recommend starting with a one-year term. If you're open to a multi-year and don't foresee going anywhere or if you know implementation can take up to six months, for example, then assess what the supplier would provide with multi-year terms once you feel good about the one-year option. 

--

No matter the investment level or business case, it’s important to protect your best interest during your software buying process. Beyond solid negotiation, good data and tracking can make ensuring contract adherence much easier.