Review analytics vendor support expectations for unavailable reports, incorrect results and delayed data, distinguishing incident response, restoration and final resolution.
Review an analytics support SLA by defining what happens when the reporting cannot be used. Separate an initial response from restoring a usable report and correcting the underlying issue. State service hours, incident severity, clock boundaries and the components covered. An acknowledgment is not a resolution, and an available page does not prove that its figures are correct or current.
The vendor evaluation guide covers overall supplier selection. This article owns purchasing support expectations, rather than calculating your operational customers' ticket attainment.
Name the output and decision affected. A report unavailable before a scheduled review can have a different consequence from a cosmetic issue. A wrong revenue definition, a failed input or unauthorized access also needs a different investigation than an unreachable page.
Agree severity from observable impact, not simply the user's frustration. State who can classify an incident and how disputed severity is handled. Identify customer dependencies such as providing an authorized corrected input or an approved definition.
Do not treat every issue as supplier fault by default. The important purchasing question is how it is diagnosed, communicated and returned to the correct owner without losing visibility.
| Milestone | What to define | What it does not establish |
|---|---|---|
| First response | Acknowledgment or useful initial action | Usable reporting restored |
| Restoration | Agreed output usable, possibly by workaround | Permanent cause corrected |
| Resolution | Agreed corrective work completed | Every unrelated issue eliminated |
| Update | Status and next action communicated | A completed milestone by itself |
Specify the support channel, service hours and information the reporter supplies. Explain when the clock begins, pauses and ends. If a workaround counts as restoration, define the output and limitations that make it acceptable.
DEMO-SUPPORT-01 uses invented targets and a Monday-through-Friday 09:00–17:00 UTC calendar, with no holidays in the example. An incident is reported Friday at 16:00. A four-business-hour restoration target ends Monday at 12:00: one hour on Friday plus three on Monday.
The supplier responds Friday at 16:30 and restores the agreed output Monday at 11:00. Response takes thirty minutes. Restoration takes three business hours: one on Friday and two on Monday. The restoration meets the invented four-hour target, even though much more wall-clock time has elapsed.
State the calendar and timezone with the result. Do not assume that business hours mean the reporter's local hours. The SLA version guide explains why the effective agreement and target matter when reporting performance.
DEMO-AVAIL-01 is a separate synthetic example. Its agreed measurement period includes every minute of a thirty-day month, with no exclusions. That is 30 × 24 × 60 = 43,200 minutes.
With ninety unavailable minutes, availability is (43,200 − 90) ÷ 43,200 × 100 = 99.792%, rounded to three decimal places. An invented 99.9% target would allow 43.2 unavailable minutes, so this result fails that target.
This calculation is meaningful only for the stated denominator and outage definition. If the agreement has maintenance exclusions or a narrower service window, use its rules and show the change. Do not reuse an availability percentage as evidence of correct calculations or up-to-date inputs.
Ask which components the supplier operates and which the customer controls. A missed source delivery can require customer action even while the dashboard remains reachable. Record how the service marks stale or incomplete results and how the incident is escalated.
Review recovery separately using the backup and restoration guide. A support response target does not prove a recoverable dataset or tested restore process.
Require actual proposed terms and evidence before describing a target as guaranteed. Keep excluded cases and untested requirements visible; a narrow support agreement should not become a claim about every reliability or security control.
Inspect the synthetic customer-growth review example, then contact Covirage with the review timing and incident expectations that matter to your team. Agree the proposed review and support scope, including the evidence required for its operating responsibilities.
No. Define acknowledgment, investigation, usable restoration and final correction separately in the proposed agreement.
No. Availability describes an agreed reachable service. Correctness, freshness and analytical usefulness need their own requirements and evidence.
No. They are invented examples to explain support-clock arithmetic. Obtain the actual proposed service terms.