Zero new JIRA custom fields. Labels-only enrichment across 12 structured fields. 4 ITIL execution paths (Incident / Service Request / Problem / Change). Agent-assisted classification of 102 existing tickets. One pipeline from intake to closure.
Amazon Working Backwards: PR/FAQ
Business Case: BC2 Modern ITSM Operating Model Framework: ADLC v3.7.3 | Date: 2026-04-13 | Status: Plan Complete (18 stories), Implementation Pending Enterprise Team: 1 HITL Manager + ADLC Agent Team (PO + SRE + Observability) Foundation: 8 existing ITSM skills, 4 Confluence templates, 102 live OPS tickets
1. Press Release
Modern ITSM Operating Model: One Pipeline from Alert to Resolution — Zero Schema Migration Required
Labels-only enrichment turns an existing JIRA OPS board into a structured ITSM command centre with 4 execution paths, agent-assisted classification, and SLA enforcement — without adding a single custom field.
SYDNEY, AU — April 2026 — Today we announce the Modern ITSM Operating Model, a complete intake-to-closure pipeline built on the ADLC Framework and JIRA Service Management. The model transforms an existing OPS board of 102 operational tickets into a governed ITSM operation with four distinct execution paths — Incident, Service Request, Problem, and Change — using a labels-only enrichment approach that requires zero JIRA schema changes and zero JSM migration risk.
Enterprise operations teams face a paradox: ITSM frameworks like ITIL 4 promise structured service delivery, but traditional implementations require months of JSM customization, dozens of custom fields, and expensive consultants. Most attempts stall at the configuration phase — the team drowns in schema design before a single ticket is properly triaged. This model eliminates that bottleneck entirely by using JIRA's native label system as the enrichment layer, with AI agents handling classification decisions that would otherwise require a dedicated triage team.
The Problem
| Challenge | Impact | What Teams Actually Experience |
|---|---|---|
| Unclassified tickets | 60-80% of ops tickets lack consistent type assignment | SRE triages by gut feel; same issue type gets different treatment depending on who picks it up |
| No enrichment standard | Each responder adds different context in different formats | Quarterly reporting requires manual ticket-by-ticket review to extract blast radius, root cause, and service impact |
| Manual triage overhead | 15-30 minutes per ticket for proper classification and routing | 102 tickets at 20 min each = 34 hours of pure triage labor per backlog cycle |
| Schema migration fear | Custom fields require JSM admin changes that affect all projects | Teams avoid ITSM structure because "one wrong custom field breaks our workflows" |
| Disconnected execution paths | Incidents, problems, and changes follow the same generic workflow | P0 incident and low-priority service request compete for the same queue with the same SLA |
The Solution: Labels-Only ITSM on ADLC Framework
The Modern ITSM Operating Model is built on three design decisions that eliminate the traditional barriers to ITSM adoption:
| Design Decision | What | Why It Matters |
|---|---|---|
| Labels-only enrichment | 12 structured fields encoded as JIRA labels (e.g., blast:org-wide, rca:config, service:ec2) | Zero schema migration. Zero custom field creation. Instant JQL queryability. Reversible at any time. |
| 4 execution paths | Incident, Service Request, Problem, Change — each with distinct SLA targets and workflow transitions | A P0 incident gets a 15-minute response SLA. A service request gets 8 hours. Different urgency, different treatment. |
| Agent-assisted classification | AI agents classify tickets using a decision tree (service down? recurring pattern? requires change?) with human approval | 102 tickets classified in minutes instead of hours. Consistent taxonomy. Auditable decision trail. |
How It Works
- Intake: Ticket arrives on OPS board via any channel (manual, alert, automation, email)
- Classify: The
/itsm:classifycommand applies a 4-question decision tree — Is the service down? Is this a recurring pattern? Does it require a change? None of the above? — and assigns Incident, Problem, Change, or Service Request - Enrich: 12 labels are applied: blast radius, root cause category, known error status, affected service, environment, support tier, plus auto-generated IDs for traceability
- Prioritize: Impact and Urgency matrix determines Severity (P0-P3), which drives SLA timers automatically via JSM native configuration
- Route & Execute: Ticket enters the correct execution path with path-specific workflow transitions, escalation rules, and resolution documentation requirements
Leader Quote
"Every ITSM implementation I have seen fails at the same point: the schema design phase. Teams spend months debating custom fields, workflow states, and migration plans. By the time they finish configuring, the backlog has doubled. This model inverts that — start classifying tickets today using labels, prove the taxonomy works on real data, then decide if custom fields add value. Most teams find they never need them."
— HITL Manager, xOps Platform (50+ AWS Accounts)
Business Outcomes
| Outcome | Metric | Mechanism |
|---|---|---|
| Triage time reduction | From ~20 min/ticket (manual) to ~2 min/ticket (agent-assisted) | Decision tree classification + label auto-application |
| Classification consistency | From ad-hoc (no standard) to 100% taxonomy compliance | 6 label prefixes with defined value sets enforced by skill definitions |
| Reporting readiness | From manual quarterly review to real-time JQL dashboards | Every enrichment field is a native JIRA label — queryable instantly |
| Zero migration risk | 0 custom fields added, 0 workflow schema changes | Labels are additive — they cannot break existing JSM configuration |
| SLA differentiation | 4 distinct response/resolution targets (P0: 15min/4hr through P3: 8hr/72hr) | JSM native SLA policies bound to Severity field (already configured) |
Customer Quote
"We had 102 operational tickets sitting in a flat Kanban board with no consistent classification. After running the agent classification on the backlog, every ticket had a type, blast radius, root cause category, and service label. Our first JQL dashboard took 5 minutes to build because the data was already structured. No JSM admin changes. No migration plan. No consultant."
— Senior CloudOps Engineer, ANZ Enterprise Platform Team
Getting Started
Three steps: classify existing backlog (validate taxonomy on real tickets) to configure SLA policies (bind severity to response targets) to operationalize intake (new tickets enter the pipeline automatically). Full implementation plan: 18 stories across 6 requirements, available in the Agile Ceremonies methodology.
Availability
| Component | Status | Detail |
|---|---|---|
| 8 ITSM Skills (classification, enrichment, service catalog, change mgmt, PIR, runbook, known errors, dashboard) | Available | .claude/skills/product/operations/ |
| 4 Confluence Templates (change management, known errors, post-incident review, runbook) | Available | .claude/templates/confluence/itsm-*.md |
| OPS JIRA Board (102 tickets, 4 issue types) | Active | 1xops.atlassian.net/jira/software/c/projects/OPS/ |
/itsm:classify Command | Planned | Sprint implementation |
| Batch Reclassification Script | Planned | Sprint implementation |
| SLA Policy Configuration Guide | Planned | Sprint implementation |
Framework: adlc.oceansoft.io | Source: github.com/1xOps/adlc-framework
2. Frequently Asked Questions
Customer FAQs
Q1: What is the "labels-only" approach and why does it matter?
Traditional ITSM implementations require creating custom fields in JIRA — fields like "Blast Radius", "Root Cause Category", "Affected Service". Each custom field:
- Requires JSM admin access to create
- Appears on every ticket form in the project (cluttering the UI)
- Cannot be easily removed once tickets reference it
- Needs screen scheme configuration to display correctly
- Breaks if the project scheme changes
The labels-only approach encodes the same information as structured labels with defined prefixes:
| Instead of Custom Field | Use Label | Example |
|---|---|---|
| Blast Radius (dropdown) | blast:{scope} | blast:single-account |
| Root Cause (dropdown) | rca:{category} | rca:config |
| Known Error Status (dropdown) | ke:{status} | ke:workaround |
| Affected Service (dropdown) | service:{name} | service:ec2 |
| Environment (dropdown) | env:{environment} | env:production |
| Support Tier (dropdown) | tier:{level} | tier:tier-1 |
Labels are additive, queryable via JQL (labels = "blast:org-wide"), and cannot break existing workflows. The only custom field retained is Severity (customfield_10127) because JSM SLA timers require it — and it already exists.
Q2: How does agent-assisted classification work?
The /itsm:classify command applies a 4-step decision tree to each ticket:
| Step | Question | If Yes | If No |
|---|---|---|---|
| 1 | Is a service currently down or degraded? | Incident | Continue |
| 2 | Is this a recurring pattern across 3+ incidents? | Problem | Continue |
| 3 | Does this require infrastructure, config, or code change? | Change | Continue |
| 4 | Default | Service Request | — |
The agent reads the ticket summary and description, evaluates each condition, and proposes a classification with labels. The HITL reviews and approves. Classification decisions are logged for audit purposes.
For batch reclassification of existing tickets, the same decision tree runs across the full backlog with a summary report showing classification distribution before any changes are applied.
Q3: What are the 4 execution paths and how do SLAs differ?
- Incident
- Service Request
- Problem
- Change
Purpose: Restore service as quickly as possible.
| SLA | P0 | P1 | P2 | P3 |
|---|---|---|---|---|
| Response | 15 min | 1 hr | 4 hr | 8 hr |
| Resolution | 4 hr | 8 hr | 24 hr | 72 hr |
Workflow: Detect → Triage → Investigate → Resolve → Post-Incident Review
Purpose: Fulfill a standard operational request.
Follows catalog-based fulfillment. Lower urgency. SLA based on request type complexity.
Workflow: Submit → Classify → Fulfill → Verify → Close
Purpose: Identify and eliminate root cause of recurring incidents.
Linked to 3+ related incidents sharing the same service: and rca: labels. Known Error records track workarounds until permanent fix is deployed.
Workflow: Identify Pattern → Root Cause Analysis → Known Error Record → Permanent Fix → Close
Purpose: Manage infrastructure and configuration changes with appropriate risk assessment.
Three change types: Standard (pre-approved, low risk), Normal (CAB review required), Emergency (expedited approval for P0 incidents).
Workflow: Request → Risk Assessment → Approval (CAB/Pre-approved) → Implementation → Post-Implementation Review
Q4: Can this work with our existing JIRA project without disruption?
Yes. The design is explicitly non-disruptive:
- Zero custom fields added: Labels are metadata that coexist with any existing configuration
- Zero workflow changes required: Execution paths are documented process patterns — JSM automation rules are optional enhancements, not prerequisites
- Zero screen scheme modifications: Labels appear automatically on tickets; no form redesign needed
- Fully reversible: Labels can be removed at any time. No data migration. No rollback plan needed.
The only prerequisite is that the OPS project has the 4 ITIL issue types configured: Incident, Service Request, Problem, and Change. If the project already has these (as the current OPS board does with 102 tickets), the model is immediately applicable.
Q5: What does the enrichment schema look like on an actual ticket?
A classified and enriched Incident ticket would have these labels:
blast:single-account
rca:infrastructure
ke:not-applicable
service:ec2
env:production
tier:tier-1
rsid:OPS-42
pattern_id:ec2-20260413
Plus the built-in fields:
- Issue Type: Incident
- Severity: High (P1) — via Impact x Urgency matrix
- Priority: High — derived from Severity
Every label is immediately queryable. Example JQL for a P1 dashboard:
project = OPS
AND issuetype = Incident
AND labels = "blast:org-wide"
AND cf[10127] = "High"
ORDER BY created DESC
Internal FAQs
Q6: Why labels instead of custom fields? Is this a scaling limitation?
Labels scale better than custom fields for enrichment metadata because:
| Dimension | Custom Fields | Labels |
|---|---|---|
| Admin access required | JSM Admin | Any project member |
| Schema migration risk | High (affects all tickets) | None (additive only) |
| JQL queryability | cf[10127] = "value" | labels = "prefix:value" |
| Cross-project portability | Field must exist in target project | Labels work in any project |
| Removal/cleanup | Difficult (field persists in DB) | Trivial (remove label) |
| Autocomplete support | Yes (dropdown) | Yes (JIRA suggests recent labels) |
| Validation | Dropdown constrains values | Convention-based (SKILL.md defines valid values) |
The trade-off is that labels lack dropdown validation — a user could type blast:ogr-wide instead of blast:org-wide. The mitigation is agent-assisted classification, where the agent applies labels from the defined taxonomy and the HITL reviews. Manual label typos become a training issue, not a system design flaw.
For organizations that later want dropdown validation, the label taxonomy maps 1:1 to custom fields. Migration path: create custom field, run a script to copy label values into the field, remove labels. The labels-only approach is a stepping stone, not a ceiling.
Q7: How does this integrate with the existing ADLC Framework and xOps platform?
The ITSM Operating Model is the operations layer (OPS board) of the same platform that manages product development (SPM board):
| Dimension | SPM Board (Product Dev) | OPS Board (ITSM Operations) |
|---|---|---|
| Project | SPM | OPS |
| Methodology | Scrum (sprints) | Kanban (continuous flow) |
| Issue Types | Story, Epic, Task | Incident, Service Request, Problem, Change |
| Enrichment | INVEST scoring, story points | ITSM labels (blast, rca, ke, service, env, tier) |
| Bridge | pattern_id:{svc}-{date} label links OPS findings to SPM product stories | Same label on both boards |
The OPS-to-SPM bridge works via the pattern_id: label. When an operational pattern is identified across multiple incidents (e.g., recurring EC2 health check failures), the pattern is scrubbed of PII and converted into a product story on SPM. This ensures operational pain drives product roadmap decisions.
The 8 existing ITSM skills, 4 Confluence templates, and the runbooks CLI (122 commands for AWS automation) provide the execution tooling. The ITSM Operating Model is the orchestration layer that connects these existing components into a coherent pipeline.
Q8: What is the implementation effort and timeline?
| Phase | Stories | Effort | What Gets Delivered |
|---|---|---|---|
| Phase 1: Classify & Enrich | 6 P0 | 1 sprint | /itsm:classify command, batch reclassification of 102 tickets, enrichment schema validation |
| Phase 2: Route & Execute | 7 P1 | 1 sprint | 4 execution path documentation, SLA policy configuration guide, escalation rules |
| Phase 3: Automate & Scale | 5 P2 | 1-2 sprints | JSM automation rules (HITL-configured), dashboard templates, cross-validation with runbooks CLI |
Total: 18 stories across 3 phases. Phase 1 delivers immediate value (structured backlog). Phase 2 and 3 are incremental enhancements.
The FAANG incremental delivery approach means Phase 1 is validated on real tickets before Phase 2 begins. If the taxonomy needs adjustment, it is corrected on 102 real tickets — not on a theoretical model.
Q9: What compliance requirements does this address?
| Requirement | How the ITSM Model Addresses It |
|---|---|
| APRA CPS 234 (Information Security) | Incident classification provides audit trail; post-incident reviews are documented via Confluence template; blast radius labels demonstrate impact assessment |
| SOC 2 Type II (Change Management) | Change execution path includes risk assessment and CAB approval; all changes traceable via JIRA workflow transitions |
| ISO 27001 (Incident Management) | Structured incident response with defined SLA targets; known error records track workarounds; root cause analysis via Problem management |
| ITIL 4 (Service Management) | Four practice areas (Incident, Problem, Change, Service Request) mapped to JIRA issue types with consistent taxonomy |
The enrichment schema's rca: (root cause) and blast: (blast radius) labels directly map to the data points auditors request during compliance reviews. Instead of assembling this data manually per quarterly audit, it exists as structured metadata on every ticket from the moment of classification.
Q10: What are the risks and how are they mitigated?
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Label convention sprawl (inconsistent naming) | Medium | Medium | Documented taxonomy in Confluence; agent-assisted classification enforces valid values; SKILL.md defines the canonical set |
| Over-customization of JSM workflows | Low | High | Design principle: use JSM native defaults first. Custom automation rules are Phase 3 enhancements, not prerequisites |
| Enrichment accuracy depends on AWS/Azure profile availability | Medium | Low | Graceful degradation — tickets can be classified without cloud enrichment; cloud context is additive |
| False positives in agent classification | Medium | Low | HITL reviews every classification before approval; first 10 tickets manually validated to calibrate the decision tree |
| HITL bottleneck on change approvals | Low | Medium | Standard changes classified as pre-approved; only Normal and Emergency changes require explicit CAB review |
3. Implementation Roadmap
What Exists Today (As-Is)
| Asset | Status | Evidence |
|---|---|---|
| OPS JIRA Board | Active, 102 tickets, 4 issue types | 1xops.atlassian.net/jira/software/c/projects/OPS/ |
| 8 ITSM Skills | Published, v1.0.0 | .claude/skills/product/operations/itsm-* |
| 4 Confluence Templates | Published | .claude/templates/confluence/itsm-*.md |
| Severity Custom Field | Configured | customfield_10127 (JSM built-in) |
| SLA Policy | Configured | P0: 15min/4hr through P3: 8hr/72hr |
| 3 Label Conventions | In use | blast:, rca:, ke: — established in prior operations |
| runbooks CLI | Published on PyPI | 122 commands for AWS automation |
| OPS-SPM Bridge Pattern | Established | pattern_id: label for cross-board traceability |
What Will Be Built (To-Be)
| Deliverable | Stories | Priority |
|---|---|---|
/itsm:classify command (agent-assisted ticket classification) | 2 | P0 |
| Enrichment schema enforcement (12-field label taxonomy) | 2 | P0 |
| Batch reclassification of 102 existing tickets | 2 | P0 |
| 4 execution path documentation (Incident/SR/Problem/Change) | 4 | P1 |
| SLA configuration guide (bind Severity to response targets) | 1 | P1 |
| Escalation rules and on-call routing documentation | 2 | P1 |
| JSM automation rules for intake pipeline | 2 | P2 |
| JQL dashboard templates for ITSM reporting | 2 | P2 |
| Cross-validation with runbooks CLI for enrichment accuracy | 1 | P2 |
Success Criteria
| Metric | Target | Measurement |
|---|---|---|
| Tickets with consistent classification | 100% of new intake | JQL: project = OPS AND labels IS NOT EMPTY vs total |
| Average triage time | Under 5 minutes per ticket | Timestamp delta: ticket created to first label applied |
| Label taxonomy compliance | 100% (only valid prefix:value pairs) | JQL audit: labels matching blast:* against defined values |
| SLA breach rate | Under 5% | JSM SLA reports per execution path |
| Backlog classification coverage | 100% of 102 existing tickets | JQL: project = OPS AND labels IN (blast:*) count |
This PR/FAQ follows Amazon's Working Backwards methodology. The Press Release describes the intended outcome as if the product has already launched — this is standard Amazon practice for pre-approval artifacts, not a claim that the implementation is complete. The current state and planned work are documented in Section 3 (Implementation Roadmap). See also: xOps BC1 PR/FAQ | Agile Ceremonies