呼叫中心系统实现方案(一)

对于呼叫中心而言，所有的系统大致可以分为4种，分别为： Inbound 系统， Outbound 系统， IVR系统，MIS系统；一个大型的呼叫中心一般都拥有以上四种系统,当然也有部分的小型或中型的呼叫中心只包含其中的几项。 Inbound系统一般都和IVR系统有着密切的关系，但是AVAYA提供了另一种简单的IVR实现，那就是VECTOR，但是如果要更加的灵活或是丰富的话，IVR系统是必不可少的部分，当然他的功能能做些什么，我将在以后慢慢说明。今天就Inbound系统做个比较详细的分析和说明，以便于从事呼叫中心系统开发人员了解整个系统应该有的功能以及将来的发现方向，以下只是个人的观点和做法，仅供参考。

我在这里指的Inbound系统不是传统意义上的电话Inbound了，当然目前他仍旧是最为主流的媒体之一，目前就Inbound的手段可以分为：传统的语音电话，传真，EMAIL，SMS以及WEB CALL（这个方式已经在很多网站上提供了支持，就连银行也有在使用这种方式）。于是要求Inbound系统所能接受的方式也就多种多样了。我对呼叫中心中使用的方式进行了排序：TELEPHONE > EMAIL > WEB CALL > SMS> FAX；为什么我会这样排序呢？传统的电话仍旧是最为人们容易接受的方式，因此可以所每个呼叫中心必定也就是要把注意力集中在这点上，EMAIL的方式已经渐渐的也为人所能接受，毕竟上网的人哪个没有用过EMAIL去询问情况呢？因此如果能合理的安排EMAIL的处理，那么也能少了不少的人力，因为大家都能理解为什么EMAIL的答复总是那么的慢（客户是这么认为的），于是，SERVICE LEVEL在EMAIL上面的将大大低于TELEPHONE方式，可以在电话空闲的时候抽出1－2个人去处理EMAIL，我看已经是很足够的了，WEB CALL正如我先前所说的，是一个新的被广泛使用的媒体，因为他有着实时，快捷，方便的有点，当然怎么样的CALL叫WEB CALL? MSN算是一种，QQ也算，只要是能聊天的都算，但是这些不带有排队和自动路由的功能，所以呢，如果系统要提供这些功能的话，不得不去找第三方或是自己开发了。SMS就不用多说了，但是用他作为呼叫中心的一个Inbound系统还是比较少的，毕竟你不知道用户到底是发什么东西过来的，于是处理的方式也就和EMAIL差不多了，但是更多的是垃圾了。FAX是个人认为快要被淘汰的Inbound手段，如没有什么特别要求话（例如什么单据，凭证什么的）个人认为还是让他去墓地比较的合适。

Inbound系统的目的只有一点，能够在一个CALL（姑且将所有方式的Inbound都在这里叫做CALL）中解决用户的问题，提高用户对服务的满意，能更好的介绍新的产品（算是一种新的增值，已经有一些方案在使用中了）。

客户

用户的信息，一般情况下，用户会留下他的联系方式，以便于未来的联系，其实不留电话根本不重要，因为获得个主叫不是什么问题，问题是留下客户的姓名，性别什么的都可以通过电话交流得知（排除特别情况）；客户的联络历史是另一个很重要的地方，当一个用户第一次打电话来的时候，就应该记录下时间同时可以和后面的案例关系起来，那么就能提供给下一次服务更多的信息。

案例

无论怎么样，Inbound项目都应该将呼入的CALL建立一个案例来处理，目的很简单为了能跟踪事情的发展，了解业务的情况，了解客户的问题所在。那么案例中应该包含哪些必须的东西呢？首先是对客户的问题做多级别的分析，如果你的项目够小的话，就分一级也就可以了，但是一般会对一通CALL分很多级，每级别都会有各个级别的分类，因此建议详细的分解级别，那么对于未来的MIS系统也好，对于OPERATION的业绩分析也好，对于客户的发展也好都有很大的帮助，因此强烈建议将级别分的“明确”、“完整”、“灵活”（这里的灵活是可以为每个级别添加种类）；再就是产品了（服务的种类）这点就每个项目的不同会有所不同，但是如果就泛指的话，无论是服务也好，人员也好都算是产品，只是一种是看不见的，一种是看的见的。询问的产品会影响你服务人员的服务水平，所以一般情况下会对不同的产品提供不同的TEAM去解决，在IVR上进行了分类之后，人工的再细分也是少不了的，因为当你服务的是一家有几百个产品的公司的时候，产品在案例中的记录也就成为了一种艺术，为什么说是一种艺术呢？因为你可以通过不同的方式来将产品呈现给我们的服务人员，从细化到序列号，型号，到泛化到大类，如果让服务人员去选择，如何将案例的重点表现出来，又如何为未来的产品推广做准备呢？呵呵，这些都是产品信息可以给出你的。分析将有注于未来的发展；再者是案例的状态，其中包括了案例目前的状态，历史状态，状态更改的原因等，这些往往有人会忽略掉后者，但是在你开发MIS系统的时候就会发现在那么FRONT END记录的东西那么的少，都不足以出一份简单的报表了，当然CASE LOG还有利于分析案例的REOPEN情况，FTR等，然后是案例的来源，如果系统做的完善的话，这点应该是不用服务人员自己去填写的，系统会根据方式来自动填写的内容；最后就是备注和附件，为什么我会加上附件这样一种东西呢？因为往往情况下，应该将用户的描述原封不动的保留给下次来查看，电话就做不到这点了（除非你把录音最为附件来和案例一起保存，这种做法实在是不多），但是EMAIL和SMS都可以最为附件来保存的话，那么对于未来的服务人员原始信息的查询就很有利了。

升级

一个再好的呼叫中心，也不可能没有一次升级，能不被投诉已经是不可能的事情了，升级的目的就是将投诉率降低到最少，能近可能的降低不能解决的问题和近可能的安抚客户，于是就出现了应答技能更好，技术更强，服务更到位的人了，我在这里说指出的升级不单单包括了内部的，也包括了外部的升级，因为有些情况下升级的内容是需要别人去安排时间上门的，例如产品的包修等。升级应包括了案例的升级，升级的时间警告，升级的多媒体的警告（可以是弹出的窗口，可以是一个OUTBOUND CALL，也可以是一条SMS）这些都可以让高级的服务人员能更加及时的答复客户，更加有效的控制案例；当然升级的历史是一定要保留的，因为OPERATION能通过他更好的考核各个层面对问题的解决情况和效率。

知识库

好的知识库能有效的提供服务人员足够的信息，本人见到过最好的知识库莫过于MSDN和图文并茂的NOKIA了，现在服务人员对知识库的要求也越来越高，能进行查询是最为起码的内容，能对知识库的准确性进行评估，能对常问的问题优先出现，能对产品做多种方式模拟，能更有效的将消息反馈给管理，能对不同的技能做不同的分类处理等，这些需求也随着技术的发展越发发展了。

其他的单据

不得不说得是由于服务的产品以及服务的面的不同，因此往往会有些不同的单据会产生，跟踪单据的情况就成为Inbound系统中的另一个部分了，客户可能会问：上次我打电话来要保修的东西，怎么现在还没有人来修呀？于是你就要查询保修单目前到底去了哪里？谁负责的了；或是用户来问，我买的东西怎么还没有送到，于是也就出现了订单的跟踪，这些都是根据不同的行业有者不同的单据，少的可能一个案例就一个单据，多的，一个案例5－10张单据都有可能，因此，建议在设计的时候使用一对多的方式比较的合适和灵活。

CTI是一个很好的东西，应该集成在我们的Inbound系统中，一方面可以将电话的信息（号码）直接提供给我们服务人员或是由后台去寻找相应的客户资料，另一方面可以让服务人员了解目前在线的人数，等待的人数，SERVICE LEVEL等，这些都是考核呼叫中心的指标，最后就是有了CTI，服务人员就可以脱离掉电话的按键，直接在电脑上进行操作，更好的地方就是很多系统都需要有CTI的功能才能得到更多的信息，例如IVR的信息等。同时有了CTI，转电话的时候也就有了数据，这点将大大的提高了升级的使用性和灵活性。

最后，要指出的是Inbound系统绝对不可能是通用的，他的通用无非是在CTI，知识库，工作流上，这些地方的设计可是灵活和通用的，但是别的地方只是建议使用通用的模型，而内容方面还是根据具体需求来开发比较的好。毕竟速度不是可以放弃的一点，越通用越花时间。