Prompt and scope
A B2B SaaS has a regional outage during a billing month, and some customers miss an availability commitment. Design a service-credit policy covering measurement, eligibility, credit caps, claim windows, automatic issuance, disputes, and financial reconciliation. The test is whether product rules are understandable, provable by engineering, and executable by finance.
What the interviewer is testing
- Whether you turn SLA metrics, exclusions, and bill scope into a computable contract.
- Whether you separate affected service, region, subscription, plan, and customer-caused failures.
- Whether you balance transparent automation with review and abuse controls.
- Whether you measure recovery, cost, retention, and disputes instead of credit dollars alone.
Questions to clarify first
- Is the commitment monthly availability, latency, or both, and is the window UTC or customer-local time?
- Is the unit a service, region, tenant, or whole bill, and how are maintenance and third-party dependencies excluded?
- Is credit based on affected service fees, total subscription fees, or a fixed amount, and what is the cap?
- Must customers claim, or can systems identify eligibility from incident and billing data?
- How do contracts, tax, channel sales, and multi-currency billing reconcile?
A 30-second answer
I would make the SLA recomputable: service, region, window, denominator, exclusions, evidence, and billing base. An eligibility engine maps incident impact to subscriptions and produces a preview; caps, claim windows, and audit trails make exceptions bounded. Complete telemetry triggers automatic issuance, while missing evidence or contract ambiguity goes to review. The customer sees impact and progress on the status page, and billing posts an idempotent credit note. I would measure eligibility accuracy, handling time, disputes, recovery, and margin impact.
Step-by-step deep dive
Step 1: Define measurable SLA semantics
Fix probes, monitoring regions, service boundaries, and the monthly denominator. Publish exclusions for maintenance, customer configuration, uncontrollable third parties, and regional scope so the interpretation does not change after an incident.
Step 2: Map impact to subscriptions
The incident record stores affected service, region, start and end, evidence version, and recovery state. Eligibility calculates overlap by tenant, subscription item, and billing period; only affected covered items enter the credit, not the entire bill by default.
Step 3: Design calculation and caps
Use a segmented or tiered formula that maps the availability shortfall to affected service fees, with a period cap. Version the formula, rounding, tax, prior refunds, and exchange rate so a customer can recompute the result from the same inputs.
Step 4: Automate issuance with claim exceptions
Generate an eligibility preview and evidence summary. Issue automatically when completeness thresholds pass; route missing monitoring, unclear contract coverage, and channel billing to review. Publish a claim deadline and allow exceptions only when contract or law permits and evidence exists.
Step 5: Prevent duplication and abuse
Create a unique key per incident, subscription, and billing period so reruns cannot post twice. Keep incident version, calculation inputs, reviewer, and issuance state. Repeated claims, tenant duplicates, and channel conflicts enter risk review without silently rejecting genuine impact.
Step 6: Connect communication to recovery
The status page explains affected service, region, timeline, and recovery without promising a credit before eligibility is known. Confirmation sends calculation detail, expiry, and an appeal path. Support uses the incident ID and same rule version as billing.
Step 7: Reconcile finance and iterate
Credit notes must reconcile, reverse, and remain auditable across monthly, annual, channel, and multi-currency plans. Track accuracy, automation rate, confirmation time, disputes, duplicate credits, renewal, and margin. Use errors to update terms, monitoring, and data quality.
High-quality sample answer
I would fix service, region, UTC window, availability denominator, exclusions, and affected billing base first. The incident system records start, end, and evidence version; eligibility overlaps that event with tenant subscriptions and calculates only affected service fees using a versioned tier formula and period cap. Complete telemetry triggers automatic issuance, while missing data or contract exceptions enter review. An idempotency key per incident, subscription, and billing period prevents duplicate posting. Customers see impact on the status page, then receive calculation detail and an appeal path. Finance reconciles tax, exchange rate, channel, and reversal. I would monitor accuracy, confirmation time, disputes, duplicates, renewal, and margin and revise the policy from observed errors.
Common mistakes
- Giving one credit percentage without defining denominator, region, or exclusions.
- Crediting the whole bill and ignoring unaffected services or items.
- Rerunning an incident without an idempotency key and posting twice.
- Promising an amount before evidence, causing status, support, and billing drift.
- Tracking credit cost only and missing disputes, recovery, renewal, and trust.
Follow-up questions and responses
Is automatic issuance always better than claims?
Automation is more transparent when telemetry, subscription mapping, and contract data are complete. Missing data or complex channel contracts need a review queue. Both paths share one calculation version and audit record.
How do you calculate annual plans?
Use the contract’s monthly allocation or affected-service basis, recording allocation rule, billing period, and currency. Do not turn the annual total into a denominator after the incident.
What if a customer says an unmonitored workflow was affected?
Keep an appeal path and request logs, tenant region, and incident correlation evidence. The decision cites the same SLA version and records approval, denial, or missing-data reason.
How do you avoid encouraging exaggerated loss claims?
Prefer server-verifiable signals, cap repeated claims and period exposure, and route anomalies to review while ensuring genuine affected customers are not silently denied by risk controls.