还能这样玩？利用有数BI和轻舟低代码搭建售后服务体系

本文将为您介绍有数BI售后服务体系构建的背景、目标及设计过程，为BI 低代码产品结合应用提供了实践案例和经验总结。

01

售后介绍

1.什么是软件售后服务？

软件售后服务是指在客户购买产品后，向客户提供的一系列服务。这些服务可以包括产品的安装、运维、升级、咨询等方面，以确保客户能够获得最佳的使用体验和价值。售后服务可以增强客户对企业品牌的信任和忠诚度。

2.软件售后系统通常使用的人员？

技术支持人员：技术支持人员是售后服务的重要组成部分，他们负责解答客户对产品的技术问题，为客户提供技术支持和指导，协助客户解决各种技术难题。

运维工程师：负责软件的维护和修复工作，包括故障排除、补丁升级、数据备份等，确保软件系统的稳定性和可靠性。

售后管理人员：售后管理人员负责售后服务的整体规划和管理，协调各类售后人员的工作，优化售后服务流程和服务质量，提升客户满意度和忠诚度。

3.软件售后人员核心考核指标？

• 售后服务响应时间：指从客户提出问题到售后服务人员响应和处理问题的时间，该指标可以反映售后服务的快速响应能力。
• 售后服务解决率：指售后服务人员解决客户问题的比例，该指标可以反映售后服务的问题解决能力和有效性。
• 售后服务质量评价：通过客户反馈、满意度调查等方式对售后服务的质量进行评估，可以了解客户对售后服务的满意程度和改进意见。
• 售后服务成本控制：指在提供高质量售后服务的前提下，控制售后服务成本的能力，该指标可以反映售后服务的经济效益和可持续性。
• 售后服务团队绩效：指售后服务团队的整体绩效表现，包括工作效率、客户满意度、售后服务质量等多个方面。

02

需求分析

1.服务流程

无论在售前，实施，售后阶段都需要售后技术支持介入，团队之间协同依赖流程申请。我们可以从流程中知道，流程中包含了客户信息。

2.体系设想

针对售后体系需要处理清楚3个事情。

• xxx客户问了什么问题，客服怎么处理？需要一个客服生产力平台。
• xxx客户买了什么产品等相关财务信息及相关环境信息？需要一个客户信息系统维护及财务信息维护。
• 售后系统核心是客户，客户标签是打通所有系统的关键。需要一个客户标签体系。

在解决上面3个问题中，我们需要一些生产力系统（低代码）和数据分析体系（有数bi）做支撑。

2.1 低代码系统设计

• 首先在各项流程中获取客户信息，在客服系统中做登记。
• 有了客户信息后，通过积分系统领取派发任务。
• 员工领取任务后，通过客服系统进行客户问题处理，同时完成工时系统工时登记。
• 在处理客户问题时，对客户的需求和缺陷分别在EP系统中做登记。
• 财务系统会记录客户生命周期，通过财务系统接口完善客户信息，运维系统基于客户信息去做客户环境信息完善。
• 日常升级等流程通过运维系统做流程审批。

2.2 BI数据体系设计

数据架构图：

指标体系图：

2.3 系统愿景

对于售后团队，我们希望通过一个系统解决上面的所有问题。未来整个售后团队的多角色只需要在一个系统运作。

• 对于技术支持人员希望可以在一个系统内，实现客户问题处理，工时登记，满意度问卷发放。
• 对于运维人员希望可以在一个系统内，完成客户环境登记，对于升级问题有流程性的管控。
• 对于管理人员希望可以在一个系统内，实现对员工能效监控，对商机挖掘，对产品质量管控。争取实现，"管好人","算清账","磨好产品"。

03

设计过程

1. 低代码系统细节设计

在系统实现过程中核心是对自己业务内容的搭建，主要包括菜单栏设计，实体表结构设计，外部接口互通，表内部逻辑相互触发机制等。在售后系统设计过程中，设计和低代码实施时间比为7:3。在实施过程中低代码确实是开发系统的神器。我这里核心总结了以下优势：

可快速构建实体（表结构），可以上传excel，也可以通过可视化的方式创建表。

在系统设计中数据库设计的质量直接决定系统的稳定性和搭建效率。低代码对实体支持非常高效，在mvc模式中，除了给你开始构建model（实体），还快速帮你构建了视图界面。

可以快速定制接口

对于外部的接口可以以可视化的方式定义和统一管理。

布局简单且灵活

布局支持线性布局，栅格布局，分栏布局。且平台有很多模板，对美观不追求定制的同学，可以让系统的美观度达到70分水平。

组件丰富，且核心组件使用简单

如系统核心是菜单挂内容，低代码可以快速构建菜单项。

自带权限体系

低代码内置权限体系，核心是：角色 用户。角色可以快速选择未来需要控制的页面资源。将角色授予用户起到权限控制目的，使用简单。同时对于权限用户体系在对接其他系统时候，我们经常需要在本系统中对用户表添加一些附加属性，用来做系统识别。

场景1：如在售后-积分系统，对于任务的发布需要指明身份，对于不同身份，在任务池中看到的任务是不一样的。因此：用户表需要加上角色字段，用于区分运维，技术支持。

场景2：如在售后-工时系统，对团队维度分析工时。我们会在BI系统中获取团队信息，最好的方式就是在用户注册时在用户表需要加上团队字段。但一般的团队都是有组织架构路径，所以填写的是 xxx/xxx/xxx 的模式。

场景3：如在售后-工时系统中，自己想看自己的工时。一般分析展示的场景都会在bi系统，自己看自己工时的场景就会演变成集成环境下数据权限适配的问题。具体实现会在BI细节设计中介绍。

备份机制和调试机制

对于开发者在开发中经常面临代码调试和版本回滚。低代码提供了生产和测试模式，且版本可回滚。这个功能对开发者来说非常实用，而且未来系统上线后难免会有一些小bug和新功能改造。

2. BI数据体系细节设计

在BI数据体系设计中核心是数据的对接，所以在设计表结构的时候既要满足系统功能的支持，还要满足分析场景的便捷性。同时未来工作模式是低代码系统为入口，所以选择BI系统一定需要具备集成能力。这里我选择有数BI，核心总结了几个优势：

简单易用

有数BI，从数据对接，数据处理，报告展示都可以通过拖拉拽的方式实现。在售后系统一共20多个页面中将近有2/5是数据分析模块，每个报告全阶段实现平均在1-2小时左右。简单易用可以极大提升工作效率。

数据探索灵活

对于业务分析来说，不同人关注的业务维度不一样，有数BI提供灵活的切片，下钻，筛选器，联动，跳转场景。

同时在设计业务场景时有些需求也是不明确的，我们也需要对数据规律做探索。产品提供x，y轴的概念，自己可以随意拖拽，可以用最直观的图形展现业务规律。

数据处理优势

可以将多源数据做结合。如工时数据可能来自运维流程，企业微信聊天记录，集团内部客服工具。这些数据来自不同系统，有数BI可以实现多源数据对接。

可以处理复杂的数据结构，如前面介绍的组织架构，可以通过数据准备快速处理。

数据性能优势

一般对于这类分析，偏向离线，有数BI有的分布式存储技术，可以将业务数据存储在BI系统，且有相关物化场景。可以实现数据秒级响应。

预警机制设置简单

在售后系统中，对产品管理会有license管控，比如license过期，我们会提前监控。此时会用有数BI做一些规则预警。

审核流设置简单

对于升级，会提交一些简单的流程，可以利用有数bi创建填报，设置审批流程。图中是填报和展示一体的业务场景。

拖拽式可拖拽流程引擎。

集成灵活

目前有数BI通过iframe方式对报表回嵌入系统，可以实现和其他系统的无缝对接。集成解决了2个问题：

（1）用户认证和权限：核心是token进行免密登录，同时在token中可以设置数据权限等其他网络安全参数。

（2）iframe页面适配：有数BI提供多种参数对集成效果做调整。

04

系统呈现

场景1：资料入口

可以将所有学习资料都超链进平台。

场景2：客户标签体系

由管理员做标签同步，实现售后系统和客服系统的标签同步。

场景3：客户信息维护&客户信息管理

客户信息管理

客户环境维护

场景4：积分系统

（1）积分规则设定模块

（2）任务发布&任务管理

任务发布

任务管理

（3）根据角色控制任务池

（4）团队人员分数分析

积分制核心是为了提高大家的工作热情，通过抢积分的方式，形成排行榜。同时排名需要纳入kpi机制中。这里需要增加兜底机制，如有任务滞留，大家都不抢，则需提前约定规则按短板机制，顺序指定分配（通俗理解：积分从低到高，指定派发给低积分者，进行一轮，一轮过后重新排名）xq。

场景5：客服系统及工时填报

（1）工作台

将客服系统和工时集成在一个页面，可以很快的完成工时录入。客服会话和工时产生关联的是标签体系和会话时间。未来可以对工时进行质检。

（2）工时管理及补录

（3）工时分析

按团队对工时进行分析，点击个人工时组成，了解用户画像。

客户维度分析，了解客户画像；根据时间维度，了解问题趋势。

场景6：服务分析场景

首响分析：首响指的是客户问的第一句话作为开始时间，客服回答的第一句话作为响应时间，两者的时间差为首响时间。一般时间越短代表响应越快。针对首相不取平均首响时间，主要是极值容易把平均值拉大，取90分位的首响，可以较好了解团队真实繁忙情况。

满意度：是由客服发问卷收集回来的评分。满意度核心看两个指标，5分制下看低分满意度的个数。问卷发放率，防止有选择性的发放问卷。

场景7：产品质量和改进

对于产品质量核心是两个需求数和缺陷数。通过和EP系统打通，把产品的缺陷数据抓入BI平台分析，在低代码中集成。

（1）缺陷分析

（2）建议分析

针对建议趋势分析同时可查看ep系统的建议明细。

场景8：运维场景

（1）升级流程管理

简单填报发起升级流程，后台通过预警做审批提醒，在看板上一目了然了解整体升级排期。方便快速安排升级计划。

（2）产品到期预警

在售后系统中，对产品管理会有license管控，比如license过期，我们会提前监控。此时会用有数BI做一些规则预警。lic文件在低代码中管控，预警在有数BI系统中发消息。

场景9：财务场景

核心管理维保收入情况，维保到期分析，增值收入管理，维保到期提醒。

同时财务信息和会话记录打通，增加双重保险，防止客户出现过保，还投入服务的场景。

场景10：权限管控场景

（1）平台权限控制

角色：管控页面资源

用户：将用户添加到平台，用于登录和其他系统的用户体系，数据权限对接。

用户侧效果：

（2）BI系统和低代码权限互通及数据权限管控

本期内容分享就到这里，谢谢大家。

作者简介

千鱼，有数BI售后部门负责人。长期服务不同行业客户，对客户产品使用的痛点非常了解。同时面对各种客户的复杂业务场景，有着非常丰富的解决经验。