摘要：建立报修呼叫客户系统是燃气行业规范企业管理的急需工作。本文详细介绍了燃气报修呼叫客户系统的需求分析、数据库设计及系统使用后的应用情况。
关键词：呼叫；报修；服务；管理
1 概述
随着国民经济的发展和人民生活水平的提高，公众对水、电、煤气等公共事业机构的服务越来越关注。城市燃气行业是城市公用事业的重要组成部分，它为千家万户提供服务，为国民经济运行提供最基本的保证。燃气系统的安全、可靠运行，燃气企业的工作效率和质量的提高将影响社会生活和经济建设的各个方面。为了提高服务质量、解决群众的实际问题，同时树立良好的服务形象，有必要根据先进的服务理念，利用先进的呼叫中心技术和管理模式，成立了专门的报修呼叫客户服务中心。
苏州燃气集团有限责任公司是苏州地区集燃气生产、工程设计、管网建设、燃气经营管理、用户服务于一体的大型国有企业。主要为苏州古城区、沧浪新城、平江新城、金阊新城的供气，现燃气民用户数已突破30万。报修呼叫客户服务中心承担客户的用气咨询、用气报修、室外报漏、投诉、举报、建议和表扬等业务。建立客户服务系统的意义在与科学规范地管理各部门的对外服务，从而有效地解决了以往的服务模式中存在的工作流程不科学、资源配置不合理、服务管理不规范的不足，充分利用计算机，实现燃气用户的各类报修、抢险、管网抢修及拆迁、改装等业务系统，做好安全管理和服务工作。
系统设计与实现是基于B/S模式的信息管理系统，系统使用的是ASP.NET环境下用C#语言开发，后台数据库使用的是SQL SERVER 2005。系统主要功能分两大部分，一块是呼叫中心，主要是控制对外线的接入，功能主要有通话记录语音查询、停气通知上传、座席管理、外线状态及各类话务统计报表。一块是客户服务中心系统，功能主要有系统管理、报修管理、巡线管理、咨询管理、事件管理及各种统计报表。业务系统与呼叫平台分离，以保证各自的独立性，有利于提高系统的稳定性、开放性和可扩展性。
2 需求分析
需求的定义包括从用户角度(系统的外部行为)和开发者角度(一些内部特性)来阐述需求。
软件需求包括3个不同的层次：业务需求、用户需求和功能需求(也包括非功能需求)。
(1) 业务需求反映了组织机构或客户对系统、产品高层次的目标要求。
(2) 用户需求文档描述了用户使用产品必须要完成的任务。
(3) 功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
2.1 业务功能结构图
苏州燃气集团客户中心系统总的功能结构图(如图1)：
2.2 CTI呼叫中心功能
CTI呼叫中心系统，主要是控制对外线的接入及呼出，功能主要有呼入呼出通话记录及通话录音、停气通知上传、座席管理、外线状态及各类话务统计报表。
2.2.1 CTI与客户服务中心系统接口流程
CTI呼叫中心系统和客户服务系统是两个相对独立的系统，都是B/S模式。要实现两系统对接，CTI话务员客户端使用C/S方式，用.NET的WebBrowser控件把客户服务系统嵌入进来，实现两系统的接口对接，这样就可以在客户服务系统中接收CTIS呼叫系统的信息，也能通过客服系统直接对外呼出。
CTI与客户服务中心系统接口流程图(如图2)：
2.3 客户服务系统功能：
客户服务系统功能结构图(如图3)：
CSS系统管理功能结构图(如图4)：
客户服务中心承担客户的用气咨询、用气报修、室外报漏、投诉、举报、建议和表扬等业务。
2.3.1用户用气报修
功能主要是记录报修人地址、接报日期时间、联系系统电话、报修内容、时限要求、预约时间等信息；工作人员根据用户所属辖区，把报修单发送到相应的服务网点。还可以根据用户所留电话进行回访，对维修情况进行满意度调查。户内故障由用户所在辖区班组受理或接收。根据报修单的联系电话、联系人、约定时间、报修内容等信息，为用户上门维修；维修结束后根据报修单号，记录施工信息，如回单时间、维修内容，维修人、维修所需材料及数量并自动计算维修人工作量分值等信息，为报修统计以及完成率进行统计分析做准备。
报修管理的业务流程如下：
步骤一：话务员进行信息的记录，能够根据报修地址调用燃气总部营业系统的客户信息库，匹配到精确的地址，如果匹配不到则手动录入。系统生成接报单，提供打印的方式传真至报修班组；
步骤二：该报修班组的维修工作人员上门维修后，工单通过传真传回给呼叫中心；
步骤三：呼叫中心工作人员进行该工单的维修内容、维修材料、完工时间的提交；
步骤四：如果需要进行回访，则话务员进行客户回访，记录回访结果后结束。
2.3.1.1报修接单子功能业务流程图及其说明(如图5)
步骤一：话务员根据客户提供的信息，选择地址查询或者是交费卡号查询；
步骤二：话务员根据查询条件得出客户的信息与以往报修记录信息和付费记录信息；
步骤三：系统根据查询的客户信息自动生成接报单，并判断维修班组，并提供打印方式进行打印；
步骤四：系统如果没有查询到具体的客户信息，由话务员根据实际情况手动录入信息，选择维修班组，生成报修单，并提供打印方式进行打印。
2.3.1.2 维修单生成子功能
步骤一：话务员根据传真上的信息，根据接报单号(报修单号)或报修地址查询相应的报修单；
步骤二：话务员根据传真中的相应接报单号的信息，输入维修人员、维修内容、维修材料清单和完成时间，生成报修回复单；如果产生费用的话，需要录入相应的费用列表；
步骤三：系统根据维修分值规则表，自动计算此次维修的维修人员所得的工作量分值及根据维修内容自动生成上门维修费(有的维修项目需向用户收取定额上门费)。
2.3.1.3 报修单回访子功能
因话务员人员有限，所有报修单不能全部回访，只能抽取一定百分比进行电话回访，并录入客户满意度等回访记录。如果发生投诉/表扬，需要将其设为需要回复，并产生投诉/表扬记录。
步骤一：话务员查询需要回访的用户报修单，批量选中需要回访的报修单进行锁定；
步骤二：话务员在锁定的报修单中进行电话回访。
步骤三：话务员根据客户满意度，进行回访信息的记录；
步骤四：如果发生投诉/表扬，将该保修单设置为需要回复，并生成投诉/表扬记录。
步骤五：回访完成后，可以进行报修单的解锁。
2.3.2巡线管理功能
该功能主要是处理室外报漏情况，接报后巡线人员现场询查，并反馈给呼叫中心，如真有泄漏，就要生成维修单进入报修流程，生成报修单分配给抢修班组进行维修。巡线管理主要是巡线记录单的生成和回复功能。巡线班组的日常巡线记录也记录到系统中，以备日后查询管理。
巡线单功能业务流程图(如图6)：
步骤一：市民报室外漏气及安全隐患问题，话务员根据报修问题，记录联系电话，录入巡线单，并根据所在地段匹配巡线人员(系统自动匹配)并根据巡线人员电话立即联系(系统自动呼出)进行巡线；
步骤二：话务员根据巡线人员回复是否存在问题判断是否将巡线单转成接报单；
步骤三：如果存在问题，由话务员将巡线单转成接报单，进入报修流程。如果不存在问题，就直接结束该巡线单。
2.3.3咨询管理功能
该功能主要是记录客户通过电话方式进行信息咨询，如果当场不能立即回答，可打印出咨询单转其它部门填写回复内容后再回复，记录回复信息。
2.3.4事件记录管理功能
该功能主要是记录突发事件、投诉记录和表扬记录信息。
2.3.5记录查询
对记录业务流程中记录的数据进行管理。
对报修的修改或者查询。查询条件有：联系人、联系地址、联系电话、报修内容、报修时段、预约时间、维修班组、报修类型等。对维修记录的修改和查询。查询条件有：接报单号、维修内容、维修人员、维修材料和维修班组等。
报修单查询中有批量打印功能，可以由话务员根据查询条件对自己当天的报修单进行批量打印，方便本部门内部管理。
2.3.5统计分析
对报修记录、咨询记录、投诉记录、维修记录、回访记录的统计。
主要根据时间段进行统计。
报修维修统计内容比较多，可生成各类统计报表，可根据历史时间统计报修的数量，同时支持一些关键筛选，如用户报修，巡线报修等。维度可以为：维修班组、报修内容、维修内容、维修人员、维修班组、维修材料、以及报修类型等(见图7)。
2.3.6系统管理
系统管理员或者班长进行系统管理。包括知识库管理、操作员管理、角色管理和业务参数管理。
知识库管理：系统管理员或者班长进行知识库的维护，来方便话务员对客户的咨询问题的答复。
(1) 新增知识库记录：一级标题，二级标题(可选)、关键字、内容。
(2) 编辑知识库记录：对知识库的标题、关键字、内容进行编辑。
(3) 删除知识库记录：删除知识库记录。
3 数据库设计
数据库设计在系统中处于相当重要的地位，在大多数数据库应用系统中，最重要、最困难的不是应用系统设计而是数据库设计，只有好的数据库设计，才能构造出强健稳定的系统。
数据库设计(模式)是否支持应用系统的对象模型是判断是否是面向对象数据库系统的基本出发点。由于应用系统设计在前，数据库设计在后，所以应用系统对象模型向数据库模式的映射是面向对象数据库设计的关健。
由于数据库是以二维表为基本管理单元的，所以对象模型最终是由二维表及表间关系来描述的。有关的变换规则简单归纳如下：
(1) 一个对象类可以映射为一个以上的数据表，当类间有一对多的关系时，一个表也可以对应多个类。
(2) 关系(一对一、一对多和多对多)的映射可能有多种情况，一般映射可以定义为一个表，也可以在对象类间定义相应的外键。
(3) 单一继承的泛化关系可以对超类、子类分别映射表，也可以不定义父类表而让子类表拥有父类属性；反之，也可以不定义子类表而让父类表拥有全部子类属性。
(4) 对多重继承的超类和子类分别映射表，对多次多重继承的泛化关系也映射一个表。
(5) 对映射后的数据表进行冗余控制调整，使其具有合理的关系。
本系统数据库的数据结构(如图8)：
数据库数据为树状结构，数据之间的关系为一对一、一对多和多对多的关系，关系清楚明了。数据结构图中列出了数据库中主要的数据模块，每个数据模块中还包含多个相关的数据或数据选项。其中接报单、接报单验收、维修材料验收、作业维修员信息、回访单、巡线单、咨询单、其它事件、知识库是业务数据表，记录业务发生的过程和结果，其它是基本编码表，描述业务实体的基本信息和编码。数据库中还有几张系统信息表，存放与系统操作、业务控制有关的参数，如用户权限、用户配置信息、地址班组关系表、管线地区关系表等。
4 结语
系统数据接口采用三层B/S结构，通过构建应用服务器，把呼叫中心的数据流与燃气公司营业客户系统、报修客服系统结合起来，充分利用了已有系统标准的数据接口，实现对后台数据库的访问。与既有业务系统接口，融合后台办公自动化和工作流系统，系统可以向既有业务系统提交业务服务请求，也可以取得既有业务的数据。如煤气费查询、欠费信息等(可根据用户欠费情况要求用户先交费再维修，维护了公司利益)。系统联通了呼叫中心座席人员、营业厅收费人员、抄表班业务员、工程管理人员与公司管理人员等各种角色使用系统的界面，使各类人员都能查询到自己所需的数据。
通过呼叫客户服务中心的运行，能有效地实现对业务、设备材料、人员的全面管理，使客户服务中心随着运营的过程效益不断地提高。同时提供实时的监控工具，使管理人员及时了解整个部门的运行状态。
参考文献
1 黄小美.城镇燃气管道失效与事故数据库设计[J].煤气与热力，2009,29(1)：40-43
2 樊建.ASP.NET+ADO.NET项目开发实例[M].北京：清华大学出版社，2004
(本文作者：唐震 苏州燃气集团 215002)
您可以选择一种方式赞助本站
支付宝转账赞助
微信转账赞助
- 注解：本资料由会员及群友提供仅供阅读交流学习，不得用于商业用途！
