Incident
A service disruption — severity, affected services, timeline, root cause, and resolution that tracks outages and issues.
Why This Object Matters for AI
AI incident prediction and auto-remediation depend on incident data; reliability improvement requires incident analysis.
Sales & Revenue Operations Capacity Profile
Typical CMC levels for sales & revenue operations in SaaS/Technology organizations.
CMC Dimension Scenarios
What each CMC level looks like specifically for Incident. Baseline level is highlighted.
Incidents exist only as war stories and Slack panic threads. When something breaks, people yell in a channel, fix it however they can, and move on. 'Remember that outage last March? What caused it?' 'I think it was a database thing — ask Dave, he was on call.' There's no incident record, no severity classification, and no post-mortem documentation. The same failures repeat because nobody captured what happened or why.
None — AI cannot analyze, classify, or learn from incidents because no incident records exist in any system. Pattern detection across outages is impossible.
Create a basic incident log — establish a shared spreadsheet or ticketing queue where every service disruption is recorded with a description, severity, affected services, timeline, and resolution summary.
Some incidents are documented but coverage is inconsistent. Major outages get a post-mortem doc; smaller disruptions go unrecorded. The post-mortem format varies — one is a detailed timeline with root cause analysis, another is a paragraph saying 'the database was slow, we restarted it.' Severity levels are subjective: what one engineer calls P1, another calls P3. There's a partial record but it's not reliable enough to analyze statistically.
AI can read the incident documentation that exists but cannot perform reliable trend analysis because coverage is incomplete and severity classifications are inconsistent. Pattern detection across incidents produces unreliable results.
Establish incident documentation standards — create a mandatory incident template with required fields for severity, affected services, timeline, root cause category, resolution steps, and follow-up action items.
Incidents are documented using a consistent template — severity, affected services, detection time, response timeline, root cause, resolution, and follow-up actions. The operations team files incident reports for every disruption above a defined threshold. The documentation is thorough and findable. But it's narrative prose — an AI agent can read incident reports but can't programmatically query 'show me all P1 incidents affecting the payment service in Q3 with database-related root causes.'
AI can search and read incident reports to answer questions about specific incidents. Can extract information from individual reports but cannot perform cross-incident statistical analysis because the documentation is human-readable narrative rather than structured, queryable records.
Make incident records machine-queryable — migrate from document-based post-mortems to a structured incident management system where every incident has typed, validated fields that support programmatic querying and aggregation.
Every incident is recorded in a structured incident management system with typed fields — severity level, affected service IDs, detection timestamp, resolution timestamp, root cause category, contributing factors, and remediation actions. Records are current, validated, and queryable. An operations manager can ask 'what is the mean time to resolution for P1 incidents in the authentication service over the last 6 months?' and get a precise, data-backed answer.
AI can query incident records programmatically, identify patterns across incidents, calculate reliability metrics (MTTR, MTTD, incident frequency), and predict which services are trending toward higher incident rates. Cannot yet model complex causal relationships between incidents because root cause categories are flat rather than hierarchical.
Formalize the incident model into a typed ontology — define incident types, causal relationship types (caused-by, contributed-to, mitigated-by), and severity frameworks so that incidents form a queryable causal graph rather than a flat table of records.
Incidents are modeled as a formal ontology with typed entities and causal relationships. Each incident links to affected services, triggering changes, contributing factors, and remediation actions through validated relationship types. An AI agent can traverse 'show me every incident caused by deployment failures in the last year, trace their contributing factors, and identify which preventive measures have been most effective' through the causal graph.
AI can autonomously analyze incident patterns through the causal graph, predict incident likelihood based on system changes, and recommend preventive measures grounded in historical remediation effectiveness. Human judgment is needed for organizational and process changes.
Implement self-documenting incident records — deploy systems that automatically capture incident timelines, affected services, and resolution steps from monitoring alerts, communication channels, and change logs without manual documentation effort.
Incidents are self-documenting. When a disruption occurs, the incident management system automatically constructs the timeline from monitoring alerts, captures affected services from the dependency graph, identifies the triggering change from the deployment pipeline, and drafts the root cause analysis from correlated signals. Engineers review and refine rather than author from scratch. The incident record builds itself as the response unfolds.
Can autonomously document, classify, and analyze incidents in real time, generating root cause hypotheses and remediation recommendations as the incident unfolds without waiting for post-mortem documentation.
Ceiling of the CMC framework for this dimension.
Other Objects in Sales & Revenue Operations
Related business objects in the same function area.
Infrastructure Resource
EntityA cloud or on-prem compute/storage resource — type, configuration, utilization, and cost that powers the platform.
Alert
EntityA triggered monitoring notification — condition, severity, affected service, and acknowledgment status.
Service
EntityA deployable component — dependencies, SLOs, owners, and health status that composes the platform architecture.
On-Call Schedule
EntityThe rotation for incident response — engineers, timing, escalation paths, and coverage.
SLA/SLO Definition
RuleA service level commitment — metric, target, measurement window, and consequences that defines reliability expectations.
Database
EntityA data storage system — type, schema, size, performance metrics, and backup status.
Log Entry
EntityA recorded system event — timestamp, service, level, message, and context that enables debugging and analysis.
What Can Your Organization Deploy?
Enter your context profile or request an assessment to see which capabilities your infrastructure supports.