Procurement: What You're (Probably) Getting Wrong About Tech SLAs

As one of the leading technology performance specialists, we've come across a lot of issues with third party vendors. In hindsight, a lot of these issues could have been made far easier had procurement made some simple changes to their processes.

Most companies these days have a pretty detailed tech vendor management process. You probably check things like GDPR compliance, information security and probably insist on some sort of SLA around uptime.

However, we think this overlooks the key problem that many vendors bring: degraded website/app speed. And we know that for each second your website takes to load, you start losing sales.

Let's look at two recent examples:

Case study 1: The expensive "cheap tool"

We recently worked with a marketing team to audit their third party vendors from a performance perspective. They'd recently changed an analytics tool from a more expensive vendor to a cheaper one.

While they ticked all the boxes - good information security policies and a 99.9% SLA, and a substantial discount on their previous vendor.

However, sales on their ecommerce store started to drop off, and their marketing spend wasn't delivering the same RoI.

After auditing the stack, it turns out the cheaper analytics tool was adding a huge amount of delay to the page by doing a slow network request on every single keystroke or button press. We estimated the cost at north of $1m/month - some 200x the monthly savings the new vendor offered.

Even worse - they had signed a 3 year commitment to lock in a lower price. With no contractual mitigations, they had no cause to terminate the new vendor.

Case study 2: The customer support tool that killed efficiency

Another common one we see are 'internal facing' tools that have serious performance issues. You're likely to use at least one day-to-day that comes to mind - one that is so slow it feels like wading through quicksand.

We've seen time and again very expensive business transformation projects, meticulously planned in every detail apart from one - how fast it is.

The end result is internal teams that lose their train of thought waiting for a page to load. Customer support agents on the phone excusing themselves saying 'our systems are slow today' - with an upset customer getting even more frustrated.

Again - at this point the sunk cost is enormous, and without contractual obligations you can be looking at a million dollar replatforming (hard to justify, despite all the frustration with the system) or putting up with a glacial system for critical business processes.

Why procurement is essential in fixing this

We've seen dozens of these situations occur, where procurement has in some ways missed the main risk of a lot of tech vendors. While uptime is often very important - a 99.9% SLA with a small credit applied does not mitigate any real risk.

We believe speed is the main risk. If you run a business that transacts mainly online like an ecommerce business - Amazon found each second of additional delay is responsible for a 10% revenue loss.

This also applies to internal facing applications. A slow app that has dozens of people working in it quickly adds up to an enormous amount of wasted staff time and poor morale.

As such we strongly recommend that you add wording that allows you to terminate contracts for impact on web performance. This will give you leverage to walk away or force improvements in the event this does happen.

Procurement is in a unique position to avoid this. A few well drafted clauses in a contract can alleviate years of painful arguments with vendors with little leverage.

In practice, this means including measurable performance metrics in your SLAs. For customer-facing integrations, consider requirements like 'Third-party scripts must not increase median page load time by more than X%' - this number and metric(s) varies dramatically depending on the type of tool. For internal tools, specify response time thresholds like 'Page loads must complete in under 2 seconds for at least 75% of sessions.'

These clauses should include remediation timelines (typically 30 days) and termination rights if performance targets aren't met. While there isn't a one-size-fits-all approach, we'd be happy to recommend specific metrics and target numbers based on your vendor type and risk profile if you get in touch.

Conclusion

We highly recommend that procurement teams do three things:

• As part of any trial period, really dig deep into the speed and performance of the product. Often lofty promises turn out to be less impressive in reality. If the product seems slow on demos - if the vendor can't get it fast for a demo, it's almost certainly going to be even worse for you in production.
• Include performance metrics in SLAs, not just uptime guarantees. While uptime matters, many vendor tools aren't mission-critical - a few hours of downtime won't break your business. But poor performance affects every single customer interaction, every single time. Treat speed as seriously as you treat security.
• Monitor this on an ongoing basis - vendors can start fast but slow down, especially at peak times when the most revenue is at stake.

We're happy to help procurement teams navigate performance issues. Do you have a vendor which you suspect is slowing you down? Or need advice on key points to include in contracts? Please get in touch. We'd love to help!