Service level agreement — turning service promises into numbers that hold up

What an SLA actually does

Every service contract contains a promise. Most state it in words that cannot be tested: the provider will render services “diligently”, “professionally”, “to industry standards”, with “best efforts”. When something goes wrong, the customer says the service was poor and the provider says it was not, and there is no way to decide who is right without an expensive argument.

A service level agreement replaces those words with numbers. It says the system will be available for a stated percentage of the time, measured in a stated way. It says a critical fault will be acknowledged within a stated number of minutes and fixed within a stated number of hours. It says the guard post will be manned around the clock, the lift restored within a stated time, the delivery made within a stated window. And it says what happens when the number is missed.

That does three things. It makes performance visible: each month, both sides can see whether the service met the standard. It makes remedies automatic: a missed standard produces a credit without anyone having to prove loss. And it makes failure actionable: repeated misses give the customer a right to leave, instead of a choice between tolerating poor service and litigating.

For a provider, a good SLA is equally valuable, because it defines the limits of what was promised. A provider whose SLA states its obligations precisely, with exclusions for things outside its control, is protected from the open-ended complaint that its service was simply “not good enough”.

Where SLAs are used

SLAs began in telecommunications and information technology, and those remain their home: hosting, cloud, software-as-a-service, managed IT, application support, network services and help desks. A SaaS subscription or software development agreement is incomplete without one.

But they are now used wherever a business depends on a continuing service. Facility management — housekeeping, security, maintenance of lifts, generators and air conditioning. Business process outsourcing — call centres, data entry, payroll, accounts. Logistics — pick-up windows, delivery times, damage rates. Annual maintenance contracts for equipment, where response and repair times are the whole point. Healthcare support — laboratory turnaround times, equipment uptime. Even professional services sometimes carry service levels for response and turnaround.

The drafting principles are the same across all of them: define the service, measure a few things that matter, attach consequences, and plan for the end. What differs is what is measured. An IT SLA measures availability and response; a housekeeping SLA measures staffing and audit scores; a logistics SLA measures on-time delivery and damage. Choosing the right measures for the business is more than half the work.

For a small business the same logic applies in a smaller form. A clinic buying billing software, a shop buying a point-of-sale system, an office hiring a security agency — each will be better served by a short SLA with a handful of measurable standards than by a long contract of generalities.

MSA, statement of work and SLA

In larger relationships the documents come in layers, and it helps to know which does what.

The master services agreement sets the legal terms that apply to everything: payment, confidentiality, intellectual property, liability, data protection, termination, dispute resolution. It changes rarely. Our service agreement and vendor agreement services cover such frameworks.

A statement of work describes a particular service or project under the master agreement: what will be delivered, when, by whom and at what price. There may be many.

The service level agreement sets the performance standards for the service, and the consequences of missing them. It may be a schedule to the master agreement, part of each statement of work, or a standalone document for a single service.

The layers must fit together. The most common drafting fault is an SLA that says credits are the sole remedy, sitting under a master agreement that preserves all remedies; or a master agreement with a liability cap that the SLA’s credits alone could exceed. The agreement should contain an order of precedence — which document prevails if they conflict — and the SLA should be read against the master agreement’s liability and termination clauses before either is signed.

Defining the service — and what it is not

No service level can be measured against a service that is not defined. The SLA should begin with a precise description of what the provider will do: the systems or sites covered, the hours of service, the functions supported, the number of users or locations, and the deliverables.

Equally important is what is out of scope. Is the customer’s own network covered, or only the provider’s? Are third-party applications the customer installs supported? Is support available on Sundays and public holidays, or only on working days? Are new sites covered automatically? Disputes very often turn on whether a failure fell within the service at all, and a clear boundary is the answer.

The SLA should also set out the customer’s obligations on which the service depends: access to premises and systems, timely approvals, accurate information, a named contact, adequate internet connectivity, and payment. Where the provider cannot meet a service level because the customer failed in one of these, the miss should not count against the provider — and the SLA should say how that is recorded.

Finally, the service description should be stable. Where the service is expected to change — more users, new locations, new modules — the SLA should refer to a change control procedure rather than rely on the original description stretching to cover things it never described.

Send us the contract — we will turn the promises into numbers

Choosing service levels that can be measured

The instinct is to measure everything. The better practice is to measure a small number of things that matter to the customer’s business, can be measured objectively, and are within the provider’s control.

For technology services the usual measures are availability of the system, response time to incidents, resolution time, and sometimes performance — page load time, transaction processing time. For operational services they might be staffing against the agreed roster, audit scores against a checklist, turnaround time for tasks, accuracy of data processing, or on-time delivery. Customer satisfaction scores are popular but subjective, and are better used for governance than for credits.

Each service level needs four things written down: the metric itself, defined precisely; the target; the measurement period — monthly is usual; and the data source — which tool, report or log is authoritative. A metric without all four will produce a dispute the first time it is missed.

Distinguish between critical service levels, which carry credits and count towards chronic failure, and key performance indicators, which are reported and reviewed but carry no financial consequence. That allows the parties to monitor many things while attaching money only to the few that justify it.

What to measure, service by service

The right measures depend on what the customer’s business actually loses when the service fails. The table gives typical starting points; the targets themselves are commercial choices.

Whatever the service, the discipline is the same: pick measures the business genuinely cares about, make sure each can be checked from a record both sides can see, and resist the temptation to add more measures than anyone will actually review.

What uptime percentages really allow

Availability is usually expressed as a percentage, and the differences between the percentages are much larger than they look. The table shows the downtime each level allows, calculated on a thirty-day month and a 365-day year.

A number on its own, however, means little. What matters is the definition of downtime. Is the system “down” only when it is completely unavailable, or also when it is so slow as to be unusable, or when a key function fails? Is availability measured every minute or every five minutes, from inside the provider’s network or from the customer’s locations? Is it measured over the whole month, or only during business hours?

Then there are the exclusions, which can hollow out any percentage: planned maintenance, emergency maintenance, failures of third-party networks, problems caused by the customer, and force majeure. Planned maintenance should be limited in duration and frequency, notified in advance, and scheduled outside business hours. An SLA promising 99.9% availability but excluding unlimited “maintenance” promises very little.

Severity levels, response and resolution

Not every fault is equally serious, and an SLA that treats them alike will either be too expensive for the provider or too weak for the customer. The usual solution is a severity matrix.

The actual times are commercial choices and differ by service. The SLA should define each severity by its effect on the business, not by technical cause, and should say who assigns severity — ideally the customer, with the provider able to challenge — because the assignment decides the clock.

Response and resolution should be defined separately. Response means an engineer has acknowledged the incident and started work, not that an automated email was sent. Resolution means the service is restored or a workaround acceptable to the customer is in place, with a permanent fix to follow. The SLA should say when the clock starts — on the customer’s report, or on the provider’s monitoring detecting the fault — and whether it pauses while waiting for the customer.

Measurement and reporting

A service level is only as useful as the evidence that it was met or missed. The SLA should say exactly how that evidence is produced.

Usually the provider measures, using its monitoring tools and ticketing system, and delivers a monthly service report within a set number of days after month end, showing performance against each service level, incidents, their severity and timings, and any credits due. The customer should have a right to access the underlying data, to use its own monitoring or logs as evidence, and to dispute the report within a stated period, with a procedure for resolving disagreements.

For operational services, measurement may involve audits — joint inspections against a checklist, attendance records, mystery visits — and the SLA should attach the checklist and say how often audits happen and who conducts them.

Two provisions prevent common disputes. First, a failure to report should itself have a consequence — for instance, the service level is treated as missed for that month — so that a provider cannot avoid credits by not measuring. Second, credits should be applied automatically on the next invoice once the report shows them due, without the customer having to make a separate claim, or at least with a simple claim procedure and a generous time limit.

Service credits

Service credits are the financial consequence of a missed service level: a reduction in the fee, usually expressed as a percentage of the monthly charge for the affected service, applied to the next invoice.

Credits are usually graded. Missing the availability target by a small margin earns a small credit; missing it by a large margin earns a larger one. For example, a provider might credit a small percentage of the monthly fee for availability just below target, more for availability well below it, and more again for a serious outage. Response and resolution failures may carry their own credits, per incident or per month.

Credits are almost always capped — commonly at a percentage of the monthly fee for the service — so that the provider’s exposure is predictable. The cap is a legitimate commercial term, but it should be realistic: a cap so low that credits are trivial gives the provider little reason to perform. Some SLAs add an earn-back mechanism, allowing the provider to recover credits by exceeding the service levels in later months; customers should treat earn-back with some caution, because it can neutralise the incentive credits are meant to create.

The SLA should say whether credits are the sole remedy for missed service levels. Providers want them to be. Customers usually accept that for ordinary misses, but should preserve their rights to terminate for chronic failure and to claim damages for serious failures, data breaches and wilful default.

Service credits and Section 74

In Indian law, a service credit is a sum named in a contract as payable on breach, and that brings it within Section 74 of the Indian Contract Act, 1872. Our NDA guide sets out the text of the section; the short point is that when a contract names a sum to be paid on breach, the injured party is entitled to reasonable compensation not exceeding that sum. The named amount is a ceiling, not an automatic entitlement.

Two Supreme Court decisions define how that works in practice. In Oil and Natural Gas Corporation v. Saw Pipes (2003), the Court upheld the recovery of pre-agreed liquidated damages for delay, holding that where the sum is a genuine pre-estimate of loss and it is difficult to prove the exact loss, the party need not prove actual loss in detail. In Kailash Nath Associates v. Delhi Development Authority (2015), the Court emphasised the other side: the sum named is the upper limit of what may be awarded; where loss is caused, reasonable compensation up to that limit is payable, and a genuine pre-estimate may be awarded where loss is difficult or impossible to prove; but where no loss at all is caused, the named sum cannot simply be recovered.

For SLAs this has three consequences. Credits should be proportionate — graded to the seriousness of the failure and capped — so that they read as a genuine pre-estimate rather than a punishment. The SLA can record that the parties consider credits a reasonable pre-estimate of the loss from reduced service, which is typically hard to quantify. And credits are often better framed as a price adjustment — the customer pays less because it received less service — which reflects what they are and reduces the scope for argument that they are a penalty.

None of this makes credits fragile. Graded, capped credits for measurable shortfalls in a service the customer paid for are exactly the kind of pre-agreed consequence the courts expect commercial parties to agree. What courts resist is the disproportionate sum, and a well-drafted SLA does not contain one.

Damages, caps and carve-outs

Credits deal with ordinary shortfalls. Serious failures — a prolonged outage, lost data, a security breach — can cause losses far beyond any credit, and the SLA and master agreement must decide who bears them.

The general law is Section 73 of the Contract Act: a party who suffers from a breach is entitled to compensation for loss which naturally arose in the usual course of things from the breach, or which the parties knew, when they made the contract, to be likely to result from it — but not for remote and indirect loss. Contracts then modify that position, and almost every service contract does so in two ways.

First, a cap on total liability, often expressed as the fees paid or payable over a period such as twelve months. Second, an exclusion of indirect and consequential loss, and often of lost profits, lost business and lost data. Providers need these to price the service; a small provider cannot accept unlimited liability for a customer’s business losses.

Customers should look carefully at the carve-outs — the categories to which the cap does not apply. The usual ones are breach of confidentiality, breach of data protection obligations, infringement of third-party intellectual property, death or personal injury caused by negligence, and fraud or wilful misconduct. Data breaches are the most important in modern contracts: the cost of notifying individuals, dealing with regulators and restoring systems can far exceed a year’s fees. Where a full carve-out is not agreed, a separate, higher cap for data protection breaches is a common compromise. The customer should also check that “lost data” is not excluded in a contract whose whole purpose is to hold its data.

Chronic failure and the right to leave

Service credits compensate for a bad month. They do not solve a bad provider. A provider that misses its service levels month after month, paying capped credits each time, may find that cheaper than fixing the problem — and a customer without an exit right is stuck with it for the rest of the term.

The answer is a chronic failure clause, which gives the customer a right to terminate the affected service, or the whole agreement, without penalty, when failures reach a defined pattern. Typical triggers are: missing a critical service level in a stated number of months within a rolling period; a single outage longer than a stated duration; credits reaching the cap in consecutive months; or a failure to meet a remediation plan.

The clause should say what termination for chronic failure brings with it: no early termination fee, refund of prepaid fees for the unused period, and the provider’s full exit and transition obligations. Some customers also negotiate a right to recover the reasonable extra cost of moving to a replacement provider.

Providers can reasonably ask for a remediation step first: on a defined level of failure, the provider must deliver a written remediation plan within a set time and implement it, and termination follows only if the plan fails. That gives a well-intentioned provider a chance to fix the problem, and gives the customer a documented basis for leaving if it does not.

Exclusions and customer dependencies

Every SLA excludes some failures from counting against the provider, and the list of exclusions is where a strong SLA can quietly become a weak one.

Reasonable exclusions are failures caused by the customer — its own systems, misuse, unauthorised changes, failure to follow instructions — and by events genuinely outside the provider’s control. Planned maintenance is a reasonable exclusion if it is limited in hours, notified in advance and scheduled at agreed times. Force majeure is reasonable if it is limited to real external events and does not include the provider’s own suppliers or staff shortages.

Exclusions to resist are the open-ended ones: “any failure of third-party networks or services”, where the third parties are the provider’s own subcontractors; “emergency maintenance” without limit; and “any event beyond the provider’s reasonable control” without a list.

For customer-caused failures, the SLA should use a relief event mechanism: the provider is relieved from the service level to the extent the customer’s failure caused the miss, provided it notified the customer promptly and did what it reasonably could. That is fairer to both sides than a blanket exclusion, and it produces a record of who caused what.

Subcontractors and back-to-back SLAs

Few providers deliver everything themselves. A SaaS provider runs on a cloud platform; a managed IT provider relies on telecom links and hardware vendors; a facility company may subcontract security or pest control. The customer’s SLA is only as strong as the provider’s arrangements with those subcontractors.

The SLA should state that the provider remains fully responsible for subcontractors’ performance as if it were its own, and that a subcontractor’s failure is not an excluded event. It should require the provider to name key subcontractors and to obtain the customer’s consent before changing them, particularly where they will handle the customer’s data.

Providers, for their part, should make their own supply contracts back-to-back with what they promise customers. A provider promising 99.9% availability on a platform whose own SLA offers 99.5%, with credits a fraction of what the provider must pay its customers, is carrying the difference itself. The same is true of data protection and security terms: a provider cannot give customers commitments on data location or breach notification that its own cloud or software suppliers do not give it.

Where data is processed by subcontractors, the customer’s data protection obligations extend down the chain, and the contract should say so.

Data protection and security

Where a service involves the customer’s data, the SLA must deal with how that data is protected, and Indian law now imposes specific obligations.

Under the Digital Personal Data Protection Act, 2023, a business that decides why and how personal data is processed is a data fiduciary, and it may engage a data processor to process personal data on its behalf only under a valid contract. The fiduciary remains responsible for compliance, including reasonable security safeguards to prevent a personal data breach, and for notifying breaches to the Data Protection Board and affected individuals in the manner prescribed. A service provider handling customer or employee data for a business is typically a processor, and the contract — the SLA or a separate data processing agreement — should cover the purpose of processing, security measures, confidentiality of staff, sub-processors, breach notification to the customer, assistance with the customer’s obligations, and deletion or return of data at the end. Our DPDP guide sets out the Act’s framework.

Separately, CERT-In’s directions of 2022 under the Information Technology Act require service providers, intermediaries, data centres and body corporates to report specified types of cyber incident to CERT-In within six hours of noticing them, and to maintain logs of their systems for a prescribed period. An SLA for IT services should require the provider to notify the customer of a security incident promptly — well within any period the customer itself must meet — and to cooperate with investigations.

Security itself should be specified, not assumed: encryption, access controls, vulnerability management, testing, and the right to see evidence such as recognised security certifications or audit reports.

Regulated customers: banks, insurers and others

Where the customer is regulated, the regulator often has its own requirements for outsourcing, and the SLA must meet them.

The Reserve Bank of India has issued directions on outsourcing by banks and other regulated entities, including specific directions on the outsourcing of information technology services, which require, among other things, due diligence on the provider, contracts with defined service levels, audit and inspection rights that extend to the regulator, business continuity arrangements, confidentiality and data protection, and controls on subcontracting. The securities and insurance regulators have their own frameworks. Payment system data is subject to RBI’s storage requirements.

A provider serving such customers will find these requirements reflected in the customer’s standard contract, and they are generally not negotiable, because the customer cannot contract out of its own regulator’s rules. What the provider can do is understand them, price them, and make sure its own subcontracts allow it to comply — in particular, the regulator’s right of inspection.

The details of these frameworks change, and the customer’s compliance team will usually specify what the contract must contain. Our role is to draft the SLA so that it meets those requirements and stays consistent with the rest of the contract.

Business continuity and disaster recovery

An SLA measures performance in normal times. Business continuity and disaster recovery provisions deal with the abnormal ones: a data centre fire, a regional power failure, a ransomware attack, a pandemic.

For technology services, two numbers matter. The recovery time objective is how long it will take to restore the service after a disaster. The recovery point objective is how much data may be lost, measured in time — for example, no more than the last hour’s transactions. The SLA should state both, describe the backup arrangements that support them — frequency, location, retention — and require the provider to test its disaster recovery plan periodically and share the results.

For operational services, continuity means having replacement staff, alternative sites or suppliers, and a plan for maintaining critical functions when normal operations are disrupted.

The SLA should also be clear on the relationship between business continuity and force majeure. A provider that has promised a disaster recovery capability should not be able to invoke force majeure for exactly the kind of event that capability was meant to handle. Force majeure excuses performance only to the extent the provider has implemented its continuity plan and still cannot perform.

Audit, governance and change control

A long-term service relationship needs structure beyond the monthly report. Three mechanisms provide it.

Governance: named relationship managers on each side, monthly or quarterly service review meetings to go through performance, incidents, risks and improvements, and an escalation path for problems that cannot be solved at that level. Minutes of service reviews are useful evidence if a dispute later arises.

Audit rights: the customer’s right, on reasonable notice and at reasonable intervals, to audit the provider’s compliance with the SLA — its measurement data, security controls, data handling and, where relevant, labour compliance — directly or through an independent auditor. Costs are usually borne by the customer unless the audit reveals a material failure.

Change control: a written procedure for changing the service, the service levels or the charges, with change requests, impact assessments, and signed approval before the change takes effect. Without it, services drift, the SLA ceases to describe what is actually being provided, and neither side can enforce it. The SLA should also provide for periodic review of service levels, so that targets can be raised as the service matures or adjusted if the business changes.

People: facility services and labour law

Where a service is delivered by people working at the customer’s premises — housekeeping, security guards, maintenance technicians, pantry staff, drivers — the SLA has a dimension that pure technology SLAs lack: the labour of the provider’s workers.

The law on contract labour makes the customer, as principal employer, answerable in certain circumstances for the wages and statutory dues of workers supplied by a contractor, if the contractor fails to pay. This framework, historically under the Contract Labour (Regulation and Abolition) Act, 1970, is being carried into the labour codes, and the registration, licensing and wage obligations should be checked under the law in force. Our contractor agreement service covers that side in detail.

A facility SLA should therefore require the provider to comply with all labour laws, pay wages on time and through bank transfer, deposit provident fund and employees’ state insurance contributions, maintain registers and produce evidence monthly, and indemnify the customer against claims. It should also cover staffing levels as a service level, background verification of staff, training, uniforms, and replacement of any worker the customer reasonably objects to.

Two further points. The SLA should state that the provider’s workers are not the customer’s employees, and the customer should avoid directing them in a way that suggests otherwise. And both sides usually agree a non-solicitation clause preventing the customer from hiring the provider’s staff directly during the contract.

Exit, transition and escrow

The end of a service contract is when the customer is most dependent on the provider and the provider has least incentive to help. Exit therefore has to be agreed at the start.

An exit plan should cover: transition assistance to the customer or a new provider for a stated period after termination, at stated rates; continuation of service during the transition on the same terms; return of data in a stated, usable format, not a proprietary one, within a stated time; certified deletion of the customer’s data afterwards, subject to legal retention obligations; transfer of documentation, configurations and knowledge; and cooperation with the incoming provider.

Where the customer depends on software it does not own, source code escrow protects it against the provider’s failure. The source code, with build instructions, is deposited with an independent escrow agent and updated with each release, and released to the customer on defined events — insolvency, cessation of business, or failure to support the software. Where the software was built for the customer and paid for, the better answer is usually ownership of the code, as our software development agreement service explains.

For operational services, exit means handing over keys, access cards, equipment, records, and completing statutory obligations to workers so that the customer inherits no liabilities.

Pricing, GST and TDS

The SLA should connect to the pricing, because credits reduce the price and changes to service levels may change it.

Charges may be fixed monthly fees, per-user or per-unit fees, time-and-materials rates, or combinations. The SLA should make clear which charges credits apply to — typically the fee for the affected service, not the whole contract — and how credits appear on invoices: as a line deduction or a credit note. That matters for GST, under which services are generally taxable, commonly at eighteen per cent for business services, and under which credit notes must follow the prescribed procedure to adjust tax already charged.

Customers paying for services must also deduct tax at source where the income-tax law requires it, at the rate applicable to the nature of the payment — fees for professional or technical services, or payments to contractors. Income-tax law was re-enacted with effect from April 2026, so section references have changed; a chartered accountant should confirm the current rules.

Long contracts should deal with price revision — annual escalation linked to an index or a fixed percentage — and with the effect on price of increases in statutory wages for labour-intensive services, which are a recurring source of dispute in facility contracts.

Disputes

SLA disputes are usually about facts — was the service down, for how long, whose fault — and the SLA’s measurement provisions will decide most of them. The rest need a process.

A good SLA provides a tiered procedure: first the relationship managers, then senior executives within a set time, then mediation, and finally arbitration under the Arbitration and Conciliation Act, 1996, with a named seat and a jointly appointed arbitrator, or the courts. Technical disputes about measurement can be referred to an independent expert whose decision is binding on that point, which is faster and cheaper than arbitration for questions of fact.

Where the dispute reaches court and qualifies as a commercial dispute under the Commercial Courts Act, 2015, a suit that does not seek urgent interim relief must be preceded by pre-institution mediation. The SLA should also state that the provider will continue to perform during a dispute, so that a disagreement about credits does not become an outage.

Before any of this, a clear written notice setting out the failures, with the service reports and logs, often resolves the matter; our legal notice service prepares one. Proceedings are for your advocate, engaged and paid by you directly; our find an advocate page can help.

Get an SLA that settles disputes before they start

An example: software for a clinic chain

A chain of six clinics in West Delhi is moving its appointments, billing and patient records to a cloud software provider. The provider’s standard terms promise “commercially reasonable efforts” to keep the service available.

The SLA negotiated instead defines availability as the ability of users at the clinics to log in and book appointments, measured every five minutes by the provider’s monitoring, during clinic hours from 7 am to 11 pm. The target is 99.5% in those hours. Planned maintenance is allowed only between midnight and 5 am with forty-eight hours’ notice. A critical incident — no clinic can book — must be responded to in fifteen minutes and resolved or worked around in two hours, around the clock.

Credits are graded from a small percentage of the monthly fee up to a cap, applied automatically on the next invoice. Missing the availability target in three months out of six, or any outage over eight hours, allows the chain to terminate without penalty. Because patient records are health data, a data processing schedule sets out security measures, restricts sub-processors, requires notification of any incident to the chain within a few hours, and provides for return of all records in a standard format and certified deletion at the end. The liability cap does not apply to data protection breaches, which carry a separate, higher cap. The provider accepted each point, because each was measurable and none was open-ended.

An example: facility management for an office

A company with a two-floor office in Gurugram engages a facility management provider for housekeeping, security, pantry and maintenance of air conditioning and power backup.

The SLA sets service levels in the terms that matter to the office: every security post manned at all times against the roster, with a credit per unmanned shift; housekeeping audits weekly against an attached checklist, with a minimum score; air-conditioning faults responded to within an hour and fixed within four during office hours; generator changeover within a stated number of seconds of a power cut, tested monthly. The provider’s supervisor submits attendance and audit records weekly.

The labour schedule requires wages to be paid by bank transfer by a fixed date, provident fund and state insurance deposited, registers maintained and copies shared monthly, background verification of every guard, and an indemnity for any claim by the provider’s workers. The company can ask for any worker to be replaced. Price revision for statutory wage increases is passed through at cost, with evidence; other increases are annual and capped.

Chronic failure — three months of audit scores below the minimum, or repeated unmanned posts — allows termination on short notice, with a thirty-day transition in which the provider hands over keys, records and equipment and settles all dues to its workers. Nothing in the SLA is unusual, but each point replaces an argument that would otherwise happen every month.

A two-page SLA for a small business

Not every SLA needs forty pages. A small business buying a service it depends on — billing software for a shop, a security agency for a warehouse, maintenance for a clinic’s equipment — can get most of the protection described on this page from a short schedule attached to the provider’s contract.

The short version has seven parts. A service description of a few lines, including hours of service. Three service levels at most — for software, availability during business hours and response and resolution for a critical fault; for a security agency, posts manned, replacement time and incident reporting. A sentence on how each is measured and a monthly report. A credit table with two or three steps and a cap. A chronic failure right to leave after repeated misses. A line on data: that it remains the customer’s, will be kept secure, and will be returned and deleted at the end. And a contact and escalation list with names and numbers.

Providers selling to small businesses often refuse to change their standard contracts. Even then, many will sign a short schedule of this kind, because it is limited and clear. If they will not, the schedule is still useful as a record of what was promised in the sales conversation, and as a checklist for choosing between providers.

If you are the provider

Providers sometimes treat an SLA as a concession extracted by customers. A well-drafted one is also the provider’s protection.

Promise what you can measure and deliver, not what sounds competitive. Define the service boundary and the customer’s dependencies precisely, so that failures caused by the customer do not count against you. Keep exclusions reasonable but real — planned maintenance, customer-caused failures, genuine force majeure. Cap credits at a level you can absorb, and make credits the sole remedy for ordinary misses, while accepting that serious failures will carry wider liability.

Make your subcontracts back-to-back with your customer commitments on availability, data protection and security. Invest in monitoring and reporting, because the party with the better data usually wins the argument about whether a service level was met. And keep a record of every relief event — each time the customer’s own failure caused a miss — notified at the time.

For small providers selling to larger customers, the customer’s standard SLA will often be the starting point. Read it against your actual capabilities and your suppliers’ terms before signing, and negotiate the cap, the carve-outs and the chronic failure triggers rather than the headline percentages.

Where SLAs go wrong

• No definition of downtime, so the percentage cannot be tested.
• Unlimited maintenance exclusions that hollow out the availability promise.
• Response time without resolution time, so an acknowledged fault can last for days.
• Provider-only measurement with no right for the customer to see data or dispute reports.
• Credits so small or so capped that they are cheaper than fixing the problem.
• Credits as sole remedy with no chronic failure right, so a poor provider cannot be left.
• Conflict between the SLA and the master agreement on remedies or liability.
• A liability cap that covers data breaches in a contract whose purpose is to hold data.
• No exit plan, so data and knowledge are held hostage at the end.
• No labour compliance terms in a facility contract, leaving the customer exposed as principal employer.

What we do, and what it costs

SLA drafting or review is ₹2,999 and ordinarily takes 2 – 4 days. We act for one side — customer or provider — and draft or review the SLA so that it fits the master agreement and the actual service.

Stamp duty is at actuals. Nothing is payable in advance. We do not give tax or regulatory compliance certification, and we do not test systems or audit providers. Arbitration and court proceedings are for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it.