家政O2O工单系统设计全流程复盘：从调研到功能设计

编辑导读：工单系统，是用于客服-客服、客服-业务、业务-客服之间沟通工具系统，它的主体使用人员是客服工作者，同时也会包含其他需要联系的业务人员，是个比较典型的To B产品。本文作者对工单系统从调研到功能设计的全过程进行了详细的梳理分析，希望通过此文能够加深你对B端产品的认识。

前些时间参与了一个面向家政公司的工单系统，现在系统研发接近尾声，自己收获很多。希望通过复盘的形式巩固自己学到的知识，同时也能帮到在B端产品路上前进的小伙伴。

本文详细记录了工单系统从调研到功能设计的全过程，适合初级产品经理阅读，有助于形成系统设计的基本方法论。由于隐私限制，部分关于公司内容已删除，同时受篇幅限制，文章复盘内容只展开关键部分，小伙伴只要懂得大概方法论即可，无需过多关注细节。话不多说，开始阅读吧。

一、确定调研目标

1. 确定工单系统的定位，战略目标，未来的发展规划；
2. 调研公司当前的组织架构，经营策略，管理模式；
3. 调研当前的业务人员的工作流程，工作内容及工作细节；
4. 梳理当前业务现状和痛点，确定优先级；

二、梳理调研结论

通过访问公司CEO和公司总经理，确定以下内容：

1. 确定工单系统的定位是希望可以取代现有的手动派单的工作方式；
2. 战略目标是通过工单系统实现业务线上化，信息化，进而提高公司业务效率；
3. 未来的发展规划是把工单系统拓展为商城后台，客户可以在小程序上下单，后期拓展为公司内网系统，同时支持以家政为核心业务，以生鲜电商，房屋中介，相亲交友，商家联盟为辅助业务的公司战略，推动公司信息化；
4. 确定公司的组织架构图，在管理模式上，公司采用统一管理模式，员工统一向对应负责人报告，负责人向总经理报告，总经理向CEO报告；
5. 为了和市场上同类产品差异化，公司的家政产品大多采用年套餐形式，比如19999元保洁50次，6999煮饭20次，主要的目标客户是有住家保姆的家庭。
6. 近期内不考虑以低利润率获取市场的进击的营销行为，需要保持10%-20%的利润率。营销注重口碑，希望通过老客户去获取新客户。在保住现有市场份额的情况下，在其他区域获取更多客户，达到扩大市场份额的目的。

组织结构图

三、绘制系统运转流程图

通过亲身体验相关岗位以及访问负责人，一线从业人员，绘制出了公司运转流程流程图，具体如下：

系统流转图

四、梳理关键业务问题

经过调研分析，总结了目前遇到的问题，具体如下：

1. 客户购买服务只能通过线下付款，下单效率低，同时也不方便传播；
2. 客户可以通过多个渠道购买形成订单，但是没有统一的订单中心，订单整理容易出错；
3. 手动派单，不但容易出错，而且会出现员工工单超出或者员工没有工单的情况；
4. 手动统计剩余工单数量，非常耗费精力；
5. 上门服务员工只能通过企业微信等聊天工具通知，效率低；
6. 服务种类多，价格也不同，工资结算非常复杂；
7. 对员工的管控能力弱，容易出现员工虚假作业问题；

五、解决思路

• 实现订单中心，订单中心记录着所有订单，管理人员可以导入订单（高优）；
• 实现工单中心，通过订单生成工单，同时完成派单（高优）；
• 实现风控中心，保证员工不会约超（高优）；
• 实现对账报表，确保订单，工单间的数据的准确性（中优）；
• 实现员工端小程序，确保服务内容通知到位，杜绝虚假作业（高优）；
• 实现客户端小程序，确保客户可以通过小程序快速下单（中优）；

六、核心业务流程

设计业务系统，应该要从核心业务流程开始。以核心业务流程为中心，向外拓展其他业务流程，从而形成紧密配合又相互独立的业务结构，这样设计的系统不但满足不断增加的功能，同时也能支撑不断增长的业务量。下面先来梳理业务系统的主要流程。

很明显的，这套业务的系统的主要流程是派单流程，也就是由订单中心-工单中心-派单形成业务流程，流程图如下：

主要流程图

产品定位

经过对公司高层访谈，我们知道公司目前要解决的问题是线上化派单，所以面向客户的小程序暂时不做，但是需要预留好相应的功能接口。基于派单线上化，判断公司需要一个控制台。由于控制台涉及对产品，订单，工单，员工的增加，删除，修改等复杂操作，所以只在PC端实现。同时上门服务员工需要收到工单消息，以及服务打卡等行为，所以还需要实现员工端。基于成本和便利性考虑，目前只做微信端的小程序。

基于以上分析，我们将工单系统拆分为三个独立部分，分别如下：

1. 商城前台：通过小程序实现，面向客户，主要功能是客户下单，客户预约工单；
2. 运营管理后台：pc端实现，统一管理整个系统所需要的订单，工单，员工，产品等所有信息；
3. 员工端前台：小程序实现，面向上门服务员工使用，主要是通知员工工单信息和员工服务打卡等功能；

七、应用架构设计

该公司首次实现线上化，没有任何代码基础，所以我们需要在设计每个模块的时候，要以服务化为目的，以便后续与其他功能模块相互合作，实现更复杂的功能。在后续会一一介绍每一个功能的设计要点。

系统架构图

八、功能模块设计

从调研中可以了解到，客户端小程序的主要功能有客户购买商品和预约上门服务。从用户使用流程来说，购买商品包括商品分类，商品展示，商品详情页，生成订单，付款等功能模块；预约上门服务包括创建工单，选择地址，展示可预约时间，查看工单详情，查看服务人员详情；

员工端小程序的主要功能是帮助员工更好地完成工单，功能模块包括接单，查看工单详情，导航，上门服务，打卡；

系统管理后台的功能模块可以分为管理模块，查询模块，财务模块，其中管理模块细分为产品管理，订单管理，工单管理，员工管理；查询模块细分为员工查询，订单查询，工单查询；财务模块细分为结算模块，对账模块，发票模块；

演进蓝图设计

在功能模块中，我们尽可能将所有能想到的功能模块一一列出，这是一个做加法的过程，我们不可能一次性实现全部功能，这个时候需要根据业务优先级，将功能模块拆分多期来完成，这是做减法的过程。确认产品功能规划和实现节奏，这就是常说的演进蓝图。

如何确定优先级呢？大家可以根据以下原则去确定

1. 优先解决频次高，工作量大，机械程度高的业务；
2. 其次是支持第一点业务的功能；
3. 最后才是风控，运营等相关功能；

以下是具体的演进过程设计

一期（实现订单-工单-派单主流程）：

1. 在对外系统中完成员工端小程序，系统管理后台；
2. 管理中后台完成产品中心，订单中心，工单中心，员工中心；
3. 业务单元支持系统中完成风控验证；
4. 基础架构支持系统中完成Passport（基于RBAC角色控制理论进行设计），Auth（微信小程序），Gis（腾讯地图接口），Msg（派单信息传递）；
5. 数据底层和应用中完成MDM（客户主数据系统）；

二期（实现客户端小程序并完善系统管理后台功能）：

1. 对外系统中完成客户端小程序；
2. 管理中后台中完成客户中心；
3. 业务单元支持系统中增加CallCenter，风控验证中增加客户端创建工单限制；
4. 职能单元支持系统中增加Finance；
5. 基础架构支持系统中增加Pay（微信支付）；
6. 数据底层和应用不增加内容；

三期（增强系统能力，并为后续功能研发做好预留功能）：

1. 业务单元支持系统中增加CRM初步能力（可以适当采购），增加CallCenter，风控验证增加订单-工单不符校验，员工调派校验等；
2. 数据底层和应用实现Data WareHouse，Data Mart，BI，Data Mining等底层模块，为数据分析做好准备，同时为集团的业务拓展留下预留功能；

九、业务数据建模

经过业务调研，发现目前业务方有如下诉求：

1. 要有产品中心，产品主要可以分为三种类型，一种是按上下午，晚上计时的服务商品，一种是按小时计时收费的服务商品，最后一种是以上两种混合计时的服务商品；
2. 要有订单中心，订单中心有客户端小程序中的订单，线下订单，第三方平台的订单；
3. 要有工单中心，管理员根据客户的需求可以在后台生成工单，客户在小程序客户端生成；
4. 要有派单系统，工单要和对应的员工匹配，提高效率。匹配方式要自由多样，方便安排派单。员工一天只能工作八小时，不能超单。为了能快速查询到哪些员工可以派单，需要查询员工派单记录；
5. 上门服务员工可以在员工端小程序接单，上门服务后可以完成打卡，拍照；
6. 员工服务完成后，根据工单的具体情况结算工资；

E-R图如下：

十、具体功能实现

1. 客户端小程序

流程图设计如下：

页面流转图设计如下：

页面设计如下：

2. 员工端设计

流程图：

页面流转图：

页面设计

3. 后台员工权限设计

经过调研，明确业务方有以下诉求：

1. 管理人员可以控制员工可访问的页面及使用的按钮权限；
2. 管理人员可以控制员工的数据访问范围，包括哪些数据可以访问，哪些数据可以可以编辑；
3. 管理人员可以控制员工可以访问哪些功能模块；
4. 管理人员可以控制员工可以控制哪些角色和职能；

设计思路：

1. 管理人员可以管理员工访问数据的范围；
2. 按钮，页面全部接口化；
3. 根据RBAC原则设计角色；
4. 数据对象可编辑，可设置；
5. 管理人员可配置员工访问的角色的范围；

具体设计页面如下：

4. 产品中心

经过调研，明确业务方有以下诉求：

1. 依据服务时间的统计规则不同，产品可以分为保洁类产品和工程类产品。其中保洁类产品的服务时间为上午，下午和晚上三个时间块，而工程类产品的服务时间是按小时进行统计。
2. 不同产品对应着不同的工单，需要不同技能的员工服务；
3. 产品根据地区进行划分，由于服务员工不同，不同地区的产品可能不同；

设计思路：

1. 在新建产品时，增加产品分类字段，用来区分产品是保洁产品还是工程产品；
2. 在产品中增加表示服务时长，技能及对应员工数的字段，生成工单后自动抓取该信息形成派单信息；
3. 新建产品时增加地区字段，保证产品按地区划分；

页面设计：

5. 订单中心

经过调研，明确业务方有以下诉求：

1. 订单中心中包含三种类型订单，分别是小程序订单，线下订单，第三方平台订单。
2. 查看订单的剩余服务情况，清晰客户的到期情况，方便平台客服提示客户复购。

设计思路：

1. 设计导入订单功能模块，可以导入线下订单，第三方平台订单，后续可以尝试接入第三方数据平台，实现订单自动导入；
2. 设计客户中心，通过客户中心可以快速找到客户对应的订单，服务，工单和其他数据。
3. 设计客户到期管理中心，通过客户到期管理中心，客服可以快速找到服务即将到期的客户，后期可以拓展为线索池模块。

页面设计：

订单中心

客户到期查询

6. 工单中心

经过调研，明确业务方有以下诉求：

1. 创建工单时不能超单；
2. 派单要灵活。比如：一个4小时的上门服务订单，可以安排1个人服务4小时，2个人服务2小时，4个人服务1小时；
3. 导入历史工单后可以得到准确的客户的可用服务情况。
4. 在派单过程中，可以直接看到符合工单要求的员工，快捷派单。

设计思路：

1. 设计创建工单验证中心。后台创建工单限制低：员工对应的剩余服务时间总和大于等于产品的服务时长，则可以创建成功。小程序创建工单限制高：员工需要满足产品设定好的员工，技能，服务时间要求才能创建工单成功。
2. 在编辑工单模块中增加编辑工单类型，员工服务时长，技能和人数选项。
3. 增加历史工单导入功能；
4. 增加工单与员工间的匹配功能；

页面设计如下：

以上是对自己对这段时间完成的工单系统的复盘。

参考资料：

《决胜B端》杨堃

 

作者：宝宝心里苦啊；公众号：宝宝心里苦啊

本文由 @宝宝心里苦啊 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。