This map is part of the service credit adjudication guide. The worked hard case walks through the decisions; this page shows where each record lives and what string ties it to the next.
Six systems, one credit decision
| System | Record it holds | Linking key it can carry | Usual owner |
|---|---|---|---|
| Status platform | Incident, timestamps, component status, subscriber notifications | Incident ID; component name | Site reliability lead |
| Incident review (wiki or document) | Which clusters, regions or tiers were affected, and why | Incident ID; cluster or region name | Engineering lead |
| CRM or contract repository | Order form, plan, tier, SLA version and effective date | Account ID; SLA version label | Revenue operations or legal operations |
| Helpdesk | Customer claim, timing, the approver's reply | Ticket number; account ID; sometimes the incident ID | Commercial operations head |
| Finance worksheet folder | Availability calculation and credit amount | Incident ID and account ID in the file name or header | Controller |
| Billing system | Credit note against a specific invoice | Invoice ID; customer ID; memo or metadata reference | Finance |
No single owner sees all six rows. That is why the commercial operations head, who touches the helpdesk and the approvals, is usually the best person to describe coverage.
The linking keys, and which way each one points
A key only helps if the record on one side stores the identifier of the record on the other. Direction matters: a ticket that quotes the incident ID joins in one step; an incident that knows nothing of tickets must be matched by date.
- Incident ID. Born on the status platform. Strong when engineers paste it into the incident review and support agents paste it into claim tickets.
- Component to account. The weakest join. A component is a service name, not a customer list, and partial outage on Statuspage means broken for a subset of customers without saying which. Component subscriptions offer a partial bridge: when an incident notification goes out, Statuspage notifies only the subscribers who follow the affected components. That subscriber list shows who was told, not who was hurt, but it narrows the search.
- Account ID to SLA version. Lives on the order form or a CRM contract field. It holds if the company records the version label and effective date rather than overwriting a single "SLA" field.
- Ticket number. Joins the claim to the approval when the approver replies on the ticket rather than by private email.
- Invoice ID and credit note reference. Stripe's credit note object stores the related invoice ID, a customer-facing memo and a metadata map for structured key-value data. Its reason field accepts only duplicate, fraudulent, order_change or product_unsatisfactory, so the SLA reasoning has to travel in the memo or metadata, for example a ticket number, or it does not travel at all.
Statuspage
StripeOne fully joined case (Illustrative)
Invented for this page. A 410-person HR software company runs an EU region and a US region. One afternoon its Payroll export component fails in the EU region for 95 minutes.
| Hop | From record | Key copied across | To record |
|---|---|---|---|
| 1 | Status incident INC-2291, "Payroll export" in partial outage | INC-2291 | Incident review: EU region only, US unaffected |
| 2 | Incident review | Region "EU" | CRM accounts on EU hosting, Business and Enterprise tiers |
| 3 | CRM account A-5520 | SLA label "v3, effective March 2024" | Order form with the v3 credit table |
| 4 | Customer email | Ticket 48817 quoting INC-2291 | Helpdesk ticket with claim and approval reply |
| 5 | Worksheet "INC-2291_A-5520" | Ticket 48817 | Credit amount approved by the controller |
| 6 | Credit note CN-0193 | Metadata ticket=48817; invoice INV-7720 | The next invoice, reduced by the credit |
Every hop has a key on both sides, so a reviewer can start at the credit note and walk back to the outage, or start at the incident and find every account that claimed. That two-way walk is what makes a credit history reconstructable rather than merely present.
Where the joins usually break, and the substitute record
| Break | Typical cause | Substitute record to ask about |
|---|---|---|
| Incident to affected accounts | No incident review, or reviews name services but not regions | Support queue spike for that window; subscriber notification list |
| Account to SLA version | Single CRM field overwritten at each renewal | Signed order forms in the contract repository |
| Claim to approval | Approver replied by private email or chat | Mailbox search by account and month |
| Approval to credit note | Credit note memo blank, no metadata | Controller's credit log; match by customer, date and amount |
| Older years | Previous billing or helpdesk tool | Archived exports and whether IDs were preserved |
A company that can name a substitute for each break still holds a usable history; it should simply say which years are fully joined and which are matched by date. Ticket-based SLA timers are a separate record type covered on the Jira Service Management export page, and the accounts receivable dispute resolution page shows a similar join problem on the receivables side. The workflow map template gives the company a blank version of this table.
Coverage questions to put to the commercial operations head
All answerable without exporting anything:
- Do claim tickets usually quote the incident ID, and since when?
- Are SLA versions stored with effective dates per account, or overwritten?
- Does the billing team put a ticket or incident reference in credit notes?
- How many credit notes a year, roughly, and how many claims were refused?
- Which years sit in a previous billing or helpdesk tool?
Why the joined version matters to AI developers is covered in what ground truth data is: a credit with its full chain is a checked outcome, not just a number. The 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 rights review decides what could be licensed and what needs de-identifying. Partners sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application. To write the introduction, use the service credit referral brief template.
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's credit notes can be walked back to their incidents, register as a partner, check the company against who qualifies, and read the program terms before you introduce the decision-maker.