低代码平台：快速构建售后服务工单管理体系，完成企业数字化转型，工单管理系统设计——架构篇

工欲善其事必先利其器，企业想要售后服务品质有所提升，少不了称手利器的加持。工单系统作为一种企业售后服务的平台，是提升售后服务效率的利器之一，正慢慢被企业所接受。

传统行业售后所面临的服务效率低，服务过程不透明，仓储管理困难，经营数据难统计等行业痛点，我们可以搭建一套工单系统，实现售后服务上“管人”“管物”“管钱”三大核心管理需求，解决行业痛点，并进行多维度数据统计分析，让数据辅助决策，满足企业现在和将来的业务发展的需求。

如家电维修行业的售后服务，消费者购买家电所需要提供的上门安装服务，家电损坏后的质保维修服务等，涉及的工程师调度，配件的领用，服务状态跟进，相关的费用清单、成本结算统计，都需要规范化的流程管理，工单系统则是助力企业将其实现流程化、信息化管理的中间介质。

工单系统在实际应用中是否能够高效解决企业售后管理问题，我们可以通过低代码平台搭建的YiTS系统进行解读：

首先，各类家电服务商遍布全国各个城市，售后维修网点、安装网点众多，想要实现统一的网点规范管理，少不了软件系统的辅助，通过YiTS系统实现对各驻点工程师进行智能化管理，实时跟进工程师的工作状态，根据消费者所在区域及售后类型，合理派工，灵活调度，实时跟进工单完成情况，可有效避免消费者等待超时，或无人响应服务等情况。

系统内部工单的管理，可按工程师实际情况进行手动派工或自动派工，工程师可基于移动端随时查看工单、自动/手动接单、更新工单处理状态，确保每一个工单能够及时分配，服务状态实时更新，服务过程透明化。

其次，家电服务行业少不了各类产品配件的维修、安装、使用、更换，为了避免配件的浪费、流向不清等情况的发生，YiTS系统内提供了仓库管理功能，清晰记录每件产品的进出库情况，工程师领用记录及产品的去向明细，各网点间的产品也可灵活调配，减少因产品缺乏造成维修进度缓慢，产品异常等情况。

对产品库存的管理，可通过系统流程配置，设置库存预警，当库存异常时，系统会及时发出预警提醒，提醒及时了解并补充产品库存，产品的调用同样可以设置提醒，产品调用后及时提醒被调用网点，以防网点产品不足能及时补充。

最后，企业的财务对账分析、经营核心数据等，通过低代码开发平台建立数据门户，生成可视化数据报表，在YiTS系统内直接复盘分析企业经营状况，物料备件库存情况，工单服务满意度等，让企业管理者能够实时掌握企业运营状态，及时调整经营策略，优化企业管理。

对于有以旧换新、购物赠送等促销活动需求的企业，可直接通过低代码开发平台在YiTS系统内扩展销售管理功能，完善企业旧物回收入库，新物出单发货的销售流程管理，实现从下单-备货（调货）-出库-发货-到家的全程监控，让企业各环节各流程都能实现数字化管理。

企业选择低代码开发平台搭建工单系统应用，不仅能缩短开发周期，多维度响应企业需求，建立企业一站式售后服务管理体系，还能满足企业对各类管理软件无缝集成和扩展，是企业数字化转型的强大助力。

万丈高楼平地起，在盖楼的时候，先起地基。产品设计先定架构，再打磨细节。接上一篇《工单新义》今天我们开始聊工单的架构。

一、产品架构

架构，高大上吧，逼格高吧，我们经常会听到一个：架构师的岗位，那架构到底是啥？其实我也不是很了解，这里我就简单谈一下我对产品架构的理解：产品架构是基于业务、深入了解用户需求之后，从0-1开始设计完整的产品方案。

好的产品架构能够完整支撑现有业务诉求、用户需求和管理诉求，同时在业务、用户、管理诉求发生变更的时候，能以最小的实现价值实现对这些变更的支持（有点中台的味道吧）。产品架构的设计离不开数据和用户。

1. 数据

设计产品架构其实是在设计业务线上化，业务线上化的展现形式就是流程，再深入一点：流程是数据+顺序+权限构成，我们在设计产品架构的时候，其实本质是在设计数据的来源、去处，明确数据从哪里来到哪里去。

2. 用户

这里的用户是角色的概念，一个产品的用户不是单一的角色，产品需要支撑多角色共同的诉求，而产品架构应该是最了解用户的，也是可以满足所有的用户诉求的。

再总结一下：梳理产品架构其实是业务线上化的过程，其实也就是梳理数据和用户操作诉求。

二、设计框架前需要明确两点

《工单新义》中已经明确的解释了工单系统是什么，做一个简单的概括：工单其实是一个支撑系统，为了支撑其他业务而存在，所以在设计工单的框架的时候，既要考虑工单本身，也要考虑其他的系统，在设计工单之前，我们先要考虑两点：

1. 工单系统设计需要考虑全公司

谈到工单，我们会联想到：客服。总觉得吧，客服人员是工单的使用人员，然后基于客服的诉求开始设计工单，常常会忽略其他部门。

这样设计出来的工单不仅会给客服造成影响，也会给其他部门带来不便，常见的场景就是：客服线下登记表格，发给其他业务部门，其他部门处理结果客服不知道，反复询问。因外部业务产生的工单（系统自动生成），客服经常会作为第一接收人，有很多情况下，客服人员是无权处理的，是需要其他业务部门支持的，工单系统设计，要考虑全公司。

2. 工单系统设计需要考虑其他系统

工单中有很大一部分数据是来源其他系统的，或者说是其他系统的某个动作导致了工单的产生，当然这一部分不用过多考虑，原因是：其他系统的动作产生工单，对于工单系统来说，就是接受了你的数据而已。

需要考虑工单处理完结或者产生某个结果时，对其他系统的影响，比如：一个订单的退款申请导致了工单的产生，经过客服人员的处理，同意了订单的退款，那么就需要让订单的状态变为：已退款（状态根据自己公司的业务确定即可），其实这个就是工单需要考虑全功的线上呈现。

至于什么新建、分配、了解业务、工单状态这些是必须的，就不在这里赘述了，后续文章会对这些展开详细讲解。

三、工单框架设计

框架图的样式是像上图呢还是思维导图，客官们自己判断吧，这里就不画工单的框架图了毕竟没有一个业务场景（主要是懒），主要就以框架里面需要考虑的内容展开吧。见下图：

工单内容：

工单页面中主要记录工单信息，和工单关联信息，比如一个工单就需要有发起人、类型、内容、状态等信息，同时提供处理工单相关联的信息，如订单。

工单状态：

工单在创建好以后，是需要流转的，是需要用状态来标识的。

工单日志：

工单从创建到最终的完结有一个过程，工单日志主要记录这个过程以及这个过程中不同人员对工单的操作。工单日志可以分成：系统日志、操作记录等。

工单分配：

工单创建好以后，会有不同的人员对工单进行处理，就需要提供工单分配功能，需要支持系统分配和人工分配。

工单类型：

工单内容记录的是不同业务场景下的问题，在工单系统中以工单类型来区分，不同的工单类型有不同的使用场景，会产生不同的处理结果。

处理人员设置：

工单的处理人员基本会基于类型进行设置，即不同的工单类型第一处理人不同，通过处理人员设置，系统就可以将工单自动进行分配，同时也可以基于处理人员的设置来进行工单权限的判断，有A类工单处理权限的人员可以在系统中看到A类工单，可以等待系统分配，也可以自动去接工单处理。

处理结果：

工单处理有了结果以后，就需要客服人员进行记录，记录好以后，触发其他系统的单据或者操作。

分析报表：

通过对工单问题的分析，可以反推业务的优化，通过对工单处理时长的分析，可以对工单SOP进行优化，而这些都离不开工单报表。

工单系统的框架离不开以上内容，业务的调研、需求的梳理最终也是对以上内容的不断优化，在设计工单系统的时候，就围绕以上八点进行展开、细化，结合我们的实际业务诉求，设计出一款好用的工单系统（所有的工单系统都是围绕以上八点进行设计，好用的只是更加符合业务诉求和操作诉求罢了）。

四、最后说几句

工单系统本身并不复杂，做一款工单系统、一款通用的工单系统很难，毕竟每一个公司的业务场景、系统功能不一致，所以很难将工单系统saas化，如果不考虑其他系统对接层面，那么可以考虑将其saas话，然后通过集成的方式处理（不过，工单系统本身复杂度不高，集成的成本可能远远大于开发工单系统的成本，客官们自己考虑即可）。

工单框架本身不复杂，复杂的是细节的设计、工单使用者的习惯、以及工单处理的培训成本，作为产品，我们要考虑前两个，后面这一块只能说尽可能的去支持，毕竟工单的处理是业务层面上的事情，我们能做的就是把系统做好，让使用者更方便的去处理系统层面无法处理的工单。

从上一篇工单新义开始，工单系统系列文章已经开始，基本会保持每周更新一篇的节奏，从工单定义到工单框架在到工单细节的设计都会讲到，产品小伙伴可以关注一下，当然如果有什么问题、想吐槽写的不好的地方、有什么希望在后续文章里面详细介绍的都可以通过留言的方式告诉我。

「上述就是小编为大家整理的工单管理平台」