前言

从五月份到八月份，将近四个月的时间里，工作的重点主要在SAAS项目运营端的售后体系能力搭建上面，因为这次的需求内容比较多，时间周期会比较久，所以单独立了一个子项目来进行，采用小步快跑分版本迭代方式进行，子项目取名为「售后服务工作台」，以下简称为「工作台」。

一、项目背景

我们知道运营端主要是给实施、运营、销售人员使用的终端平台，目的是为了服务客户的售后相关问题。在SAAS软件这个领域中，实施和运营同学不仅要解决商户售后使用问题，还要努力提高SAAS业务的新签率、活跃率、续约率这三大业务核心指标。

目前售后服务的核心场景主要包括实施培训、促活流程、续约流程、商户管理等。随着业务的发展，运营平台在功能能力上已不足以提高售后团队的日常工作效率，相关核心工作需要规范流程，相关过程数据需要进行指标化统计。为此，需要一个可视化的操作面板工具来服务于业务团队，工作台就由此而来。

二、产品目标

搭建一个业务流程化、数据可视化的售后工作面板，通过系统功能规范化售后团队日常工作，通过数据反馈提升产品能力，一方面提高售后团队人效，另一方面为SAAS产品的建设提供有效数据反馈。

三、系统设计

在工作台项目搭建过程中，会涉及到工单的概念，目的是让各个业务流程以工单的形式进行落地化，能够实现人员转派、工单升级、催办逾期提醒、数据统计等功能，进而让售后工作高效展开。目前公司有很多工具都可以实现工单的上述能力，经过调研比对，我决定还是自己搭建一套简单的工单模型，其主要原因是由于我们自身的工单不只只是做日常工作的度量衡工具，在页面展示上还需要关联出业务数据的众多属性内容，接入公司的平台在数据聚合方面会显得尤为吃力，并且我们有很多个性化的场景会变更工单的状态流转，在自己系统中处理会更加方便。

系统设计包含了设计方案、业务架构图、产品架构图、系统架构图、逻辑流程图、运行架构图、时序图、实体关系图、数据库设计等，这些图有些是必须的，像运行架构图关系就不是很重要，不过为了全面好看点就都画了下。因为涉及到公司数据图形就不展现出来了，这里说一下相关图的作用：

业务架构图：站在产品人员或者说非技术人员视角上，来描述整个项目的功能流程。
产品架构图：站在技术的视角上，来描述出系统中的产品结构，从终端平台到页面功能再到服务名称。
系统架构图：对系统的服务架构进行说明，比如从负载层SLA+Nginx到网关层再到Web层->Service层->数据持久层，每一层的关系涉及的中间件都可以罗列出来。
逻辑流程图：通过流程步骤的关系，将业务场景表达清楚。
运行架构图：这里可以是站在技术的视角，将服务的运行调用链路关系说明清楚。
时序图：通过时序图，将业务流程的调用链路、调用方式、调用目的一一说明清楚，时序图可以很好的体现业务流程在系统中的执行情况。
实体关系图：区分出领域与领域之间、实体与实体之间的边界关系。
数据库设计：库、表的设计，表之间的ER图。

四、迭代里程碑

工作台的项目从3月份开始产品规划，5月份投入研发，分七期建设，到8月中旬结束，共计5个半月时间，投入产研4人。

项目采用小版本迭代方式，半个月一个大版本，一周一个小版本进行发布，目的是为了让售后同学能尽早使用每个新功能，减少他们人为操作计算的时间，另一方面是希望售后同学对新功能的使用提供反馈效果。

五、项目复盘

售后工作台的能力搭建，目的是为了更好的服务于实施/运营/销售团队，提高内部人员工作人效，另外重要一点是能对SAAS产品建设输出有效的反馈需求，进而提高整个产品的各方面能力。

业务团队若没有系统的工作流程，在执行效率上上肯定会大打折扣，但是系统功能的开发也要切实与业务团队的现状保持紧密节奏，倘若系统能力跑在业务执行前面，功能价值肯定短期很难得到体现，况且随着业务的发展变化，所做功能很有可能废弃或者改版，所以在需求的确认时一定要了解清楚业务现状，不只是讨论功能的可行性，功能成本和带来价值才是关注的重点。

内部工具产品的核心目标依然需要回归人效提升，对于新签、活跃、续约等非单一因素可影响的综合类业务指标难以直接撬动，依赖业务本身的策略。