从0-1搭建客服赔付域的功能架构

01 购物场景

在消费者购买前或者购买后总是会发生各种各样的问题，我们通过几个常见的例子来看看：

场景一：张三买了一双鞋，下单之后三天了都没有发货，气呼呼地找到了客服，对客服一顿抱怨：“为什么不注明发货时间？为什么发不了货也没有提示？”从此张三心里觉得这平台发货慢，有急需的东西的时候再也不来买了。

场景二：李四买了一件衣服之后，收到货之后一打开，衣服都破了，于是在平台操作了退货，供应商收到了退款之后，知道自己的东西不行，直接操作了退款。客服完全不知道发生了这样一件事情，李四心里觉得这平台的东西质量不行，以后买一些贵重的东西不来这买了。

可以看到的是这些列举的场景涉及到了很多方面的问题，有物流端的、有供应商端的，也会有平台本身的，要完善好这些问题，不是一朝一夕能够轻易的解决的，无论是系统还是业务流程都需要不断地的建立体系进行完善。但在运营的过程中会有很多的问题会发生，那难道在解决好这些问题之前，对于消费者的心智和留存就没有别的方法来挽留了吗？

答案当然是否定了，那就讲到今天的主题：赔付。

02 赔付系统设计

明确了相关的业务场景之后，我们可以初步对赔付体系进行一个定位：无论是售前或者是售后都会涉及到对消费者利益的损失，那么在这个时候我们就可以把这些会产生侵害的环节设计到对应的赔付系统当中。所以我们可以初步设计出赔付的体系：

赔付模型

我们把赔付整体分成两个大部分：第一部分：本域系统模型；第二部分：跨域协同；第一部分：本域系统模型先看一级流程图。

一级流程

在整个赔付体系里涉及的对象有：赔付方案、赔付对象、赔付操作人员、赔付金额、赔付权限、赔付审批、赔付订单、赔付售后单。

出于对场景的复杂性考虑，我们在后续的设计过程中应该考虑使用策略思维，通过单据和方案的匹配提高操作便利性和提高效率。另一方面通过对底层数据配置的方式完成多变场景的快速响应。

第二部分：跨域协作从模型的设计上会涉及到：供应商、财务、营销、交易、BI等系统的改造，那么做好跨域的数据传输显得十分重要，这样才可以保证系统的协调性，我们可以通过梳理 协议的方式呈现：

跨域协同

基于以上我们基本对赔付整体产品框架的搭建已经完成，下面就针对具体的落地方案设计产品的产品方案：

03 赔付产品原型

基于面向对象的设计，因为场景的复杂性，直接设计为各个模块互相独立，相互关联的方式，分为：

赔付管理：单据建立赔付单据，通过赔付单据和业务单据的管理，应用策略产生业务数据；

赔付单管理

赔付单新增

赔付策略：组合底层方案等数据，生成新赔付策略；

赔付策略

赔付方案：定义赔付金额，通过关联场景使用；

赔付方案

赔付权限：定义角色的赔付上限，控制成本使用；

赔付权限

数据字典：定义基础字段文本，无任何意义，各种地方调用。

数据字典

通过搭建各层数据，形成完成的数据结构，同时支持每层结构的新增和重新编辑之后再调用，从而达到系统扩展，快速响应的目的。

04 赔付数据监控

一切功能和场景的尽头都是数据基于这样的思想，我们在上线之前应该考虑好对应的数据监控方向：一是对上线功能的监控；二是对赔付数据的利用。

从而达到业务赋能数据，数据分析业务的目的。

05 结语

对于赔付的整个模块来说，这只是一个简单的起步，在各种场景补充进来后，扩展现有的结构，增加对象：如 供应商，等对象的参加到体系之后必然会对现有的结构产生冲击。再比如增加赔付的方式也会对现有的结构产生冲击，对于0-1的功能搭建，更重要的是对于结构健康性的考量给出相应的设计。

本文作者 @化鹿 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！