分类： 金融服务云数据模型基础知识

学习目标 

完成本单元后，您将能够：

• 比较和对比业务和保险配置文件。
• 描述如何在保险数据模型中跟踪客户财产。
• 讨论Insurance for Financial Services Cloud支持记录汇总的方式。

认识你的顾客

保险数据模型提供了对客户数据进行建模的方法，以便您可以更好地了解客户的需求，从而促进富有同情心的客户参与度以及向上销售和交叉销售的机会。为此，数据模型包括“人员生活事件”和“业务里程碑”对象。

生活事件是发生在客户生活中的离散的重要体验，通常会触发重大的变化和调整。例如毕业，结婚，分娩，生病或受伤，以及换工作或失业。

业务里程碑等同于企业的生活事件。示例包括并购，业务部门的拆分，股票回购等。

再次向蕾切尔·亚当斯问好。如您所知，瑞秋（Rachel）是Cumulus Insurance的重要客户。目前，她在Cloud Kicks（一家时尚舒适的定制运动鞋的制造商）担任数据科学家，并嫁给了Nigel Adams。像Zeynep这样的销售代理和像Zaw这样的服务代理可以使用这种信息来祝贺Rachel最近结婚周年，并寻找机会向她的丈夫出售保单。

Nigel最初来自纽约市，并在那里拥有一家成功的夜总会：Cloudburst。特工Zaw（还分配了商业保险）可以使用此信息尝试向Cloudburst在曼哈顿新开业的俱乐部出售消防保险。让我们看看数据模型中的所有情况。

商业和保险简介

Business Profile对象代表被保险企业的保险相关属性，Insurance Profile对象代表被保险人的保险相关属性。这两个对象可用于了解客户的风险状况。

考虑以下数据模型图示，该图示捕捉了有关Cloudburst业务历史的关键点：以前的破产历史。代理商在将业务保险单出售给Cloudburst时可能会注意这一点。 

同样，代理人和承销商可以在出售瑞秋人寿保险单时考虑与瑞秋对烟酒的爱好有关的风险。 

客户财产

客户财产对象记录了客户的可保财产。考虑拥有两辆汽车的拉切尔：一辆轿车和一辆越野车。但是，只有轿车是由Cumulus投保的。对客户拥有的所有财产（例如房屋和汽车）的了解为代理商带来了交叉销售和向上销售的机会。 

通过金融服务云家庭看全局

金融服务云保险支持记录汇总。记录汇总显示相关列表中家庭所有成员的所有相关记录。例如，保险单记录汇总将显示特定家庭的任何成员拥有的所有保险单。记录汇总可帮助保险提供商可视化家庭中的保单足迹（保单总数）。

Salesforce船舶会记录“保险单”和“索赔”对象的汇总。管理员可以通过将“家庭保险政策”和“家庭索赔”拖动到“帐户（家庭）布局”的相关列表部分，使用户可以访问这些汇总。

现在，可以从家庭页面的“相关”选项卡访问voila，与保险和索赔相关的汇总。

汇集全部

到目前为止，在本模块中，我们已经在行业关键方面的背景下看到了金融服务云保险数据模型的一些片段。让我们看看将它们放在一起时的整体保险模型是什么样的。

在本模块中，您学习了Financial Services Cloud中的保险数据模型如何帮助您跟踪与业务以及重要用户的活动（例如销售和服务代表）相关的关键信息。保险数据模型有助于将与保险单和索赔摘要相关的所有信息带到Salesforce，因此您可以360度查看保单持有人。 

要知道，尽管保险数据模型为您提供了开箱即用的对象和字段，但它还使您可以定义不同数据集之间的关系。它不是万能的数据模型。相反，它具有灵活性，可以帮助您根据业务需求管理大型和小型企业。 

加起来

我们知道，保险数据模型可能看起来有些庞大。但是您看到了业务架构师Karuna和她在Cumulus Insurance的勇敢的朋友为他们的业务建立保险数据模型和架构以实现对保户的360度全方位了解的过程是多么容易。

现在考虑如何根据您的特定业务需求采用，实施和定制针对金融服务云的保险。借助针对金融服务云的保险，您可以帮助代理商和服务代表跟踪其绩效并始终专注于其目标。销售经理还可以查看所有分销商的综合绩效摘要或监视其个人绩效。代理商和服务代表可以将保单持有人的360度视角与生活事件和业务里程碑相结合，为客户提供及时相关的建议：同时提高NPS和底线。

学习目标 

完成本单元后，您将能够：

• 比较和对比业务和保险配置文件。
• 描述如何在保险数据模型中跟踪客户财产。
• 讨论Insurance for Financial Services Cloud支持记录汇总的方式。

认识你的顾客

保险数据模型提供了对客户数据进行建模的方法，以便您可以更好地了解客户的需求，从而促进富有同情心的客户参与度以及向上销售和交叉销售的机会。为此，数据模型包括“人员生活事件”和“业务里程碑”对象。

生活事件是发生在客户生活中的离散的重要体验，通常会触发重大的变化和调整。例如毕业，结婚，分娩，生病或受伤，以及换工作或失业。

业务里程碑等同于企业的生活事件。示例包括并购，业务部门的拆分，股票回购等。

再次向蕾切尔·亚当斯问好。如您所知，瑞秋（Rachel）是Cumulus Insurance的重要客户。目前，她在Cloud Kicks（一家时尚舒适的定制运动鞋的制造商）担任数据科学家，并嫁给了Nigel Adams。像Zeynep这样的销售代理和像Zaw这样的服务代理可以使用这种信息来祝贺Rachel最近结婚周年，并寻找机会向她的丈夫出售保单。

Nigel最初来自纽约市，并在那里拥有一家成功的夜总会：Cloudburst。特工Zaw（还分配了商业保险）可以使用此信息尝试向Cloudburst在曼哈顿新开业的俱乐部出售消防保险。让我们看看数据模型中的所有情况。

商业和保险简介

Business Profile对象代表被保险企业的保险相关属性，Insurance Profile对象代表被保险人的保险相关属性。这两个对象可用于了解客户的风险状况。

考虑以下数据模型图示，该图示捕捉了有关Cloudburst业务历史的关键点：以前的破产历史。代理商在将业务保险单出售给Cloudburst时可能会注意这一点。 

同样，代理人和承销商可以在出售瑞秋人寿保险单时考虑与瑞秋对烟酒的爱好有关的风险。 

客户财产

客户财产对象记录了客户的可保财产。考虑拥有两辆汽车的拉切尔：一辆轿车和一辆越野车。但是，只有轿车是由Cumulus投保的。对客户拥有的所有财产（例如房屋和汽车）的了解为代理商带来了交叉销售和向上销售的机会。 

通过金融服务云家庭看全局

金融服务云保险支持记录汇总。记录汇总显示相关列表中家庭所有成员的所有相关记录。例如，保险单记录汇总将显示特定家庭的任何成员拥有的所有保险单。记录汇总可帮助保险提供商可视化家庭中的保单足迹（保单总数）。

Salesforce船舶会记录“保险单”和“索赔”对象的汇总。管理员可以通过将“家庭保险政策”和“家庭索赔”拖动到“帐户（家庭）布局”的相关列表部分，使用户可以访问这些汇总。

现在，可以从家庭页面的“相关”选项卡访问voila，与保险和索赔相关的汇总。

汇集全部

到目前为止，在本模块中，我们已经在行业关键方面的背景下看到了金融服务云保险数据模型的一些片段。让我们看看将它们放在一起时的整体保险模型是什么样的。

在本模块中，您学习了Financial Services Cloud中的保险数据模型如何帮助您跟踪与业务以及重要用户的活动（例如销售和服务代表）相关的关键信息。保险数据模型有助于将与保险单和索赔摘要相关的所有信息带到Salesforce，因此您可以360度查看保单持有人。 

要知道，尽管保险数据模型为您提供了开箱即用的对象和字段，但它还使您可以定义不同数据集之间的关系。它不是万能的数据模型。相反，它具有灵活性，可以帮助您根据业务需求管理大型和小型企业。 

加起来

我们知道，保险数据模型可能看起来有些庞大。但是您看到了业务架构师Karuna和她在Cumulus Insurance的勇敢的朋友为他们的业务建立保险数据模型和架构以实现对保户的360度全方位了解的过程是多么容易。

现在考虑如何根据您的特定业务需求采用，实施和定制针对金融服务云的保险。借助针对金融服务云的保险，您可以帮助代理商和服务代表跟踪其绩效并始终专注于其目标。销售经理还可以查看所有分销商的综合绩效摘要或监视其个人绩效。代理商和服务代表可以将保单持有人的360度视角与生活事件和业务里程碑相结合，为客户提供及时相关的建议：同时提高NPS和底线。

学习目标 

完成本单元后，您将能够：

• 确定保险索赔的组成部分。
• 描述如何将临时保单参与者（例如交通事故的见证人）包括在索赔中。
• 将案件与索赔相关。

凹凸，凹痕，划痕

还记得第二单元的瑞秋吗？她最近与丈夫奈杰尔（Nigel）一起发生了一起交通事故，撞坏了汽车的挡风玻璃，需要将汽车拖走。Esperanza Fulton看到事故发生时，正在骑自行车上班。为这个细节添加书签：我们很快将对其进行重访。

雷切尔（Rachel）打电话给积云保险公司（Cumulus Insurance），并把他引到Zaw，您会记得第1单元中的积云客户服务代理商。Zaw很高兴协助Rachel提出索赔。

Zaw检查了Rachel的政策，发现路边援助已涵盖在内。Zaw还注意到Nigel是Rachel保险单的保单参与者。 

提出索赔

Zaw发起新的索赔请求。他输入了事件的所有相关详细信息，并将Rachel的汽车添加到与索赔相关的保险索赔资产中。下图表示了它的数据模型。

目击者帐户

Zaw将索赔的参与者输入系统。还记得埃斯佩兰萨（Esperanza），这是该部门早期的事故的偶然见证人？她也是索偿参与者。Zaw还作为索偿参与者记录了她的详细信息。让我们看看它的数据模型是什么样的。

就事论事

Cumulus Insurance以使客户满意而感到自豪，并要求严格的服务水平协议（SLA）来处理索赔。Cumulus使用Salesforce Service Cloud管理SLA和里程碑。 

因此，当Zaw在道路交通事故后回答Rachel的求助电话给客户支持时，他使用“启动第一损失通知”（FNOL）流程来记录事故详细信息。FNOL流是Insurance for Financial Services Cloud中可用的许多现成流之一。结果将自动创建一个新案例，Zaw将案例编号提供给Rachel，以备将来跟踪之用。

雷切尔（Rachel）得到的初始损失估计为$ 1000，但在索赔解决时，已减为$ 700。因此，当瑞秋（Rachel）对该决定提出异议时，会自动创建另一个案件（这是一种特殊的案件，称为索赔案件-一分钟内会涉及更多内容），但这一次违反了她的原始索赔。该新案例通过索赔案例对象与索赔相关联。此关系的数据模型可视化如下。

学习目标 

完成本单元后，您将能够：

• 确定保险索赔的组成部分。
• 描述如何将临时保单参与者（例如交通事故的见证人）包括在索赔中。
• 将案件与索赔相关。

凹凸，凹痕，划痕

还记得第二单元的瑞秋吗？她最近与丈夫奈杰尔（Nigel）一起发生了一起交通事故，撞坏了汽车的挡风玻璃，需要将汽车拖走。Esperanza Fulton看到事故发生时，正在骑自行车上班。为这个细节添加书签：我们很快将对其进行重访。

雷切尔（Rachel）打电话给积云保险公司（Cumulus Insurance），并把他引到Zaw，您会记得第1单元中的积云客户服务代理商。Zaw很高兴协助Rachel提出索赔。

Zaw检查了Rachel的政策，发现路边援助已涵盖在内。Zaw还注意到Nigel是Rachel保险单的保单参与者。 

提出索赔

Zaw发起新的索赔请求。他输入了事件的所有相关详细信息，并将Rachel的汽车添加到与索赔相关的保险索赔资产中。下图表示了它的数据模型。

目击者帐户

Zaw将索赔的参与者输入系统。还记得埃斯佩兰萨（Esperanza），这是该部门早期的事故的偶然见证人？她也是索偿参与者。Zaw还作为索偿参与者记录了她的详细信息。让我们看看它的数据模型是什么样的。

就事论事

Cumulus Insurance以使客户满意而感到自豪，并要求严格的服务水平协议（SLA）来处理索赔。Cumulus使用Salesforce Service Cloud管理SLA和里程碑。 

因此，当Zaw在道路交通事故后回答Rachel的求助电话给客户支持时，他使用“启动第一损失通知”（FNOL）流程来记录事故详细信息。FNOL流是Insurance for Financial Services Cloud中可用的许多现成流之一。结果将自动创建一个新案例，Zaw将案例编号提供给Rachel，以备将来跟踪之用。

雷切尔（Rachel）得到的初始损失估计为$ 1000，但在索赔解决时，已减为$ 700。因此，当瑞秋（Rachel）对该决定提出异议时，会自动创建另一个案件（这是一种特殊的案件，称为索赔案件-一分钟内会涉及更多内容），但这一次违反了她的原始索赔。该新案例通过索赔案例对象与索赔相关联。此关系的数据模型可视化如下。

学习目标

完成本单元后，您将能够：

• 列出并描述不同类型的生产者。
• 解释生产者，政策和法律实体之间的关系。
• 描述约会及其与生产者的关系。
• 将保险公司的法人实体与授权的保险公司联系起来。

认识Insurancetown的生产者

保险生产者是代表保险公司向客户出售保险产品的人。Financial Services Cloud中的保险数据模型为建模以下类型的生产者提供了灵活性。

• 直接—保险公司员工
• 专属保险-保险公司的合同代理商，仅出售单个保险人的保单
• 独立-保险公司的合同代理商，销售多个保险公司的保单

多生产者协作

除了传统的单保单制保险人框架之外，保险数据模型还允许多个保单生产者在单个保单上进行协作。让我们来看几个例子。

一对一

积云保险通过两种代理销售保险：一种是专属代理，另一种是独立代理。以下示例说明了如何在这两个代理中对策略与生产者之间的关系进行建模。

在下图中，IP1423是一个独立的生产商，其模型为联系Marcello Ghirlando，并为MaxProtect代理工作。他已出售人寿保险单：LI-1235-567。

CP1323是被模拟为用户石川久美子的俘虏生产者。她已售出汽车保险单：CI-1235-568。

多对多

保险数据模型通过“生产者策略分配”支持多对多的生产者策略关系，这是保险策略与生产者之间的结合对象。我们将在这里简化示例，只考虑圈养生产者。但是要知道，所有生产者类型都支持多对一的生产者政策关系。

来自Cumulus的大型商业保险保单通常需要一组代理商和服务代表协同工作以管理该保单。

在下图中注意，三个生产者P001，P002和P003如何在相同的商业保险单BI-1235-567上工作。

生产者许可证和任命

保险生产者（可互换地称为代理人或保险经纪人）是由州的保险部门许可在该州出售保险的个人。保险有不同的类别，生产者必须在他们希望进行业务交易的每个类别中获得许可。Karuna使用“营业执照”对象为Cumulus生产者的营业执照建模，包括诸如“执照类别”和“授权范围”之类的执照详细信息。

任命是保险业与保险公司之间的一项协议的保险行业行话，该协议授权保险公司代表保险公司销售保险产品。Karuna使用分发服务器授权对象对约会建模。通常会根据诸如事故，财产和伤亡之类的权限来颁发许可证并进行任命。发行人授权对象具有对“业务许可”对象的查找，以捕获许可-任命关系。

在以下示例中，Ridhima Kapoor为代理机构MaxProtect工作，并且她获得了“事故和财产”权限的许可。但是，Cumulus Insurance已指定Ridhima仅在“事故”权限范围内出售保单。

保险人的法人实体和授权保险公司

Karuna使用“授权保险线”对象来对保险人的法人实体有权出售的保险线进行建模。授权保险行可以查询法人实体，该对象捕获保险人的法人实体或子公司。

在下图中，Cumulus人寿保险公司是Cumulus Insurance的法人实体，并且被授权在美国销售人寿保险产品系列。积云人寿保险公司又任命了代理机构MaxProtect来销售人寿保险项目下的保单。

学习目标

完成本单元后，您将能够：

• 列出并描述不同类型的生产者。
• 解释生产者，政策和法律实体之间的关系。
• 描述约会及其与生产者的关系。
• 将保险公司的法人实体与授权的保险公司联系起来。

认识Insurancetown的生产者

保险生产者是代表保险公司向客户出售保险产品的人。Financial Services Cloud中的保险数据模型为建模以下类型的生产者提供了灵活性。

• 直接—保险公司员工
• 专属保险-保险公司的合同代理商，仅出售单个保险人的保单
• 独立-保险公司的合同代理商，销售多个保险公司的保单

多生产者协作

除了传统的单保单制保险人框架之外，保险数据模型还允许多个保单生产者在单个保单上进行协作。让我们来看几个例子。

一对一

积云保险通过两种代理销售保险：一种是专属代理，另一种是独立代理。以下示例说明了如何在这两个代理中对策略与生产者之间的关系进行建模。

在下图中，IP1423是一个独立的生产商，其模型为联系Marcello Ghirlando，并为MaxProtect代理工作。他已出售人寿保险单：LI-1235-567。

CP1323是被模拟为用户石川久美子的俘虏生产者。她已售出汽车保险单：CI-1235-568。

多对多

保险数据模型通过“生产者策略分配”支持多对多的生产者策略关系，这是保险策略与生产者之间的结合对象。我们将在这里简化示例，只考虑圈养生产者。但是要知道，所有生产者类型都支持多对一的生产者政策关系。

来自Cumulus的大型商业保险保单通常需要一组代理商和服务代表协同工作以管理该保单。

在下图中注意，三个生产者P001，P002和P003如何在相同的商业保险单BI-1235-567上工作。

生产者许可证和任命

保险生产者（可互换地称为代理人或保险经纪人）是由州的保险部门许可在该州出售保险的个人。保险有不同的类别，生产者必须在他们希望进行业务交易的每个类别中获得许可。Karuna使用“营业执照”对象为Cumulus生产者的营业执照建模，包括诸如“执照类别”和“授权范围”之类的执照详细信息。

任命是保险业与保险公司之间的一项协议的保险行业行话，该协议授权保险公司代表保险公司销售保险产品。Karuna使用分发服务器授权对象对约会建模。通常会根据诸如事故，财产和伤亡之类的权限来颁发许可证并进行任命。发行人授权对象具有对“业务许可”对象的查找，以捕获许可-任命关系。

在以下示例中，Ridhima Kapoor为代理机构MaxProtect工作，并且她获得了“事故和财产”权限的许可。但是，Cumulus Insurance已指定Ridhima仅在“事故”权限范围内出售保单。

保险人的法人实体和授权保险公司

Karuna使用“授权保险线”对象来对保险人的法人实体有权出售的保险线进行建模。授权保险行可以查询法人实体，该对象捕获保险人的法人实体或子公司。

在下图中，Cumulus人寿保险公司是Cumulus Insurance的法人实体，并且被授权在美国销售人寿保险产品系列。积云人寿保险公司又任命了代理机构MaxProtect来销售人寿保险项目下的保单。

学习目标

完成本单元后，您将能够：

• 列出典型保险单的关键属性。
• 设置策略的覆盖范围详细信息。
• 配置政策的付款信息。
• 描述保险数据模型如何支持工人的赔偿政策。

保险单的基础

保险数据模型将与保险单和索赔摘要相关的所有信息带到Salesforce，因此您可以360度查看保单持有人。让我们看看Cumulus如何与其中一位保单持有人做到这一点。

雷切尔·亚当斯（Rachel Adams）是Cumulus的长期高净值客户，她与该公司有数项财务关系。她最近从积云购买了轿车轿车保险。

一些策略属性如下。

• 有效期：1年
• 开始日期：2020年1月1日
• 结束日期：2020年12月31日
• 已付保险费：$ 1000

如果您已经获得了 Financial Services Cloud数据建模徽章，您就会知道Rachel Adams被建模为个人帐户，这是Financial Services Cloud的长期对象。

关键对象

但是，如何表达Rachel汽车保险政策在Salesforce中的关键属性？以下对象捕获了保险单的详细信息以及该保险所投保的汽车。

目的	描述
保险政策	将此视为保险数据模型中的根对象。其他一切都从这里流出。保险单对象捕获基本信息，例如保单编号和类型，被保险人名称，生效日期，适用保费等。
保险单资产	该对象包含该保单所保险资产的高级信息。资产的实际详细信息在“客户属性”对象中捕获，该对象从此处链接到该对象。
客户财产	该对象详细描述了“保险单资产”对象，并且包含诸如汽车模型，公平市场价值等详细信息。

这是所有这些信息及其相互联系的视觉显示方式。

显示覆盖范围

我们的全明星销售代理Zeynep最初向Rachel出售了她的汽车保险单，而Zeynep现在帮助Karuna为Cumulus建立了保险数据模型。Karuna从Zeynep得知Rachel的汽车政策包括：

• 全面覆盖
• 碰撞伤害范围
• 人身伤害保险

碰撞损坏的范围尤其包括：

• 赔偿限额为$ 50,000
• 个人免赔额$ 500

反过来，雷切尔政策中的其他内容（全面和人身伤害）也有进一步的细微差别，但我们暂时不涉及这些内容。Karuna将她到目前为止对Rachel的保单所拥有的其他详细信息映射到Salesforce保险数据模型。

保险单参加者

雷切尔（Rachel）希望她的丈夫奈杰尔（Nigel）包含在汽车保险单中。奈杰尔（Nagel）周末用雷切尔（Rachel）的轿车来杂货店购物，雷切尔（Rachel）想确保自己被遮盖。Nigel通过他的其他金融投资已经成为Cumulus客户。与Rachel一样，他使用Person Account对象在Salesforce中建模。

Karuna使用“保险保单参与者”对象将他与Rachel的保单联系起来。

一项政策下的多种资产

由于最近的工作奖励，雷切尔决定奖励自己全新的SUV。她希望Cumulus在现有政策下为这辆新车提供服务。但是她想提出一些细节：她想全面覆盖SUV，而不是轿车。卡鲁纳开始工作。

数据模型的多功能性

雷切尔的丈夫奈杰尔（Nigel）也一直在疯狂收购。最近生意兴隆，他给自己买了一辆新的小型货车。雷切尔与Zeynep进行了核对，以查看是否可以将新车添加到她现有的汽车保险单中，以及是否会降低总保费。是的，是的！雷切尔（Rachel）还希望增加其继女尼亚拉（Nyala）作为小型货车的司机。

Karuna开始为这个高级方案建模。保险数据模型灵活而灵活是一件好事。

您有仪表盘警报

Zeynep在一个星期一的早晨登录，只是看到一个仪表板警报，提醒她这是几天里Rachel的30岁生日。曾经是销售摇滚明星的Zeynep利用这次机会向Rachel交叉销售新的人寿保险。

Rachel感谢Zeynep的积极主动：她从Cumulus购买了资产支持的人寿保险。这项政策可以保护生命，但也可以让雷切尔投资于股票和债券等市场证券。雷切尔（Rachel）提名她的丈夫奈杰尔（Nigel）为政策提名人。让我们欣赏一下Karuna在这上面的手工。

分配付款

雷切尔（Rachel）希望每季度通过其主要信用卡支付人寿保险保费。这是Karuna对信用卡信息，季度保费付款和帐单关系进行建模的方式。

路上的颠簸

雷切尔（Rachel）需要就自己的汽车保险单提出索赔。当Cumulus Insurance将索赔的收益转移到Rachel的银行帐户时，Karuna使用Financial Account Transaction对象为该活动建模。

我们已经覆盖了所有人

保险数据模型支持替代保险的实现：您可以将保险的主列表带入“保险类型”对象，然后利用“保险保单”联结对象对在特定保单下购买的保险建模。看起来就是这样。

雇主保险

Rachel的雇主Cloud Kicks已购买了工人赔偿政策，以支付其工厂发生的任何事故所产生的费用。工人补偿政策通常涵盖不同工厂地点的不同类别的员工。这是Karuna建模的方式。

学习目标 

完成本单元后，您将能够：

• 描述保险业。
• 分析审查数据模型的关键注意事项。

介绍

保险业务是古老，庞大而迷宫的。关于它存在的最早记录证据之一是大约公元前1750年左右的著名《汉mura拉比法典》。穿越地中海的商人将通过贷款为其装运的货物提供资金，并且他们将向贷方支付额外的金额，以获得贷方的保证，即如果货物在海上被偷窃或丢失，该笔贷款将被取消。 

时代已经变了，但是作为保险提供者，您仍然可以全力以赴：您需要跟踪生产者，保单持有人以及为客户及其资产提供的保险范围。由于需要保险，因此保险业务是一家复杂的企业。任何事情都不能被假设或认为是理所当然的，并且业务的每个方面都需要记录下来并加以追踪，因为这不仅关乎金钱，而且关乎人类生命本身。这就是为什么周到且全面的保险数据模型是成功必不可少的原因。

向保险数据模型问好 

在本模块中，您将学习Financial Services Cloud中的保险数据模型如何帮助您跟踪与业务以及重要用户的活动（例如销售和服务代表）相关的关键信息。  

保险数据模型有助于将与保险单和索赔摘要相关的所有信息带到Salesforce，因此您可以360度查看保单持有人。 

保险数据模型就是这样-一种专门为保险公司设计的数据模型。与Salesforce合作伙伴和客户合作构建的保险数据模型提供了开箱即用的功能，可以在Salesforce中组织数据。它可以帮助各种规模的保险公司以各种方式与客户，销售代表，服务代理商和分销商联系。可以将数据模型视为一个巨大的餐具室，内部装有许多不同的东西。但是，在数据模型储藏室中，您的所有成分都得到了完美组织。这样，当您需要某些东西时，便会确切地知道在哪里以及如何找到它。现在谁不想这样的厨房呢？

在使用保险数据模型之前，管理员必须花费数月的时间（并投入大量的IT资源）来使食品杂货井井有条。他们需要手工并从头开始创建类似的数据架构，因为没有可用的标准。现在，有了这种数据模型，管理员可以在设置传统Salesforce部署所需的正常时间的一半时间内启动并运行。相当了不起。

在下一个单元中，我们将详细介绍保险数据模型。现在，知道该数据模型使用标准Salesforce对象（例如客户和联系人）和自定义对象（例如策略付款方式和账单）来跟踪所有类型的连接。这些跟踪和组织的连接使在Salesforce中查找所需信息变得简单。 

假设您需要一个与特定家庭有关的所有保险单的综合视图。您可以使用保险数据模型（以及相关的较大的Financial Services Cloud数据模型）轻松完成此任务。 

但是，等等，还有更多！保险数据模型还跟踪客户的保费支付历史以及针对保单提出的所有索赔。是否想知道谁都有权出售事故授权线？是否想找出事故现场的目击者发生了什么？您可以使用保险数据模型做更多的事情。

保险数据模型为您提供了开箱即用的对象和字段，同时还允许您定义不同数据集之间的关系。它不是万能的数据模型。相反，它具有灵活性，可以帮助您根据业务需求管理大型和小型企业。 

我们知道，金融服务保险云数据模型一目了然。因此，让我们跟随全国性保险公司Cumulus Insurance的工作人员，他们正在努力优化其数字化转型历程。

参加积云保险 

Cumulus Insurance是金融服务巨头Cumulus Cloud Corporation的一部分，是全国范围内大型，多元化的保险服务提供商。积云拥有忠实的客户群，他们一直以来都对其保险需求表示信任。但是，与许多其他行业一样，当今的保险行业正处于数字化破坏的阵痛之中。年轻的客户需要出色的体验-他们只会与提供这些体验的公司开展业务。这就意味着像Cumulus这样的公司需要快速调整并重新考虑他们如何在每个接触点与客户建立联系。他们需要进行数字化投资，以提供一流的客户体验。

认识梦想团队

让我们在积云团队见面。如果您已经获得了“销售和服务保险代理控制台”徽章，那么您可能已经认识了其中一些人 。

• Zeynep Aksoy是摇滚明星的销售代理商。
• Zaw Aung是Zeynep的客户服务同事。
• Matt Admin是Cumulus的全明星Salesforce管理员。
• Karuna Bagh是业务架构师，负责建立保险数据模型并审查对象之间的有效关系以优化运营绩效。她想帮助Zeynep和Zaw等销售和服务代表轻松管理其客户关系。

关键注意事项

数据模型对象可以通过多种方式相互关联。要记住的重要一点是，并非所有场景都需要所有关联。这取决于业务规模，要执行的操作以及目标产品或服务的类型。Karuna可以通过选择最适合Cumulus的对象关联来保持保险业务的灵活性。 

在使用数据模型之前，她考虑了以下几点。

• 保险单有很多利益相关者：这不仅限于保单持有人，而且还可以涵盖偶然的旁观者，例如发生交通事故的目击者。Karuna必须找到一种使数据模型适用于所有典型保险方案的方法。
• 必须向Cumulus的代理商提供方法，使其有机地发展业务，并在完成工作时更好地完成工作。Karuna必须改进数据模型，以便代理获得保单持有人的360度视角。由此产生的见解可以在代理商的日常工作范围内为代理商带来向上和交叉销售的机会。
• 数据模型必须说明人们从事风险保护的复杂方式。客户可能需要为他们的某些资产购买保险，而不是为其他资产购买保险，即使所有资产都已投保，他们也可能希望在同一保单内为特定资产提供不同类型的承保范围。
• 对于保险销售代理商来说，没有什么比将销售推销与客户生命中的重大事件挂钩更有价值的了。这就是生活事件和业务里程碑功能背后的力量。Karuna必须确保将客户生活事件的详细信息无缝地传递给代理商，从而最大程度地发挥新的业务潜力。

Karuna意识到她手头上有一项艰巨的任务，因此从数据模型开始了自己的旅程。她希望她可以组织能够紧密协作的数据簇。她毫不怀疑，借助这种保险数据模型，她可以帮助Cumulus和Zeynep等销售代理以及Zaw等服务代表实现最大的业务效率。