IT Customers have become familiar with IT suppliers offering service credits should an IT service under-perform against service level. Service Credits can fail to reinforce supplier performance and have subsequently gained a negative press. Nigel Chisnall, of PTS Consulting, explains the deficiencies of simplistic application of Service Credits, illustrates a variant approach and rediscovers their role in performance improvement.

What are Service Credits?

The principal way to build a relationship between an IT customer and an IT supplier is through a contract supported by Service Level Agreements. Mutual expectations are set out in functional and performance terms and Service Credits are frequently used as a corrective mechanism. The suppler credits the customer for its underperformance. Of course, what the IT customer sees as ‘credit’ is what the IT supplier usually experiences as ‘debit’ – usually a reduction in its monthly service charge.

The Service Credit is often portrayed as a punitive measure positioned between service failure and Contract Renegotiation. Much discussion of this negative role of Service Credits has appeared in the IT press but Credits remain a staple feature of large public and private sector service ICT Service contracts.

Can Service Credits harm value?

Credits have a management overhead for both parties in monitoring and maintaining a Service Credit regime. While a Credit may be incontestable for specific underperformance, they are often a blunt instrument in actually shaping IT Supplier performance. Adding Service Credits at Contract Design as a material punitive measure also encourages risk-aware pricing where the suppliers’ charges are designed to accommodate failure. This is undesirable from both sides and risks undermining good will.

The original intent of Service Credits needs to be rediscovered. This is the careful shaping of supplier performance such that the possibility of invocation drives specific positive IT supplier behaviour. If the purpose of a Credit is clear to both parties, a stick can suddenly look more like a carrot.

Is there an alternative?

First, a Credit need not be the return of money to the Customer; it could be recompensed in the form of professional project services or a penalty could be offset by accumulated over-performance.


Secondly, the construction of the Credit should mirror the discomfort incurred by the service failure. This requires a real-world understanding of how IT systems and services behave in a steady state environment and, more importantly, in situations of stress. Credits also should be proportionate, appropriate and fair. To illustrate, here are two common examples of IT Service behaviour under stress:

  • A reactive IT service relates to contracts such as where the IT supplier responds to trouble tickets in prescribed time frames though the arrival of these tickets is unpredictable or non-deterministic. IT Suppliers often use versions of statistical multiplexing to accommodate reactionary behaviour. A captive or dedicated outsourcer will size its operation for worst case scenario based on heuristics, rules of thumb, expert judgement or historical evidence. There may be a tolerance for occasional failure provided the service has over-performed.
  • A repeatable routine performance such as production of a statutory security or start of day IT status report which drives a workload. In this case, the IT supplier is aware that timeliness is operationally essential to the IT customer. There will be a Service Level with low tolerance for failure but no chance to over-perform.

The following diagrams illustrate two ways in which individual IT services vary in their characteristics and how a Credit regime needs to be shaped to mirror under-performance. The first concerns an Escalator Function, the second a Ratchet Function.

An Escalator is a function that allows a Credit to ramp up if uncorrected - the Monthly Credit increases typically as an uncapped multiplier. As the performance is corrected the Escalator falls back to zero after a period of failure-free operation. This is a good profile for a reactive IT service such as response to service desk calls.

A Ratchet Function is more useful when the Credit persists over time without escalation. This is a good profile for routine operational tasks such as a supplier delivering a time-sensitive infrastructure status report. If the report is delayed, a state of uncertainty is introduced where the customer has to reserve IT staff against the possibility, rather than the certainty, of action. The consequence is often a ‘false positive’ with consequent inconvenience for the customer. It denies the customer the chance to deploy its IT staff on other tasks and so is an opportunity cost. In this example the persistent but delimited shape of the credit mirrors the pain felt by the customer.

Some IT services have a cumulative or queuing impact when left uncorrected and where a single failure leads to bottleneck demand for IT recovery resources - this in turn increases the likelihood of repeat failure. These types of situation need careful modelling when shaping an appropriate Credit regime.

A Service Credit therefore needs to be mathematically shaped in line with the IT performance that it seeks to positively reinforce. Beyond the Escalator and Ratchet, a number of time-based mathematical functions can be modelled in spreadsheets. Any model must allow stress testing where the IT Customer can run failure scenarios and model the impact of under-performance or, more positively, estimate the value it places on preserving performance.

Positive use of Credits

IT Customers need to consider mechanisms where good behaviour can offset previous failure if there is a demonstrable and empirical basis for recognising improvement. For example, if the time between failure increases or the absolute failure volume falls over time, penalties might be reversed. It does seem good general practice to tightly couple action to consequence - any penalty or reward should closely track the IT supplier’s performance as closely as possible.

If scenarios are run in a spread sheet, best practice Business Modelling suggests removing variables and active formulae from the spread sheet and controlling the model by external variables. In Microsoft Excel this requires modelling through macros rather than embedded formulae. By careful programming, we can theoretically stress test potential failure scenarios and shape a target Credit regime relevant to the portfolio of IT services being contracted.

An IT customer may conclude that a Credit regime is inappropriate or too complex for a given contract. However the act of building and stress-testing scenarios, analysing the impact of under-performance and calculating the value of correct performance remains a valuable exercise. The IT customer will have a deeper understanding of how an IT service might behave in production and can therefore make considered risk assessments.

Using these principles, the IT supplier and IT customer can come together in intelligent dialogue.  You will need to tailor a Service Credit regime to reinforce the values an IT customer places on the performance of its IT services.  IT providers will find this exercise useful with the resulting contract arrangements robust and equitable.

Nigel Chisnall specialises in global scale IT decision support and heads the Operational Transformation service line at PTS Consulting.