How to Write a Credit and Remedy Table for an AI Service Outage

Definitions matter more than targets. Practitioners routinely conflate "response time" with "acknowledgement time" and with "resolution time," and vendors exploit the ambiguity (UnderDefense AI SOC SLA guide). A defensible schedule separates three obligations: how fast the provider acknowledges the ticket and begins triage, how fast it delivers a fix, workaround or documented next action, and what the customer receives if either fails (SupportGPT support SLA guide).

For an AI service outage, the acknowledgement clock should start when your ticket is submitted through the contractually named channel, not when the vendor's automated system creates an internal record. The support SLA literature is explicit that a receipt email is not active support and that the response clock should run until formal acknowledgement and active triage begin (SupportGPT). The resolution clock should start at the same moment and stop when the vendor restores the service or delivers an approved workaround, with defined pause rules for time spent waiting on information you owe them.

Severity tiers keep this honest. A critical incident (service down, no workaround) deserves a 15 minute acknowledgement and a 4 hour resolution target. A high incident (degraded throughput, workaround available) can justify 30 minutes and 8 hours. Low severity can run to the next business day. Write each tier as its own row with its own credit, because a single target applied to every ticket rewards the vendor for reclassifying your incident downward.

Assume your AI service is billed at $18,000 per month on a single line item. Your schedule sets a 15 minute acknowledgement target and a 4 hour resolution target for critical incidents. A missed acknowledgement earns 5 percent of the monthly line ($900). A missed resolution earns 15 percent ($2,700). Both are measured against the same invoice, per incident.

Now run a bad month. The service degrades at 09:00 on a Tuesday. Your team files a critical ticket at 09:04. The vendor first acknowledges at 10:12, which is 68 minutes after submission, so the acknowledgement target is missed. Service is restored at 16:40, which is 7 hours 36 minutes after submission, so the resolution target is missed too.

The stacking cap is doing real work in that table. Without it, the vendor's exposure for one incident is 20 percent of the month's fee, which is the same number here, but a second incident later in the month would push toward 40 percent and the vendor will simply refuse that in negotiation. A 20 percent per-incident cap and a 50 percent per-month cap are the kind of limits that appear in actual agreements (Law Insider).

The rework allowance is the line most buyers omit. Calculate it once, from your own ticket data: how many support hours your team spent on the incident, multiplied by a fully loaded hourly cost, plus any credits or refunds you had to issue to your own customers. If your team spent 20 hours at $75 fully loaded, that is $1,500, and add $500 of customer goodwill credits to reach the $2,000 figure above. The point is not the exact number. The point is that a 20 percent credit on an $18,000 invoice ($3,600) may be smaller than the all-in cost of the incident to you, which is why the credit should be a floor and not the ceiling.

That gap is the insight a flat credit hides. Service credits are designed to be a calibrated, pre-agreed remedy that avoids litigation over actual damages, which also means they are almost always smaller than the buyer's real loss (ContractKen). Treat the credit as partial compensation and negotiate the rest through the mechanisms in the next section.

A credit table that only lists percentages is a price list, not a remedy. Build it with these columns and fill every one for every severity tier.

The claim procedure deserves special attention because it is where most credits are lost. Vendors commonly require a written request within a short window, frequently 30 days from the incident, and customers who do not track incidents forfeit credits even when the breach is uncontested (ContractKen). Put a calendar reminder in your incident process on day one, not day twenty-nine.

The exit right is the remedy that actually changes behavior. Mature clauses include a chronic-failure termination right, for example two or more service level breaches in a rolling three month period, or any single outage exceeding a defined duration (ContractKen). Without it, a vendor can pay credits indefinitely and never fix the service.

Vague trigger language. "Best effort response" and "within one business day" cannot be measured and cannot be enforced (UnderDefense). Replace every qualitative phrase with a number and a clock.

Broad exclusions. Scheduled maintenance, emergency patches, customer-caused outages, force majeure, beta features and third-party network failures can swallow the remedy entirely if drafted broadly (ContractKen). Tighten each exclusion to events genuinely outside the vendor's control and cap the maintenance window allowance in hours per month.

Uptime-only thinking. An API can return a success status while the AI agent cites a source that does not exist or routes a task to the wrong tool (Wavect AI agent SLA template). Availability and output quality need separate metrics, because a fully available platform can still produce wrong answers (Adaptive Security SLA guide). Add at least one quality or accuracy trigger to the table alongside the two clocks.

Sole-remedy language without carve-outs. If you accept that credits are your only remedy for every failure, you give up the ability to terminate or claim for the failures that cause the most harm (ContractKen). Carve out data loss, security incidents and chronic failure.

No rework line. Without a documented rework allowance or a credit floor tied to your own cost data, the credit may not cover the internal effort the incident created.

Draft the table as a schedule, not as prose in the body of the agreement. A schedule is easier to update, easier to attach to an order form, and easier for both finance teams to reconcile. Reference it from the main agreement so the caps and the claim procedure inherit the contract's governing law and dispute terms.

Next, define the measurement method with the same care as the targets. Say who measures, from where, over what window, and using whose clock, because two parties measuring the same service from different vantage points will get different numbers (All Quiet). If the vendor's logs govern, require read-only access to the relevant incident records so you can verify the timestamps yourself.

Then negotiate the escalation ladder. A missed acknowledgement should page a named support manager. A missed resolution should trigger a written root cause analysis within a fixed number of business days. A second miss inside a rolling quarter should trigger the exit discussion. These are cheap concessions for a vendor that believes in its service and expensive ones for a vendor that does not.

Finally, test the table against a real month of your own history before you sign. Pull three incidents from the last year, apply the proposed thresholds and percentages, and see what the credits would have been. If the answer is a few hundred dollars against thousands of dollars of rework, the table is decoration. If you are running AI workloads across several providers and want one invoice line to anchor these calculations, Quanta Inference bills text, image, video, audio and embedding models through one API key, prepaid and priced in US dollars, which makes the monthly denominator simple to state at https://quantaintelligence.ai/inference.

Incident record template (copy into your ticketing system)

incident_id:
severity:              critical | high | medium | low
service_line:          the invoice line item the incident affects
ticket_submitted_at:   UTC timestamp, contractually named channel
vendor_ack_at:         UTC timestamp, first human triage action
service_restored_at:   UTC timestamp or approved workaround time
ack_target_minutes:    from the credit table
res_target_hours:      from the credit table
ack_credit_pct:        from the credit table
res_credit_pct:        from the credit table
monthly_line_usd:      from the invoice
rework_hours:          your team's hours on the incident
rework_cost_usd:       hours x fully loaded rate
customer_goodwill_usd: refunds or credits you issued
claim_deadline:        incident date + claim window
claim_submitted_at: