Earnback of service credits in technology service agreements is an absurd concept that should be rooted out of contracts
As often seen, service credits are commonly used in technology service agreements to compensate clients for a service provider’s failure to meet a committed level of service. Whilst service credit mechanisms can range from simple to byzantine, earnback of service credits is one of the more egregious pieces of nonsense you can see in a service level agreement.
To take a step back, there is a social concept that you can somehow repay your bad actions to society by doing good works. It is a form of utilitarian philosophical thinking where the greater good can outweigh the bad; perhaps industrialised in the sale of indulgences back in Medieval times. Conceptually, a murderer can go to prison for many years to “pay their debt to society”, but they still killed somebody, nevertheless. So, the concept is based on some possibly dubious principles and which does not always survive robust scrutiny. Indeed, as often is the case with socio-philosophical inventions like this, there are conditions under which the simple equations fail, and the answer they produce is nonsense.
As an aside, and I hesitate to bring it up, but if you want to test boundary conditions and how a rule, social or otherwise, works or doesn't work in extremis, then try applying the Jimmy Savile Test (OK, yuck). If you don't know, Jimmy Savile was a uniformly horrible person who curried favour with rich and famous people in the high strata of society with his apparent "good works" as a cover for his obscene behavior. The test is this: if somebody proposes a generic rule then you think to yourself "what about Jimmy Savile?", and if the answer is "Euw!", "No way!", "Disgusting!", then the rule is probably a bust.
Back to earnback, which in the context of a commercial service agreement, means the service provider doing some good works to overcome below par performance at some point in time. Those good works then exempt them from paying compensation to the client which would otherwise be payable for the poor performance. Timing-wise, the performance bump can be ex-ante where previous good works put money in the bank to credit against claims, or ex-post where the good works occur after the default. In the generality, it is all about the push and shove of risk transfer between client and service provider; earnback pushes back risk to the client.
As a principle, earnback of sorts could make sense for a development activity or manufacturing piecework process creating widgets where poor rate of production in one month can be offset by increased output in later months so that the same expected pile of widgets is created in the overall period, meeting the expected weighted average production rate.
However it makes little sense in an operating service where the service delivered is of its moment and the experience is transient. In the service world, a dog, as they say, is only as good as its last trick – not an average of its good and not so good tricks. Sometimes it makes even less sense…
Consider this typical earnback clause that you might find in a service agreement…
This says what it says which is that if the service provider behaves for three months following a service level default then they can play their “get out of jail free” card and not pay the service credit for their default. Graphically, it looks like this…
The story is: the service provider commits to deliver to a service level in the contract. They then default on that service level in Month N, and proceed to meet the service level in Months N+1 to N+3.
The earnback clause magically absolves them of paying for the default…by doing the job they are already being paid to do. This is patently absurd: why does doing that job same as any other time exempt them from paying the compensation? Thanks for nothing!
In the fetid atmosphere of the negotiating rooms when these types of clause were first invented (maybe the 1980s?) it probably all seemed to be a very clever manipulation of risk and incentives. You can see other examples of “cleverness” where complex mechanisms have been designed that don’t make sense in the cold light of today (e.g., service level escalator ratchets which don’t work in a multi-vendor SIAM setup).
In the hierarchy of performance metrics many of the older concepts like earnback of service credits fiddle in the bottom tier of technical performance measures whilst user experience burns: the client suffering an “All-Green Hell” SLA dashboard for a service that users hate passionately. Better to focus design efforts on performance regimes further up the pyramid…
So, root out earnback from your service agreements, let the service provider make its penance at the time of default and move on!