5/7번째 챕터

15분

운영 화면에서 같은 결론 확인하기

대시보드에서 자동 처리와 사람 검토의 분포를 읽고 한 청구의 판단을 팀 전체 현황과 연결합니다.

이번 단계의 질문

청구 한 건에서 발견한 판단을 운영팀 전체의 처리 현황과 어떻게 연결할까요?

왜 지금 필요한가

한 건의 ESCALATED 결정은 담당자 한 명의 다음 행동을 정합니다. 운영팀은 여기에 더해 전체 청구 중 자동 처리와 사람 검토가 어떻게 나뉘는지, 어떤 이유가 반복되는지 확인해야 합니다.

대시보드에서 해 봅니다

claims_processing(별칭: 청구 처리 대시보드)을 엽니다. 먼저 세 가지 질문에만 집중하세요.

Claims Received에서 접수된 청구가 10건인지 확인합니다.
Decision Distribution에서 APPROVED 4건, REJECTED 1건, ESCALATED 5건인지 확인합니다.
Escalations by Reason에서 confidence 0.52 below threshold 0.6을 찾습니다.

깊이 보기 — 위젯 8종 전체

Claims Received (statistic) — 접수된 청구 10건
Decisions Made (statistic) — 결정이 기록된 청구 10건
Avg Extraction Confidence (statistic) — 원시 평균 0.845
SLA Met Rate (statistic) — sla_met이 참인 비율 100%
Decision Distribution (도넛) — 승인 4건, 거부 1건, 에스컬레이션 5건
Escalations by Reason (막대) — 결정 사유별 건수
Claims by Channel (막대) — email 4건, portal 4건, fax 2건
Recent Claims (데이터 테이블) — 최근 접수 순서의 청구 최대 100건

이 화면이 나오면 성공

Decision Distribution에서는 사람 검토가 필요한 ESCALATED가 가장 큰 그룹으로 보입니다. Escalations by Reason에서는 지금까지 따라온 CLM-2025-006의 낮은 confidence 사유를 다시 찾을 수 있습니다.

결과를 읽어 봅니다

대시보드는 새로운 결정을 만들지 않습니다. extracted_fields와 decision_log에 남은 결과를 운영 질문에 맞춰 다시 묶어 보여 줍니다. 한 청구에서 시작한 판단이 팀의 처리 분포에 어디에 놓이는지 확인하는 화면입니다.

깊이 보기 — 데모 위젯을 해석할 때의 한계

Escalations by Reason의 현재 쿼리는 이름과 달리 ESCALATED만 거르지 않고 모든 결정의 reason을 집계합니다. 에스컬레이션 사유만 보려면 쿼리에 WHERE decision = 'ESCALATED' 조건이 필요합니다.

또한 claim_adjudicator는 모든 행의 sla_met를 true로 기록합니다. SLA Met Rate의 100%는 실제 처리 시간을 계산한 결과가 아니며, 에스컬레이션 비율과 SLA 사이의 인과를 설명하지도 않습니다.

다음 판단

한 청구의 판단이 팀 전체 처리 현황에서 어디에 놓이는지 확인했습니다. 이제 마지막 설명에 필요한 값의 출처와 자동화 경계를 네 문항으로 점검합니다. 그다음 처음의 운영 문제로 돌아가 해결 흐름을 한 번에 정리합니다.