有赞保险业务的分析与架构设计

1、背景

有赞微商城为商家提供了全行业全场景的电商解决方案，帮助商家在社交电商、直播电商等场景下快速布局。在整个交易流程中，对退货时运费减免的支持已成为了电商场景的标配。有赞也提供了 “退货包运费” 产品来满足消费者及商家在此场景下的诉求。

本文从“退货包运费”这个产品出发，分析保险业务的特征，介绍有赞保险业务系统的架构设计。

2、退货包运费及保险业务分析

在目前消费者权益保护法对消费者网购支持的大背景下，许多类目的商品都能支持七天无理由退货。由此也衍生出退货时物流运费支出的一些争议，给消费者和商家带来困扰。“退货包运费”产品的出现正是为电商业务解决在退货流程中这类问题，从而提升购物体验。

2.1 产品价值

• 从消费者角度，退货运费减免信息的透出能让消费者得到承诺，并在实际发生退货退款时减少运费支出。
• 站在商家角度，产品能降低消费者网购时的选择成本，提高下单转化率，以及有效地减少在售后处理上的人力投入。

2.2 产品流程分析

当商家开通“退货包运费”后，其服务开始作用在交易链路上：

• 消费者支付前，在商品详情页及下单确认页里准确地判断并展示服务内容。
• 消费者支付后，在订单详页面的“退货包运费”一栏中显示当前的服务状态及内容。
• 商家发货后，收取商家一些的费用，向保险公司投保，生成保单，服务进入生效阶段。
• 退货退款时，如果消费者选择的是上门取件，可以直接抵扣退货运费。如果是自行寄回，消费者需先行支付运费，退款完成后，保司自动赔付给消费者。

2.3 产品风险管控分析

为了避免一些骗保、刷单、恶意退款、薅羊毛等不良行为影响产品的正常运营，“退货包运费”会在关键流程节点接入有赞强大的风控体系来保障产品的健康发展，比如：根据不同的风险因素适当调整服务费率、服务前的风控审核、申请赔付前的审核等。

2.4 保险业务分析

“退货包运费”是一种保险类的业务，消费者或商家支付较低费用，约定了在小概率风险事件（退货）发生时，对于被保的一方（消费者）发起赔付，达到减免退货物流运费的目的。目前市场上许多保险公司（下简称：保司）有对应成熟的保险产品，有赞也与保司合作一起为消费者和商家提供服务。

有赞保险类业务的能力要与保司的能力匹配，而保险这种业务形态已经比较成熟，在《中华人民共和国保险法》里对于保险业务活动进行了规范，从中我们能看到保险业的基本业务活动。

“保险，是指投保人（注1）根据合同约定，向保险人（注2）支付保险费，保险人对于合同约定的可能发生的事故因其发生所造成的财产损失承担赔偿保险金责任，或者当被保险人（注3）死亡、伤残、疾病或者达到合同约定的年龄、期限等条件时承担给付保险金责任的商业保险行为”。

保险合同是保险活动的载体，是投保人与保险人约定保险权利义务关系的协议。围绕保险合同的签订、变更、终止以及当事人权利义务的履行，都是保险业务的范畴。保险分为财产保险和人身保险，在电商场景中，我们一般涉及到的是财产保险。生命周期见下图：

保险合同（下简称：保单）里一般包含了以下内容：

1. 保险人的名称和住所；
2. 投保人、被保险人的姓名或者名称、住所，以及人身保险的受益人(注4)的姓名或者名称、住所；
3. 保险标的；
4. 保险责任和责任免除；
5. 保险期间和保险责任开始时间；
6. 保险金额（注5）；
7. 保险费以及支付办法；
8. 保险金赔偿或者给付办法；
9. 违约责任和争议处理；
10. 订立合同的年、月、日。

在保单的有效期里，可以对保单进行变更、终止、修改条款等，依据保单中条款申请理赔。

3、架构设计

3.1 业务架构设计

通过上面的价值及流程分析，“退货包运费”产品能分解出以下一些流程活动：

• 服务管理方面：提供服务的生命周期管理，如开通、关闭服务。对于有赞而言，要对已开通的商家做风险管控，还需要支持冻结、解冻、清退等操作，商家也能查看到服务费率的历史变更情况。
• 服务单管理方面：可服务内容的查询，服务单的查询，服务单的生命周期管理，比如下单、生效、抵扣试算，抵扣申请，自动申请理赔，理赔修改。

这些流程活动依赖保险领域的业务能力来支撑，具体见下图：

3.2 技术架构设计

在应用设计中，我们将整个保险类业务的应用架构分为业务服务层、领域服务层、组件层、依赖层：

• 业务服务层：对接有赞生态SAAS业务，提供“退货包运费”服务，即感知交易的全流程，推进服务单据状态流转。根据商家的经营情况，批量更新费率。
• 领域服务层：对上层提供标准承保、理赔的服务。另外，为支持上层不同的保险类产品，需要为不同的产品配置不同收费规则、管理对应的保司渠道。
• 组件层：提供领域服务的可复用的基础能力，比如向保司投保理赔、风控校验审核、业务校验、支付退款等。
• 依赖层：组件服务里主要依赖了一些中台性质的服务，如店铺、会员、交易、支付、风控。

对于领域服务层的设计，适合应用领域驱动设计(简称：DDD）这种建模方法。从上面的保险领域分析中，我们梳理出几个主要的领域模型：

领域服务层主要围绕保单、理赔单对外提供服务。

支撑子域有：

• 产品中心：定义一个保险类产品，包括产品的服务明细条款，协议模板，协议约定校验，保险人信息，收付款方式等。
• 标的管理：管理保险标的相关的信息，在“退货包运费”里就是退货运费相关信息，如订单信息，退货商品的信息、物流信息等。
• 渠道管理：出于产品成本及业务稳定性考虑，一个保险产品有多个保司渠道备份，渠道管理负责渠道的定义，与保司接口适配，主要有投保，理赔，保单查询等。

通用子域有：

• 计费管理：用于支持产品、商家、消费者、商品等多维度的费率配置及对订单收费计算。
• 产品-渠道路由：支持产品下，根据权重、稳定性、费率、最低单量、定制等不同维度的衡量标准选出匹配的渠道。

领域服务层之下，是支撑这些服务的组件：

• 业务规则相关：投保校验、理赔校验。
• 资金相关：保费收取、保费退回、投保记账、理赔记账。
• 渠道相关：渠道投保、渠道理赔。
• 风控相关：风控投保审核、风控理赔审核。

应用架构如下图：

4、后记

在有赞电商生态中，还有许多保险类业务可以切入的场景，比如准时发货保障，针对美妆类过敏包赔的承诺，对生鲜、3C类的损坏赔付等。这些场景对有赞保险业务的能力建设提出了更高的要求，保险系统将向高复用、易扩展的方向继续演进，以支持业务的拓展。

注：

1. 投保人是指与保险人订立保险合同，并按照合同约定负有支付保险费义务的人。
2. 保险人是指与投保人订立保险合同，并按照合同约定承担赔偿或者给付保险金责任的保险公司。
3. 被保险人是指其财产或者人身受保险合同保障，享有保险金请求权的人。投保人可以为被保险人。
4. 受益人是指人身保险合同中由被保险人或者投保人指定的享有保险金请求权的人。投保人、被保险人可以为受益人。
5. 保险金额是指保险人承担赔偿或者给付保险金责任的最高限额。