Support & maintenance including SLAs

If you are wishing to sell software, either as an on-premise product or a SaaS application, support and maintenance is going to be an important consideration for you in terms of ongoing revenue and product development and for your customers.

This note gives an overview of the key issues to address in a support and maintenance contract, whether as a standalone service or as part of a wider SaaS contract.

 

Acknowledgement, response and fix

There are three core elements that your customers will be wanting from you in a support contract:

  • That you will acknowledge their support request
  • That you will provide a full response so they understand what they are doing to fix the issue
  • That you fix the problem

The contract should address these three actions, clearly identifying when any timescales for acknowledgement, response and fix start to run. For example, do they begin when the customer logs the error or when some other trigger event occurs?

 

First line / Second line / Third line support

Increasingly, customers have their own in house IT support teams. This means that they may only require support from you for more complex problems. ‘The expressions’ first line, second line and third line support have been coined to explain the difference between these levels of support. However, these are not industry standard definitions and the contract should make it clear exactly what is included / excluded.

First Line Support

First line support is typically a help desk and deals with issues that customers can often fix themselves, such as password resets and ‘how to’ requests. First line support requests generally come from the users themselves.

Second Line Support

Second line support problems are either identified directly by the first line support teams or they are escalated from the first line support teams. Second line support teams usually include technicians, analysts and engineers and either provide support up to third line support or receive input from the first line team.

Third Line Support

Third line support is needed when issues get more difficult. Specialist knowledge is almost always needed, with IT engineers focusing on different systems and hardware, often with little to no crossover with other skills and specialisms.

If you will be provided only first line and /or second line support, the contract should make it clear that you will not be responsible for delays caused by the first line / third line support provider.

 

Fix or target resolution

As a supplier you will likely want to avoid giving guaranteed fix times and instead have target resolution times to avoid situations where unexpectedly complex issues result in you being in breach of SLAs.

 

SLAs

Customers will usually require SLAs for support responses. It is important that it is made clear in the contract whether these are calculated by reference to business hours / days or on a 24/7 basis. The example below shows how a failure to appreciate the difference between these can have a huge impact on the effectiveness of the SLA.

The Customer identifies a major fault at 4.30pm on a Thursday and the contract contains a response time SLA of 1 hour:

 

 

SLA calculated on a 24/7 basis

SLA calculated on a Support Hours basis defined as 9am – 5pm 7 days a week

SLA calculated on a Business Hours basis – 9am to 5pm Monday – Friday excluding bank and public holidays in England

Maximum timescale for response by the Supplier

5.30pm Thursday

9.30am Friday

9.30am Friday

 

Unless the Friday is Good Friday in which case 9.30am the following Tuesday

 

Availability SLAs

If you will be providing a SaaS solution or hosting services, then you may offer an availability SLA. If you are not hosting the software and instead are providing support and maintenance for a software produce which is hosted by the customer, you should avoid giving availability service levels because the availability of the software will be largely outside of your control.

The table below sets out typical availability SLAs and their related downtime:

 Availability SLA

Downtime

(per day)

hrs:min:sec

Downtime

(per month)

Downtime

(per year)

99.999%

00:00:00.4

00:00:26

00:05:15

99.99%

00:00:08

00:04:22

00:52:35

99.9%

00:01:26

00:43:49

08:45:56

99%

00:14:23

07:18:17

87:39:29

 

Exclusions

It will be important for the contract to clearly set out any exclusions to the support and maintenance services which you will be providing. Examples of common exclusions are:

  • Planned maintenance
  • Unscheduled / emergency maintenance
  • Failures outside of the supplier’s control
  • User error
  • Modifications made by the customer

 

Assessing severity

SLAs are often dependent on the nature and severity of the problem. It is important that the contract clearly differentiates between the severity levels and sets out which party will ultimately determine the severity of any problems reported by the customer. It should also set out how any dispute regarding the assigned severity level will be escalated (making it clear that the SLA timescales will continue to run while the dispute is being escalated).

It is important for a supplier to be able to replicate problems on test systems to be able to investigate the underlying reasons for the fault.

 

Global users

If your customers have offices outside of the UK, you should make it clear in the contract whether support requests can be made in languages other then English and what time-zones your support teams will operate in.

 

New releases, versions and upgrades

In addition to dealing with error resolution, support and maintenance contracts should also address issues connected with changes to the SaaS application or the supported software. Issues which will need to be addressed in the contract include:

  • Are new releases, versions, or upgrades included in the fee?
  • Is continued maintenance dependent on the customer purchasing upgrades?
  • Is the supplier entitled to withdraw support from old versions of the software?
  • In what circumstances can the customer postpone the installation of upgrades? What impact will this have on the supplier’s support and maintenance obligations?
  • If a new version is very different from the existing version will the supplier be required to assist with issues such as data conversion or migration and staff training?
  • How regularly will upgrades be provided?
  • What warranties does the supplier give in relation to interoperability with existing software/hardware?

 

Duration and renewal

It is important for both you as supplier and the customer that there is no uncertainty in relation to the extent of the obligations on each party. The duration of the contract will be important to both parties.

The contract should make it clear whether the use of the software product / SaaS application is conditional on the ongoing purchase of support and maintenance services and how any self-supporting process would be managed.

The expected length of the relationship between the parties should be considered at the outset together with issues relating to termination and renewal and any related costs.

For further information please contact Kathryn Rogers on +44(0)1892 506 147 or at kathryn.rogers@crippspg.co.uk.