Skip to main content

analyze-a-support-backlog

Measure a support backlog, identify customer and operational risk, and produce a capacity-aware recovery plan. Use when ticket age, volume, reassignment, reopen rates, or missed commitments are increasing.

소스 정보

저장소
protosphinx/sphinxstack
최근 소스 활동
2026년 7월 29일 13:55
감지된 SKILL.md 언어
영어
스타
3
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
analyze-a-support-backlog
category
data
description
Measure a support backlog, identify customer and operational risk, and produce a capacity-aware recovery plan. Use when ticket age, volume, reassignment, reopen rates, or missed commitments are increasing.
# analyze-a-support-backlog Explain what is accumulating, why it is stuck, and which recovery actions reduce harm without hiding demand. Keep new inflow, historical backlog, and data-quality problems separate. ## Inputs - Export a dated queue snapshot with status history, priority, channel, product, customer segment, owner, and timestamps. - Gather service-level definitions, staffing hours, arrival and completion rates, incident history, and known migrations. - Document exclusions, missing fields, merged cases, spam rules, and clock behavior. ## Procedure 1. Define backlog, age, first response, active work, waiting state, resolution, reopen, and breach precisely. 2. Reconcile the snapshot to the support system totals and quantify missing or invalid records. 3. Split new inflow from carried backlog and chart age distribution rather than only the average. 4. Segment by impact, reason, channel, product, customer state, owner, reassignment, and reopen history. 5. Identify blocked dependencies, missing ownership, automation loops, duplicate demand, and policy bottlenecks. 6. Compare arrival and sustainable completion capacity with uncertainty and seasonality noted. 7. Model recovery options such as dedicated sweeps, routing repair, product fixes, deflection, or temporary staffing. 8. Rank actions by customer harm reduced, effort, risk, owner, and time to observable effect. 9. Create a daily recovery dashboard with inflow, outflow, age bands, breaches, and quality guardrails. 10. Set exit criteria and a follow-up review to confirm the backlog did not merely change labels. ## Boundaries Do not bulk-close, redate, suppress, or merge tickets to improve the chart. Protect private customer content and avoid publishing agent rankings without appropriate context and permission. Do not treat reduced ticket volume as success if access to support or reporting quality worsened. ## Done - The report reconciles to a dated source snapshot and states data limitations - Backlog size, age, inflow, outflow, and risk segments are computed and checked - The recovery plan names actions, owners, capacity assumptions, guardrails, and exit criteria - Follow-up evidence can distinguish real resolution from relabeling or suppressed demand
GitHub에서 보기