保険業務プラットフォームでは、毎日多くの商品検索、見積依頼、見積提示、申込操作が発生します。ページ閲覧やボタンのクリックが増えると、活発に使われているように見えます。しかし、それによって完了した業務も増えているのでしょうか。
総保険料が減少したときには、さまざまな説明が挙がります。流入が減った、見積提示が遅い、商品が合っていない、申込手続きに問題がある。どれもあり得る説明ですが、何から確認すべきかは簡単には決まりません。
指標体系は、この曖昧な問題を分解するためのものです。まず業務の成果を確認し、次にプロセスに沿って変化の場所を絞り込み、最後に原因の仮説と取るべき行動につなげます。
この記事では、保険業務プラットフォーム上の一件の業務を追いながら、問題を説明できる指標体系を組み立てます。対象は主にプラットフォームのプロダクト運営と見積・申込プロセスです。保険会社全体の経営、支払余力、担当者の業績評価には、別の分析枠組みが必要です。
1. 指標を選ぶ前に、業務の目的を決める
指標を並べる前に、三つの問いを置きます。最終的にどのような成果を生みたいのか。利用者はどの段階を通るのか。何が業務の完了を妨げるのか。
この場面では、指標を相互につながる三つの層に整理できます。
| 層 | 答えたい問い | 主な指標 |
|---|---|---|
| 業務の成果 | 有効な業務が最終的にどれだけ完了したか | 発行済み証券数、総保険料、一件当たり保険料 |
| プロセスの効率 | どの段階で進み、どこで止まるか | 各段階の転換率、待ち時間、完了までの時間 |
| 利用と品質 | 誰が使い、操作を円滑に完了できるか | 機能利用者数、アクティブ率・継続率、失敗率、エラー理由 |
チャネル、商品、利用環境、証券発行の方式、利用者区分は、指標を分解するための切り口です。例えば「モバイルWeb」は切り口であり、「モバイルWebでの申込送信成功率」が具体的な指標になります。
三つの層は一緒に見る必要があります。総保険料だけでは、成果の変化は分かっても、どこで変化したかは分かりません。クリック数だけでは、操作は分かっても、有効な業務につながったかは分かりません。
ダッシュボードでは、少数の成果指標を先に置き、プロセスと品質の指標で説明するとよいでしょう。指標同士の関係と、読む順番が明確になります。
2. 一つの業務フローで、分散したページをつなぐ
いったんページ名から離れ、一件の業務が始まりから終わりまでに何を経験するかを見ます。
これは分析のための基本フローです。実際のサービスでは、一部の段階を省略したり、担当者とのやり取り、資料の追加、支払いなどが入ったりします。最終的な「証券発行成功」をどのシステム上の状態で判定するかは、実際の業務に確認する必要があります。画面名だけで判断してはいけません。
操作が発生しても、業務が完了したとは限らない
同じ段階でも、少なくとも三つの状態を区別できます。
| 状態 | 例 | 答えられる問い |
|---|---|---|
| 操作の意図 | 「保険を申し込む」をクリック | 続けようとしたか |
| 操作の完了 | バックエンドが申込送信の成功を確認 | 送信が実際に完了したか |
| 業務の成果 | 合意した証券発行成功の状態に到達 | 有効な業務につながったか |
これらは置き換えられません。利用者が何度もクリックすることも、クリック後に入力チェックで失敗することもあります。送信が成功しても、その後の処理が続いている場合があります。
クリックは操作の分析、送信結果は操作完了率の分析、最終的な業務状態は成果の集計に使います。証券数や保険料は、対応する業務記録から取得します。
画面の経路が違っても、比較する段階をそろえる
PC向けWebとモバイルWeb、通常の見積依頼と事前の取り決めに基づく発行経路、新規と継続では、画面や入口が異なることがあります。クリック経路ごとに独立したファネルを作ると、比較しにくいレポートが増えてしまいます。
まず共通する業務の段階を定義し、具体的な経路を対応付ける方が理解しやすくなります。
| 実際の経路 | 分析時の扱い |
|---|---|
| 通常の商品見積依頼・よく使う商品からの入口 | 入口の違いを残し、見積依頼の送信成功を共通の段階として確認 |
| 見積依頼のコピー | 元の業務と新しいフローを区別。同じフロー内の変更・再試行は別に記録 |
| 事前の取り決めに基づく証券発行 | 経路の識別情報を残し、実際に通る段階を確認 |
| 新規・継続 | 業務区分を分け、それぞれの段階間の転換を分析 |
| 手動見積・自動見積 | 見積方式を分け、成功率と待ち時間を比較 |
この対応付けは、「どの業務区分が、同じ段階で異なる動きをしているか」を確認するためのものです。
ある経路が特定の段階を通らないなら、その段階を含むファネルをそのまま当てはめません。両方が通る段階で比較するか、経路を分けて表示します。
3. フローに沿って、各指標を説明する
各段階では、利用者の目的、完了の判定、変化があったときに次に確認することを整理します。
1. 商品検索：必要な入口を見つけられるか
まず、機能が利用されているかを確認します。
- 操作回数：ページ閲覧とボタンクリックを別々に集計します。素材ではどちらもPVとして扱われていても、指標名を明確に分けます。
- 利用者数（UV）：操作した利用者を重複排除して数えます。プラットフォームのアカウント、訪問者識別子など、どの単位を使うかを明示します。
- 機能利用率：利用資格のあるアクティブアカウントのうち、その機能を使った割合です。
- ボタンクリック率：ボタンを見た利用者のうち、クリックした割合です。信頼できる表示記録が必要です。
機能利用率とクリック率では分母が異なります。前者は機能がどれだけ広く使われたか、後者は入口を見た後にどれだけ選ばれたかを表します。
同じ検索ボタンが複数の画面にある場合、画面や位置を切り口として持たせます。入口をまとめるだけでは、利用者がどこで機能を見つけたのか分かりにくくなります。
共有回数や共有した人数も記録できます。ただし、共有が見積依頼や申込につながったかを判断するには、その後の業務を追跡できる必要があります。
2. 見積依頼：必要な情報を送信できるか
「見積を依頼する」のクリックは、有効な見積依頼の送信と同じではありません。入力画面への到達、入力開始、送信成功について、それぞれ何件の業務フローが到達したかを追います。
ここでは三つの指標が役立ちます。
- 見積依頼の送信成功フロー数：送信が完了した業務フローの重複排除数。
- 見積依頼の入力完了率：入力段階に入った同じ集団のうち、所定の観測期間内に送信を完了した割合。
- 見積依頼の入力所要時間：入力段階への到達から、最初の送信成功までの時間。
入力画面への到達数が変わらず、完了率だけが下がった場合は、必須項目、入力チェック、資料アップロード、APIの応答を確認します。入口への流入を増やすだけでは、解決しない可能性があります。
3. 見積提示：送信した依頼に適時に回答が届くか
次に、業務が利用可能な見積を取得できたかを見ます。
見積取得率は、有効な見積依頼の同じ集団のうち、所定の期間内に少なくとも一つの利用可能な見積を取得したフローの割合、と定義できます。
一件の依頼に複数の見積版ができたり、複数の提示者が関わったりすることがあります。業務ファネルでは、見積を取得したかどうかをフロー単位で数えます。作業量を調べる場合は、見積の件数を別に数えます。集計する対象が異なります。
待ち時間も有用ですが、平均値だけでは一部の長い待ち時間を見落とすことがあります。中央値のP50とP90を併記すると、典型的な待ち時間と遅い側の状況を確認できます。
見積を取得済みのフローだけで待ち時間を計算する場合は、見積待ちのフロー数と現在までの待ち時間も示します。まだ待っている遅い業務を除くと、実態より速く見えるためです。
手動見積と自動見積は分けて表示します。扱う業務の複雑さが異なる可能性があるため、商品、チャネル、資料の充足度と合わせて解釈します。
4. 申込への移行と送信：見積後に業務が進むか
ここは二つの問いに分けられます。
一つ目は、見積を取得した後、どれだけのフローが申込手続きに移ったかです。見積後の進捗を表しますが、保険料、保障内容、顧客の判断、担当者のフォローなども影響します。
二つ目は、申込手続きに入った後、どれだけのフローが申込送信を完了したかです。こちらは、情報入力と送信の完了に近い指標です。
二つ目の定義は、例えば次のように書けます。
申込送信成功率 = 申込手続きに入った同じ集団のうち、観測期間内に送信が成功したフロー数 ÷ その集団の申込手続き開始フロー数。
分子は、分母に含まれる同じフローから数えます。「今日の送信成功数」を「今日の申込手続き開始数」で割るだけでは、対象が一致しないことがあります。今日送信した業務は、昨日手続きを始めたかもしれません。
日次レポートは各段階でその日に起きた件数を示せますが、ファネルでは同じ業務集団を追跡します。どちらにも価値がありますが、答える問いが違います。
5. 最終的な成果：有効な業務は何件完了したか
成果の指標では、確認済みの業務状態に立ち返ります。
この記事では説明用に、指定した発行日時の範囲で発行成功の状態に達し、合意した条件で無効化記録を除いた証券を数えます。保険料には、その同じ証券集合に記録された金額を、一貫した版の扱いで使用します。実際のレポートでは、状態、版、日時、金額の条件を確認する必要があります。解約、契約内容の変更、実際の入金額などは、別の指標として設計できます。
証券の集合と金額の条件が一致していれば、次の分解が使えます。
総保険料 = 証券数 × 一件当たり保険料。
総保険料が減ったら、まず証券数、一件当たり保険料、または両方が変わったかを確認します。
- 証券数の減少：業務の流入元、各段階の転換、最終的な完了状況を確認。
- 一件当たり保険料の減少：商品構成、保険金額、業務区分、価格などを確認。
「一人当たり保険料」の「一人」も明確にします。操作アカウント、保険契約者、被保険者では、分母も指標の意味も異なります。
保険金額の合計や一件当たり保険金額も補助指標になります。ただし、異なる保険種目を比較するときは、金額の意味が比較可能かを確認します。数値を足せることと、業務上比較できることは同じではありません。
4. 利用者と体験の指標を、業務の文脈に戻す
利用者規模や操作体験は、プロセスの変化を説明する助けになります。その前に、誰を分析するのかを定めます。
操作する利用者と保険契約者は別の役割
操作する利用者は、営業担当者、提携チャネルの担当者、その他のアカウントである場合があります。一方、保険契約者と被保険者は保険業務上の役割です。具体的な関係は、実際のプラットフォームで確認します。
これらを混ぜると、アクティブ率、継続率、一人当たり保険料の意味が曖昧になります。
操作アカウントでは、新規、アクティブ、継続利用を観測できます。例えば「一週間に少なくとも一度、定義した主要業務操作を完了した重複排除アカウント数」は、ログインだけを数える指標より、業務での利用に近い定義です。
これは設計案であり、主要操作は実際の業務目標に応じて決めます。新規作成アカウントと、初めて業務機能を使ったアカウントも、別の指標名にします。
継続率は、主要操作を初めて完了したアカウントを集団として、指定した後の週にも同じ操作を行ったかを追えます。起点、再利用の行動、観測期間を明示します。「定着度」も、具体的な頻度や利用比率に落とし込みます。
属性は差異の説明に使い、好みは表示条件と合わせて見る
保険契約者、被保険者、保険種目、商品の属性を使って、業務を分けて分析できます。「変化はどの種類の業務に集中しているか」を確認するためです。
行動から好みを探ることもできますが、クリックが多いだけでは好みが強いとは限りません。表示回数が多い、上の位置にある、初期状態で選ばれている、といった可能性があります。クリックの差は、表示や入口の条件と合わせて確認します。
失敗回数に加えて、失敗率と復旧を確認する
失敗が増えた理由は、問題の増加かもしれませんし、単に業務量の増加かもしれません。失敗したフロー数と、対応する操作を試みたフロー数を合わせて見ます。
再試行も分けて記録します。一件が五回失敗して最後に成功した場合と、五件が一回ずつ失敗してすべて離脱した場合では、体験が異なります。
例えば、次の三つを併記できます。
- 失敗したリクエストの回数：技術的な障害の発生量。
- 一度以上失敗したフローの重複排除数：影響を受けた業務の範囲。
- 失敗したフローのうち、観測期間内に復旧して成功した割合：問題を解消できたか。
エラー理由は、入力チェック、認証、権限、APIタイムアウトなどに分類できますが、実際の記録に基づいて分類します。登録・ログイン、本人確認、オンラインサービス手続きには、それぞれのフローを作り、必要に応じて申込の主フローと関連付けます。
保険金支払額や請求手続きの完了は、別の業務サイクルに属します。元のマインドマップでもこの部分は未確定のため、この記事の申込ファネルには含めません。
5. 集計条件が、指標の信頼性を決める
同じ指標名でも、計算方法が同じとは限りません。主要指標には簡潔な定義カードを用意すると、チームで再利用しやすくなります。
申込送信成功率を例にします。
| 項目 | 明示する内容 |
|---|---|
| 業務上の問い | 申込手続きに入った後、円滑に送信できるか |
| 集計単位 | クリック数や人数ではなく、重複排除した業務フロー |
| 分母 | 定めた開始日時の範囲で、初めて申込手続きに入ったフロー |
| 分子 | 分母のフローのうち、観測期間内にバックエンドで送信成功を確認したもの |
| 重複排除・版 | 同じフローの再試行の扱いと、新たに開始した業務の識別 |
| 時間条件 | タイムゾーンを統一し、段階の開始日時と送信成功日時を保持 |
| データ元 | 業務状態またはサーバー側の成功イベント。画面上の計測は行動を補足 |
| 分解の切り口 | 商品、チャネル、利用環境、証券発行の方式、見積方式など |
| 未完了の業務 | 処理待ち、明確な失敗、観測期間内の未完了を区別 |
ファネルを計算する前に、記録をつなぐ
段階を横断する分析用のフロー識別子を持ち、見積依頼、見積、申込、証券との対応関係を管理できると理想的です。これはデータ設計の提案であり、既存システムにすでにその項目があるという意味ではありません。
利用者アカウントだけでは、同時に進める複数の業務を区別できません。画面の時刻だけでも、変更、再試行、端末をまたぐ操作を確実につなぐことは困難です。
一件の見積依頼から複数の証券が発行される場合は、成功フロー数と証券数を別に集計します。証券数を見積依頼フロー数で割って、通常のフロー転換率と呼ぶべきではありません。
各集団に十分な観測時間を与える
ある段階に入ってから七日以内の完了を観測するとします。開始から一日しか経っていない業務には、十分な観測時間がありません。七日間観測済みの集団と直接比較すると、新しい集団の完了率を過小評価します。
「観測期間が完了した集団」と「まだ観測中の集団」を分けて示します。七日は説明用の例であり、実際の期間は業務の進み方に応じて決めます。期間を超えて完了した業務も、別に追跡できます。
次の段階に進んでいないからといって、失敗したとは限りません。処理待ち、自発的な離脱、技術的な失敗、期限内の未完了は、できるだけ分けて記録します。
6. 保険料減少の例で、分析を進める
ここまでの指標をどう組み合わせるか、簡略化した例で見てみます。
以下の数値はすべて仮のもので、実際の業績ではありません。 二つの集団は見積依頼の送信成功から追跡し、同じ長さの観測期間を完了しています。この例では、一つのフローから発行される証券は最大一件とします。通貨と、証券・保険料の集計条件も同じです。
表の証券数と保険料も、この二つの見積依頼集団に属する、各観測期間内の成果です。発行日を基準に別途集計したプラットフォーム全体の総量ではありません。
| 段階・成果 | 前の集団 | 現在の集団 |
|---|---|---|
| 見積依頼の送信成功フロー数 | 1,000 | 1,000 |
| 利用可能な見積を取得したフロー数 | 800 | 800 |
| 申込手続きに入ったフロー数 | 560 | 560 |
| 申込送信が成功したフロー数 | 448 | 336 |
| 発行成功の証券数 | 400 | 300 |
| 一件当たり保険料 | 2,000人民元 | 2,000人民元 |
| 総保険料 | 800,000人民元 | 600,000人民元 |
手順1：比較できる成果かを確認する
減少を説明する前に、集計条件、観測期間、金額の扱いが一致するかを確認します。データの遅延、イベントの欠落、業務状態の変更も調べます。
定義が変わったなら、まずその影響を説明します。直接、業務の悪化として扱ってはいけません。
手順2：総保険料を証券数と一件当たり保険料に分ける
一件当たり保険料は2,000人民元で変わらず、証券数が400件から300件に減っています。そのため、総保険料は80万人民元から60万人民元に減り、減少率は25%です。
この例では、証券数の変化が減少を説明します。次に優先して調べるのは、個々の証券の金額よりも、業務が完了するまでのプロセスです。
手順3：変化が最も明確な段階を見つける
見積依頼の送信成功、見積取得、申込手続き開始のフロー数は変わっていません。一方、申込手続き開始後の送信成功率は、
448 ÷ 560 = 80%
から、
336 ÷ 560 = 60%
に下がっています。差は20ポイントです。二つの割合の差は、ポイントで表します。
送信成功から証券発行までの割合は、どちらも約89.3%です。この簡略化したデータでは、申込手続き開始から送信成功までを優先して調べます。
ここで分かったのは変化の場所であり、原因はまだ確定していません。
手順4：具体的な業務区分に分解する
利用環境、チャネル、商品、証券発行の方式で分け、減少が特定の区分に集中しているかを調べます。各区分の構成比も確認します。全体の転換率は、ある区分の成績が下がった場合だけでなく、転換率の低い区分の割合が増えた場合にも下がります。
モバイルWebの特定の発行経路に集中しているなら、その経路の情報入力、認証、API応答、再試行を確認します。
手順5：仮説を立て、検証を計画する
ある入力段階でチェック失敗が増え、失敗後の復旧成功率も下がっていたとします。この場合、「情報入力やチェックが申込送信を妨げている可能性がある」という仮説を立てられます。
次に、対象集団のエラー記録、フォームの版、状態のつながりを確認し、同じ影響を受けたフローで異常が起きているかを検証します。修正や調整の後は、観測期間が完了した集団で、送信成功率、所要時間、失敗率と、その後の業務品質を追います。
ここで指標が行動につながります。「保険料が減った」という広い問題から、場所を特定し、記録を確認し、継続して観測できる段階へ進めます。
次の分析にも、この手順を使う
この枠組みは、次の順に使えます。
- 業務の目的と最終的な成功状態を定める。
- 主なフローを描き、経路ごとに通る段階を示す。
- 主要な段階で、件数、転換率、所要時間を定義する。
- 識別単位、重複排除、観測期間、データ元を明示する。
- 商品、チャネル、利用環境、業務区分で変化を分解する。
- 失敗理由と復旧状況を使って、仮説を立てて検証する。
保険業務プラットフォームでは、見積依頼、見積提示、申込への移行、送信、最終的な成果が主な流れです。自動車販売や商品の購入では段階が変わりますが、「成果→プロセス→原因の仮説→行動」という順序は再利用できます。
よい指標体系は、最初に何を見るか、変化したらどこを調べるか、次の行動を支える証拠は何かを、読者に示すものです。
素材について：数値例は仮のものです。実際に適用する際は、対象システムの業務定義と集計条件を確認してください。
この記事を楽しんでいただけましたか？
役に立った場合は、私の活動を支援することをご検討ください。