设计案例：SmartX 售后服务系统

如何设计一套拥有大量数据、复杂权限、多部门参与的系统。

ROLE

Only Designer

TIMELINE

Dec, 2018

PLATFORM

Web

Client

SmartX

MY CONTRIBUTION

UI / UX Design

Product Management

Project Management

项目介绍

为售后服务流程定制一套系统

售后服务系统是继合作伙伴网站后，与 SmartX 合作的另一个项目。SmartX 是国内领先的超融合产品与企业云解决方案提供商，为企业客户提供自主研发的 SMTX OS 软件和一体机硬件产品。这次的需求方是售后部门，希望建立一个管理客户关系、为客户提供售后服务的系统。

SmartX 在公司内部划分了销售、市场、商务和售后等部门，每一笔销售给客户的产品都需要经过多个部门才能完成：售前工程师与客户沟通需求 → 商务与客户签订采购合同 → 售后工程师上门实施安装 → 售后部门提供售后服务。

售后部门在为客户提供售后服务时，十分依赖于对客户信息、硬件环境、集群信息的掌握，依据这些信息定位问题并提供解决方案。由于各流程分属不同部门负责，部门之间的信息同步会有延迟，加上售后部门在流程后期才开始参与，往往不能掌握完整的信息，使得定位问题更加困难，售后的效率和满意度难以得到保证。

因此，我们想打造一个可以供销售、商务和售后部门的同事共同使用的系统，覆盖从客户签约、记录销售合同、录入客户信息、生成售后服务编号、上门安装并补充客户实际集群信息、查询客户购买产品的保修期限等全部售后流程。

目标是实现：

签订合同时为客户生成唯一的服务校验码；

商务部门录入客户信息和合同信息，包括购买的软件、硬件数量；

系统根据客户购买时间自动计算售后服务期限（不同设备服务期限不同）；

在客户遇到问题联系售后部门时，通过提供服务校验码，售后部门即可获取客户信息、硬件信息、集群信息等，快速定位问题。

设计难点

拥有大量数据、复杂权限、多部门参与的系统

项目开始后，我们与售后负责人和其他将来会使用该系统的团队成员进行多次访谈，了解了团队现有的工作方式、合作流程后，我们发现打造售后服务系统需要解决以下主要问题：

#1 数据繁重

合同数据、客户信息、集群信息，以往每一项数据都是由多个表格来维护，现在我们需要把所有这些数据加入到系统中。这也意味着我们要面对大量的数据和表单，如何能保证录入和维护时的体验，降低出错的可能性？

#2 部门间权限复杂

系统会被销售、商务和售后部门的同事共同使用，各部门成员都有对应的职责，在系统中对应不同的操作权限，账号系统和成员权限都需要仔细考虑。

#3 资源相互耦合

一个合同中采购的软件、硬件可用于创建一个集群，也可能创建多个集群。反过来，用户多次采购的设备也可能用于同一个集群扩容。因此合同与集群之间的关联需要灵活的设计，保证客户数据的完整性和及时性。

设计流程

1. 用户访谈：发现问题

售后服务系统主要用户涉及商务、售后多个部门的成员，因此了解他们日常的工作流程十分重要。在项目开始前，我们对产品的实际使用者（售后、商务部门成员、售后负责人）进行访谈，对这些问题进行了解：

当前各部门的职责划分、工作流程；

部门之间如何沟通协作；

与客户签订合同的常见类型；

客户会遇到哪些常见问题；

售后部门处理问题的流程；

在进行了 3~4 轮的当面沟通后，对售后部门实际工作中会遇到的障碍有了整体的了解，存在的主要问题有：

1.1 销售商品缺少唯一可追踪的服务校验编号

软件或硬件卖给客户时，缺少唯一可追踪的服务校验编号。一方面，对企业来说，售后部门难以追踪客户购买了哪些设备，对客户信息和客户环境缺少完整的记录，只能依赖于售后工程师上门检查；另一方面，对客户来说，缺少唯一编号意味着在遇到问题联系售后时，无法准备描述有问题的设备，增加了定位问题的困难。

1.2 部门之间存在信息壁垒

为客户提供良好的售后服务体验，依赖于对完整信息的掌握。虽然部门间工作职责有着明确的划分，对客户信息的掌握也分散在各部门，比如客户信息和合同信息在商务部门与客户签订合同时获取，客户集群信息是在售后工作人员上门实施安装时获取。另外部门之间信息同步不及时，也会影响售后服务的体验。

1.3 缺少系统性管理平台

以往合同与客户信息更多是保存在 Excel 或 Google Docs 中，并依赖于人工控制可见范围，比如在售后部门需要客户或合同信息时，商务人员将表格或在线文档分享给他们，这样效率低且容易因版本产生错误，缺少一个统一的管理平台来维护这些关键信息。

设计流程

2. 需求整理：厘清产品流程

对各部门现有的工作流程和问题了解之后，我们开始了对需求的整理工作。

首先在与客户沟通后，我们将项目分为了 2 期，一期主要包含平台的基础搭建工作和集群服务验证功能；二期在一期的基础上增加工单系统、售后计时、统计分析等进阶功能。

然后我们开始着手一期功能的具体实现细节，经过上一个项目 SmartX 合作伙伴网站从零开始的搭建，在账号体系、权限设计和通知系统这些基础功能上有了比较成熟的设计思路，所以本阶段更关注产品本身的流程，本阶段的产出是包含实现细节的项目需求文档和需要设计页面的汇总。

根据上一步的访谈结果，我们将客户、商务团队、售后团队在系统中的工作职责整理到流程图中。

设计流程

3. 设计探索

需求和产品流程确定后，开始了对设计上的探索。

设计探索主要围绕以下方面展开：

整体风格：包括视觉风格、交互形式，如何与客户品牌保持一致的形象；

信息架构：包括整体导航、页面布局、一二级页面跳转关系等；

列表：列表是系统中展示数据的主要形式，因此关于列表的搜索、筛选、添加操作以及翻页控件也需要找到合适的形式；

#1 整体风格

与客户沟通后，售后服务系统作为企业内部工具，希望整体风格与品牌形象保持一致，同时在视觉和交互能保持简单、清晰，能帮助售后人员更好更高效地完成任务。

我们从客户官网和产品中提取了设计元素，例如客户官网的风格化背景图以及客户产品的色板，将其应用到整体的视觉设计中。

#2 信息架构

信息架构层面主要考虑整体导航、页面布局和不同层级页面的逻辑关系处理。为此我们试验了多种布局方式，并与客户探讨了系统未来的规划，最终根据以下因素确定了最终版本：

层级简单，交互易用；

针对不同权限的用户（看到的内容数量可能不同），都能提供一致的操作体验；

满足客户未来功能扩展需求；

#3 列表

列表对于拥有大量数据的产品都是必不可少的组件，虽然看似简单，但其实包含了多种组件和复杂的交互操作，例如搜索、筛选、排序、操作以及翻页控件等，因此要根据实际需求对组件进行定制。

在与客户沟通了解对列表数据的处理需求后，我们迭代完成了最终的设计。

在探索阶段，我们与客户一直保持沟通，除了使用 Invision / Paper 等线上协作工具随时将最新的设计想法分享给客户外，还将备选方案打印出来，进行当面沟通，从客户那里获得反馈，并不断迭代出最终的设计方案。

设计方案

满足需求基础上进行交互创新

为了应对繁多的数据，在交互设计和视觉设计上我们进行了多样的创新，我们从实际使用者的体验出发，关注他们的日常工作流程，并通过设计优化流程中的细节，让售后人员的工作效率得到提升。

#1 表单填写帮助

由于售后服务十分依赖于对客户数据和集群数据的掌握，因此数据录入是系统中必不可少的环节。但同时大量数据的录入操作可能对实际使用者造成使用上的困难。

例如在录入合同时，就需要录入以下信息：

客户信息

项目信息

硬件信息

销售人员信息

财务信息

Offering 信息

一体机配置

……

我们尝试通过设计来让数据录入的环节更简单，除了提供 Excel 导入功能，支持将已有合同信息导入外，我们在表单的设计上也进行了探索。

关于表单，我们主要考虑使用者的填写体验，降低使用难度和出错的可能性，提升填写效率。表单中有术语和专业名词，通常表单的名称字段无法说明清楚，需要额外的解释，另外也会有些操作需要谨慎操作，为此我们引入了表单填写说明的设计：在录入合同和录入集群信息时，在表单左侧增加了填写说明栏，针对对应的区域和字段进行填写的帮助说明。

通过这样的设计，团队成员在使用时即可清楚地知道各区域、字段要如何填写，有哪些需要注意的地方，即使是新成员也可以快速上手，避免出错的可能性。

另外在表单中，我们也仔细为各输入框考虑了合适的默认填充字段，引导用户按照规则填写。在分区域的长表单页面加入了收起 / 展开区域功能，在修改时可专注填写单个部分。

#2 全局搜索

为客户提供优质的售后服务依赖于对客户信息的掌握，在前期依赖于成员对各类数据的准确录入。在售后阶段则依赖对数据的处理效率。

通常客户遇到问题联系售后时，售后需要第一时间了解客户信息和硬件环境信息，才能有针对性地为客户提供解决方案。想要获取完整的信息，就是根据客户提供的碎片信息，碎片信息又不一定有固定的种类，因此一个强大的全局搜索能大大提升售后处理的效率。

搜索功能支持对客户、合同、集群、工单（二期）和成员等信息的模糊搜索。在搜索时，只需要把客户提供的碎片信息输入到搜索框中，即可触发自动联系，在输入完全部信息前就能找到相关的合同或集群，点进对应的详情页，就能看到前期录入的所有信息，快速帮助客户定位问题。

#3 账号权限设计

系统数据中包含很多机密数据，对公司和客户都十分重要，比如客户信息、合同信息和集群信息。这些数据从属不同部门管理，比如商务部门负责录入合同数据，售后工程师负责录入客户集群信息……不同数据需要严格控制可以访问的人群，防止重要数据被滥用或修改。

这也需要对权限进行细致的区分，因此我们将原有的角色权限（部门成员的权限）拆散为最小粒度操作：访问权限、添加内容权限、修改内容权限，单个部门成员权限即是一系列操作的组合。权限分配不再严格按照部门来划分，在管理员添加成员选择部门时，权限会根据部门选择预设的默认权限，同时支持灵活的调整，这样也实现了为团队内部不同分工的成员分配不同的权限。

加上系统本身的登录权限，构成了系统的完整权限设计。在员工离开公司时，关闭登录权限即可。