I’ve said it before: often, when it comes to custom software development projects, a disproportionate amount of time and effort goes into the pre-launch phases of the project. Of course, it’s important to have thoughtful consultation, to plan and prioritize properly, to select the right vendor, and ultimately to build the right application. I’m not discounting that.
Software is a living thing, though. It needs to be supported. By a certain level of service (see what I did there?).
That’s where Service Level Agreements (SLAs) come in.
Service Level Agreements are exactly what they sound like: contracts that define the expectations, methods, and costs associated with the support and maintenance of a web application or mobile app. They’re also known as “support contracts,” and are typically negotiated and executed prior to the launch of a custom web application or mobile application.
As with software development contracts, the shape and details of SLAs vary wildly from firm to firm. However, they are commonly comprised of a few key elements, and there are a handful of areas you need to understand. Let’s break those down.
There’s no industry standard for the components of a Service Level Agreement. That would be too easy. The content in an SLA varies from provider to provider, but commonly includes any combination (or all of) the following:
Of course, each of these sections will have a variety of detail depending on the experience level of the shop, the size / risk of the software, the client, and more. There are also items in addition to this content – for example, details on uptime, CPU, and security monitoring and notification; details on disaster recovery processes; and so forth.
Diving into detail on each of the above is beyond the scope of this article – instead, I’ll focus on the “service level” part of the contract. Generally speaking, though, the breadth and depth of your SLA should align with the size of your project and organization. That is to say, the service level agreement for custom voter registration software should be larger and more detailed than the SLA for a $5,000 Squarespace photography website.
When it comes to the “service level” part of Service Level Agreements, there are 6 critical areas you, the buyer, need to understand. Those areas:
If both you and your development firm are in alignment on the above, you’re in good shape. Here’s what you need to know in each of those areas.
I hate to break it to you, but at some point in the lifecycle of your custom software, something will stop working (or, you’ll discover something that never worked properly). Or, the functionality might be intact, but you or someone on your team might need some help in completing the task. That means you need support, and you need to submit a support ticket.
In turn, this brings us to acceptable ticket submission methods, including what contexts “acceptable ticket submission” applies to. The SLA should clearly identify:
Response times should outline both the expected response time, and the maximum acceptable response time, to a support ticket. This clears up any misconceptions or assumptions on how long your support team should take to respond to a ticket. An example might be 60 minutes (expected), 4 hours (maximum) for a High Priority issue (more on Critical issues below).
The expected / maximum response times will likely vary based on the urgency level of the ticket, whether or not it was submitted during regular business hours or outside of them, and whether or not your SLA has 24/7 coverage.
Again, all the details here are variable and dependent on what your firm offers, the size and value of the software to your organization, and your budget. At Paper Leaf, we have SLAs for our clients ranging from very lightweight (standard business hours, quarterly routine maintenance) to heavyweight (24/7 support, as-needed maintenance, detailed monitoring and infrastructure, etc). The solution should be appropriately tailored to your needs.
Note: The word “response” in “service level response times” is important to understand. It doesn’t mean the issue will be fixed in that time window. It means the firm has to respond within that window, commonly with an acknowledgement of ticket receipt and any additional information. This is because fixing an issue can take a wide window of time, and thus a blanket promise can’t be made.
When it comes to ticket submission methods and service level response times, the determining factor is likely the issue level and the definitions associated with those levels. Here’s what I mean:
Issue Levels normally range from Low Priority to Moderate Priority to High Priority. The definitions of these levels are important for both parties to understand, as they clear up any assumptions around what a “High Priority” ticket actually is, and thus how to submit it and what to expect for response times. Here are the definitions we use for our Issue Levels:
When these levels are understood, both you and your development firm can be comfortable knowing how to classify issues as they’re logged, with no misaligned expectations.
Often, bugs (or issues) are conflated with features. ‘Features’ meaning either changes to existing features, or the outright addition of entirely new features.
You won’t likely have a section called “Bugs vs. Features” in your SLA – actually, that would be kind of funny. It’s important that, if you’re assuming your web application or mobile application will require not just managed web services and support but also tweaks or additions to features, your SLA covers this distinction though. And, it’s important for you, the client, to understand the differences. New features, for example, are not beholden to the response times that issues are.
This doesn’t have to be complicated. Here’s how we do it:
With language like the above, all your bases for Service – bug fixes and new features/feature improvements – are covered.
Despite everyone’s best efforts, sometimes bad things happen. By bad things, in this context, I mean downtime for your application. If your SLA is a wide-ranging one that includes hosting and infrastructure, you should make sure a mechanism for holding your firm accountable for uptime is in place. A common mechanism for this in Managed Web Service Level Agreements are Credits.
Basically, the firm promises your site will have a certain level of uptime, measured monthly. This is commonly 99.999% (“five nines”). If the site suffers downtime, the Credit mechanism can help you recoup some cost and incentivize the firm to make sure the site is stable and uptime is high.
Here’s what our Credit system for managed web services looks like:
| Uptime | Credit Back to Client |
| 99.5% to 100% | 0% |
| 98% to 99.4% | 5% |
| 95% to 97.9% | 15% |
| 90% to 94.9%` | 25% |
| 89.9% or below | 50% |
The “Credit Back to Client” is calculated based on the actual monthly service charge paid by the Client for the affected service. So, if they pay $1500 / month for managed web services, and they had 94.8% uptime, they’d receive a $375 credit (25%).
This is just how we tackle it at Paper Leaf – as always, the details will vary from provider to provider.
The final, critical point to understand about SLAs are the exclusions – meaning, what precludes the promises made in the SLA around the above mentioned items (primarily uptime and response time)? A few that are common include:
These exclusions, if you find one provider to tackle all services (hosting, support, feature development), are relatively straightforward. However, the more cooks in the kitchen, the more complicated it gets.
For instance: Who is allowed access to the CMS? The server? The repo? What are their access permissions for each of these areas? This can take many forms:
While there can be benefits to having a variety of access levels, it greatly reduces what promises can be made in the SLA – and how those promises can realistically be enforced.
For example, let’s say your driver inspection and reporting software slows way down, or even goes down entirely. You have your support firm who signed the SLA, internal IT who are also hosting the platform, content managers with upload permissions, and a subcontracted external developer. It can be almost impossible in instances like this for the firm to make performance or uptime promises. There are simply too many scenarios out of the firm’s control.
However, if you have one firm responsible for hosting/infrastructure, maintenance, support, and new feature requests, you have one place to point if things go wrong, and the firm can make much more confident promises about your level of support and uptime.
If you’re evaluating SLAs and providers for your custom software, you’ll be well-positioned if you remember these key points:
Remember, building the right software is important – but the support and service of that software is equally as important. That’s why understanding Software Service Level Agreements matter, and why you should evaluate those at the same time you’re evaluating your technology consultant and/or design and build partner.
