Software support helpdesk services – key contracting principles

13 April 2022

In our recent blog, we explored why a Framework Agreement structure is typically the most appropriate customer contracting model for IT managed services providers (“MSPs”) and IT consultancies which offer a diverse product and service offering. Whilst our initial blog focussed on the purpose and terms of the Framework Agreement itself, that document is merely the starting point, given that a Work Order is also needed to document specific terms relating to each product or service offered by an MSP or IT consultancy. A typical service offering is a dedicated software support helpdesk, usually provided to support each of the software products offered by the MSP or IT consultancy to its customers. This blog considers a handful of the key issues to bear in mind when documenting the terms of a Work Order relating to the supply of a software support helpdesk service.

Scope of services. Typically, the bare minimum requirement of a software support helpdesk service is to try and remedy faults with the supported software which are reported by the customer during specified hours. However, the service may well extend beyond that. Perhaps the MSP or IT consultancy may also advise on the use and functionality of the supported software, dealing with ad-hoc operational queries from the customer that may arise from time to time. The service could also involve the MSP or IT consultancy monitoring the supported software itself in order to identify problems as they occur and attempt to resolve them without the customer first having to report them.  A customer’s expectations of a software support helpdesk service could therefore be very different from the service that is actually provided and a key function of the Work Order is to fully and accurately set out the service scope.

Given that a customer may expect the scope of a software support helpdesk service to be a lot wider than it is, it’s prudent for service providers to explicitly carve out circumstances where they are not obliged to provide the service. This may involve carving out any obligation to remedy faults with the hardware on which the software operates, or clearly stating that there is no obligation to remedy issues caused by the customer’s acts or omissions (such as using historic versions of the software or using the software in a manner which is inconsistent with its operating manual).

Service Level Agreement (SLA). Customers will expect a software support helpdesk service to include an SLA of some sort, the terms of which should be set out in the Work Order. The SLA serves to set parameters as to the level of support the customer will receive based on the severity of the fault that needs to be remedied.

At the very least, an SLA should make it clear as to the process the customer needs to follow in order to report a fault, for example via telephone, email or a web chat service. Service providers usually use their own discretion to prioritise support requests based on their severity, often placing them in categories ranging from minor errors which do not significantly affect functionality of the supported software, to material errors which have disabled major operating functions of the supported software. Almost all SLAs will subject the MSP or IT consultancy to an obligation to respond to the customer with acknowledgement of the support request (possibly including confirmation of the specific individual on the support desk to whom the support request has been allocated), within a specified timeframe after the fault has been reported, depending on its severity. There may also be an additional obligation on the service provider to periodically provide the customer with updates on the steps being taken to remedy the fault within agreed timeframes.

Customers may also push for the SLA to include a timescale during which any reported fault is to be remedied. However, service providers may want to resist SLAs of that nature, given how difficult it is to predict with any certainty as to how long it will take to fix a fault. A softer obligation to remedy a fault ‘as soon as reasonably practicable’ could serve as an alternative to a definitive longstop within an SLA, although that approach reduces certainty as to whether the SLA has been breached which, in the event of a dispute between the parties, could serve to lengthen proceedings. 

Service credits. Arguably, the efficacy of an SLA can be gauged by the consequences faced by the service provider upon any breach of its terms. A common approach in the event of an SLA breach is to provide the customer with a right to receive a service credit i.e. a reduction in the fees due to the service provider. Often, the amount of the service credit will increase in line with the severity of the corresponding fault covered by the SLA.

Certain MSPs and IT consultancies will resist giving service credits arguing that the time spent pre-agreeing specific sums for multiple levels of SLA breaches is disproportionate to the certainty provided by the remedy in the event of breach. Other service providers cite the likelihood of expending significant time and effort with customers dealing with disputes as to whether service credits apply or, if they do, the applicable sum due, as another disincentive to the inclusion of a service credit regime. However, a carefully drafted set of service credit provisions may expressly state that a service credit is an exclusive remedy for any breach of the SLA. Inclusion of a clause of that nature would serve to prevent the customer from seeking any other remedy for breach of the SLA, such as a claim for damages for losses arising directly from that breach. For an MSP or an IT consultancy it’s arguable that the certainty of pre-agreeing a sum for a material breach of an SLA is preferential to having to deal with a damages claim in respect of that breach.

Penalties. A service credit should represent a genuine pre-estimate of the loss suffered by the customer as a result of the service provider’s breach of the corresponding SLA. A proportionate service credit of that nature is known as a liquidated damages clause and would be upheld by a court. However, if a service credit is excessively high, and bears little or no relation to the actual loss suffered by the customer, it will be considered a penalty clause. As a matter of public policy, penalty clauses are not enforceable, as they serve to punish the service provider, above and beyond fairly reimbursing the customer.  

Negotiating appropriate levels of service credits can become protracted between a customer and their MSP or IT consultancy. However, given the possibility of service credits being deemed penalty clauses, an MSP or IT consultancy has a perfectly valid argument to raise whenever faced by a customer which insists on the inclusion of excessive service credits which bear little resemblance to the commercial consequences of breaching the SLA. 

FURTHER INFORMATION

If you would like advice on a contract to govern the provision of a software support helpdesk service, feel free to contact one of our specialist technology lawyers here

 

ABOUT THE AUTHOR

Andrew Solomon has a broad range of expertise in corporate law, regularly advising in respect of share and asset sales, investments and share options (in particular EMI schemes). His commercial practice is focussed on drafting and negotiating technology contracts, although he also advises in relation to a wide range of commercial issues, such as intellectual property, branding, data protection and sponsorship arrangements.

 

Share insightLinkedIn Twitter Facebook Email to a friend Print

Email this page to a friend

We welcome views and opinions about the issues raised in this blog. Should you require specific advice in relation to personal circumstances, please use the form on the contact page.

Leave a comment

You may also be interested in:

Skip to content Home About Us Insights Services Contact Accessibility