In BusinessChat, an Incident is a top-level work item category designed to manage widespread, systemic problems that impact multiple customers at once. Examples include a payment gateway outage, a product recall, or a widespread carrier shipping delay.
Incidents leverage the same foundational infrastructure as Tickets and Tasks—sharing custom fields, history, comments, and internal discussion tools—but feature distinct operational guardrails and a specialized data model to manage large-scale impact effectively.
1. Key Characteristics & The Many-to-Many Model
While Tasks and Tickets maintain a strict one-to-one mapping with a single customer contact, Incidents introduce unique, highly flexible behaviors:
Many-to-Many Contact Linkage: An Incident serves as the anchor entity. Multiple independent customer contacts can be attached directly to a single Incident, allowing your team to link hundreds of affected users to one root cause. Conversely, an incident can also be created with no linked contacts initially.
Independent of Tickets: Incidents do not exist in a parent-child relationship with Tickets. An individual customer’s Ticket and the global Incident affecting them remain independent, parallel objects in the database.
Strict Creation Roles: Because Incidents affect broad segments of your customer base, creating a net-new Incident from scratch is restricted. It can only be initiated by users with Admin or Owner roles directly from the Work Items landing page.
Inbox Restrictions: Regular team members cannot spin up an Incident directly from the inbox chat view. From the right side panel of a live conversation, users are only authorized to link an existing contact to an already active Incident.
2. Setting Up Incident Types & Fields
Admins configure specific Incident Types to standardize how major issues are logged and reviewed.
Mandatory Severity Levels: Unlike other categories, Severity applies strictly to Incidents. Every Incident must map to standardized severity tiers: Critical, High, Medium, or Low. Severity scales influence your system filters, reporting dashboards, and operational views, though they carry no implicit automation logic on their own.
Global Library Fields: Incidents utilize standard mandatory fields (Title and Description) and can pull any number of custom or reference fields from the global library. Admins have full control over the ordering and mandatory status of these fields per type.
SLA Configuration: Incidents are fully governed by a Time-to-Resolve (TTR) SLA clock, which is configured in hours based on your organization's business hours and time zone.
3. The 4-Stage Incident Lifecycle
Incidents share the unified structural infrastructure of the system but drop one key stage entirely : Incidents do not have a "Waiting on Customer" stage. Because your company entirely owns the accountability and resolution of a systemic outage, the lifecycle is concentrated across four distinct stages:
Submitted: The Incident is logged. The global Time-to-Resolve (TTR) clock begins ticking immediately.
In Progress: The engineering, operations, or triage teams are actively working on a fix. The SLA clock continues running. Any sub-statuses like "Waiting on 3rd Party Vendor" continue to run against your internal metrics.
Resolved: A terminal state indicating the systemic issue is fixed. The SLA clock stops.
Canceled: A terminal state indicating the incident report was invalidated or called off.
4. Ticket Promotion (Ticket → Incident)
When an agent handling an individual customer's Ticket suddenly realizes that the issue is not isolated but systemic, they can execute a one-click Promotion.
The Transformation: Pushing the promote action instantly flips the work item type from a Ticket to an Incident.
Data Continuity: The item retains its exact same UUID ID, audit log, internal discussion comments, and original creator team. The original customer contact is seamlessly preserved as the very first linked contact on the newly formed Incident.
Cross-Linking and Cross-Reference ID System: While your internal data model preserves background history, executing a promotion fundamentally opens a brand-new Incident record born from that Ticket. Crucially, the system assigns a new, dedicated Incident ID and `INC-` reference number to the case. The original source Ticket is automatically canceled by the system. To ensure visibility, the two records stay permanently cross-linked, and the promotion action automatically appears in the audit histories of both the original Ticket and the new Incident.
Configuration Switch: The promoting user simply selects a pre-configured Incident Type to instantly map the item to its new severity levels, custom fields, and specialized lifecycle statuses.
One-Way Constraint: The original Ticket ceases to exist as a Ticket—it is now the Incident. Pushing an Incident backward into a Ticket (or any other type conversion) is strictly unsupported by the system.
5. Bulk Customer Communications
To eliminate the manual burden of messaging hundreds of affected users individually, Incidents feature a dedicated Bulk Business Communications UI directly on the Incident details page.
Unified Messaging: Agents compose a single status update or announcement within the UI. The system automatically broadcasts it as a personalized message to the individual WhatsApp or chat conversation threads of every single contact linked to the Incident.
Dynamic Variables: The broadcast engine dynamically maps template variables (such as customer names or specific order numbers) to keep the outreach personalized.
Operational Usage: This mass-communication tool is designed to be used both mid-incident to push out critical progress updates and at final resolution time to deliver a unified closing note. It operates completely independently of standard single-Ticket notification rules.
6. Incident Reporting Metrics
Because Incidents carry an inherently higher operational cost, the reporting layer tracks several unique metrics to measure business impact:
Impact Size Tracking: Dashboards surface total Incident volume alongside your precise linked contact counts to visualize the exact scale of an outage.
Recurrence Patterns: The system tracks how frequently identical or related Incident configs break over distinct date windows to isolate chronic systemic vulnerabilities.
SLA Final State Reports: Every TTR breach event is logged discretely to outline your overall breach distribution across specific teams, owners, and severity profiles.
Incident Metrics Breakdown By Type: The system completely replaces legacy custom-field tracking with structural Type grouping. Because incident configurations match real operational triggers (such as *Carrier delay* or *Site outage*), grouping analytics by Type natively uncovers recurring systemic root causes without needing an extra "Root Cause" custom field.
Inverse Severity Verification: Dashboards explicitly measure median resolution times across severity levels. A healthy operational system should demonstrate an inverse relationship—Critical-severity issues must resolve fastest, while Low-severity issues resolve slowest. If Critical-tier resolution times climb, the reporting layer automatically fires warning alerts to flag failures in incident response capacity.
Team Effort Metric: The reporting layer tracks active owned time (effort hours) per team or individual user during incident response. This aggregates contiguous intervals where an incident was in an active In Progress state, allowing managers to see exactly which team carried the heavy operational load during an outage.
7. How to create a new Incident type
To create a new incident type, follow these steps:
From your profile icon, click on Settings
Choose Work Items> Items Types, and click Create.
From the new page, add an incident description, and the necessary fields from the dropdown and toggle on or off the mandatory status.
In the States section, Unlike Tickets, Incidents do not support a "Waiting on Customer" parent stage. Therefore, you must only configure sub-statuses under the remaining 4 pre-configured main statuses (Submitted, In Progress, Resolved, Canceled) and assign the relevant team for each status. To add a sub-status, click "Add state" under the relevant Status and choose from the dropdown.
Note: you can delete a sub-status, but you cannot delete a pre-configured Status.
From the SLA section, choose the time to resolve (exp:24H) and choose the SLA calendar from the pre-configured option or create your own.
To create your own SLA calendar, click "New Calendar" and fill in your team's shifts or SLAs.
Once you finish all the configuration, click Create
