Support & maintenance: a customer perspective
If you are procuring software, either as an on-premise product or a SaaS application, support and maintenance is going to be an important consideration.
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 to a support contract. You want the supplier to acknowledge your support request quickly, provide a full response so you understand what they are doing to fix the issue and, most importantly, you want them to 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 you log the error, when the supplier identifies the error themselves through proactive monitoring or when some other trigger event occurs?
Fix or target resolution
As a customer, you will ideally want a guaranteed fix time for any reported faults. However, suppliers are often reluctant to give guaranteed fix times, arguing that it is impossible to assess every potential issue and the related fix time.
Where guaranteed fix times cannot be obtained, you should seek target resolution times from the supplier together with undertakings as to what will happen if those target resolution times are not met. For example, if a supplier fails to meet a target resolution time for a major issue, you may want an undertaking from the supplier to continue working to resolve the fault on a 24/7 basis. You may also want a related escalation path to senior figures in the supplier’s business because having your fault on the CEO’s radar can often help to speed up the resolution.
The contract should clearly define timescales for all of the supplier’s actions. It needs to be made clear whether SLAs are calculated by reference to business hours / days or on a 24/7 basis (see our note on Contract Management and SLAs for more details). If you have offices outside of the UK, you should make sure that the SLAs are appropriate for all time zones. For example, you don’t want a help desk which only operates during UK business hours if a large percentage of your users will be based in Australia.
First line / Second line / Third line support
Increasingly, businesses have their own in house IT support teams. This means that they may only require support from suppliers 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 second 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 have offices outside of the UK, another important factor may be whether the support and maintenance services are available in other languages to ensure that your user base is adequately supported.
Support and maintenance contracts often contain a long list of exclusions. As a customer it will be important for you to review those exclusions and consider whether they are reasonable. For example, are they genuinely things which are outside of the supplier’s control? If yes, do you have other ways of mitigating the potential impact of those issues? Some exclusions in support and maintenance contracts can seem reasonable on the face of them but with further consideration, they might not be acceptable to you as a customer. For example:
- An exclusion of support for issues caused by user error. If the software product / SaaS service to which the support contract relates requires a lot of user input, it is foreseeable that, even with a good level of training, users will from time to time make mistakes. You don’t want to find that you are left without support as a result of such mistakes. In these circumstances, you could consider including a maximum number of user error issues during each support period and agreeing with the supplier that you will pay extra fees if you exceed that number. This puts the onus on you as the customer to ensure that your staff are well trained but does not leave you unsupported.
- An exclusion of support for downtime caused by a third party supplier. If you are contracting for the provision of a SaaS service, the SaaS provider might be outsourcing the hosting to a third party supplier. In these circumstances, you should not be left without a remedy just because the SaaS provider’s supplier let them down. The SaaS provider should have a contract with the hosting provider which addresses such a failure and as a result you should be able to claim against the SaaS provider for their hosting provider’s failure.
- An exclusion of support for downtime caused by a failure of a utilities provider. If you are contracting for the provision of a SaaS service, it might be reasonable for the SaaS provider to exclude liability if the service is unavailable due to a power-cut. However, if you are expecting your SaaS provider to have backup generators or backup servers in different locations, such an exclusion would not be reasonable because it would undermine the backup service you had contracted for.
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 the customer and the supplier 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. If you, as the customer, are investing heavily in the procurement of the software / SaaS application and in training your staff, you will want to know that you will be able to receive support and maintenance services for as long as you require.
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.
Termination and escrow
Trigger events for termination should be clearly defined in the contract and it should be considered whether failure to maintain software in accordance with the maintenance contract could potentially trigger the release from escrow of source code to the software. For more information on escrow see our note on Escrow: A customer perspective.