Report affected accounts for a major incident

Report a major incident through a reviewed incident-to-account relation. Keep ticket count, distinct linked accounts and confirmed affected accounts as separate measures. This gives service leaders a traceable communication list without turning repeated contacts into repeated customers or assuming silence means no impact.

Incident linkage is a practical source pattern: Atlassian's feature documentation describes linking support requests to major incidents. The reporting method below still depends on the quality and completeness of each organization's links and impact evidence.

Define the incident and observation boundary

Use one incident record for the reviewed operational event, a ticket-to-incident relation and an incident-to-account relation. At the account layer, one row represents one account's impact evidence for that incident at the cutoff.

Inputs include incident key, service scope, recorded start and end evidence, ticket key, account mapping, linkage source, impact status, impact evidence time, communication status and snapshot time zone. Record whether the population comes from tickets alone or also from reviewed service telemetry and account-service mappings.

The customer service leadership questions identify which accounts and incident categories warrant attention. This method supplies the underlying relation rather than adding another general KPI list.

Classify evidence before counting accounts

Use approved statuses such as confirmed affected, linked but impact unconfirmed, reviewed not affected and account identity unknown. The labels describe the evidence available at the snapshot. A ticket mentioning the event is not automatically confirmation that its account experienced the relevant service failure.

If one ticket links to multiple incidents, retain the many-to-many relation with reasons. Do not duplicate ticket totals across incidents and then add them into an undifferentiated portfolio count. If several account aliases refer to one customer, resolve them through a reviewed identity map before deduplicating.

Preserve accounts with no support ticket when independent reviewed evidence places them in scope. Conversely, never claim coverage of the entire installed base from a ticket-only report.

DEMO: reconcile contacts and impact evidence

These counts are synthetic for one incident at October 6, 2026, 5:00 p.m. Eastern. Labels A, B and C are fictional groups, not actual customers.

Eight tickets reconcile to seven linked to three identifiable accounts plus one unmapped ticket. There are two confirmed affected accounts, one identifiable account awaiting impact review and one ticket whose account remains unknown. Eight contacts do not become eight affected accounts.

The decision is to prepare communication review for the two confirmed accounts, investigate C's evidence and resolve the unmapped ticket. The report cannot say that only two accounts were affected across the whole customer base; its observed population is explicitly limited.

Add a communication view without inflating impact

At the incident-account grain, record last reviewed communication evidence, assigned relationship owner and next check. Several messages to one account should not increase the affected-account count. A delivered message is also different from an acknowledged message; retain only statuses the source supports.

Keep sensitive ticket text out of broadly distributed summaries. Review access to underlying evidence and use account keys or approved display names according to the audience. The purpose is to coordinate a factual operational response, not publish unrestricted incident details.

Keep contact intensity and service commitments distinct

Use contact volume against an account's baseline to examine unusual demand around an event. That analysis measures contacts, not all impacted users or the incident's technical duration.

Evaluate any ticket obligations through SLA attainment per account. Availability commitments, remedies and technical impact require their own evidence and approved interpretation. A closed incident does not by itself prove every linked request is resolved or every customer's service has recovered.

Validate before a leadership review

Reconcile source incident counts, relation counts and distinct account counts. Sample repeated contacts, multiple incident links and missing identities. Preserve previous snapshots if an incident's affected population changes after investigation.

Contact Covirage with the intended service scope and available linkage fields to discuss a bounded review. A useful first output is a dated account-impact table with explicit evidence statuses and a defensible observed-population statement.