Decoding Software Service Level Agreements

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.

What Goes Into a Software Service Level Agreement?

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:

1. Support. Also known as customer service – phone support, email support, etc. – but also includes bug fixes (“ticket resolution”) and feature enhancement / new feature development.
2. Regular Maintenance. Also known as “routine maintenance” or “scheduled maintenance,” the software you had built will require regular updates – security upgrades, new version releases, and the like. That’s what this means.
3. Hosting/Infrastructure. Often, the Support and Regular Maintenance of a custom software solution is bundled together with Hosting and Infrastructure costs (I’ll expand on why below). Hosting and Infrastructure content within an SLA commonly defines the hard costs (e.g. servers, load balancers, etc.) as well as the maintenance to the infrastructure environment (e.g. upgrading or patching server software).
4. Backups/Testing. SLAs should also include details around backups (type, frequency, number stored) and potentially the testing frequency (weekly, monthly, quarterly) of those backups.

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.

The 6 Service Level Areas to Understand

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:

1. Ticket Submission Methods
2. Response Times
3. Issue Levels and Definitions
4. Bugs vs. Features
5. Credits
6. Exclusions

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.

Ticket Submission Methods

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:

• Phone support: Is a phone call an acceptable method? (It should be.) Assuming so, the SLA should also include what number to call, and the hours of operation.
• Email support: Is email an acceptable method for submitting a ticket? (It should be.) Assuming so, the SLA should also include what email address to use, and if that changes outside of certain business hours or for certain levels of issue (more on that later).
• Ticketing software: Does your Service Level provider use a specific tool (for instance, we use Asana) for ticketing? Do you, the client, have direct access to that tool for logging issues? Assuming so, the SLA should identify that tool, and if that changes outside of certain business hours or for certain levels of issue (more on that later).

Service Level Response Times

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.

Issue Levels and Definitions

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:

• High Priority: Issue renders the Application unusable and has no workaround, or causes loss/corruption of stored data.
• Moderate Priority: Not High Priority, but does have significant impact / is important as defined by Client.
• Low Priority: Have isolated impact and may have workarounds. Most issues are considered low.

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.

Software Bugs Versus Software Features

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:

1. We indicate in the SLA whether or not “design, development, QA, and other software development services” are included under the “Support” definition.
2. In the pricing table, we include the hourly rate for those (or, if it’s a retainer, we include the size of that retainer).
3. Finally, we include language that indicates that “any work on new or existing features will be scoped for cost and approved by the Client prior to beginning work.”

With language like the above, all your bases for Service – bug fixes and new features/feature improvements – are covered.

Credits

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:

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.

Exclusions

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:

• Circumstances out of the provider’s control: e.g. hurricanes, embargo, interruption of 3rd party services, and the like.
• Scheduled or emergency maintenance
• Client acts or omissions (e.g. willful misconduct, custom scripting/coding, etc.)
• Internet service provider outages/issues

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:

1. In-house development teams with full access
2. In-house IT teams with server access
3. External contractors with application access
4. Content managers with application access
5. External hosting providers with server and application access

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.

Moving into Your Next Service Level Agreement

If you’re evaluating SLAs and providers for your custom software, you’ll be well-positioned if you remember these key points:

1. SLAs are about clear expectations and accountability. That’s why definitions for issue level, ticket submission methods, and response times need to be understood.
2. You get what you pay for. Make sure to align the scope of your SLA with the size, complexity, and impact of your software.
3. Evaluate cost, but also risk. Generally speaking, lower cost SLAs mean lesser service and more risk. The inverse is also true. It’s up to you to sort out what is an acceptable level of risk to take on.
4. A one-stop provider is easier. One service provider means more promises can be made around uptime and service, and you have one place to go if something goes awry. Multiple providers equals fewer promises, and potential finger pointing.

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.