Skip to content
Beta

Support

Last updated on

This module defines how operational support works after migration. It clarifies who handles incidents, which service requests are provider-managed, and which requests remain customer-managed.

The objective is a transparent, testable support model with predictable escalation behavior.

  • Incident ownership: Which teams lead initial analysis, mitigation, and permanent resolution for each incident category?
  • Service request ownership: Which requests are fulfilled by provider operations and which by customer teams?
  • Escalation paths: How are severity levels, response targets, and communication channels enforced?
  • Evidence and traceability: How are requests, decisions, and response quality documented?
  1. Define support scope boundaries and service catalog expectations.
  2. Build incident classification and escalation matrix with response objectives.
  3. Separate provider-responsible and customer-responsible service request types.
  4. Establish ticket, communication, and governance interfaces between all teams.
  5. Validate model quality through incident drills and request handling simulations.
  6. Run support model in production and tune it using measured outcomes.

Incident model

Severity scheme, ownership matrix, escalation chain, and communication rules.

Service request model

Service catalog with fulfillment ownership, lead times, and approval boundaries.

Operating evidence

Support KPIs, review cadence, and continuous improvement backlog.

At STACKIT, support covers multiple topic areas that should be visible to all Run stakeholders:

For the complete support model and contact details, see Support .

  • The support model depends on accepted role transfer in Operating Model Handover.
  • Stable service run and change discipline are covered in Operate.
  • Optional adoption orchestration and stakeholder alignment are covered in Customer Success.