支払いが遅いという報告で何を測るべきか

一言でいうと

支払い遅延は、ひとまとめの時間では直せず、区間に分けてはじめて直す場所が出てきます。平均はテールを隠すので、苦情を入れる人は平均にはいません。

なぜ必要なのか

「保険金の支払いが遅すぎる」という問い合わせを受けます。ダッシュボードを開くと平均処理時間は4.8日で、目標値の7日以内に収まっています。指標上は何も問題がありません。

それでも苦情は入り続けます。当然です。苦情を入れる人は平均に当たる人ではありません。その人は25日目も待っている側にいて、平均は短い案件が多いから低いのであって、長い案件がないから低いのではありません。

どう動くのか

請求は次の段階を通ります。

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

受付は、顧客が書類を出した時点です。調査は、事故が実際にあったか、約款の保障範囲かを確認する段階で、必要な案件だけが進みます。病院記録の確認や現地調査がここに入ります。審査は、支払いの可否と金額を決める段階で、支払いは、実際にお金が出る段階です。

遅延を捉えるには、この段階の間の時間を別々に測らなければなりません。ひとまとめに「受付から支払いまで20日」としか言わなければ、直す場所がありません。分けて「調査で18日」と出てはじめて、調査の割り当てルールを見直そうという話になります。

そして平均の代わりにパーセンタイルを見ます。

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

遅延を報告するときは、遅延がシステムのせいなのか審査のせいなのかを分けなければなりません。受付から調査の割り当てまでが長ければ人員・割り当ての問題で、支払い決定から実際の振込までが長ければシステム・精算周期の問題です。この区別なしに「支払いが遅いです」とだけ報告すると、顧客企業は開発チームに仕事を投げ、開発チームは直すものがない場所を掘ることになります。

不支払いには理由コードが付きます。免責期間内の事故、契約前告知義務違反、約款上の免責、保障対象外の診断などです。ここでよく出る誤用が1つあります。書類不備を不支払いの理由に使うことです。書類が足りなければ補完を依頼すべきで、支払いを拒否する場面ではありません。このように処理された案件は、異議を申し立てるとほとんどが覆り、覆った不支払いは統計ではなく事故です。顧客は受け取るべきお金を受け取れないまま、何か月も過ごしたのです。

支払いが遅れると利息が付きます。標準約款には支払期日が決まっていて、その日を過ぎると、過ぎた日数分の遅延利息を上乗せして支払わなければなりません。1件あたりの金額は数千ウォン程度で小さく見えますが、問題は2つです。全社で集計すると金額が大きくなること、そして何よりも遅延件数そのものが検査での指摘事項になることです。

ここで金額の計算に関するルールが1つあります。保険金額は最初から最後まで整数のウォンで扱います。実数で計算すると、0.1 + 0.2が0.3にならないという理由で突合が1ウォンずつずれ、その1ウォンの原因を探すのに何日もかかります。割り算が必要なら、掛け算をすべて先に行い、最後に1回だけ割ります。

現場での姿

1つ目に、段階表と元帳が合わないことはよくあります。段階履歴には審査が終わったと記録されているのに、請求元帳には決定が入っていない案件が数件ずつ残ります。その顧客たちは何の通知も受けられずに待っています。同じ数字を2か所で数えてみるのが、こうした案件を見つける最も速い方法です。

2つ目に、遅延レポートに平均だけを書いて送っても何も起きません。読む人が「問題なし」と読むからです。p90とp99を並べ、その時間がどの区間から出たのかまで書いてはじめて、次の会議で決定が下ります。

3つ目に、不支払い理由コードの分布は、覆った件数と一緒に見てはじめて意味が生まれます。コード別の件数だけを見ると均等に広がっていて正常に見えますが、覆りが1つのコードに集中していれば、それは統計ではなく審査ルールの欠陥です。

請求システムでデータがずれる場所

請求の流れをシステムに移すときに難しいのは、ルールではなく状態と時間です。現場で繰り返し目にするものが3つあります。

同じ請求が何度も入ってきます。アプリで1回、FAXで1回、支店で1回と入ってくることがよくあります。人が見れば同じ案件なのに、システムは別々に受け付けます。受付の段階で重複候補をまとめて見せる画面がなければ、二重支払いが支払いのあとで見つかります。契約番号・事故日・傷病コード・請求金額で候補を絞り、判断は人が行います。

補完依頼が状態を戻します。書類が足りずに差し戻すと、請求は審査前の状態に戻ります。このとき処理期限をどう数えるかが決まっていなければなりません。止めるのか、進め続けるのかによって、遅延利息と苦情が分かれます。状態を戻す遷移は、必ずその理由と時刻を一緒に残します。

金額は何度も変わります。請求額、審査額、決定額、支払額がすべて違い、不支払い・一部支払い・追加支払いがあとに付きます。1つの金額欄を更新する構造にすると、「なぜこの金額になったのか」に答えられません。金額は履歴として積み、現在の値は計算します。

支払いの失敗を流れに入れます。口座が間違っていて振込が返戻されることは、常にあります。支払いを「終わり」とみなすと、この案件はシステムから消え、顧客だけが待つことになります。支払いのあとにも、返戻・再支払いの状態が必要です。

審査の自動化は、拒否ではなく通過に先に使います。明らかに支払うべき少額の案件を自動で通過させれば、人は難しい案件に集中できます。逆に自動拒否を先に入れると、間違ったときのコストがはるかに大きく、その判断がなぜ出たのかを説明する負担まで負います。

次のラボですること

請求200件と段階履歴を作り、受付から支払いまでを4つの区間に分けます。平均116時間の裏に隠れているp90の389時間とp99の609時間を明らかにし、テール17件の時間のうち95%が調査区間から出たことを数字で指し示します。不支払い30件の理由コードを数えて、覆りが1つのコードに集中していることを見つけ、遅延利息をウォン単位の整数で計算します。