This worked case is part of the service credit adjudication guide, which covers what to inventory before an SLA redesign. Here the job is one hard case, walked step by step, ending with how a SaaS finance advisor can recognize similar cases at a client.
The case: 140 minutes down, but only for Enterprise
Illustrative and invented for this page. A 260-person B2B software company sells three tiers: Starter, Business and Enterprise. Enterprise customers run on a dedicated cluster and sign an SLA promising 99.9% monthly uptime, with a 10% credit on the monthly fee when availability falls below that, down to 99.0%.
One weekday evening the Reporting API on the Enterprise cluster stops answering for 140 minutes. Starter and Business traffic, on the shared cluster, is untouched. The status page shows the Reporting API component in partial outage, which matches Atlassian's Statuspage definition of a component completely broken for a subset of customers. For those customers it was simply down.
AtlassianWhat went wrong is easy to state. What to do about it was not: whose SLA applies, how to measure downtime for a subset, and whether anyone owes a credit before a customer asks.
Step by step: who decided what, and which record shows it
| Step | Who acted | Decision or fact | Record that captured it |
|---|---|---|---|
| 1. Trigger | Site reliability on-call | Reporting API unavailable on the Enterprise cluster for 140 minutes | Status platform incident with start and end times |
| 2. Scope | Engineering lead | Outage limited to the dedicated Enterprise cluster; Starter and Business unaffected | Internal incident review naming the cluster |
| 3. Rule | Commercial operations head | Enterprise SLA version in force that month applies: 99.9% target, 10% credit band | Contract repository: SLA version with effective date |
| 4. Calculation | Finance analyst | (43,200 minus 140) divided by 43,200 for a 30-day month gives 99.68% | Availability worksheet saved with the incident ID |
| 5. Claim | One Enterprise customer | Requests a credit 12 days after the incident, inside the contract's claim window | Support ticket with the customer's email |
| 6. Approval | Commercial operations head, controller | Approve 10% of an $18,400 monthly fee | Approval reply on the ticket; controller sign-off |
| 7. Result | Billing team | A $1,840 credit against the next invoice, not a refund | Credit note linked to that invoice |
Read down the right-hand column and the history explains itself. Remove any one row and a reviewer can no longer tell why the amount is $1,840, or why other customers received nothing.
The three judgment calls in the case
Step 2, scope. The status page recorded a component, not a customer list. Somebody decided that only the Enterprise cluster was affected, and that decision lives in an incident review, not on the status platform. Without it, a later reader cannot tell whether Business customers were wrongly left out.
Step 3, rule. Enterprise customers signed different SLA versions over the years. The worksheet only makes sense against the version in force that month, which is why the main guide treats old SLA versions as inventory.
Step 5, claim. Many SLAs make credits claim-driven. AWS's compute SLA, for example, requires a request by the end of the second billing cycle after the incident and applies credits only against future payments, not as refunds. In this case only one Enterprise customer claimed. Whether the company credited the others proactively, and who decided not to, is a decision in its own right and should be visible in the record.
AWSStep 7 then follows mechanically. A credit note adjusts a finalized invoice without voiding it, as Stripe's documentation describes, so billing holds the amount and the invoice it reduced. It does not hold the reasoning from steps 2, 3 and 5.
StripeVariants of the same case that are just as useful
The approved claim is the tidy version. The variants often teach more, because they show the rule meeting resistance:
| Variant | What changes | Extra record that explains it |
|---|---|---|
| Late claim refused | Customer writes after the claim window | Refusal reply citing the window and SLA version |
| Partial approval | Customer claims 180 minutes; logs support 140 | Worksheet comparing customer and company timings |
| Goodwill credit outside the SLA | A Business customer complains and gets a credit anyway | Approval naming it goodwill, with the approver |
| Disputed scope | Customer says the outage reached the shared cluster | Engineering note or log extract settling the scope |
For AI developers, each variant is a rule applied to messy facts with a recorded outcome. The exception-handling guide explains why records like these are informative, and the B2B credit limit approval process and accounts payable exception handling pages show the same shape in other finance workflows.
Spotting a similar case at a SaaS client
A finance advisor can test for this history in one conversation, without opening a ticket or a worksheet:
- Tiers on separate infrastructure. Dedicated clusters or regions for top tiers make one-tier outages common.
- More than one SLA version. Ask when the SLA last changed and whether older customers kept the earlier terms.
- Claims arrive by ticket or email. If credits are claim-driven, refusals exist somewhere.
- Someone writes incident reviews. Ask who decides which customers an incident affected, and where that decision is written.
- Credit notes carry a pointer. Ask whether credits reference a ticket or incident ID, or only an amount. The cross-system map shows which keys make those joins work.
If most answers are yes, the company probably holds several years of cases like this one. The next question is who can authorize a conversation about them; the sign-off tree for these records answers that, usually through the commercial operations head to the CEO.
The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Customer contracts often make SLA terms and credit amounts confidential, so what could be licensed and what must be de-identified stays unknown until SourceX's rights review. Partners sign the Channel Partner Agreement before submitting introductions; the first valid introduction within the 90-day window is credited when the company submits a verified application. More SaaS workflows are on the software and SaaS page.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a SaaS client can follow a one-tier outage from incident to credit note, register as a partner, confirm the company against who qualifies, and read the program terms before you introduce its CFO.