SLA and Service Credit Management Software: Why Outage Minutes and Contract Clauses Never Meet

Why service credits leak money in both directions at once

The outage minutes are in your monitoring system. The commitment is in a PDF stored in a contracts folder, negotiated three years ago by someone who has since left, with a redlined exclusions clause that differs from your standard template. The credit is calculated by a service delivery manager, in Excel, on the afternoon the customer asks for it.

That arrangement fails in two directions simultaneously, which is why it survives so long. Customers who are organised and assertive claim credits, sometimes for events their own contract excludes, and get paid because arguing costs more than paying. Customers who are not organised never claim, and quietly conclude at renewal that the commitments in their contract were decorative. The first group costs you margin. The second group costs you the renewal, which is much more expensive, and you never see it coming because nobody logs an unclaimed credit.

There is no established product category here, which surprises people. Monitoring vendors measure availability but know nothing about your contracts. Contract lifecycle tools store the document but know nothing about your network. Ticketing systems record incidents but do not compute financial consequences. The join is a person with a spreadsheet, and at a certain contract count that person becomes both a bottleneck and a risk.

Problem 1: every contract defines availability differently, and you have not read them all recently

Two contracts both say 99.99 percent. One measures per circuit, the other per site with redundancy considered. One excludes scheduled maintenance in a defined window, the other excludes maintenance only if notified 10 business days ahead. One excludes customer premises power, the other is silent on it. One starts the clock at ticket creation, the other at first customer report, the other at fault detection by you.

Those differences change the number materially, and they are invisible unless someone reads the specific agreement. So in practice the service delivery manager applies the standard template's logic to a non standard contract, and either overpays or underpays, and nobody catches it because nobody else is going to read the PDF either.

What a custom build does: model the commitment, not the document. Metric type, measurement scope, calculation period, the exclusion set with their notification conditions, the clock start definition, the credit ladder, the cap, the claim window, and the chronic condition thresholds. Each contract becomes a configured instance of that model, entered once by someone who has actually read it. That entry exercise is itself valuable, and every operator we have done it with has found at least one clause they were not honouring and at least one they had been honouring more generously than required.

Problem 2: outage minutes are not the same as chargeable minutes

An event lasts 214 minutes wall clock. Of that, 40 minutes fell inside an approved maintenance window, 25 minutes were attributable to a customer caused condition at their site, and the remainder counts. Getting from raw event duration to chargeable duration requires the exclusion rules from problem one applied against real data about what happened and when.

Your monitoring system knows the state changes. Your ticketing system knows the cause code, the customer communications, and whether anyone recorded that the site had a power failure. Neither knows the contract. So the exclusion decision is a human reading a ticket and making a judgement, and that judgement is not recorded anywhere the customer can see, which is why credit conversations turn adversarial.

What a custom build does: correlate the monitoring state change with the ticket that covers it, apply the contract's exclusion rules automatically where the data supports it, and surface a reviewable derivation where it does not. Chargeable minutes are computed with every deduction itemised and attributed to a clause. Then the credit is not an opinion. It is arithmetic the customer can follow, and the argument moves from the total to the specific exclusion, which is a conversation you can win when you are right and should concede quickly when you are not.

Problem 3: credits are reactive, and reactive is the worst possible timing

Today, a credit conversation begins with a customer complaint, usually to their account manager, usually with frustration already attached. You then spend two days calculating, and by the time you respond the relationship damage is done regardless of the number.

Reverse it. When the event closes, the system computes the credit. If the contract entitles them to it, you issue it proactively on the next invoice with the derivation attached. The cost is the same money you would have paid anyway, minus the customers who never would have claimed, and that difference is real. But the return is that you are the provider who told them before they asked, which is worth more at renewal than the credit is worth on the invoice.

What a custom build does: credit determination runs automatically at event close and at period close, produces a pending credit with a review step, and routes to billing on approval. Where a contract requires the customer to claim within a window, the system tracks the window and flags an unclaimed entitlement so you make a deliberate choice rather than benefiting from their inattention by accident.

Problem 4: chronic conditions and termination rights are nobody's job to watch

Most serious enterprise contracts carry a chronic clause: repeated failures within a rolling window entitle the customer to terminate without penalty, sometimes with additional remedies. That clause is a business risk that lives entirely in a document, and nobody is watching the counter.

The first time most operators notice is when the customer's lawyer notices. By then you have lost the ability to intervene, which is the whole point of the clause existing.

What a custom build does: the chronic counter is a live field per contract, visible to the service delivery team, with escalation before the threshold rather than after. Two failures against a three failure threshold with four months left in the window is an operational emergency dressed as a metric, and it should be on a dashboard the account team sees weekly. This one capability has, in our experience, justified the whole build more than once.

Problem 5: performance reporting to customers is manual and therefore inconsistent

Enterprise customers expect monthly or quarterly service reports. Produced manually, they arrive late, look different depending on who made them, and often quietly omit a bad month. Customers notice, and inconsistent reporting reads as evasion even when it is just workload.

What a custom build does: generate the report from the same computed data that drives credits, on a schedule, in one format, whether the month was good or bad. Give large customers a portal if they will use one. The consistency is the point. A customer who receives the same honest report every month trusts the number in the month you need them to.

What a custom build costs and how long it takes

A focused first release covering the commitment model, contract configuration, event ingestion from your monitoring and ticketing systems, exclusion handling, and credit calculation with derivation runs $50,000 to $110,000 and ships in 10 to 14 weeks. This is one of the smaller builds in the enterprise operations category, mostly because the data sources already exist and the scope is genuinely containable. A full platform adding customer performance reporting and a portal, claim and dispute workflow, chronic condition tracking, multi service and multi site aggregation, and billing integration runs $130,000 to $300,000 phased over 5 to 10 months.

What drives cost up: the number of genuinely distinct contract shapes, since 300 contracts on four templates is straightforward and 300 bespoke agreements is a modelling exercise. The number of monitoring and ticketing sources, particularly after a merger. Multi service commitments where availability, latency, and repair time are measured differently and interact. And billing integration, which is usually the longest pole because credits have to land correctly on an invoice in a system that was not designed to receive them.

What keeps cost down: starting with your top 50 contracts by revenue and your standard template, and treating bespoke agreements as a second phase. Those 50 usually carry most of the exposure.

Build versus buy, and why buying is hard here

There is no dominant product for this, which is unusual and worth stating plainly rather than pretending otherwise. Some ITSM and monitoring platforms include SLA tracking, and they measure against a configured target reasonably well. What they do not do is model a negotiated commercial clause with its specific exclusions, clock definitions, credit ladder, cap, and claim window, then produce a defensible financial number. That gap is why this is nearly always a build.

Stay manual if you carry under about 30 enterprise contracts, they all sit on your standard template with no negotiated variations, and credit events are rare. A monitoring export and a careful spreadsheet is proportionate and you have better places to spend.

Build when two or more of these are true. You carry more than roughly 150 contracts with financially backed commitments. Your larger customers have negotiated bespoke terms and nobody currently reads them at credit time. You have paid a credit you did not owe, or discovered one you did. You cannot answer today how many contracts are close to a chronic threshold. Or your service reporting is produced by hand and arrives late often enough that customers have mentioned it.

How to choose a developer for SLA and credit management software

Ask them to model the commitment before you sign. Contract, service instance, commitment with metric type and measurement scope, exclusion rule with conditions, clock definition, credit ladder with caps, claim window, chronic threshold, event, chargeable duration derivation, and credit record. If they propose an uptime percentage field with a target, they have built a monitoring dashboard and you will still be calculating credits in Excel.

Ask how they will handle a contract amendment that changes terms mid term. Commitments need effective dating, because an event in March is judged against March's terms, not against today's.

Ask what they have integrated on the operations side. Pulling state changes from a network monitoring platform, correlating them to tickets in a system like ServiceNow or Jira Service Management, and posting a credit to a billing system are three separate problems. Ask for the named systems.

Ask who owns the code, in writing, before kickoff. You should own the repository, the infrastructure accounts, and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. This system produces numbers you will present to customers in commercial disputes, and the logic behind them should never sit inside someone else's product.