zoukankan      html  css  js  c++  java
  • Java生鲜电商平台-生鲜系统中商品订单系统售后系统设计

    Java生鲜电商平台-生鲜系统中商品订单系统售后系统设计(服务订单履约系统)

    说明: 电商之下,我们几乎能从电商平台上买到任何我们日常需要的商品,但是对于很多商品来说,用户购买发货后,只是整个交易流程开始的第一步,后续商家提供的上门服务才是整个交易过程中用户对商品和品牌感知力最强的时候,如何抓住这最后一公里实现用户体验和商品品牌效益最大化,是各个品牌商打造占领品牌核心竞争力和占领口碑的战略高地时不得不考虑的关键。本文将与你探讨以location为中心的生活服务平台的核心——服务订单履约系统。

    什么是服务类商品的订单履约

    例如:当客户有安装维修家政的服务需求,并且在系统中下单后,系统会产生一张服务订单,包括订单信息、发票、费用、优惠、时效、预约、上门、服务、评价等等内容,从订单的产生到这个服务订单完结整个过程被称为服务订单履约。履约系统的主要目的就是让我们能够高效优质的完成服务从线上到线下的全过程,保证用户和客户的满意。

    生活服务平台的订单履约系统的架构和核心功能

     
     

    从订单数据的上下传通道来看,整个系统涉及三大部分:订单转换中心、服务订单履约中心、业务支撑模块中心。

    履约中心的上游是转换中心,主要是对接各个产生销售平台的订单,常见的有品牌商天猫、苏宁、京东的店铺,这些平台上的店铺订单结构和信息格式都不尽相同,为了能将订单统一化管理,不能因为每个平台的订单信息调整变更系统的主体结构,所以在订单转换中心会针对不同的平台推出不同的订单适配器,将各个平台产生的订单进行结构和格式的统一,便于我们接下来的标准化流程的推行。

    订单适配器主要是对商品信息、客户信息、物流信息、服务信息等内容进行统一格式的翻译,以及部分信息(服务人员、服务状态、预约时间、时间节点信息、服务照片、服务定位等信息)的回传。

    服务订单履约中心是整过服务平台的核心,通过订单转换中心与销售平台进行信息同步和交互,履约中心内部通过服务调度、订单管理、订单计划、时效考核等多个系统以及风控、财税、结算、客服等多个外围系统对订单的各个环节流程进行把控,支撑和管理服务人员以及服务订单,进而完成整个服务流程的监管和标准化运营。

    服务履约流程的详细讲解

    一个服务订单从产生到完成一共要经历十余个关键的履约节点,涉及销售平台,订单转换中心、服务调度系统、订单匹配系统、时效监控系统、财务系统等多个子系统。

    生活服务属于线下的供给,和以实体商品为中心的交易平台不同,生活服务提供的是到家的服务商品,客户在电商平台购买产品后,只是服务履约过程的开始,区别于基于SKU为中心的服务,上门生活服务的核心库存是服务人员的服务能力,服务能力极大的受限于不同区域的服务能力储备,并且上门服务能力的资源调度响应度要远小于网约车这种短服务周期的服务商品,而且受限于不同的地区的成本,每个地区的的不同区域都可能采取不同的运营方式,在这些遍布全国的网点中,怎么样保证在各个区域极为有限的服务能力情况下保障各个环节的时效性与异常及时响应是服务履约系统的核心,每一个环节的卡顿和不及时,都会导致履约过程的延长,影响的是终端用户对品牌商的信任和品牌商对服务平台的信任。

     
     

    新订单

    新订单来源一般分为三类:对接品牌商的三方电商商户平台,品牌商的ERP系统对接,自有销售平台下单。

    三方电商平台对接:针对B端客户的品牌商在电商平台开设专卖店,各个电商平台对于生活服务类产品都有专门的接口开放,主要包括订单信息数据交互、服务信息数据交互、时效信息数据交互等等。以天猫平台为例,天猫的家装类商家的服务订单都需要通过天猫的喵师傅平台进行对接,所有的订单都需要服务人员通过喵师傅APP进行核销完成,天猫才会与商家结算服务佣金(这其中涉及到天猫的对不同的服务内容有不同的考核要求,不详述),以此来管控天猫家装品类的服务质量,并完成对各个服务平台的考核。京东和苏宁等平台也都有各自的安维服务对接系统。

    品牌商的REP系统:B端的客户会有很多的销售渠道,并且最终把所有渠道的订单统一用ERP管理,这时候我们只需对接ERP系统后,定时抓取ERP中产生的新订单,并把订单格式转换为统一的订单格式即可。

    自有销售平台下单,一般服务平台都会有自己的下单平台,在自有平台生成的订单按照我们需要的标准订单格式来处理即可。

    订单拆分合并

    在用户实际购买中,主商品是需要分派到服务平台下发服务任务的,可是用户的支付订单往往还伴随着无需上门服务的商品(如赠品、其他商品等)或者需要多个工种分别上门服务的时候,我们需要对订单进行拆解与合并,只提取对应需要服务的商品信息并生成订单。

    订单信息审核确认

    当我们生成服务订单后,往往需要商家确认一遍这些订单都是真实需要服务的订单和服务价格(服务成本受限于地域和时效,不同的地区和不同的服务上门时间价格都不同),避免因为刷单或订单拆分过滤不完全造成的服务资源的浪费(个别时候也会存在订单丢失的情况),产生额外空跑费用。当然人工审核有利有弊,根据客户实际情况调整即可。好处是但是对于有刷单需求的电商店铺来说,可以避免很多虚假订单增加额外服务成本,缺点是商家需要额外安排人员进行手动审核过滤,影响的服务时效的履约过程以及电商平台对服务时效的考核指标。

    订单分区域

    中国有3185个市县,每个区域的经济发展水平都不同,这就导致了各区域的服务成本和服务人员素质的不同,搭建全国的服务网点,势必要考虑到西部地区的很多区县面积大距离远,部分特殊的商品因为对服务人员的从业素质要求比较高,所以在这些地区服务人员就成了极其稀缺的资源,对于一些特殊商品,几个县内只有一个人能完成订单的情况不在少数,单程服务距离超过50km也是常事,这时候我们在订单区域与划分与时效考核上面需要针对不同的区域制定不同的服务标准、费用结算标准与催单机制。

    对于订单区域的划分我们有两种处理策略:1.无服务能力的区域无法下单(生成订单)2.无论是否有服务能力均可以下单。

    第一种策略的优势在于我们的订单与运营拓展的服务区域匹配,典型的有金刚钻才揽瓷器活的方式,这种策略对于平台的服务能力、规模到一定程度后,无法覆盖的服务区域较少/投入产出比较差时,采用此策略。

    第二种策略的优势在于我们平台搭建初期,不是所有的订单都会有服务能力覆盖,我们需要借助这些订单的区域去重点拓展我们的服务能力、范围,根据订单的服务区域拓展服务区域在平台发展初期有较强的性价比,可以用最少的人力实现效益最大化,但是对于服务的质量管控和时效的考核上会有一定的不足,这需要在运营上进行弥补和风控。

    订单派单类型分类

    这一步我们需要对订单类型进行分类,安装、维修、回访、测量、售后等等,不同的商品涉及的具体服务类型都不同,有资质的服务网点和服务人员也都不尽相同,我们需要在这里对服务内容、服务区域于服务能力进行关联匹配并完成派单,保证合适的订单发到合适的人(网点)手上。

    服务分派

    在服务订单分派时,我们通常会使用三种派单调度方式:中心调度、抢单调度、人工调度。

    “中心调度”优点在于每个服务订单必有人认领,系统可根据各个区域的服务能力按照一定的比例规则分配订单,现在采用中心调度基本上都是自营服务网点或者强协议关系的合作网点,这样的好处是可以通过协议或者大额押金进行约束,以此完成对服务质量的强管控。缺点在于,由于是自营的服务网点(固定人力成本较高),该区域需要有稳定大量的订单量才能维持网点的正向运转,所以一般在城市的主要城区一般会采用这种方式搭建服务网点。

    “抢单调度”优点在于每个服务人员都会根据自己的个人能力进行抢单。主要区域的抢单也可以促进服务人员对自我能力提升的积极性。缺点在于1.对于服务能力不足的地区会导致无人接单;2.困难的订单(风险大)会无人抢单,造成超时;3.非平台标准定价的订单会有卖家订单价格过低的导致无人受理的情况;4.服务人员挑单以及服务质量和售后都无法保障。

    “人工调度”显而易见,就是由平台客服进行手动派单,由于“中心调度”“抢单调度”不能够保证订单100%都有人受理,剩下的无人受理的订单、平台无服务范围覆盖的订单、紧急订单、重VIP订单均需要人工手动介入处理,同时对于服务事故订单、异常售后订单、服务费用变更等情况均需要人工介入进行调度。优点是精准度较高,订单全程有专人跟踪,缺点是成本较高。

    在平台的构建中,三种订单调度的方式需要相互结合来让效益最大化。

    服务订单受理

    服务订单受理是客户对于服务过程感知开始的第一步,这一步的时效也是服务平台需要重点考核的内容,当客户的订单生成后,服务人员需要在承诺的时间范围内接单确认受理。在此过程中需要对时效进行监控,时效预警常见会分为这样几级别:

     
     

    服务订单预约

    订单预约分为两种:客户主动预约、服务人员主动预约。

    客户主动预约:我们需要给客户提供订单预约的入口,同时还要计算服务库存,一般对于服务时间能够达到标准化以及服务能力可控的服务商品均采用此方式,如平台自营的家政保洁类服务均是采用此种方式。客户提交预约信息后需要尽快给予客户反馈告知客户预约有效。

    服务人员主动预:在服务人员的系统中提供预约入口,服务人员与客户通话商定服务时间后录入系统中完成预约过程。

    值得注意的是风控层面来说,这个环节最好加入预约真实性核验的机制,防止服务人员虚假预约,然后虚假完成订单骗取结算款的情况。常见产品层面的思路就是监控服务人员的通话记录来判断是否与客户产生了真实的预约通话,直接调用通话记录的方式比较原始,且安卓和IOS系统的限制较多,所以目前部分平台在使用AXB的中间号的方式来进行监控,对这就对平台的技术和AXB号码的服务提供商提出了比较苛刻的挑战。但是市面上仍有部分体量较小的服务平台因为受限于技术和成本的原因,采取只发布安卓客户端的方式,毕竟在安卓系统中是能够拿到用户通话记录的,IOS中是获取不到的。

    订单时间&路径规划

    对于已确认预约的订单,服务人员需要在系统内能够看到自己的订单时间分布,每周的每一天分别有哪些待处理的订单,哪些天被安排的比较满,哪些天还没有安排比较空余,一天上午中午下午晚上的订单分布如何,这样的规划对于服务人员在与客户预约时能做到合理安排时间。在服务人员当天上门时,有的订单是预约在上午,有的是在中午,有的在下午,有的在晚上,我们通过以时间为主地点为辅的方式帮服务人员完成当天最短的行程路线规划。

    服务

    服务是整个履约的核心,也是系统始终无法替代的环节,这一环节的管控的核心主要是真实上门服务,而不是虚假服务。我们通过获取定位与服务地址进行比对的方式判断,但是受限于不同手机的定位精确度以及服务环境GPS信号的问题,产生位置偏移的概率较大,地址信息作为评判的参考之一。所以通常都是以服务完成后的服务反馈来倒推服务上门的真实性。

    服务核销 POI核销&照片

    服务核销是判断服务人员是否真实履行服务的重要依据,常见的核销方式有核销码核销、POI核销、照片核销。

    核销码核销:核销码发送到用户手机上,并提醒用户只有在服务确认审核通过后才给予服务人员,服务人员在系统中核销时,订单号与核销码一一对应即可完成订单核销,此订单判断服务完成。这种方式服务人员与用户的交流成本提高,但确实是把握订单核销真实性的有力的方式。

    POI核销:基于地理位置点的核销方式,受限于不同手机的定位精确度以及服务环境GPS信号,可作为提升判断核销准确性的方式之一。

    照片核销:照片核销基本上是每个平台完成订单的必要条件,但是照片从实际来说只能作为辅助判断,不可以作为必要的评判标准,因为服务现场我们是不得而知的,服务人员拍照时可能会规避一些服务缺陷营造完美完成的情况。

    总的来说我们可以只提供一唯一的核销方式,也可以使用几种方式进行组合来完成这个服务结束的过程,具体根据服务商品的特性和运营方式来确定即可。

    服务审核回访

    每个订单都要有固定的审核周期,审核服务的完成状况,这一步根据情况放在商家端或者平台审核,按照一定的规则筛选出需要回访的订单,如果出现服务异常则在此周期内冻结服务费用,重新走售后订单的处理流程即可。订单审核通过或者超过审核期后未审核时才会进入费用结算流程。

    对账结算

    对账结算根绝服务人员特性的不同分为月结、零散结算、线下结算三种方式,月结针对的是大的服务网点,每个月有固定的账期,按月对账打款提现,当订单的结算金额在该账期内解冻后,便释放到当前账期的结算池中,等完成对账等必要财务流程后,打款结算。零散结算是订单被释放一笔可提现后,即可提走,无提现窗口期的限制。线下结算有一定的风险,但是在实际的业务环境中仍是不可避免的,所以系统中需要保留此项操作,每个平台的运营和结算规则都不同,还有一些会涉及到税务和票据的情况,根据自己平台的实际情况制定合理适用的结算规则和结算风控规则即可。

    服务完成

    订单提现打款结束,整个服务履约过程结束。

    结语

    以上便是一个服务订单从创建到完成的全过程以及各个环节的核心关注点,本文只描述了通用的服务核心环节。在实际业务环境中,对于不同品类的服务订单履约,肯定会有不一致甚至冲突的地方,需要我们系统性的规划整个履约系统,适合自己业务的才是最好的,理解文中的精神纲领。文中提及的服务履约过程每个环节详细展开都能成文,而其中涉及到与订单风控、财税、结算、工单、评价等系统之间的交互等都未展开,那就待续吧。

    联系QQ:137071249

    QQ群:793305035

  • 相关阅读:
    JSON 语法
    AJAX 原理与使用
    SpringMVC MVC 架构模式
    HTTP 协议
    OSI 七层参考模型与 TCP/IP 四层协议
    MyBatis 延迟加载(十四)
    关于JVM调优
    mysql的锁
    spring boot启动原理
    redis相关问题解决
  • 原文地址:https://www.cnblogs.com/jurendage/p/12068631.html
Copyright © 2011-2022 走看看