保険金請求処理のデータテンプレート
保険金請求処理のデータテンプレート
- 保険金請求データの収集に推奨される属性
- 保険金請求プロセスで追跡すべき主要なアクティビティ
- Sapiens ClaimsProからデータを抽出する手順
保険金請求処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 保険金請求プロセスの特定の時点で発生した業務アクティビティまたはイベントの名称です。 | ||
| 説明 この属性は、保険金請求のライフサイクルで実行された個々のステップやタスクを表します。例として、「保険金請求の提出」「初回審査の実施」「支払いの実行」などがあります。各アクティビティはプロセス上の個別の時点を示し、開始時刻と、場合によっては終了時刻を持ちます。 アクティビティの分析は、プロセスマイニングの中核です。プロセスマップの可視化、ステップ間のボトルネックの特定、アクティビティの発生頻度の分析、プロセスのばらつきの把握に役立ちます。特定のケースIDにおけるアクティビティの順序が、プロセスフローの基礎となります。 重要な理由 プロセスの各ステップを定義する情報であり、プロセスマップの作成やボトルネック、非効率な箇所の特定に欠かせません。 入手先 通常は、Sapiens ClaimsProのイベントログ、ステータス変更記録、またはタスク完了テーブルから取得します。ステータスコードや取引種別からのマッピングが必要になる場合があります。 例 保険金請求を登録調査を開始支払い額を算定保険金請求を終了 | |||
| イベントのタイムスタンプ EventTimestamp | 特定のアクティビティまたはイベントが開始した正確な日時です。 | ||
| 説明 イベントのタイムスタンプは、保険金請求プロセスにおける各アクティビティの開始時刻を記録します。イベントの順序付けや、イベント間の所要時間の算出に必要な時系列情報を提供します。このタイムスタンプは、イベントログの時間情報の基盤となります。 プロセスマイニングでは、サイクルタイム、待ち時間、アクティビティの所要時間など、時間に関するすべての指標の算出に欠かせません。ボトルネックの発見、時間の経過に伴うプロセスパフォーマンスの分析、実際の発生時刻に基づくSLAコンプライアンスの監視に役立ちます。 重要な理由 イベントを時系列に並べ、サイクルタイムやボトルネックなど、所要時間に基づく指標を算出するために欠かせません。 入手先 Sapiens ClaimsProのイベントログまたは取引ログのテーブルで、アクティビティやステータス変更の情報とともに記録されています。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| ケースID ClaimId | 各保険金請求を一意に識別するIDです。請求のライフサイクルを追跡するための主要なケースIDとして使用します。 | ||
| 説明 ケースIDは、1件の保険金請求に関連するすべてのイベントとアクティビティを結び付ける基本的な識別子です。請求の受付から最終的なクローズまでの全過程を再構成し、一貫して分析できます。 プロセスマイニングでは、イベントログの各レコードをケースIDに関連付ける必要があります。これにより、各請求の全経路を追跡し、プロセスのバリアントを可視化し、エンドツーエンドのサイクルタイムを算出して、ボトルネックや標準ワークフローからの逸脱を特定できます。ケースIDを軸にデータを分析することで、請求の全体像を把握できます。 重要な理由 関連するすべてのアクティビティを1つのプロセスインスタンスにまとめ、保険金請求のライフサイクルをエンドツーエンドで分析するために欠かせません。 入手先 Sapiens ClaimsProの主要な請求取引テーブルにある主キーです。正確なテーブル名とフィールド名は、システムの文書を確認してください。 例 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| イベント終了時刻 EventEndTime | 特定のアクティビティが終了した正確な日時です。 | ||
| 説明 イベント終了時刻は、アクティビティの完了時刻を示します。開始時刻と終了時刻が同じ瞬時のイベントもありますが、多くのアクティビティには所要時間があります。このタイムスタンプがあれば、各ステップにかかった時間を正確に測定できます。 この属性は、アクティビティの「処理時間」と、アクティビティ間の「待ち時間」を区別するために使います。請求の処理に実際に費やした時間と、キューで待機していた時間を分けて把握できます。時間のかかっているアクティビティを特定するうえで重要です。 重要な理由 個々のアクティビティの処理時間を算出し、付加価値を生む時間と待ち時間を区別できます。 入手先 開始時刻と同じ取引ログに記録されている場合があります。記録がない場合は、後続イベントの開始時刻から推定する必要があります。Sapiens ClaimsProの文書を確認してください。 例 2023-10-26T11:30:00Z2023-10-26T15:00:15Z2023-10-27T13:45:00Z | |||
| 保険金請求の種類 ClaimType | 自動車、財物、賠償責任など、保険金請求の分類です。 | ||
| 説明 保険金請求の種類は、事業分野や損失の性質に基づいて請求を分類します。プロセスを分ける基本的な属性であり、請求がたどるワークフローや関与するチームを左右することがあります。 保険金請求の種類ごとにプロセスを分析することは、事業分野による効率や手順の違いを特定するうえで重要です。たとえば、自動車保険の請求は自動化が進み迅速に処理される一方、商業用不動産の請求は複雑で時間がかかる場合があります。この属性は、「示談金額の一貫性指数」重要業績評価指標(KPI)の算出に必要です。 重要な理由 事業分野ごとにプロセスを比較し、各請求区分のベストプラクティスや固有のボトルネックを特定できます。 入手先 Sapiens ClaimsProの主要な請求レコードにある標準フィールドです。保険金請求システムの基本的なデータ項目です。 例 自動車物損一般賠償責任労働者災害補償商業用不動産 | |||
| 保険金請求の重大度 ClaimSeverity | 保険金請求の複雑さや財務上の影響見込みを示す分類です(例:低、中、高)。 | ||
| 説明 保険金請求の重大度は、請求の複雑さ、リスク、または財務上の損失見込みを示す評価です。この評価によって、審査の厳しさ、必要な損害査定人の経験、請求がたどるワークフローが決まることがあります。 この属性は、「請求重大度別サイクルタイム分析」ダッシュボードに欠かせません。複雑な請求が効率的に処理されているか、またはサイクルタイムの長期化に大きく影響しているかを把握できます。重大度の高い請求は低い請求より時間がかかると見込まれるため、パフォーマンス指標を解釈する際の重要なコンテキストになります。 重要な理由 サイクルタイム分析に必要なコンテキストを提供します。請求によって処理時間が異なる理由や、複雑な案件が効率的に処理されているかを把握できます。 入手先 Sapiens ClaimsProで手入力されるフィールドの場合と、請求の特性に基づいて算出されるスコアの場合があります。 例 低中高複雑 | |||
| 担当損害査定人 AssignedAdjuster | 保険金請求または特定のアクティビティを担当する損害査定人の名前またはIDです。 | ||
| 説明 この属性は、請求に対する処理を実行したユーザーまたはリソースを特定します。担当損害査定人を追跡することで、業務量の配分、個人のパフォーマンス、リソースの割り当てを把握できます。 分析では、担当者ごとにプロセスマップを絞り込み、請求の処理方法やパフォーマンスを比較し、研修の機会を特定できます。「損害査定人・部門別アクティビティ負荷」ダッシュボードの作成や、「損害査定人の業務量バランス」重要業績評価指標(KPI)の算出にも欠かせません。 重要な理由 リソース分析に欠かせない属性です。業務量の偏り、成果を上げている担当者、研修の必要性を把握できます。 入手先 Sapiens ClaimsProのユーザーアクティビティログや取引テーブルに記録されています。多くの場合、レコードを作成または最後に変更したユーザーに関連付けられています。 例 John Smithj.smithUSR-00451 | |||
| 担当部門 AssignedDepartment | 特定の段階で保険金請求を担当する部門またはチームです。 | ||
| 説明 この属性は、請求またはアクティビティを担当する事業部門やチームを示します。例として、「初回受付」「複雑案件」「SIU(特別調査部門)」などがあります。部門別にプロセスを分析できます。 部門別の分析により、特定のチームに固有のボトルネックを特定し、部門間の引き継ぎを把握して、部門ごとの効率を評価できます。「損害査定人・部門別アクティビティ負荷」ダッシュボードや、組織全体のプロセス分析に欠かせません。 重要な理由 チーム間のプロセスパフォーマンスや引き継ぎを分析し、組織内のボトルネックを明らかにできます。 入手先 多くの場合、システム内のユーザープロフィールに関連付けられているか、請求レコードに直接割り当てられています。Sapiens ClaimsProの文書を確認してください。 例 自動車保険金請求部門財物保険金請求特別調査部門 | |||
| 示談金額 SettlementAmount | 請求を解決するために請求者へ支払われる最終的な金額です。 | ||
| 説明 この属性には、保険金請求の示談金額が記録されます。請求による財務上の影響や、プロセス中に下された判断を反映する重要な結果指標です。 プロセス分析では、「請求判断・示談インサイト」ダッシュボードで示談金額を使い、プロセスのバリアントや損害査定人の対応が示談結果とどう関連するかを分析します。また、「示談金額の一貫性指数」重要業績評価指標(KPI)の主な入力データとして、類似した請求に対する示談判断のばらつきを特定するのに役立ちます。 重要な理由 重要な結果指標です。プロセスのバリアントと照らし合わせて分析することで、プロセスの非効率や逸脱が財務結果に与える影響を明らかにできます。 入手先 Sapiens ClaimsProで、請求に関連付けられた財務または支払い取引テーブルに記録されています。 例 5000.001250.75250000.00 | |||
| SLAステータス SlaState | クローズした請求が解決目標日を守ったかどうかを示す計算フラグです。 | ||
| 説明 この属性は、「請求クローズ」アクティビティのタイムスタンプと「ResolutionTargetDate」を比較して算出します。請求を「期限内」や「遅延」などに分類し、SLAパフォーマンスをすぐに確認できるようにします。 この計算フィールドは、「請求解決SLAコンプライアンス」ダッシュボードの基盤です。遅延した請求をすぐに絞り込み、遅延につながった共通のプロセス経路やボトルネックを調査できます。「期限内請求解決率」重要業績評価指標(KPI)にも直接役立ちます。 重要な理由 SLAコンプライアンスを直接測定し、期限を過ぎて解決した請求を簡単に絞り込んで分析できます。 入手先 この属性はソースシステムにはありません。データ変換時に、「請求クローズ」アクティビティの「EventTimestamp」と「ResolutionTargetDate」を比較して算出します。 例 期限内遅延 | |||
| ソースシステム SourceSystem | データの抽出元のシステムを示します。この場合はSapiens ClaimsProです。 | ||
| 説明 この属性は、プロセスデータの取得元に関するコンテキストを示します。このデータセットでは「Sapiens ClaimsPro」のような固定値の場合もありますが、複数のシステムからデータを統合する環境では特に重要です。 分析では、データガバナンスや問題の調査に役立ち、インサイトを正しいソースシステムに関連付けるためにも使われます。データの来歴を管理し、プロセスの技術的な背景を把握するための重要なフィールドです。 重要な理由 データの来歴と追跡可能性を確保します。複数システムのデータを統合する場合や監査の際に欠かせません。 入手先 通常は、データの抽出、変換、読み込み(ETL)の処理中に、レコードの取得元を示す固定値として追加されます。 例 Sapiens ClaimsProClaimsPro v10.1 | |||
| 事故発生日 LossDate | 保険金請求の原因となった事故や事象が発生した日付です。 | ||
| 説明 事故発生日は、損失発生日とも呼ばれ、請求の対象となる実際の事故(自動車事故や物損など)が発生した日付です。顧客の視点では、保険金請求の一連の流れの起点となることがよくあります。 この属性は、事故発生日から「保険金請求の提出」日までの期間である報告遅延の算出に重要です。この期間を分析すると、顧客の行動を把握し、より早い報告を促す機会を特定できます。早期の報告は、より良い結果につながることがよくあります。 重要な理由 事故そのものの発生日を示し、事故発生から請求提出までの報告遅延を分析できます。 入手先 主要な請求レコードにある基本フィールドで、事故受付通知(FNOL)の際に記録されます。 例 2023-10-202023-11-152024-01-05 | |||
| 保険証券番号 PolicyNumber | 保険金請求の対象となる保険契約を一意に識別する番号です。 | ||
| 説明 保険証券番号は、請求と請求者が契約している特定の保険契約を結び付けます。補償内容、限度額、免責金額など、請求の処理や判断に影響する重要な情報を確認できます。 プロセスフロー分析で直接使わない場合もありますが、詳細な調査では重要な属性です。請求データと保険契約データを結び付け、顧客との関係やリスクプロファイルをより広い視点から把握できます。また、保険証券ごとに請求を集計し、問題のある契約や傾向を特定することもできます。 重要な理由 請求と保険契約を結び付けます。プロセスデータと補償内容や限度額などの契約情報を組み合わせ、詳細な分析を行えます。 入手先 Sapiens ClaimsProの主要な請求レコードにある標準フィールドで、保険契約管理システムの契約情報と請求を結び付けます。 例 POL-987654321POL-123456789POL-555444333 | |||
| 最終データ更新日時 LastDataUpdate | ソースシステムからデータを最後に更新または抽出した日時です。 | ||
| 説明 この属性には、Sapiens ClaimsProからデータを最後に取得した日時が記録されます。分析対象データの鮮度を把握するために必要で、通常は同じデータセット内のすべてのレコードで共通の値になります。 分析やダッシュボードでは、このタイムスタンプがデータの最新性を判断するための重要なコンテキストになります。リアルタイムの情報を見ているのか、過去の時点のスナップショットを見ているのかを把握できるため、適切なタイミングで業務上の判断を下すうえで役立ちます。 重要な理由 データの鮮度を示し、分析結果がどの時点の情報に基づいているかを把握できます。 入手先 データ抽出(ETL)の処理中に生成され、データセットに記録される値です。 例 2024-05-21T02:00:00Z2024-05-20T02:00:00Z | |||
| 却下理由 ReasonForRejection | 保険金請求が不承認となった場合や支払いが拒否された場合に示される具体的な理由です。 | ||
| 説明 請求の判断が「不承認」の場合、この属性にその根拠が記録されます。「保険契約の免責事項」「証拠不十分」「不正の疑い」など、標準コードまたは自由記述で理由を示します。 この情報は、「請求判断・示談インサイト」ダッシュボードで役立ちます。却下理由を分析すると、不完全な情報による不承認が多いなどの傾向が明らかになり、データ収集段階の問題を特定できます。保険金請求が不承認となった根本原因の分析にも役立ちます。 重要な理由 不承認となった請求の背景を把握し、根本原因を分析することで、不承認率の低減や提出情報の品質向上につなげられます。 入手先 「請求不承認」または「請求判断」のアクティビティに関連付けられ、Sapiens ClaimsProのステータスコードまたは理由コードのフィールドに保存されていると考えられます。 例 保険契約の免責事項補償対象となる事故ではない依頼した情報が未提出重複請求 | |||
| 受付チャネル SubmissionChannel | 保険金請求が最初に提出された方法です(例:オンラインポータル、代理店、郵送)。 | ||
| 説明 この属性は、新規請求の受付チャネルを示します。チャネルによって初期データの品質が大きく異なり、その違いが後続のプロセス全体に影響することがあります。 受付チャネル別にプロセスを分析すると、効率や品質に関する疑問に答えられます。たとえば、「請求受付チャネル別効率」ダッシュボードでは、オンラインポータルで提出された請求が郵送の請求よりサイクルタイムが短く、手戻り率も低いかどうかを確認できます。こうしたインサイトは、受付チャネルの最適化やデジタル化への投資判断に役立ちます。 重要な理由 どの受付チャネルが効率的な処理につながるかを特定し、自動化や顧客体験の向上に向けた機会を把握できます。 入手先 通常は最初の問い合わせ時に取得され、Sapiens ClaimsProの主要な請求レコードに保存されます。 例 オンラインポータル代理店郵送電話 | |||
| 手戻りあり IsRework | 手戻りループに含まれるアクティビティを特定する計算済みの真偽値フラグです。 | ||
| 説明 同じ請求でアクティビティまたは一連のアクティビティが繰り返された場合、この属性は「true」に設定されます。たとえば、請求が「初回審査」から「追加情報の依頼」へ進み、再び「初回審査」に戻った場合、2回目の審査は手戻りとして記録されます。 手戻りを記録することは、プロセスの非効率を定量化するうえで重要です。「請求の手戻り・再提出の傾向」ダッシュボードや「請求の手戻りループ頻度」重要業績評価指標(KPI)に使われます。手戻りループを特定して分析することで、初期データの品質不足やガイドラインの不明確さなど、根本原因を見つけ、無駄な作業を減らす対策を講じられます。 重要な理由 繰り返されているアクティビティを明示し、プロセスの非効率を定量化できます。対象を絞った改善にも役立ちます。 入手先 ソースシステムにはありません。プロセスマイニングツールが、1つのケース内でアクティビティの繰り返しを検出して算出します。 例 truefalse | |||
| 解決目標日 ResolutionTargetDate | サービスレベル合意(SLA)に基づき、保険金請求をクローズする目標日です。 | ||
| 説明 解決目標日は、保険金請求をクローズする期限です。請求の種類、管轄区域、保険契約の条件などに基づいて設定されます。パフォーマンスやサービスレベル合意の遵守状況を測る基準になります。 この日付は、「請求解決SLAコンプライアンス」ダッシュボードと「期限内請求解決率」重要業績評価指標(KPI)の基礎となります。実際の「請求クローズ」日と目標日を比較することで、請求を「期限内」または「遅延」として自動的に分類し、SLAパフォーマンスを明確に把握できます。 重要な理由 SLAコンプライアンスを測る基準です。期限内の解決率を算出し、遅延リスクのある請求を特定できます。 入手先 Sapiens ClaimsProの主要な請求レコード、または関連するSLA管理モジュールに保存されている場合があります。 例 2024-01-152024-03-202024-06-01 | |||
| 請求ステータス ClaimStatus | 保険金請求の現在の業務上の状態です(例:オープン、保留中、クローズ)。 | ||
| 説明 この属性は、任意の時点における請求案件全体のステータスを表します。アクティビティがイベントを示すのに対し、ステータスはイベントの結果として生じた請求の状態を示します。請求のライフサイクルにおける現在の位置を大まかに把握できます。 請求ステータスを分析すると、未完了の請求件数や現在の段階を把握できます。業務用ダッシュボードでの確認や、プロセス全体を通じたステータス更新の頻度と内容を追跡して「請求ステータス透明性スコア」重要業績評価指標(KPI)を算出する際にも役立ちます。 重要な理由 請求の現在の状態を大まかに把握できます。進行中の業務量の追跡や、案件の進捗確認に役立ちます。 入手先 Sapiens ClaimsProの主要な請求レコードにある基本フィールドで、さまざまな業務取引によって更新されます。 例 オープン保留中:情報待ちクローズ:支払い済みクローズ:不承認 | |||
保険金請求処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 保険金請求の判断を確定 | 権限を持つ査定担当者が、請求の承認、一部承認、または却下を正式に決定し、記録した状態です。プロセスの重要なマイルストーンです。 | ||
| 重要な理由 この重要な判断によって、その後のプロセス経路(支払いまたは終了)が決まります。判断までの時間は、重要なパフォーマンス指標です。 入手先 請求の処理結果または判断フィールドに値が入力され、保存された時点で記録される独立したイベントと考えられます(例:「承認済み」「却下」)。 記録 判断フィールドまたはステータス(例:「請求ステータス」)が「承認済み」「却下」などの最終判断に設定されたタイムスタンプです。 イベントタイプ explicit | |||
| 保険金請求を受け付け | 申請経路を問わず、契約者または第三者から保険金請求を最初に受け付けた時点を示します。保険金請求プロセスの起点であり、システム連携または手入力で記録されることが一般的です。 | ||
| 重要な理由 このアクティビティは、プロセスの主な開始イベントです。受付から登録までの時間を分析すると、データ入力や初期設定の遅れを特定できます。 入手先 最初の請求レコードの作成タイムスタンプ、または請求のメインテーブルにある「受付日」フィールドから取得できると考えられます。 記録 システム上で請求レコードが作成されたイベントです。First Notice of Loss(FNOL)の入力と関連付けられていることがよくあります。 イベントタイプ explicit | |||
| 保険金請求を登録 | Sapiens ClaimsProで一意の請求IDを正式に作成し、割り当てたことを示します。通常、最初の受付後に行われ、請求が正式にシステムへ登録され、処理対象になったことを表します。 | ||
| 重要な理由 社内処理の正式な開始を示します。「保険金請求を受け付け」からこのアクティビティまでの時間で、受付処理の効率を測定できます。 入手先 請求レコードのステータスが「保留中」などの仮の状態から「登録済み」または「オープン」に変わったタイムスタンプから推定できます。明示的なログ記録がある場合もあります。 記録 請求のステータスが「登録済み」「オープン」または同等の有効な状態に変わったタイムスタンプです。 イベントタイプ inferred | |||
| 保険金請求を終了 | 支払いや却下の通知を含むすべてのアクティビティが完了し、システム上で請求案件が正式に終了した状態です。通常のプロセスにおける主な終了イベントです。 | ||
| 重要な理由 このアクティビティはプロセスの終了を示し、請求ごとの全体のサイクルタイムを算出できます。 入手先 請求のメインステータスが「終了」または同等の最終状態に更新されたタイムスタンプから推定できます。 記録 請求のメインステータスフィールドが「終了」に変わったタイムスタンプです。 イベントタイプ inferred | |||
| 支払いを実行 | 支払い額を送金する金融取引が実行された状態です。このイベントは、請求者または受取人への送金時点を示します。 | ||
| 重要な理由 顧客にとって重要なマイルストーンです。「保険金請求の判断を確定」からこのアクティビティまでの時間は、顧客満足度に大きく影響します。 入手先 請求IDに関連付けられた財務モジュールの支払い取引レコードから、タイムスタンプを取得します。 記録 請求に関連付けられた支払い取引ログ、または財務システムのインターフェース記録にあるタイムスタンプです。 イベントタイプ explicit | |||
| 調査を完了 | 必要な調査アクティビティがすべて終了し、調査結果が文書化された状態です。請求の最終判断を行うための前提となります。 | ||
| 重要な理由 この重要なマイルストーンは、証拠収集段階の終了を示します。調査の効率と、意思決定までの時間への影響を分析できます。 入手先 ステータスが「調査完了」または「判断待ち」に変わった記録、あるいは最後の調査タスクの完了タイムスタンプから推定できます。 記録 調査の終了を示すステータス変更のタイムスタンプ、または調査のサブタスクがすべて完了になった時刻です。 イベントタイプ inferred | |||
| 保険金請求を再開 | 一度終了した請求が、追加確認や対応のために再開された状態です。新しい情報や異議申し立てをきっかけに発生する例外イベントです。 | ||
| 重要な理由 プロセス上の例外や、最初の請求処理に問題があった可能性を示します。再開される請求の割合が高い場合、判断の品質や顧客との連絡に課題がある可能性があります。 入手先 ステータスが「終了」から「オープン」または「レビュー中」に変わった記録から推定できます。 記録 最終状態または終了状態から、いずれかの有効状態またはオープン状態に変わったタイムスタンプです。 イベントタイプ inferred | |||
| 保険金請求を却下 | 請求が正式に却下され、案件を終了する準備が進められている状態です。判断が「却下」となった「保険金請求の判断を確定」の後に行われます。 | ||
| 重要な理由 主要な代替プロセス経路を示します。この経路を分析すると、却下された請求の傾向を把握し、適切な手順が守られたか確認できます。 入手先 多くの場合、「保険金請求を終了」と同じイベントで、最終判断の属性によって区別します。「判断」フィールドの値が「却下」の場合に、別のアクティビティとしてモデル化できます。 記録 請求の最終判断の属性が「却下」または同等の値である場合、「保険金請求を終了」イベントから特定します。 イベントタイプ calculated | |||
| 初回確認を実施 | 査定担当者または請求処理担当者が、提出された請求の詳細と文書の初回確認を完了した状態です。この段階で請求の初期的な妥当性と次の手順を判断します。 | ||
| 重要な理由 このマイルストーンは、請求の振り分けにかかる時間を把握するうえで重要です。ここで遅延すると、全体のサイクルタイムや顧客満足度に大きく影響する可能性があります。 入手先 ステータスが「レビュー中」「確認済み」に変わったタイムスタンプ、または初回確認のタスクやワークフローの完了時刻から推定できます。 記録 「初回確認」タスクの完了タイムスタンプ、または請求のイベントログや履歴テーブルに記録されたステータス更新イベントの時刻です。 イベントタイプ inferred | |||
| 損害額を査定 | 損害の金額が正式に決定され、記録されたイベントです。最終的な支払い額を算定するための重要な情報となります。 | ||
| 重要な理由 この段階は、財務計画と準備金の管理に欠かせません。損害額の査定が遅れると、支払い手続き全体が滞る可能性があります。 入手先 システムで準備金または損害額のフィールドが確定または承認されたタイムスタンプとして記録されると考えられます。 記録 「損害額」または「準備金額」フィールドの最終入力または承認に関連付けられたタイムスタンプです。 イベントタイプ explicit | |||
| 支払いを承認 | 支払いを実行するための社内承認が下りた状態です。通常、上司または別の財務担当者が内容を確認し、支払いを承認します。 | ||
| 重要な理由 請求の判断と金額の算定後に行われる、社内の財務承認ワークフローでの遅延を特定します。 入手先 システムのワークフローで承認操作が行われたときに記録される明示的なイベント、またはステータスが「支払い待ち」「支払い承認済み」に変わった記録と考えられます。 記録 支払いが承認されたことを示す明示的なイベントログの記録、またはステータス変更のタイムスタンプです。 イベントタイプ explicit | |||
| 支払い額を算定 | 請求の承認後、請求者に支払う最終金額が算定された状態です。この段階の後に支払いの承認を行います。 | ||
| 重要な理由 判断後の金額算定にかかる時間を測定します。ここでボトルネックが発生すると、最終的な支払いが遅れる可能性があります。 入手先 システムの財務モジュールで「支払い額」フィールドに値が入力され、確定したタイムスタンプから推定できます。 記録 請求レコードの「支払い額」フィールドが確定した時点のタイムスタンプです。 イベントタイプ inferred | |||
| 調査を開始 | 請求に関する正式な調査段階の開始を示します。専門担当者の割り当て、検査の予定調整、証拠の詳細な収集などが行われる場合があります。 | ||
| 重要な理由 このアクティビティは、重要で時間がかかることの多い段階の開始を示します。調査にかかる時間を測定することは、大きなボトルネックの特定に役立ちます。 入手先 ステータスが「調査中」に変わった記録、または最初の調査関連タスクや担当割り当ての作成日から推定できます。 記録 請求のステータスが「調査進行中」または同等の状態に更新されたタイムスタンプです。 イベントタイプ inferred | |||
| 追加情報を依頼 | 査定担当者が情報の不足や不備を確認し、契約者または第三者に追加情報を依頼した状態です。このアクティビティから、プロセスでよく発生する待機状態が始まります。 | ||
| 重要な理由 このアクティビティは、手戻りのループの開始点です。発生頻度が高い場合、最初のデータ収集に問題があり、遅延や手作業の増加につながっている可能性があります。 入手先 連絡文書の送信時に記録された明示的なイベント、または請求のステータスが「情報待ち」や「保留中」に変わった記録から特定できます。 記録 請求のステータスが「情報待ち」に変わったタイムスタンプ、または外部への連絡を記録したログの時刻です。 イベントタイプ inferred | |||
| 追加情報を受領 | 依頼した情報を受領し、請求処理を再開できる状態です。このイベントにより、追加情報の依頼から始まった手戻りのループが終了します。 | ||
| 重要な理由 「追加情報を依頼」からこのアクティビティまでの時間を分析すると、外部要因による遅延を把握し、顧客の期待に沿った対応に役立てられます。 入手先 請求のステータスが「情報待ち」から「オープン」や「レビュー中」などの有効な状態に戻った記録から推定できます。受信文書のログと関連付けられている場合もあります。 記録 ステータスが「保留中」から「アクティブ」に変わったタイムスタンプです。文書のアップロードをきっかけに変わることがよくあります。 イベントタイプ inferred | |||
データ抽出ガイド
このプロセスのデータ抽出方法は現在検証中です。後ほど再度ご確認いただくか、 お問い合わせ ください。
始める準備はできていますか?
このテンプレートを使ってデータを準備し、今日から保険金請求処理の改善に取り組みましょう。インサイトを見つけ、ワークフローの大幅な改善につなげてください。
保険金請求処理を迅速化し、滞留を今すぐ解消
処理の70%を自動で完了し、迅速な支払いを実現している企業に続きましょう。
クレジットカードは不要です。数分で設定できます。