AMS incident triage
Illustrative use case, not a case study.
Incoming tickets are classified, safe diagnostics collected, similar incidents retrieved, and a runbook suggested before an engineer acts.
The problem
Tickets arrive with partial descriptions, get assigned to the wrong queue, and bounce before anyone looks at the logs. Our experienced people spend their day re-diagnosing problems that someone solved last month.
How it works today
A user raises a ticket in the service desk. A first-line analyst reads it, asks for screenshots or details, and assigns it based on the words in the subject line. The assigned engineer gathers logs, searches old tickets by memory, and works out the fix. Knowledge is captured inconsistently, if at all.
See the scenario
Illustrative workflow. Subtitled.
Transcript
- Tickets arrive half described, land in the wrong queue, and bounce. Experienced people spend the day re-diagnosing problems someone solved last month.
- Triage classifies the ticket, collects the diagnostics the team agreed are safe, retrieves similar incidents, and suggests the runbook and the right group.
- An engineer receives the enriched ticket and decides on any remediation. Triage prepares; it never acts on production.
- Measured on routing accuracy, resolution time, and recurrence. Illustrative use case. Let us discuss yours.
Proposed workflow
- Classify the ticket against the application and incident taxonomy
- Collect the diagnostics the support team has agreed are safe to gather automatically
- Retrieve similar past incidents and their resolutions
- Suggest the matching runbook and the likely assignment group
- Hand the enriched ticket to an engineer who decides on and performs any remediation
Where a person stays in control
- A person authorizes and performs any remediation; triage only prepares
- Diagnostic collection is limited to the agreed read-only set
- Runbook suggestions are reviewed and corrected so routing improves over time
Platform mappings indicate environments in which to assess this idea. Actual implementation depends on configuration, licenses, APIs, data, and permissions. Benefits are stated qualitatively; numeric claims require a documented baseline.