项目编号 | 销售价格(万元) | 新需求 | 开发成本(万元) | 开发成本中代码编写部分(万元) | 开发成本中测试部分(万元) | 利润(万元) | 稳定性(一年宕机的小时数) | BHCC |
1 | 10 | 0% | 0 | 0 | 10 | 10 | 10 | 30万 |
2 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
3 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
4 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
5 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
6 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
7 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
8 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
9 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
10 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30万 |
我们可以看到,一年运营下来,软件的稳定性没有下降,每个项目宕机总时长都是10小时,每个项目的BHCC值都是30万,但是企业只有10万元的利润,离预期100万元的收益很远。
还有一个隐藏很深,但是致命的问题,就是人员不够了,需要扩招研发人员。为什么呢?因为软件开发了一年,10%的修改需要的时间是1.2个月,只要发生两个项目并行,就会出现人员不够的情况,只能扩招1个研发人员,那么,一年运营下来,血本无归。
国内大部分公司选择的方案是如下的:
项目编号 | 销售价格(万元) | 新需求 | 开发成本(万元) | 开发成本中代码编写部分 (万元) | 开发成本中测试部分 (万元) | 利润(万元) | 稳定性(一年宕机的小时数) | BHCC |
1 | 10 | 0% | 0 | 0 | 10 | 10 | 10 | 30万 |
2 | 10 | 10% | 10 | 4 | 0 | 6 | 30 | 25万 |
3 | 10 | 10% | 10 | 4 | 0 | 6 | 60 | 20万 |
4 | 10 | 10% | 10 | 4 | 0 | 6 | 120 | 15万 |
5 | 10 | 10% | 10 | 4 | 0 | 6 | 180 | 10万 |
6 | 10 | 10% | 10 | 4 | 0 | 6 | 210 | 9万 |
7 | 10 | 10% | 10 | 4 | 0 | 6 | 240 | 8万 |
8 | 10 | 10% | 10 | 4 | 0 | 6 | 270 | 7万 |
9 | 10 | 10% | 10 | 4 | 0 | 6 | 300 | 6万 |
10 | 10 | 10% | 10 | 4 | 0 | 6 | 330 | 5万 |
一年运营下来,企业只有64万元的利润,收益大幅提高,而且不需要扩招人员,可怕,稳定性降低很多很多,一年宕机到330小时,可能是每天宕机一次。BHCC值逐步下降到5万。
还有一个隐藏很深,但是致命的问题,就是稳定性的问题是经常是乘法关系,即多个不稳定因素会关联在一起,导致系统更加不稳定,因此一年宕机330小时的估算是非常保守的。
而对于客户来说,导致众多运营上技术问题的核心都在于软件公司将测试成本省去,因为软件公司可能活不下去。
二 灵活性
技术上问题的核心在于稳定性和灵活性的矛盾,即需求的满足和变化的适应需要灵活性。现在再看看呼叫中心的灵活性产生的原因,灵活性有多么大,多么可怕。
呼叫中心系统灵活性产生的原因我认为有以下几个方面:
- 新的通信方式的不断产生;
- 新的行业不断扩展;
- 新的计算机软件技术的不断发展;
- 新的业务模式的不断创新;
- 新的管理方式的不断深化;
从技术上来说,灵活性产生的原因是两个方面,第一,整合的要求,第二,策略变化的要求。
(一)整合的要求
呼叫中心系统是一个全方位整合的系统,这一点我们很容易理解。
有一个上海的合作伙伴,我在和他的CTO聊天的时候,双方都是感慨万千。CTO说,他们是在语音板卡上开发的呼叫中心,做电视购物呼叫中心系统,有这样一个问题:客户提出了业务软件的一个修改,他认为工作量不大,但具体做业务软件的时候,发现需要修改坐席业务软件,具体做坐席业务软件的时候,发现需要修改软电话…….最后,需要修改对语音卡的控制,总计需要修改7-8个模块,而销售只谈了2万元,而且这种事在他们公司经常发生。
对于很多的客户,在系统整合的要求方面,他们确实要求很高,例如,在录音调听软件中,需要整合各种监控信息、报表信息、客户信息等等。甚至有的客户认为呼叫中心的所有管理软件应该按照Portal的概念组织。
呼叫中心的各个组成部分。PBX、CTI、ACD、IVR(包含传真)、ADS(自动外拨系统)、ACC(短信、邮件等异步通信方式的呼叫中心)、ICC(Internet呼叫中心)、录音服务器、录音调听软件、坐席软电话、坐席业务软件、业务软件,报表和实时统计,这些部分虽然数量不多,但是每一部分和其他交互很多,下面,我们分析一下交互,这种分析不是根据一个项目的需求分析的,而是大量项目的总结,也就是说如果你要想做一个可以在大量项目中复用的软件,那么这些交互你必须都要想到,否则,你的软件只能在少量的项目中使用。
整合产生的灵活性要求举例:
1、PBX:这是整合要求最少、灵活性要求最低的。
它只和CTI整合,很庆幸,ITU、ECMA和微软等等公司做了很多标准,我们按照标准做就行了,但是,还是有个别PBX厂商对标准支持的不好,需要CTI软件去适应;
2、CTI:整合要求最多、灵活性要求最高,这部分是大家比较熟悉的:
a)ACD需要从CTI获取交换机各种来电信息并通过CTI需要进行呼叫路由;
b)IVR需要从CTI获取交换机各种来电信息并通过CTI需要进行呼叫控制;
c)ADS需要通过CTI需要进行外拨并从CTI获取呼叫外拨结果;
d)录音服务器需要从CTI获取交换机各种呼叫信息形成相关的录音记录;
e)坐席软电话需要通过CTI进行全方位的坐席电话操作和信息显示;
f)报表需要从CTI获取中继、分机等呼叫信息并形成历史报表数据;
g)实时统计需要实时从CTI获取中继、分机等呼叫信息并形成实时统计数据;
3、ACD:应该说整合要求很多、灵活性要求很高,这部分大家应该非常陌生:
a)IVR,分成三个方面,第一,ACD系统需要根据客户来电在IVR输入的信息,如业务分类,账号等等信息来进行呼叫路由;第二,ACD系统在很多情况下是将呼叫物理驻留在IVR上,控制IVR进行排队音乐和提示的播报和转接操作;第三,ACD系统可能将呼叫路由到IVR,如在电话刚刚进入呼叫中心的时候,或者在做呼叫溢出的时候,这是ACD需要IVR占用情况的实时统计和命令IVR进入哪一个语音流程;
b)ADS,ADS对ACD的需要也全面,大体分成三个方面:第一,ADS外拨电话接通后,需要将呼叫通知ACD,让ACD分配到一个最适合的坐席;第二,ADS在执行外拨算法的时候,需要根据ACD提供的历史统计数据和实时统计数据,如每一个坐席或坐席组的历史平均通话时长和当前每一个坐席的占用状态;第三,ADS需要ACD配合呼入电话的需求,进行混合(Call Blending);
c)ACC,ACC的短信、邮件、传真的请求需要ACD进行统一排队和分配;
d)ICC,ICC的文本交谈、电子白板、文件传输、护航浏览的请求需要ACD进行统一排队和分配;
e)录音服务器,录音服务器需要对ACD的信息进行记录,如坐席相关的信息,坐席姓名、工号、排队情况、技能组等等;
f)坐席软电话,软电话需要和ACD系统进行交互,主要是坐席状态管理、技能管理、分组管理等等,并且ACD要根据软电话的状态进行呼叫路由和分配;
g)报表,ACD需要产生大量的报表数据以供运营分析和辅助决策,如呼叫排队情况、呼叫分配情况、坐席状态的统计、坐席工作量统计等等;
h)实时统计,ACD需要以实时统计的形式提供现场管理的手段;
4、ADS(自动外拨系统):
a)ACC(短信、邮件等异步通信方式的呼叫中心),ACC同样需要主动发起,需要ADS统一管理;
b)录音服务器,需要记录外拨特有的录音信息,如外拨时长,还需要录制客户应答之前的声音;
c)坐席软电话,屏幕弹出等操作需要和ADS进行配合;
d)业务软件,需要对外拨的任务管理、外拨客户资料管理方面与ADS交互;
e)报表,需要形成ADS相关的各种报表,以便调整外拨策略;
f)实时统计,两个方面,一方面ADS需要形成实时统计的数据,以供管理人员进行实时调整干预,另外一方面,外拨算法需要根据实时统计数据执行外拨算法,尤其是在预测外拨的情况下;
5、ACC(短信、邮件等异步通信方式的呼叫中心):
a)录音服务器,短信、邮件等媒体,同样需要进行坐席质量管理;
b)录音调听软件,对于短信、邮件等媒体,需要特定的浏览器去显示;
c)坐席软电话,在坐席操作界面需要对短信和邮件进行显示和坐席操作,需要配合坐席业务软件进行客户资料管理和知识库调用;
d)坐席业务软件,配合实现与电话相同的处理流程;
e)业务软件,配合实现与电话相同的处理流程;
f)报表,实现与电话相同的历史统计;
g)实时统计,实现与电话相同的实时统计来实现现场管理;
6、ICC(Internet呼叫中心):
a)录音服务器,同ACC;
b)录音调听软件,同ACC;
c)坐席软电话,同ACC;
d)坐席业务软件,同ACC;
e)业务软件,同ACC;
f)报表,同ACC;
g)实时统计,同ACC;
7、录音服务器:
a)录音调听软件,很自然,录音调听软件和录音服务器进行交互,展示给运营管理者,以便进行质量考核;
b) 坐席软电话,录音的启动和停止、录音记录的信息需要软电话提供;
c) 坐席业务软件;两个方向,方向一,坐席业务软件可以随时根据权限调听录音服务器中的录音,以便业务关联和信息补充录入,方向二,坐席业务软件需要为录音记录补充需要的信息,如质检人员可以在录音调听软件中看到产品信息和订购信息;
d) 业务软件,业务软件的订单、工单信息,经常要直接关联录音文件;
e) 实时统计,录音的状态需要实时统计,展现给运营管理者;
8、录音调听软件:
a) 坐席业务软件,很多坐席业务软件要求内置录音调听软件;
b) 业务软件,很多业务软件要求内置录音调听软件,同时,录音调听软件经常需要同时获取业务软件的数据,以便进行质检;
c) 报表和实时统计,很多录音记录的信息需要来源于报表,同时,很多录音调听软件需要内置报表和实时统计,进行统一的显示;
9、坐席软电话
a)坐席业务软件,大家很容易理解,这是呼叫中心必须的;
b)业务软件,大家很容易理解,坐席业务软件和业务本来就是一体的;
10、坐席业务软件
a)报表,坐席自我管理经常需要进行报表的显示,如显示本坐席或本组坐席历史的平均通话时长、平均应答次数、平均转接次数等等;
b) 实时统计,坐席自我管理经常需要进行实时统计的显示,如显示本坐席或本组坐席实时的平均通话时长、平均应答次数、平均转接次数等等;
11、业务软件、报表、实时统计
很多客户会要求为了运营分析方便,将业务的实时统计信息、业务的历史统计信息、呼叫的实时统计信息、呼叫的历史统计信息在一个软件中显示,有的要求在中间件中显示,有的要求在业务软件中显示。
(二)流程策略的要求
和其他的软件一样,呼叫中心软件存在大量的需要随时调整地流程和策略,如IVR流程、呼叫路由流程、呼叫分配策略、外拨策略、报警策略、坐席状态管理策略等。
(三)稳定性和灵活性的矛盾
如果没有整合的要求、没有流程策略的不断变化,呼叫中心就可以很稳定,就像我们经常见到的电话交换机、网络交换机、打印机一样;
如果没有不间断运行的要求、性能的要求,呼叫中心就可以很灵活,就像我们经常见到的OA软件、CRM和ERP软件一样。
呼叫中心就是呼叫中心,需要解决这个矛盾,我们不得不演进到第五代呼叫中心”,下一篇,我们看看一种基于SOA思想的解决方案。
标签:长白山 平凉 开封 雅安 阿拉善盟 丽江 日喀则 通辽
巨人网络通讯声明:本文标题《第五代呼叫中心之SOA—连载3》,本文关键词 ;如发现本文内容存在版权问题,烦请提供相关信息告之我们,我们将及时沟通与处理。本站内容系统采集于网络,涉及言论、版权与本站无关。