呼叫中心软件平台实现方案及报表的实施
       自毕业到现在,在呼叫中心这个行当滚打了那么多年,不能说是见识了多少风风雨雨,但是经历形形色色的客户倒是事实,特别是外包业务的呼叫中心,更是如此,你能碰到的客户可能是一个长期的客户:一做就是几年;要不就是短期的:1-2个月就搞定的。于是对于不同的客户以及不同的客户需求,就有着很多中实现方案了。以下,我就几点系统开发和规划方面的经验与大家一起分享以下。
 
       市场调研项目:
 
       这种项目应该说是比较简单的项目,只要打出电话去,联系客户,收集要的资料,保存呼叫结果,就可以了,这种项目一般情况都是比较短期的,除非有些特别的客户,例如咨询公司、数据公司等。
 
技术标准
       数据的准确性——这点应该是市场调研公司的注意的关键地方,很多公司要求给的数据有长度的限制,字节的限制,选项的相互逻辑性的控制等,以确保数据的准确性,而且这个也将成为KPI来处理。
 
       数据的可重复利用——一般情况来说,市场调研的标准是数据的准确性,要求提供多少份合格的数据就可以了,但是有时候会出现数据量不够或很差的情况,大的咨询公司可能还要求给出更详细的数据使用情况报表,因此这点也是技术上要考虑到的。
数据的真实性——这点要就要求而言,不同的公司仍然有不同的要求,但是我相信如果没有录音系统,那么这点对与技术而言就没有什么意义了。
 
       可变性——这点一定要注意,不要给自己找麻烦,因为这样的客户,往往会在不同的时候给出不同的变化,如果是短期的,可能不会,但是如果是中期或是长期的话,一定会发生这样的情况。
 
       实现方案
       一个数据库就可以了,但是就情况来说,不是什么都用一个数据库,如果是很简单的甚至给个Excel就可以满足要求了,如果是大的或是要求复杂的公司,那么建立一个系统是个很好的方法,利人利己。
 
       方案1.
       短期项目,要求不高,收集的资料没有特定的逻辑或是逻辑相当简单,AGENT数量不多:建议使用EXCEL来作,只要一个TEAM LEADER来分配数据,每天收集成功的数据,进行数据筛选就可以了。一般不需要工程师的支持,如果需要的话,也就是给个好用点的EXCEL模板。
 
       方案2.
       中期项目,要求不高,但是问卷的内容存在变化,存在简单逻辑,建议使用.NET技术开发,更新也好,发布也好很方便,但是需要数据库的支持,因此需要有一个数据库开发工程师,一个.NET开发工程师。
 
       方案3.
       中长期项目,要求很高,既需要字段的长度,又需要字段内的内容不存在全角或是特别字符,又要求符合逻辑,一定使用数据库支持,同时前端建议使用DELPHI或是C++开发可以很好的控制字段内容和逻辑,为什么不建议使用VB那?因为VB的字段长度控制存在问题。需要一个数据库开发工程师,一个前端开发工程师;
 
     (注明,以上的方案中,都假设有现成的CTI支持,因为不同的公司有自己不同的CTI,不同的排队机也有不同的CTI,可能有直接提供OCX控件的,当然也可能只是给了个2次开发的DLL)
 
       电话销售
 
      项目的目的很简单,能很好的联系客户,进行销售,成功的订单量是最主要的目的了,于是对于系统的要求也就是“信息”——其中包括了FAQ,相应的新的优惠措施等,但是这些都可以在TEAM LEADER的BRIEFING中得到信息,但是毕竟一开始的时候这些东西是十分重要的,在对于一些大的客户的电话销售的项目中,还要注意真个系统的开发尽量降低流程的关节,能够一个人一通电话结束就最好。
 
技术标准
 
      流程简洁——一般的电话销售都认为流程很简单,其实必定存在不可确定的因素:例如上门送货后失败了,用户没有来,用户反悔了等,这些情况必然会引起后续流程的出现,这些流程的出现将导致2个严重的问题:1,报表,一天和一天的报表是固定的,如果有退单的情况出现,那么对于前一天的报表就存在问题,那么就需要表明,或是用别的方式将实际数字和情况表示出来,虽然这些是营运要考虑的问题,但是作为IT,他们一定会来和你说“我只要一个准确的报表,不关你用什么办法”,于是就把压力转交到你这里了,所以在一开始的设计时候就要考虑到这点。
 
      质检——这点和上面的不同,因为这次的质量检测指的是对必须信息的必要性的检查,因为这样做可以提高订单的准确性。
 
       预约数据的控制——不要引起客户的反感,所以对于预约的数据或是BUSY NO ANWSER的数据都要做次数的控制。
 
       实施方案
       
       方案:
 一般电话销售存在以下几个步骤:
A. 数据的提取,进行电话销售
B. 销售成功,成功订单;销售不成功,决定是否有机会再做销售;预约;
C. 核实订单,决定上门的时间和地点;
D.  上门的结果反馈;
E. 成功:标记成功,失败:表明原因,有销售人员决定是否可以再跟进;
 
      这个项目的实现没有什么技术上的限制,可以用你喜欢的技术,根据开发时间的长短来决定,但是还是建议使用B/S方式,一定要注意状态的明确,时间和人也一定要明确。一个数据库开发工程师,2-3个开发工程师。
      
       客户服务
 
      这个应该是INBOUND的业务了,没有固定的标准,因为可能客户有了他们自己已经很成熟的CRM系统,你要做的就是给他们一个CTI就可以了,让他们可以打电话接电话,然后给他们像CMS这样的报表就可以了,当然,也可能从头到尾的CRM都要你来开发,这样的项目我是比较喜欢的,比较有挑战性,一般就不是2-3个工程师能完成的任务了,如果时间紧迫的话,那么就需要更好的控制了。
 
       技术标准
       IVR——一个少不了的INBOUND东西,没有语音流程就没有好的客服了,能让用户在IVR里面结束他们的问题就最好了,那么就可以降低AGENT的工作量,那么IVR的设计就尽量简洁明了,不要多而繁琐的IVR,因为可能客户还会问你要IVR报表来考核你。
 
       完善的CASE系统——对于客户服务来说,CASE系统是少不了的,用户的每一通电话都将是一个CASE,所以CASE的分类,CASE的解决方案是你在开发的时候要考虑到的,而且这点东西一定在不断的增加当中的,你可以用数据库来保存,但是我的已经是用个文本文件来保存更好,因为这样起码可以降低不必要的数据库请求,因为CASE库是很庞大的,在上面做的东西很多的。而且CASE的状态的变化也是可能会变的。
 
       复杂的DSS——对于客户服务而言,营运部门一定会问IT要数据分析的很多报表了,这点你要做好思想准备,CASE的分类,解决方案的分类那是一个不可能缺少的东西,每天的,每周的,每月的报表也是,所以你要建立一个CONTACT HISTORY来保存CASE在每天的结果,那么无论是天还是周还是月的话,报表是不会错的,否则只留一个状态,你就哭去吧。
 
      速度——有的公司要求ACHT的时间有控制的,因此慢的很的系统建议你不要用,用的话,责任就都是你的了,营运会把ACHT的原因进行详细分析,然后,如果存在一点点系统的延时引起的ACHT长度增加的话,那么你的责任就大了,所以,建议不要用J2EE,那个东西在人少的时候还可以(10-20个),如果(50)那么就慢死你了,然后系统开销又大,老板的钱不会随便花的。
录音——请保证你的录音一定有。
 
       实现方案
      J2EE方案:开销大的方案,除非出于客户的需求和你有很强的技术人员,否则建议不用这个方案;但是他的好处呢,可以移植,作个完整的,以后还可以出去卖,一个很不错的第三产业;
.NET方案:强烈内部推荐的方案,速度快,懂的人多,系统开销小,维护方便多了;
 
       以上都是一点点我的经验啦,由于边幅的问题,很不具体,如果你是IT的或是对我们的IT很敢兴趣或是有什么好的经验或问题都可以发邮件来联系我,哈哈。
 
       无聊的时候写写文章也不错。学习还是硬道理….
 
www.51callcenter.com 注:
作者联系方式:netis_sun@hotmail.com
 
 
                                                                                                       呼叫中心行业资讯网
 
 


  • 上 一条 信息:
  • 下 一条 信息: 
  • 分享到: