Service Credits and a Performance Bond: What an Enforceable IT SLA Looks Like at Renewal

The short answer: most IT SLAs describe targets and stop there. An SLA becomes enforceable when three more things are in place: a measurement both sides accept, a consequence that happens automatically when a target is missed, and a limit that keeps the provider solvent enough to fix the problem. Service credits and a performance bond are tools for the second part — not substitutes for the first.

What does an enforceable IT SLA actually need at renewal?

A service level agreement is a promise with numbers in it. Whether it is worth anything depends on what happens on the day one of those numbers is missed. In a lot of IT services contracts the honest answer is: nothing in particular. The monthly report shows a red cell, someone apologises in the quarterly review, and the invoice arrives unchanged.

This article is written for the finance or operations lead who has lived through that, is now renewing, and wants the next contract to bite. It covers the three layers an enforceable SLA needs — measurement, consequence and proportion — how IT SLA service credits and set-off against invoices actually work as mechanisms, when a performance bond or parent guarantee is proportionate and when asking for one simply raises your price, and the clauses that usually matter more than any of them.

One thing to say plainly before going further: this is a commercial guide, not legal advice. It describes how these mechanisms work and the commercial logic behind them. It does not draft clause wording, it does not interpret Hong Kong law, and it does not tell you whether any particular clause would be upheld. That is a question for your own lawyer, with your actual contract in front of them. What this article can do is make sure the brief you give that lawyer is the right one.

The scenario: an SLA that was met on paper and missed in practice

Picture a Hong Kong trading and distribution group of around 120 people. Head office, finance and the sales team sit in Kwun Tong. The warehouse and a small quality-control team are across the boundary near Dongguan. There is a three-person sales office in Singapore. Orders come in through a mix of EDI feeds, email and a distributor portal, and the warehouse runs on handheld scanners talking to an inventory system that syncs back to the accounting package in Hong Kong. This is a composite, not a named client — but every moving part in it is ordinary for a group of this shape.

Two years ago the group signed a managed IT contract with a published SLA. Every monthly report since then has shown SLA adherence comfortably above target. And yet the CFO's file of complaints is thick.

On the Monday before a major shipping cut-off, the warehouse scanners stopped syncing. Pickers went back to paper for most of a day. The ticket was logged at 8:40 a.m. It was classified P3 — "single site, workaround available" — because paper counted as a workaround. The clock paused twice while the provider waited for someone in the warehouse to reboot a switch. The ticket was resolved inside its P3 target. The report called it a success.

In the same quarter, the finance team lost access to the accounting system for three hours on the last working day of the month. The ticket was raised by email at 5:50 p.m., which under the contract's business-hours definition meant the clock did not start until 9:00 the next morning. Again, on paper, target met.

Nothing in either incident breached the SLA as written. That is the point. When the CFO asked what the group was entitled to, the answer was: an apology and a service improvement plan. So the renewal brief now says, in one line, that the new contract must include "service credits set off against payments and a performance bond".

That is a much sharper question than "what is your SLA?" It is also only half of the right question — because both incidents above would have produced zero service credits under almost any credit regime, since neither was recorded as a miss. Credits enforce targets. They do nothing about how the targets are measured.

Why isn't a priority ladder enough on its own?

Every competent IT provider publishes a priority ladder: P1 for business-down incidents, P2 for serious degradation, down to low-priority requests, each with a response and resolution target. We have covered how those ladders are built, and how impact and urgency combine to decide a priority, in our guide to IT support SLA priority levels. This article assumes you already have one and starts where that guide deliberately stops: what contractually happens when the ladder is missed.

A ladder is necessary. It is not sufficient, for three reasons.

First, a ladder is a set of targets, not a set of consequences. It tells you what the provider intends to do. It says nothing about what changes if they don't. A target without a consequence is a forecast.

Second, the ladder is only as good as the classification feeding it. The warehouse outage above was a P1 in business terms and a P3 in the ticketing system. A ladder with generous targets and a lenient classification process can report near-perfect adherence while the business experiences something very different.

Third, the ladder measures the provider's part of the timeline, as the contract defines it. Business hours, pause rules and clock-start events all decide how much of what you actually waited through gets counted. None of these are on the ladder itself. All of them are in the definitions section of the contract, which is the part most buyers read last.

So the renewal work falls into three layers, in this order: fix the measurement, then attach consequences, then decide how much security you need behind those consequences.

Who controls the measurement — and why does that decide everything?

Before negotiating a single percentage point of service credit, decide what counts as a miss. This is where most of the real value in an SLA renewal sits, and it costs the provider far less to concede than a credit rate does — which makes it easier to win.

When does the clock start?

The options are usually: when the user first reports the problem by any channel, when a ticket is created in the provider's system, or when the provider acknowledges the ticket. The gap between the first and the last can be substantial, especially if email reports sit in a shared inbox before anyone turns them into a ticket. Ask for the clock to start at the earliest event you can both evidence — typically the time-stamp of the first report through an agreed channel, whether phone, portal, email or chat.

Also agree what "response" means. An automated acknowledgement email is not a response. A human engineer reviewing the ticket and making first contact with the affected user is. If the contract does not say which, assume the provider will count the cheaper one.

Whose hours, and when can the clock pause?

A contract that measures P1 targets in business hours only is telling you something important about what you have bought. For a group with a warehouse that ships on Saturdays and a finance team that closes the month at night, it may be the wrong product, not the wrong clause. The right fix is usually to buy the coverage hours you need, rather than negotiate harder on a business-hours SLA.

Pause rules are the other half. It is reasonable for the clock to stop while the provider is genuinely waiting on you — for access, for a decision, for a user who is unreachable. It is not reasonable for it to stop while the provider waits on its own subcontractor, or for "awaiting customer" to be set automatically whenever a question is sent. Ask for pause reasons to be logged, visible to you, and limited to a short defined list.

Who classifies a ticket, and what happens when it is reclassified?

This is the single most-argued clause in any SLA dispute, and the one the scenario above turns on. Agree up front, in writing, what makes an incident a P1 for your business specifically: warehouse scanning down during operating hours, the accounting system unavailable during month-end close, the order portal refusing distributor logins. A generic definition such as "business-critical system down" leaves the call to whoever is on shift.

Then agree three rules. You can raise a ticket's priority, and the provider must accept the raise immediately and argue about it later. Any downgrade by the provider must be recorded with a reason and notified to you. And the SLA clock for a reclassified ticket runs from the original report time at the corrected priority, not from the moment of reclassification. Without that last rule, a ticket wrongly logged as P3 and upgraded to P1 at lunchtime would have a fresh P1 clock starting at lunchtime — which means the misclassification itself is never measured.

Is the report something both sides can audit?

A monthly SLA report generated by the provider, from the provider's system, using the provider's definitions, is a useful document. It is not evidence you can check. Ask for access to the underlying ticket data — at minimum an export with creation time, priority history, pause history and resolution time — so that your own team, or an independent reviewer, can recompute adherence. If you are already using monthly reports in a quarterly review, the same data export is what turns that review from a presentation into a conversation.

How do IT SLA service credits actually work?

A service credit is an agreed reduction in what you pay when the service falls below the specified level. It is calculated by a formula written into the contract, it applies without either side needing to prove what the shortfall cost, and it usually appears as a line on a later invoice. The logic is commercial: you paid for a level of service, you received less, so the price adjusts.

That is all a service credit is. The design choices are in how the formula works, what limits it, and how the money actually moves.

How is a service credit calculated?

Most regimes combine three variables: which target was missed (response or resolution, and at which priority), how badly, and how often. Some attach a fixed amount to each missed P1 or P2 ticket. Others measure monthly adherence per priority and apply a credit when adherence falls below a threshold. Many use a sliding scale, so that one missed target costs little and a pattern costs more.

A hypothetical worked example, with every number invented purely to show the mechanics — these are not market rates and not Brocent's rates. Suppose a monthly fee of HK$150,000. Suppose the contract says each P1 ticket that misses its response target generates a credit of 2% of the monthly fee, each P1 that misses its resolution target generates 4%, and P2 misses generate half of those amounts. Suppose credits in any month are capped at 15% of that month's fee.

In a bad month with one P1 response miss, one P1 resolution miss and two P2 resolution misses, the calculation would run: 2% plus 4% plus two times 2%, which is 10%, or HK$15,000 — under the cap, so the full amount is credited against a later invoice. In a catastrophic month with four P1 resolution misses, the formula gives 16%, the cap applies, and the credit is HK$22,500.

Look at what the example shows. The worst month produced a credit that is almost certainly a fraction of what four business-down incidents actually cost a trading group in lost shipments and overtime. That is not a flaw in the example. It is how credit regimes are built, and it is why the next section matters.

Why is a credit not the same as damages?

A service credit is designed as a price adjustment, not compensation for your loss. Nobody calculates what the missed target cost you; the formula decides the amount in advance. That is exactly what makes credits workable — no argument about consequential loss, no evidence-gathering, no delay — and exactly what makes them small.

How a credit interacts with any other claim you might have for the same incident — whether it is your only remedy, whether it counts towards other sums, whether it is described as your sole remedy for a missed target — depends on the drafting and on the law that governs the contract. That is a question to put directly to your lawyer. Do not assume either way, and be cautious of any summary, including this one, that tells you what the answer is without seeing the clause.

What does a cap do — and why do providers insist on one?

A cap limits total credits in a period, usually expressed as a percentage of the fee for that period. Providers insist on one for a reason that is partly self-interested and partly in your interest too: a managed IT contract is priced on thin margins, and an uncapped credit regime can turn one bad month into a month where the provider is paying to serve you. A provider in that position has every incentive to reduce the effort it puts into your account, which is the opposite of what you want after a bad month.

The useful question is not whether there should be a cap but what happens when you hit it. A well-built contract treats a capped-out month — or repeated months near the cap — as a trigger for something other than money: a formal remediation plan, escalation to named senior people, and eventually a termination right. That is what turns a cap from a ceiling on your remedy into a tripwire.

What is earn-back, and is it a trap?

Earn-back lets a provider recover credits it has paid if performance over a following period exceeds target. Providers ask for it because it rewards recovery. Buyers dislike it because it can mean credits are never really paid.

Earn-back is not inherently unreasonable. It becomes a problem when the recovery window is long, the recovery threshold is easy, or the credit is only issued at year-end and so can be netted off before it ever appears on an invoice. If you accept earn-back, keep the window short, set the recovery threshold above normal target, and make sure credits are issued as they accrue, not reconciled annually.

Can service credits be set off against the invoice?

"Set-off" in this context means the credit reduces a payment you owe, rather than arriving as a separate refund. There are two quite different ways this is done in practice, and the renewal brief should say which one you want.

In the first, the provider calculates the credit from the monthly SLA report and applies it as a line on the next invoice. You pay the net amount. This is administratively clean and is how most credit regimes are designed to operate. Its weakness is that the provider does the calculation.

In the second, the contract gives you a documented right to deduct an agreed credit yourself from a payment due, typically after the credit has been calculated and notified and a short dispute window has passed. This gives you more control but needs a clear procedure, because deducting an amount the provider disputes is exactly the kind of thing that turns a service conversation into a payment dispute.

What you should not do is withhold payment on your own reading of a report when the contract does not clearly give you that right. Whether a given set-off arrangement works the way you expect is a drafting question for your lawyer. The commercial point is simpler: credits that are calculated automatically, applied to the next invoice, and visible on it are credits that actually get paid.

Target-only SLA vs service-credit SLA vs credit plus bond: what changes provider behaviour?

The CFO's instinct in the scenario was to escalate straight to the strongest instrument. It helps to see what each level of enforcement actually changes about how a provider runs your account.

How the three models compare

• Target-only SLA: the provider publishes a ladder, reports against it and discusses misses in a review. Behaviour is driven by reputation and the renewal date. It can work well with a provider that cares about the relationship, and it costs nothing extra. Its weakness is that in the months that matter most, when something has gone badly wrong, nothing automatic happens — which is the situation the group in our scenario is trying to leave.
• Service-credit SLA: a missed target has a price, calculated automatically and applied to the invoice. This changes behaviour where it counts — inside the provider's own operations. A credit-bearing P1 is escalated faster, a pause reason is scrutinised harder, and misclassification becomes visible because someone on the provider's side now has a reason to track it. It works best when the measurement layer is fixed first; a strong credit regime on a lenient classification process mainly generates arguments.
• Credit plus performance bond or guarantee: on top of credits, a third party — a bank, an insurer or a parent company — stands behind the provider's obligations up to a stated amount. This does not change day-to-day behaviour much; the service desk does not know the bond exists. What it changes is your position if the provider fails badly enough to stop performing at all, or cannot pay what it owes. It protects against insolvency and abandonment more than against slow tickets, and it comes at a cost that will appear somewhere in the price.

Put simply: credits change behaviour; a bond changes your recovery position in a failure. They are answers to different questions, and a renewal brief that asks for both without saying which risk each one is covering will usually get a higher quote rather than a better contract.

When is a performance bond or parent guarantee proportionate?

A performance bond is typically an undertaking from a bank or insurer to pay you up to a set amount if the provider fails to perform its contract. A parent company guarantee is an undertaking from the provider's parent group to stand behind its subsidiary's obligations. They are common in construction, large outsourcing deals and public-sector procurement. In a mid-market managed IT contract they are unusual, and there is a reason for that.

A bond is not free. The provider's bank will charge for issuing it, may require collateral or tie up part of the provider's credit facilities, and the provider will price that cost into the contract. A parent guarantee is cheaper to give but exposes the parent's balance sheet, and some groups simply do not give them for contracts below a certain size. Either way, you pay for the protection. The question is whether what it protects against is worth that price.

It tends to be proportionate when several of the following are true:

• The switching cost is very high. The provider is running systems you could not quickly move — a heavily customised platform, infrastructure it owns and hosts, or a transition that would take many months.
• There is significant upfront investment on your side. You are paying for a large transformation project, or prepaying a substantial amount, and a failure mid-project would leave you with sunk cost and nothing working.
• The provider's financial position is genuinely uncertain. A young company, a thin balance sheet, or a subsidiary with few assets of its own.
• Your own obligations to others depend on it. Customer contracts, regulatory commitments or lender covenants that would be breached if the IT service stopped.

It tends to be disproportionate when the service is standard managed IT support, priced monthly, on a contract you can exit with reasonable notice, delivered by a provider with a track record you can check. In that situation the protections that matter most are the right to leave and a clean handover — which cost the provider far less to give, and so should be much easier to win.

If you do decide a bond or guarantee is warranted, ask for it early in the process, tell the provider what risk it is meant to cover, and ask them to price it separately. That way you can see what it costs and decide whether it is worth it, rather than finding it buried in a higher monthly rate.

What will a provider push back on — and when is pushback a good sign?

Expect pushback on four things. Uncapped credits. Credits on targets that depend on your staff or your third parties. An open-ended right to withhold payment. And a performance bond on a standard monthly service.

Some of that pushback is self-interest. Some of it is a provider telling you honestly what it can deliver. It is worth telling them apart.

Pushback that is a good sign sounds specific. "We can't give credits on resolution time for incidents that depend on your carrier, but we'll give them on response and escalation, and we'll report the carrier's times separately so you can take it up with them." "We'll accept a lower cap if the capped-out month triggers your right to terminate." "We'd rather not give a bond, but here is our audited financial position and here is our exit assistance commitment." A provider that negotiates this way is showing you where its real control ends — which is exactly what you need to know before you sign.

Pushback that is a warning sounds general. "Our standard terms don't allow changes." "Credits aren't something we offer." "Classification is at our engineers' discretion." A provider that will not let you see ticket data, will not define a P1 in your terms, and will not attach any consequence to a miss is telling you how the next contract will feel — the same as the last one.

A provider that agrees to everything without a question is also worth a second look. Enforcement terms that are conceded too easily are sometimes conceded because nobody expects them to be used.

Which clauses matter more than service credits?

Credits enforce a running service. The clauses below decide what happens when a running service is no longer the goal — and in a renewal after a bad contract, they are often worth more.

What should exit assistance cover?

The strongest enforcement tool you have is the credible ability to leave. That is only credible if leaving is practical. Exit assistance should oblige the outgoing provider to cooperate with a successor for a defined period, keep delivering the service at the agreed level until handover is complete, hand over configurations, credentials and documentation in a usable form, and attend a defined number of knowledge-transfer sessions. It should say how that assistance is charged, before you need it. We walked through what a structured transition between providers looks like in practice in how a Hong Kong trading company switched IT providers.

Who owns the data and the documentation?

Network diagrams, asset registers, runbooks, admin credentials, licence records, backup configurations: these should be yours, kept current during the contract, and accessible to you at any time — not only on exit. A provider that holds the only copy of your admin credentials has a form of leverage no credit regime can offset.

Does the contract require continuous improvement, or only reporting?

A monthly report tells you what happened. A service improvement plan says what will change because of it, who owns each change, and by when — and a quarterly review checks whether it did. The difference between those two is the difference between being informed about problems and having them fixed.

Is there a genuine escalation path?

Credits are money. What you often need, in a bad week, is attention. A named escalation ladder — service desk lead, service delivery manager, then a director with authority to reassign resources — with contact details and time-frames written into the contract is worth more on the day than any percentage.

What does Brocent publish and stand behind?

Since this article is written by a managed IT provider, it is fair to say where we stand, and where the limits of any credit regime, including ours, sit.

For on-site field work, our published dispatch SLA tiers are on the dispatch rates page: on Normal Business Hours (8×5) coverage, a 2-hour P1 response, 4-hour P2 response and next-business-day on-site attendance; on Extended Hours (8×7), 1 hour, 2 hours and same-day on-site; and on 24×7 Emergency, a 15-minute P1 response, 1-hour P2 response and 4-hour on-site arrival. These apply to dispatched field work and you choose the tier you pay for.

For the help desk that runs inside our managed plans, our SLA and quality framework is a separate service line with its own targets. Tickets are classified P1 to P5, and the classification criteria are agreed upfront and documented in the service contract — which is the measurement point this article argues matters most. A P1 receives a 15-minute first response and a 4-hour resolution target. We report monthly on SLA adherence by priority, response and resolution times, ticket ageing and trends; we hold quarterly service reviews with an account manager and a service improvement plan; we track customer satisfaction on each ticket; and we work to a 99%+ SLA adherence target. You can read how the 24/7 help desk is staffed and how it fits into our managed services.

On consequences, our framework includes contractual service credits for missed P1 and P2 targets. The credit rates and the conditions attached to them are set in the master service agreement for each engagement, so we do not publish a single figure here — and we would encourage you to read that section of any provider's agreement, ours included, as closely as the targets themselves. We do not offer a performance bond as a standard part of our managed IT plans; if your situation is one of those described above where a bond is proportionate, raise it early and we will discuss it as a specific request rather than assume it.

And the honest limits. A credit regime, however well drafted, never makes you whole for a business-down day. It only covers what the contract says the provider controls. And it is only as fair as the classification and measurement feeding it. That is why we put the classification criteria in the contract rather than in an internal procedure, and why every tier of our per-user plan includes customer-owned documentation and credentials — so that the most important enforcement right you have, the right to leave cleanly, is real from the first day.

A renewal checklist for the CFO

If you only take a page into the renewal meeting, take this one.

• Your P1 definitions, in your words. Three to five named business situations that are always P1, regardless of how many users are affected.
• Clock start and response definitions. First report through any agreed channel starts the clock; a human first contact counts as response.
• Coverage hours that match your operations. If the warehouse ships on Saturdays, buy Saturday coverage.
• Pause rules. A short list of legitimate pause reasons, logged and visible to you.
• Reclassification rules. Customer can raise priority immediately; provider downgrades are logged and notified; clocks run from the original report.
• Data access. A ticket-level export you can use to recompute adherence.
• Credit formula, cap and trigger. Automatic calculation, applied on the next invoice, with a capped-out month triggering remediation and, if repeated, a termination right.
• Earn-back, if any. Short window, recovery threshold above target, credits issued as they accrue.
• Exit assistance and documentation ownership. Defined, priced and owned by you.
• Bond or guarantee. Only if one of the proportionality tests applies — and priced separately so you can see what it costs.
• Legal review. Your lawyer reviews the drafting. This checklist is the brief, not the clause.

Frequently asked questions

What is a service credit in an IT SLA?

A service credit is an agreed reduction in the fee when the provider misses a defined service target. It is calculated by a formula set in the contract — usually based on which priority was missed, by how much and how often — and normally appears as a deduction on a later invoice. It is a price adjustment, not compensation calculated from your actual loss.

Are service credits the same as a penalty?

Commercially, they are designed as something different: a pre-agreed adjustment to the price of a service delivered below the agreed level, rather than a punishment. Whether a particular credit clause operates the way either side intends depends on its drafting and the governing law, which is a question for your lawyer. This article does not express a view on the legal characterisation of any clause.

Can we deduct service credits from the invoice ourselves?

Only in the way your contract provides. Most credit regimes have the provider apply the credit to the next invoice. Some give the customer a defined right to deduct an agreed credit after notice and a dispute window. Withholding payment on your own reading of a report, without a clear contractual right, risks turning a service issue into a payment dispute. Agree the procedure before you need it.

What is a reasonable cap on service credits?

There is no single right figure, and we would be wary of anyone who quotes one as a market norm. A cap is reasonable if it is meaningful enough to change the provider's behaviour, not so large that one bad month makes your account unprofitable to serve, and linked to a non-financial trigger — remediation, escalation, and eventually termination — once it is reached.

Should we ask for a performance bond?

Ask for one if your switching costs are very high, you are making a large upfront investment, the provider's financial position is genuinely uncertain, or your own obligations to others depend on the service. For standard monthly managed IT support with a reasonable exit route, strong exit-assistance and documentation-ownership terms usually protect you better for much less cost. If you do ask, ask early and have it priced separately.

Who decides whether an SLA was missed?

The contract should decide, through definitions that both sides agreed in advance, applied to ticket data both sides can see. In practice the provider's system produces the report, so your protection lies in agreed P1 definitions, logged pause reasons, a reclassification rule, and access to the underlying ticket export so the numbers can be checked independently.

What if the provider disputes how a ticket was classified?

That is why the classification criteria for your business should be written into the contract, not left to on-shift judgement. A sensible rule lets the customer raise priority immediately, with any dispute resolved afterwards against the agreed criteria, and runs the SLA clock from the original report time at the corrected priority. Disputes that remain should go to the named escalation path, then to the quarterly review.

What should exit assistance cover?

A defined period of cooperation with your next provider, continued service at the agreed level until handover, delivery of all configurations, credentials, documentation and asset records in a usable form, a set number of knowledge-transfer sessions, and an agreed basis for charging for all of this — written down before the relationship ends, not negotiated during it.

From an enforceable SLA to a predictable budget

The group in our scenario did not really have a service-credit problem. It had a measurement problem, a coverage-hours problem and an exit problem, and service credits were the first tool it reached for because they are the easiest to describe in a procurement brief. Fix the definitions first, attach automatic consequences second, add a bond only where the failure it protects against is genuinely possible, and make sure leaving is practical — and the SLA becomes something that changes behaviour rather than something that decorates a report.

The other half of enforceability is predictability. A contract where every change, every site and every after-hours callout is priced separately is hard to hold to account, because you cannot tell whether a bad month was a service failure or a scope argument. Our per-user managed IT plan prices support per user per month in Hong Kong — from HK$855.14 on the Startup tier for 1–5 employees, HK$1,247.40 on Established for 5–300 employees and HK$1,561.21 on Growth for 10–500 employees, with Enterprise quoted to scope — billed monthly per user or per device, with discounted annual and multi-year terms. Every tier includes customer-owned documentation and credentials. You can compare what each tier covers on our pricing page.

If you are preparing a renewal brief and want a second view on how the measurement, credit and exit terms fit together, talk to our team. We will tell you what we would commit to, and where we think a different arrangement would serve you better.