Technology Media and Communications.jpg

Service credit mechanisms – worthwhile or an unhelpful burden?

24 February 2016

Service credit mechanisms are very common in contracts for ICT services and solutions.  However, there are mixed views about how useful they really are.  For some, a mechanism which allows a customer to recoup a portion of fees for poor service is a 'must have'.  For others, such mechanisms are seen as blunt instruments for incentivising good performance with little benefit.

In reality, whether service credits are of benefit or just a hassle comes down to how good the relevant service credit mechanism is, and that will depend on the nature of the services and the customer-supplier relationship. It also will depend on the value of the contract and the credits on offer - if only a very small amount of money is up for grabs, the cost/benefit analysis can of course be very different.  In working out what will be a good service credit mechanism for the particular contract you're dealing with, the following questions are worth asking:

  • What are the service levels that really matter to the customer? Mechanisms which apply credits to every failure to meet service levels, no matter how trivial, can involve considerable administrative burden with no real benefit to the customer. It can also have a detrimental impact on a supplier/customer relationship - the English case of Mid Essex Hospital Services v Compass Group (2013), where a catering company was credited £84,550 for a day-old chocolate mousse, is a good, though extreme, example of this. While having a range of measurable and monitored service levels can help track issues in service performance and identify areas for improvement, it's usually better to focus service credits on the service levels that really matter.

     

  • How will service levels be measured and reported on? Service credit mechanisms can fail to do their job if performance against the levels can't or won't be regularly measured or reported on. They can also simply be a source of ongoing dispute if the customer has no way of really verifying performance and does not have confidence in the supplier's reporting. Addressing how service levels will be reported on and measured is important to crafting a good service credit mechanism. Customers should also be careful to check that service levels are not expressed as "targets" only, and that any carve outs from responsibility to meet service levels are well-defined.

     

  • Is it possible to amend the mechanism to focus on what matters as time goes on? Of course, the service levels that are really important to a customer might change over time. If only certain service levels attract credits there is also a risk that a supplier might focus its attentions on meeting those service levels at the expense of others. One way to address this is to allow the customer to change the service levels that attract credits (or change the weightings that apply to each service level) during the term of the contract.

     

  • Does the mechanism address material non-performance and persistent non-performance? Often poor performance really becomes an issue when there are persistent problems over a number of months which fundamentally erode customer confidence in the service. Credit mechanisms can work better if they address persistent poor performance, as well as one-off catastrophic failures. For example, a failure to resolve a service incident within the required timeframe three times in a month, or every month for three consecutive months, could attract a credit. In more complicated mechanisms, a compounding factor may be added so that if a breach continues, the available credit grows.

     

  • Are earn-backs, incentives or balanced score cards appropriate? Earn backs allow a supplier to "earn back" service credits in the months after a service level breach by meeting the service levels. Incentive or bonus schemes may require a supplier to be paid extra if they exceed service levels. Balanced scorecards involve averaging performance over a period. These all involve giving a supplier some "credit" for (eventual) good performance/over-performance. Proponents of these mechanisms argue that they can have a positive impact on the ongoing relationship and are fairer on the supplier. The counter to this is that these mechanisms may be susceptible to gaming. It's also worth considering whether over-performance is all that valuable to the customer. If the customer is happy with the agreed service level why should it pay more for a level of service it doesn't need?

     

  • How do the credits impact on other contractual remedies for breach? It's not uncommon for service credits to be couched as a customer's sole remedy for breach of service levels. If that’s the case, customers should consider two key issues before accepting this; do they want the right to terminate if service level performance meets a particular threshold, and are the level of the service credits really going to be sufficient to compensate them for loss if the levels are not met? The latter is particularly important if service credits payable under the contract are capped.

     

  • Could the size of the credits be open to challenge? The prohibition on contractual penalties is quite often front of mind when parties consider liquidated damages for delays in meeting milestones. It seems to be less common to think about the rule against penalties in the context of service credits. This is probably because the amounts at stake tend to be a very low portion of the fees paid by the customer. However, if the service credit mechanism could require the payment of significant amounts that might be viewed as extravagant or entirely disproportionate to any loss, it's worth taking legal advice about the risk that the credits could be unenforceable as penalties. It may also be helpful to specify in the contract that the credits are not liquidated damages but provide for reduced fees to reflect the value of a reduced level of service.

 

This article was written by Amy Ryburn, partner in our TMT team, for the IITP Techblog (24 February 2016). The original article can be found here.