4
Active recurring problem patterns
Service Improvement
Reduce repeat incidents by treating patterns as managed problems.
The problem review surface is now route-native in `apps/web`, turning recurring pain into visible improvement work instead of leaving that continuous-improvement view in the legacy bridge.
2
Problems with named action owner
3
Automation or runbook candidates
-22%
Target drop in repeat-incident load
Recurring Problem Register
These are the issue patterns worth treating as problems, not just individual incident closures.
| Problem Pattern | Evidence | Likely Root Cause | Owner / Next Move |
|---|---|---|---|
| Remote access latency recurs during peak morning load | Shared timing, same gateway path, repeat vendor escalation | External dependency plus weak pre-staged diagnostics | Infrastructure lead: expand runbook and tighten vendor packet |
| Public data refresh posts late after upstream anomalies | Manual validation and unclear handoff ownership | Weak pre-check discipline and split ownership | Data owner: assign a single accountable owner |
| Access onboarding delays tied to missing approvals | Requests arrive without named approver or business role confirmation | Intake quality and approval readiness gap | Service desk lead: require approver before routing |
| Teams workspace cleanup requests reopen after closure | Ownership standards not sustained after cleanup work | Governance guidance exists but reinforcement is weak | Collaboration owner: convert cleanup into managed standards |