数据驱动在转转客服工单系统中的应用

2024-01-27 01:10

本文主要是介绍数据驱动在转转客服工单系统中的应用,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

客服工单系统是客服解决用户实际问题、处理日常工作最常用的系统。为有效辅助客服的工作,系统需要及时提供用户、商品和订单等信息。同时,客服工单的创建、流转和处理,也需要各种类型表单的操作。所以基础信息的展示和交互、表单的展示和操作,对于客服工单系统至关重要。本文就为大家介绍,在转转客服工单系统中,我们是如何通过数据驱动的方式解决这类问题的。

ad9107b90a4b3da6fe7b836ba27aa12d.png

基础信息

展示形式

这里以工单详情为例,工单详情以模块的方式,提供包括基础信息、用户信息、订单信息等重要的数据,如下图:

e64a5b7bf4110845854ee5582274f71e.png

每一个模块都是由大量不同的类型信息平铺展示,如下:

dd581d528f8289519a8c79db542abad5.png

这些信息数据量和类型繁多,数据字段跟公司的业务有关,数据类型涵盖从最简单的文本展示、链接跳转,到图片预览、弹窗交互等,这些不可能由前端单独一一去做处理。所以我们通过归类和抽象,将数据格式进行统一化、对共性组件进行抽离,交由不同的组件处理。在介绍基本使用之前,先看下整体的结构设计。

结构设计

四个层次

工单详情的每一个大模块都可以分为四个层次,分别为:数据共享层、业务层、抽象层、数据展示层。

每一个业务层都是一个可折叠的面板,未展开前都只展示简略信息。其数据均由数据共享层提供,展开后可通过请求共享的 url,获取详细数据。

19e8fab681495e8bd15b6d9074b9fa05.png bf4efa92ab5313be2ad3dce0fca65f83.png

这里控制请求逻辑的就是抽象层。 其中包括了一个展开后自动请求的 hook---useAbstract,以及一个根据 useAbstract 返回值控制展示的 Abstract 组件,获取到的数据最终传给数据展示层--DetailInfoArea。

//  useAbstract
const [infoDataList, isEmptyInfo, loading] = useAbstract({ isShow, initShowData })
// 这里infoDataList为返回数据,isEmptyInfo用于控制展示,loading是加载状态
// Abstract
<Abstract infoDataList={infoDataList} isEmptyInfo={isEmptyInfo} isLoading={loading}></Abstract>
// DetailInfoArea
{!isEmptyInfo? infoDataList.filter((item) => Array.isArray(item.data) && item.data.length).map((infoItem, index) => {return (<Card key={index}><DetailInfoAreaorderId={orderId}bussinessType={bussinessType}data={infoItem.data}/></Card>)})
: null}

最终通过一个 type 和组件的映射匹配出相应的组件。

import PopInfo from '../PopUp/PopInfo'
import LinkAirPlane from '../FormComponent/LinkAirPlane'
import Text from '../FormComponent/Text'
import countDown from '../FormComponent/CountDown'
…… // 其他组件export default {// Pop类组件PopInfo,PopDrawer,// link类组件LinkAirPlane,// 其他数据展示组件Text,countDown,……
}
三类组件

通用数据展示组件分为三大类:pop 类 、 link 类、其他类型组件。

8869a3b25a8a33e2cd3ca6fd5822072f.png
  1. Pop 类组件:用于点击后弹窗/抽屉展示数据或操作--常用做其他数据展示的容器

  2. Link 类组件:由于点击后跳转

  3. 其他类型组件:基础展示 text、table 数据、图片/视频展示...

具体组件类型、名称和作用如下:

归属类型组件名称作用
Pop 类组件PopInfo通用弹窗信息展示
PopIframe通用弹窗嵌入页面展示
PopForm通用弹窗表单组件
PopDrawer抽屉信息展示
Link 类组件LinkAirPlane带有特殊 UI 样式的链接
LinkGroup多链接
Link单一链接
其他类型组件Text纯文本项展示,最基础的展示
AudioPlayInfo音频播放
SimpleTable表格数据展示
ClickReplace脱敏数据展示,点击查看全部
ImgHoverPop图片展示及预览
CountDown倒计时,用于工单某些流程的计时
数据结构

以下为每一个数据展示项的基本数据结构

[{"type": "", // 用于匹配系统中内置的组件"label": "", // 标识数据项的标题"value": "", // 标识数据项的值"noAuth": "", // 没有该项查看权限的标识"extInfo": { // 额外的信息,可以放入href、formType字段从而达到嵌套组件的形式....}}...]

基本使用

案例 1:展示用户的基础信息,其中包括用户名、注册时间、手机号、头像以及一个测试流水表格

{"respData":[ // 对应最外层模块内容{"label":"基础信息", // 模块的名称"data":[ // 模块中信息项:以label--value的形似展示{"label":"用户名","value":"转转第一""noAuth":false},{"label":"注册时间","value":"2022-02-21","noAuth":false},{"label":"手机号","value":"182****328","type":"ClickReplace","extInfo":{ // extInfo用于放一些组件需要的特殊参数"params":{"uid":"12345678910233445"},"url":"url"},"noAuth":false},{"label":"","value":"https://abababab.jpeg","type":"ImgHoverPop","extInfo":{"popWidth":"200px"},"noAuth":false},{"label":"","value":"测试流水","type":"SimpleTable","extInfo":{"data":[// 表格数据],"columns":[// 表格列配置]},"noAuth":false}],"noAuth":false}],"respCode":"0"
}

展示内容如图所示

960e15d6476f18d27a43275ab9780a93.png

本例前两个字段使用的默认的渲染类型,只展示单一信息

手机号和头像展示则匹配了内部的通用组件:

  • 手机号采用了脱敏的方式,只有在点击之后才会加载全手机号,属于单一数据展示类组件

  • 第三项使用了缩略图的展示形式,点击后会对图片进行预览,属于单一数据展示类组件

    bc8eb7b634d26ea63a2177f16860773e.png
  • 最后的流水表格使用内部的SimpleTable组件展示

嵌套使用

案例 2:我们在基础信息部分需要展示一个流水,以弹窗的方式实现。这里就要通过嵌套的方式进行处理

这里涉及到的弹窗组件就是上文所说的 Pop 类组件,如下所示:

bea8d607b21de4fa7d2648c1d5c435b9.png

这里使用的是 PopInfo,extInfo 中增加 url 表示弹窗的内容通过 getUserFlowList 获取,因此点击“测试流水详情”后会请求该接口。

{"label":"测试流水","value":"测试流水详情","type":"PopInfo","extInfo":{"url":"getUserFlowList"},"noAuth":false
}

获取接口后,其返回数据既返回了数据 data,也返回了表格的列配置。

{"respData":{"dataGroup":[{"type":"SimpleTable","extInfo":{"data":[// ......],"columns":[// ......]}}]},"respCode":"0"}

此处弹窗中的内容为流水信息,使用表格来展示,type 为案例 1 所用的 SimpleTable 组件。

2dd61628c0e3a944a54cd6a6c59780a0.png

对比一下案例 1 中直接使用 SimpleTable,此处嵌套使用时,只需通过数据获取接口来衔接弹窗和内部数据的,其返回数据的结构都是保持一致的,这也是此设计可以嵌套使用的根本原因。

接下来将焦点转移到工单系统中的表单信息。表单在工单系统的地位用“灵魂”形容可能也不为过,因为客服解决用户问题的过程,涉及到记录问题内容、问题分类、沟通细节、处理方式、工单流转等,这些操作都依赖表单的能力。所以一套强大的表单处理系统对实现工单系统流转起到关键作用,下面介绍由数据驱动的 FormRender 在工单系统中的应用。

表单信息

在工单系统,我们使用 FormRender 处理表单。为什么是 FormRender,而不是普通的 Form?

1、同基础信息类似,表单中的字段非常多,包含输入框、单选框、多选框、下拉框、日期选择、时间选择、级联等。

2、字段本身有很多的配置项,如校验规则、默认值、联动信息等,所以需要一种强约束的数据格式保证表单字段的正常渲染和交互。

3、针对不同的用户问题,客服创建的工单需要由不同的字段组合来承载信息,如果没有统一的表单管理,维护效率不容乐观。

FormRender(后面简称 FR) 是一个通过 JSON Schema 生成标准 Form 的渲染引擎,也是一站式表单方案,拥有比较强大的功能,可以满足复杂的表单需求。接下来看看 FR 如何运用在工单系统中。

FormRender 的基本使用

比较下面的代码

// input第一种写法
<Form><Form.Itemrequiredlabel={'这是输入框'}<Input placeholder={'请输入~'}  className={style['my-input']}/></Form.Item>
</Form>// formRender的写法
const form = useForm()
const renderSchema = {displayType: 'row',labelWidth: 130,type: 'object',properties: {content: {title: '这是输入框',placeholder: '请输入~',type: 'string',required: true,"props": {className: style['my-input'],}}}
}
<FormRender schema={renderSchema} form={form} />

最终的效果如下:

3a1361d283d31db5d4d853141cac1694.png

我们可以看到,其实 FR 是借助schema对表单做了相应的配置化。

FR 是如何通过 schema 渲染指定的组件呢?FR 属性 type,描述组件的值的数据类型,属性 format,用来描述输入框的格式,它与属性 type 一起可以判断使用哪个组件来渲染,以及校验表单数据。

内置组件与 scheme 的默认匹配规则为:

export const mapping = {default: 'input',string: 'input',array: 'list',boolean: 'checkbox',integer: 'number',number: 'number',object: 'map',html: 'html','string:upload': 'upload','string:url': 'url','string:dateTime': 'date','string:date': 'date','string:time': 'time','string:textarea': 'textarea','string:color': 'color','string:image': 'imageInput','range:time': 'timeRange','range:date': 'dateRange','range:dateTime': 'dateRange','?enum': 'radio','?enum_long': 'select','array?enum': 'checkboxes','array?enum_long': 'multiSelect','*?readOnly': 'html',
};

除了有以上内置组件外,FR 还支持自定义组件,通过 widget 属性(将在下一节中介绍)注入。

另外,FR 通过 rules 属性来配置对表单的校验规则,通过 props 属性透传给组件,用来扩展字段,值得强调的是 FR 支持所有 antd 组件库支持的展示。

自定义组件

工单系统目前支持的表单类型包括:文本框、文本域、单选、多选、下拉、级联、日期选择、时间选择,大部分都可由 FR 的内置组件支持,但有些特殊的需求,FR 不能很好的支持,级联组件就是其中一个。

如何在 FR 中写一个自定义组件?

// 引入自定义组件
import CascaderSingle from './CascaderSingle'
// 定义schema数据
const renderSchema = {displayType: 'row',labelWidth: 130,type: 'object',properties: {cascader: {title: '城市',type: 'string',widget: 'CascaderSingle' // widget指定自定义组件名称"props": { // 定义渲染数据options: [{id: '1001',name: '北京',children: [{id: '10011',name: '海淀',children: [{id: '100111',name: '好地方'}]},{id: '10011',name: '朝阳'}]}]}}}}
// 将自定义组件,通过widgets通知FR渲染
<FormRender widgets={{ CascaderSingle }} schema={renderSchema} form={form} />

渲染效果如下:

9babeece818b090c7f5d0d1fa8ba485e.png

总结以下几点:

  1. 自定义的组件,需要支持 value/onChange 这两个 props,用于双向绑定;

  2. 通过 widgets 给 FR 注册自定义的组件;

  3. 设置对应的 schema 数据,包括 widget 属性和自定义组件接受的 props(上述例子中的 options)

一般自定义组件,通常是解决特定的场景需求,如特殊 UI、特定的组件、异步加载数据的组件等。在下一节会介绍异步加载数据的场景。

生命周期

对于 FR 来说,生命周期是指渲染和提交数据的时机,根据官网介绍,包括 onMount、beforeFinish 和 onFinish。

  • onMount 用于加载初始数据;

  • beforeFinish 用于提交表单前的服务器校验;

  • onFinish 是获取表单数据和校验信息。

  • onMount 需要特别强调的是,它是指表单首次加载时执行,而且 schema 数据不能为空(undefined、null 和{}均表示空数据)。如果初始的 schema 数据是由服务器异步加载,那么 onMount 一般无法满足需求,官方则推荐使用 react 的 componentDidMount 或类似的 hooks 来加载。

在工单系统中,绝大多数的表单初始数据都是由接口获取,所以一般很少用到 onMount。但有一个例外,其中有一个级联表单,虽然初始数据是非空 schema 数据(一般是简单的配置项),但真正的 options 数据是由单独的接口异步获取,这时 onMount 就派上用场了,因为 onMount 还能用来通过异步获取数据的方式进一步补充 schema。

const onMount = () => {//通过接口异步获取数据apiQueryAllRootCause().then((res) => {const _data = res?.dataList?.map((item) => {return { ...item, name: item.causeName, key: item.id, isLeaf: item.isEnd == 1 }})//获取需要补充schema的字段的路径const schemaPath = getSchemaPath(infos?.formData?.find((it) => it.fieldType == type))//补充schema数据form.setSchemaByPath(schemaPath, {props: {options: handleGetFaqData(_data)},enumArea: _data})})}<FormRenderwidgets={widgets}schema={renderSchema}form={form}onMount={onMount}/>

这里用到了 FR 的 setSchemaByPath 方法,它的目的就是对指定路径修改 schema。由于 schema 是有一定结构格式的数据,为了方便快速定位具体某个元素,用 path 来表示该元素相对表单数据的位置。我们看官网给的例子:

const formData = { x: [{ y: { z: 1 } }] };

那么 z 元素的 path 是 x[0].y.z。所以在工单系统复杂的表单中,要对指定的表单元素修改 schema,通过 path 设置是一个非常高效的选择。(更多关于 path 的内容,详见:如何正确书写 path  https://xrender.fun/form-render/demos/index3)

表单的其他设计

74166e26116a49035f4f3f5a8f239456.jpeg

在工单系统,系统管理人员会配置大量的字段,由于历史原因,保存字段的时候并非标准 schema 数据,所以当通过字段创建表单时,需要进行一次格式转换,如下图。左图为转换之前格式,右图为转换后的 schema 格式。

2e207d35253a6934ddd029e4c79ba3b0.png19e8d1e23d46b4351297e88a84a9aa86.png

在右图中我们注意到,字段元素【字段 2】外层又包裹了一层 schema 格式数据,并且用字母 a 表示元素数据,这是为了美化排版,节省页面空间,产品设计中增加了双列展示的效果,系统通过字母组合来表示具体的某一行。如下图:

2d5b97cf6a34f26267e3e35fe76d72cf.png493bf1e4c6be87bd90334e9752bbd0f0.png

在组件自定义方面,增加上传功能、拖拽功能、异步请求的级联组件、联动组件等,可以满足业务多种场景需求。

总结

数据驱动的好处,在于前后端可以通过清晰的数据格式明确页面的呈现和交互效果;另外,在修改数据时,可以只修改接口返回,而前端无需上线。

数据驱动在客服工单系统中的应用还有很多,比如表格视图、流程渲染等,这些应用都能大幅提高开发效率和维护性。

在追求低代码的大潮流下,客服工单系统虽然非常复杂,但我们吸取低代码的设计思想去简化系统的复杂度。

想了解更多转转公司的业务实践,点击关注下方的公众号吧!

这篇关于数据驱动在转转客服工单系统中的应用的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/648633

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务,目标是自动识别图像中的对象类别。通过卷积神经网络(CNN)等深度学习技术,我们可以构建高效的图像分类系统,广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统,包括环境

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd