What Should You Measure When Payment Is Reported as Late

한 줄 요약

지급 지연은 통짜 시간으로는 고칠 수 없고 구간으로 쪼개야 고칠 자리가 나오며, 평균은 꼬리를 감추므로 민원을 넣는 사람은 평균에 없다.

왜 이게 필요했나

"보험금 지급이 너무 느리다" 는 신고를 받습니다. 대시보드를 열면 평균 처리 시간이 4.8일로 찍혀 있고, 목표치인 7일 안에 들어옵니다. 지표상으로는 아무 문제가 없습니다.

그런데 민원은 계속 들어옵니다. 당연합니다. 민원을 넣는 사람은 평균에 해당하는 사람이 아닙니다. 그 사람은 25일째 기다리고 있는 쪽에 있고, 평균은 짧은 건이 많아서 낮은 것이지 긴 건이 없어서 낮은 것이 아닙니다.

어떻게 동작하나

청구는 이 단계를 지납니다.

접수 → 조사 → 심사 → 지급 / 부지급 → (이의)

접수는 고객이 서류를 낸 시점입니다. 조사는 사고가 실제로 있었는지, 약관 담보 범위인지 확인하는 단계로, 필요한 건만 갑니다. 병원 기록 확인이나 현장 조사가 여기 들어갑니다. 심사는 지급 여부와 금액을 정하는 단계이고, 지급 은 실제로 돈이 나가는 단계입니다.

지연을 잡으려면 이 단계 사이의 시간을 따로 재야 합니다. 통짜로 "접수부터 지급까지 20일" 이라고만 하면 고칠 자리가 없습니다. 쪼개서 "조사에서 18일" 이 나와야 조사 배정 규칙을 손보자는 말이 나옵니다.

그리고 평균 대신 백분위수를 봅니다.

평균     짧은 건이 끌어내린다. 목표 달성으로 보이게 만든다
p50      절반의 사람이 겪는 시간
p90      열에 하나가 겪는 시간. 민원이 여기서 나온다
p99      최악의 백 분의 하나. 언론과 감독기관이 여기를 본다

지연을 보고할 때는 지연이 시스템 때문인지 심사 때문인지를 갈라야 합니다. 접수에서 조사 배정까지가 길면 인력·배정 문제이고, 지급 결정에서 실제 이체까지가 길면 시스템·정산 주기 문제입니다. 이 구분 없이 "지급이 느립니다" 라고만 보고하면 고객사에서는 개발팀에 일을 던지고, 개발팀은 고칠 것이 없는 곳을 파게 됩니다.

부지급에는 사유 코드가 붙습니다. 면책기간 내 사고, 계약전 알릴의무 위반, 약관상 면책, 보장대상 아닌 진단 같은 것들입니다. 여기서 자주 나오는 오용이 하나 있습니다 — 서류 미비를 부지급 사유로 쓰는 것입니다. 서류가 모자라면 보완을 요청해야지 지급을 거절할 일이 아닙니다. 이렇게 처리된 건은 이의를 제기하면 거의 다 뒤집히고, 뒤집힌 부지급은 통계가 아니라 사고입니다. 고객은 받을 돈을 못 받은 채 몇 달을 보낸 것입니다.

지급이 늦으면 이자가 붙습니다. 표준약관에는 지급기일이 정해져 있고, 그날을 넘기면 넘긴 일수만큼 지연이자를 얹어 줘야 합니다. 한 건당 금액은 몇천 원 수준이라 작아 보이지만, 두 가지가 문제입니다. 전사로 모으면 액수가 커지고, 무엇보다 지연 건수 자체가 검사 지적 사항이 됩니다.

여기서 금액 계산에 관한 규칙이 하나 있습니다. 보험 금액은 처음부터 끝까지 정수 원으로 다룹니다. 실수로 계산하면 0.1 + 0.2 가 0.3 이 아니라는 이유로 대사가 1원씩 어긋나고, 그 1원의 원인을 찾는 데 며칠이 갑니다. 나눗셈이 필요하면 곱을 전부 먼저 하고 마지막에 한 번만 나눕니다.

현장에서 만나는 모습

첫째, 단계표와 원장이 안 맞는 일이 흔합니다. 단계 이력에는 심사가 끝났다고 찍혀 있는데 청구 원장에는 결정이 안 들어와 있는 건이 몇 건씩 남습니다. 그 고객들은 아무 통지도 못 받고 기다리고 있습니다. 같은 숫자를 두 곳에서 세어 보는 것이 이런 건을 찾는 가장 빠른 방법입니다.

둘째, 지연 보고서에 평균만 적어 보내면 아무 일도 일어나지 않습니다. 읽는 사람이 "문제 없네" 로 읽기 때문입니다. p90 과 p99 를 나란히 놓고, 그 시간이 어느 구간에서 나왔는지까지 적어야 다음 회의에서 결정이 납니다.

셋째, 부지급 사유 코드 분포는 뒤집힌 건수와 함께 봐야 의미가 생깁니다. 코드별 건수만 보면 고르게 퍼져 있어 정상으로 보이는데, 뒤집힘이 한 코드에 몰려 있으면 그것은 통계가 아니라 심사 규칙의 결함입니다.

청구 시스템에서 데이터가 어긋나는 자리

청구 흐름을 시스템으로 옮길 때 어려운 것은 규칙이 아니라 상태와 시간이다. 현장에서 반복해서 보는 세 가지가 있다.

같은 청구가 여러 번 들어온다. 앱에서 한 번, 팩스로 한 번, 지점에서 한 번 들어오는 일이 흔하다. 사람이 보면 같은 건인데 시스템은 별개로 받는다. 접수 단계에서 중복 후보를 묶어 보여 주는 화면이 없으면, 이중 지급이 지급 이후에 발견된다. 계약번호·사고일·상병코드·청구금액으로 후보를 잡고, 판단은 사람이 한다.

보완 요청이 상태를 되돌린다. 서류가 모자라 되돌려 보내면 청구는 심사 전 상태로 돌아간다. 이때 처리 기한을 어떻게 셀지가 정해져 있어야 한다. 멈춰야 하는지, 계속 가는지에 따라 지연 이자와 민원이 갈린다. 상태를 되돌리는 전이는 반드시 그 사유와 시각을 함께 남긴다.

금액은 여러 번 바뀐다. 청구액, 심사액, 결정액, 지급액이 다 다르고, 부지급· 일부지급·추가지급이 뒤에 붙는다. 하나의 금액 칸을 갱신하는 구조로 만들면 "왜 이 금액이 나왔는가" 에 답할 수 없다. 금액은 이력으로 쌓고 현재 값은 계산한다.

지급 실패를 흐름에 넣는다. 계좌가 잘못되어 이체가 반송되는 일이 늘 있다. 지급을 "끝" 으로 보면 이 건은 시스템에서 사라지고, 고객만 기다린다. 지급 이후에도 반송·재지급 상태가 있어야 한다.

심사 자동화는 거절이 아니라 통과에 먼저 쓴다. 명백히 지급해야 하는 소액 건을 자동으로 통과시키면 사람은 어려운 건에 집중할 수 있다. 반대로 자동 거절을 먼저 넣으면 틀렸을 때의 비용이 훨씬 크고, 그 판단이 왜 나왔는지 설명해야 하는 부담까지 진다.

다음 실습에서 할 것

청구 200건과 단계 이력을 만들고, 접수부터 지급까지를 네 구간으로 쪼갭니다. 평균 116시간 뒤에 숨어 있는 p90 389시간과 p99 609시간을 드러내고, 꼬리 17건의 시간 중 95%가 조사 구간에서 나왔다는 것을 숫자로 지목합니다. 부지급 30건의 사유 코드를 세어 뒤집힘이 한 코드에 몰려 있는 것을 찾고, 지연이자를 원 단위 정수로 계산합니다.