用户买保险的心理，是想为未来的风险求一份心安，一般不会盼着自己去理赔。不过，一旦真的出险了，那用户要理赔成功的需求就会非常强烈。
一、背景
线上理赔的流程可以简单概括为：报案、审核、结案。以理赔成功为例，用户关注的大致有以下几点。
能否理赔成功，主要是保险公司决定的，我们暂且不讨论。审核流程咱们也之后再说，本文主要讨论的是报案。
1）顺利找到报案入口：入口明显一些，多一些曝光；
2）及时得到理赔指导：这个主要靠业务（理赔专员）的专业性和积极性；
3）准确高效提交所需理赔资料：用户端顺利提交资料其实有一个隐藏的基础条件，我们展示给用户的需要他们提交的资料是及时的、准确的、全面的；
二、问题分析
1、问题来源
理赔时所需用户提交的资料是与用户购买的保险产品相对应的，不同的保险产品所需不完全相同，当用户出险，可以选择按照页面提示上传理赔所需资料。
如果每一个保险产品所需要的理赔资料都让研发写死在页面上，那显然是不合理的，成百上千的保险产品的理赔流程页会让。
- 代码无意义重复
- 研发时间的浪费
2、解决方案
通过管理后台，实现理赔流程动态配置。既可以支持业务人员在管理后台灵活配置用户端的页面内容，也可以减少开发成本、提高开发人员的工作性价比。方便业务随时调整内容，不用因研发资源排期而耽误用户理赔。
三、功能设计
1、理赔流程页面拆解
每个理赔产品的理赔资料内容都不会完全不一样，页面上主要需要配置的信息有：是否可以理赔、支持的理赔类型、理赔资料、理赔资料提示、理赔资料示例图……
这些内容之所以出现在我们的眼前，都是通过管理后台进行配置上传。
2、管理后台
理赔流程的页面是由业务人员在管理后台新增理赔产品并配置相关内容后产生的。
2.1、申请理赔入口出现的条件
- 后台理赔产品处于启用状态
- 用户购买了保险产品
- 用户已过保障责任的等待期（取多个保障责任的最小值）
2.2、理赔产品状态切换
- 启用——禁用：新购买产品的用户不能看到申请理赔的入口，原先申请理赔的用户仍然可以进行后续流程
- 禁用——启用：新创建的理赔产品默认都是禁用状态，审核无误方可启用，yong户可见申请入口
2.3、编辑模版
虽然理赔所需要的内容因保险产品而异，但是大致也是有一个框架的。理赔的类型跑不出：医疗理赔、津贴理赔、重疾理赔、身故理赔、伤残理赔。每一个理赔类型所需的理赔资料（项目、提示、示例图）也很少会变化。
因此我们完全可以内置一个理赔类型和理赔项目的模版，方便业务编辑。
当然了，内置的模版是支持业务二次编辑的。
2.4、复制功能
画重点！一个内容配置后台，不可缺少的功能。可以有效减少业务人员重复劳动以降低运营成本。
2.5、用户信息联动
理赔流程大致分为「填写信息」和「提交资料」两部分。
用户在「填写信息」时选择的理赔类型需要和「提交资料」所需内容相一致。
用户投保时填写的信息需要在「填写信息」对应展示。
2.6、保障额度计算
由基本保额与计算公式得出的保障额度，方便业务人员查询和结案。
2.7、理赔特别说明
- 当用户住院未出院，不方便开始理赔操作时。我们可以通过理赔特别说明提示用户申请理赔时所需的材料，方便用户提前准
- 当用户方便操作理赔时。理赔特别说明页也可以起到一次性告知用户理赔所需材料的义务
2.8、信息输入优化
- 就诊医院。初期可以填写，在建立了平台自己的理赔医院信息后可优化为筛选
- 银行卡、身份证识别。初期可以填写，之后可对接三方OCR服务
四、总结
对于互联网保险来说，能否为用户提供快捷方便的理赔服务，是其树立品牌形象和提高竞争力的有效手段。
理赔流程的动态配置现在是一个很简单的配置。最好的方式是将页面内容拆分成组件，方便后续扩展。当然了一切基于业务，希望之后有可以落地的项目。
