Keep Business Context Stable During an Incident
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
A common challenge I see in Incident Management is the tendency to change key fields—such as Service, Service Offering, or Business Impact—as an incident moves between support tiers. While reassignment and escalation are natural parts of resolution, changing business context mid-stream often creates confusion and weakens the value of incident data.
Where issues typically arise
In many environments:
Tier 1 sets a Service or Offering based on the customer’s experience
Tier 2 or Tier 3 updates those fields to reflect a deeper technical component
Infrastructure teams replace the Service with a CI or platform for routing purposes
Over time, the incident no longer represents the original business impact—it represents whoever last touched the record.
Why this causes problems
When business context changes during escalation:
Reporting becomes unreliable (counts by service, impact, or offering are skewed)
Ownership of the customer experience becomes unclear
Post-incident reviews focus on technical details instead of business outcomes
Trend analysis and problem identification lose accuracy
A more effective approach
Treat Service and Service Offering as stable context, not routing tools.
Set Service / Offering early to capture what the customer is affected by
Keep those values consistent throughout the incident lifecycle
Use Assignment Group changes to manage escalation
Engage infrastructure teams via reassignment, child tasks, or Problems
Capture technical details in CIs, work notes, or related records—not by overwriting business context
This allows multiple teams to collaborate without losing sight of the customer-facing impact.
How this aligns with mature practices
This approach aligns well with:
CSDM principles (separating customer context from technical delivery)
Experience-focused Incident Management
Reliable reporting and service health analytics
It also reduces the temptation to “game” fields just to force routing.
Key takeaway
Escalation should change who is working the issue, not what the issue represents. Keeping business context stable results in clearer communication, more trustworthy data, and better long-term insights.
Please give a Thumbs Up if you find Helpful!!
