Skip to main content

商品と契約を管理する

学習の目的

この単元を完了すると、次のことができるようになります。

  • 保険仲介ソリューションによって保険商品モデルの作成と管理が簡易化するしくみを説明する。
  • 商品モデルを使用して保険契約を設定する。
  • 商品カタログマネージャーを使用して複数の保険会社の保険データを標準化し、比較する。
  • 保険契約の更新、更改、裏書を管理する。

仲介業者向け保険契約の管理

前の単元では、仲介業者が複雑なデータの管理、クライアントとの強固な関係の構築などを行うときに Financial Services Cloud 向け保険仲介がどのように役立つかを学びました。次は、仲介業者がクライアントの保険契約を設定、管理、更新するときの重要な機能である保険契約管理について詳しく見ていきます。

効果的な保険契約管理は、保険会社の保険プランを選択することだけではありません。仲介業者は、データを標準化して補償範囲と給付を構造化し、保険契約を正確かつ最新に維持する必要があります。標準モデルがあれば、効率的に商品やサービスの内容を比較してクライアントに保険契約を設定し、保険プランの変更時に調整することができます。

商品モデル

すべての保険契約は商品モデルから始まります。商品モデルでは、保険会社が提供する給付、補償範囲、条件が構造化されています。このデータの標準化により、仲介業者は提供する商品やサービスを確実に比較し、クライアント目標に沿った保険契約を作成することができます。

複数の保険会社の多様な給付プランを管理するのは大変です。なぜなら、それぞれの保険会社で使用される用語、補償範囲グルーピング、給付属性は異なるため、選択肢を比較してクライアントに最適な商品を推奨することが困難であるからです。保険仲介ソリューションには保険会社全体の保険データを標準化する商品カタログマネージャーが備わっているため、こうした作業が簡易化します。

Justin Pardo は、Cumulus Brokerage の Salesforce システム管理者です。商品カタログマネージャーを使用して、従業員給付 (EB) 商品の標準化された商品モデルを設定します。

対応するテキストで示されている EB 商品の商品構造。

モデルでは、統合された構造の下に医療、歯科、眼科補償が整理されています。各補償範囲にはグループ化された給付と属性が含まれており、保険契約全体で一貫性が確保されています。

商品モデル階層の各レベルはプランコンポーネントを表します。Cumulus では、次のように EB モデルが構造化されています。

名前

種別

説明

シナリオ

従業員給付 (1)

ルート商品

保険契約全体がモデル化されたものであり、すべての補償範囲の親として機能します。

EB のルート商品には、すべての補償範囲と給付が含まれます。

補償 (2)

商品コンポーネントグループ

グループ内の関連商品がバンドルされ、子商品が一貫した構造にまとめられています。

補償グループで 3 つの補償範囲仕様 (医療、歯科、眼科) がバンドルされています。

医療 (3)

補償範囲スペック

ルート商品の下の補償範囲がモデル化され、個々の給付専門分野の親として機能します。

医療保障範囲仕様には 4 つのコンポーネントグループ (プランに関する一般情報、外来診療、カイロプラクティックサービス、処方薬) が含まれています。

カイロプラクティックサービス (4)

商品コンポーネントグループ

1 つの補償範囲の下に関連給付専門分野がグループ化されています。

カイロプラクティックサービスグループでは 2 つの関連給付専門分野 (カイロプラクティックケア、はり治療) がバンドルされています。

カイロプラクティックケア (5)

給付専門分野

補償範囲の特定の給付が定義され、給付の条件の概要を説明する属性が含まれます。

カイロプラクティックケア給付専門分野には 4 つの属性 (自己負担割合、自己負担額、訪問の制限、通貨の制限) が含まれます。

自己負担割合 (6)

Attribute (属性)

特定の給付条件を表し、データ型と状況が保存されます。

自己負担割合属性にはパーセントのデータ型が含まれ、事前定義された選択リスト値を含めることができます。

各商品向けに新しい給付専門分野と属性を最初から作成する代わりに、システム管理者は商品分類テンプレートを最大限に活用することができます。そうすれば、それぞれの新しい給付専門分野で事前定義済みの属性がデフォルトで継承されるため、一貫性が確保されます。

保険契約モデル

標準化された商品モデルが設定されたら、仲介業者はモデルを使用してクライアント固有の保険契約を定義します。契約では選択された商品の構造が継承されますが、クライアントに固有の詳細情報 (補償範囲の制限、免責、保険料など) が含まれます。

次の図は、商品モデリングフェーズ時に作成された仕様がどのように保険契約とその子レコードに関連付けられているかを示します。

保険契約給付のオブジェクトと、各オブジェクトとモデリング仕様との関係。

次の表は、Cumulus のシナリオのコンテキストにおけるオブジェクトを示しています。

オブジェクト

説明

シナリオ

保険契約 (1)

クライアントの設定済み商品モデルを表し、保険契約の詳細 (保険契約番号、種別、日付、保険料など) が保存されます。

Cumulus は、Sally’s の従業員給付の保険契約を作成して EB ルート商品に関連付けます。

保険契約補償範囲 (2)

特定の保険契約の補償範囲の詳細が保存されます。

Cumulus は医療、歯科、眼科の保険契約補償範囲を Sally’s の契約に追加し、対応する補償範囲仕様に各補償範囲を関連付けます。

保険契約給付 (3)

保険契約補償範囲に含まれる給付を定義します。

Cumulus は給付を各補償範囲に割り当てます。補償範囲は、補償範囲を含む商品コンポーネントグループからの構造を継承します。

保険契約補償範囲給付属性 (4)

給付の条件の詳細が保存されます。

Cumulus は、保険会社のドキュメントに基づいて自己負担額と自己負担割合の値を指定します。

契約を設定する

この時点で、どのように契約を設定すればよいのだろうかと疑問に思われているかもしれませんから、あるシナリオを考えてみましょう。Cumulus のカスタマーサービス担当者 Julia Marks は、ある顧客に新しい保険契約を設定したいと考えています。この単元では、保険契約レコードを作成する方法を学び、補償範囲の詳細を定義し、給付と属性を入力します。これにより、Julia は商品モデルをクライアント固有の商品に変換します。

まず、Sally’s Aviation の新しい保険契約を作成し、従業員給付のルート商品にリンクします。

従業員給付商品にリンクされた新しい医療保険契約。

新しい契約と契約補償範囲には、補償範囲のすべての詳細情報が保持されます。

次に、Julia は医療商品を表す保険契約補償範囲を契約に追加します。

医療商品にリンクされた新しい医療保険契約の補償範囲。

医療保障範囲仕様をこの特定の医療保障範囲に接続することにより、仕様からのすべての給付と属性が保険契約で使用可能になります。

大まかな契約の詳細を設定したら、階層構造から給付属性までの特定の補償範囲情報を設定します。

保険契約補償範囲ページから給付を簡単に直接追加して管理するには、カスタムタブを作成し、プラン給付 Lightning コンポーネントを追加します。

保険契約補償範囲の [Plan Benefits (プラン給付)] タブ。

次に、階層構造を定義します。階層構造はネットワークベースの保険プランで重要であり、保険会社が費用分担レベルと医療提供者の利用を定義するのに役立ちます。大半の健康保険プランでは、下位階層の医療機関は少ない自己負担額で最上位の給付をメンバーに提供しますが、上位階層の医療機関には費用分担が高い要件があります。

Julia は、標準のネットワーク内またはネットワーク外の枠組みに基づいて、2 階層の医療保障構造を選択します。

階層が定義された [Add Benefits (給付を追加)] ウィンドウの [Tier Details (ランクの詳細)] セクション。

次に、保険会社のプラン設計に基づいて給付を割り当てます。補償範囲は商品モデルからの給付を継承するため、各階層に適切な値を入力するだけです。

[General Plan Information (プランに関する一般情報)] グループには、両方の階層に年間免責金額を追加します。

各階層の条件が指定された [Add Benefits (給付を追加)] ウィンドウの [General Plan Information (プランに関する一般情報)] セクション。

プランに特定の属性が含まれない場合は、空白のままにすると補償から除外されます。

給付の詳細を保存したら、プラン給付コンポーネントから確認できます。商品モデルの給付構造によってグループ化され、階層全体が表示されているため、すべての情報を一目で簡単に確認できます。

補償範囲と階層に従って給付がリストされている HMO プラチナプランの [Plan Benefits (プラン給付)] タブ。

中核となるすべての詳細が設定されたため、契約内容の更新に取り組む準備が整いました。

保険契約を編集する

保険契約は静的なものではありません。クライアントとの交渉、保険会社の更新、規制の変更と共に変化していく必要があります。保険仲介ソリューションによって契約の詳細情報の変更作業が簡易化されるため、クライアントは常に正確な情報を保持できます。

Cumulus Brokerage は Sally’s 従業員プランの改訂された保険会社ドキュメントを受け取りました。ドキュメントには、年間免責金額とネットワーク外サービスの医院訪問の自己負担額の増加が含まれています。

Julia はプラン給付コンポーネントからこの条件を選択し、[Edit (編集)] をクリックして値を更新します。

各階層の自己負担額の値の変更を含む [Edit Benefits (給付を編集)] ウィンドウ。

作業内容を保存したら、保険契約ページに新しい補償の詳細情報がすぐに反映されます。

各階層の年間免責金額と医院訪問給付の変更値が示されているプラン給付リスト。

このような柔軟性により、クライアントは常に正確な最新情報を保持できるため、仲介業務の俊敏性を維持できます。

保険契約ライフサイクルを管理する

保険契約の設定は最初のステップにすぎません。作成、発行から更新、裏書、キャンセルまで、仲介業者はすべての業務をスムーズに進める必要があります。つまり、手作業によるエラーをなくす必要があります。保険仲介ソリューションを使用すれば、こうした作業を自動化して時間の節約、正確性の向上、ワークフローの簡易化を実現できます。

保険契約アクションの効率化

すばやく更新する必要がある場合、 保険仲介ソリューションを使用すれば、契約リストビューと契約詳細ページの両方で、主要なアクション (編集、裏書、更新、キャンセル) をすぐに実行できます。

直観的なインターフェースを使用して、データをクリーンに保ち、保険契約レコードの一貫性を維持することができます。

更新サポート

更新は、時間がかかりミスが生じやすくなる可能性があります。特に、複数のチームが異なるシステムで、または完全にシステム外で作業し、入力する必要がある場合はなおさらです。保険仲介ソリューションでは、主な保険契約データを保持して再使用することにより、このプロセスが簡易化します。同一の保険会社での更新の場合、システムで関連する詳細 (対象個人、受取人、補償範囲のパラメーターなど) が自動的に複製されるため、シームレスに移行されます。更新に異なる保険会社が関わっている場合は、保険仲介ソリューションによって重要な契約情報が保持され、ブローカーは保険会社固有の項目の更新、手動による再作業の削減、一貫性の確保を実現できます。

たとえば、Julia が HMO プラチナ契約の更新を開始するとします。数回クリックするだけで必要な詳細情報がコピーされるため、同一データの再入力ではなく変更内容の確認に集中できます。

裏書と明確なバージョン履歴

P&C 部門で一般的に行われている裏書により、期間途中で保険契約を変更できます (補償範囲制限、免責、または条件の更新)。保険仲介ソリューションによって明確なバージョン履歴が維持されるため、各裏書は記録されて元の契約にリンクされます。これにより、誰もが変更内容を確実に追跡し、コンプライアンスと監査能力を確保することができます。

既存契約を再利用する

多くの保険契約は類似する構造であったり、給付パッケージが同じ内容であったりします。既存の保険契約をテンプレートとして再利用すれば、時間を節約し、類似する商品やサービスの一貫性を保つことができます。

この機能により、手動によるデータ入力の削減、ミスの軽減、全体の効率の向上が実現し、契約ライフサイクル全体が円滑に進みます。

この単元では、保険仲介ソリューションで給付プラン管理と保険契約ライフサイクルが簡易化するしくみを学習しました。標準化された商品モデル、効率化されたワークフロー、柔軟な契約管理機能により、仲介業者は業務を効率化し、クライアントを満足させることができます。

次の単元では、保険料率プラン、保険拠出プラン、対象資格ルールを使用して保険契約をさらに拡張できる方法を見ていきましょう。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む