Classify before assigning
Capture the affected capability, first observed time, account scope, market or asset, interface, request identifier, and whether the customer can reproduce the issue. Do not collect private keys, passwords, seed phrases, or unnecessary financial data.
A matching active incident should route to an incident-linked queue. Account-specific authorization, balance, identity, or security issues need restricted handling even when a wider incident exists.
- Availability incident
- Delayed data
- Rejected action
- Account-specific state
- Security concern
- How-to question
Use one verified status source
Store the incident identifier and public status URL on related cases. Agents should summarize the current verified update rather than inventing a root cause or recovery time. When the incident update changes, notify affected cases through a controlled template that includes the timestamp.
Do not close cases merely because the public incident is resolved. Confirm whether the customer's original action completed, failed, or remains unknown.
Preserve a useful escalation package
Engineering needs reproducible evidence, not a forwarded conversation. Create an escalation record with sanitized request IDs, timestamps, client version, route, response category, and user-visible impact. Deduplicate reports against the incident while retaining the count and affected segments.
After recovery, classify reopened cases and unresolved account states separately from general availability.
- Incident link
- Sanitized evidence
- Affected cohort
- Latest customer update
- Resolution state
- Follow-up owner
Referenced resources
- Novrinex support
The public support destination used as a concrete routing example.
- Novrinex status
The platform status destination that support can use for verified incident communication.
Submit one incident-related case and one account-specific security case with similar symptoms, then confirm the first joins the incident queue while the second retains restricted handling.