为移动电信客户服务(中）
——写给移动电信公司的客户服务白皮书
2001/07/25
三、如何部署一个客户服务系统？
基本功能
今天，成功的客户服务系统是按以客户为中心的形式设计的。按照这种设计，如果他们想要保持或者发展与客户的关系，每一个客户服务系统的实施必须能够管理交互，以适应客户的需求。无论联系从客户开始，还是从客户服务中心开始，对客户的了解都是至关重要的。利用这种了解，可以在客户和客户服务中心之间提供最好的交互。
所有的移动电信公司客户服务系统都有一组共有的需求。主要需求包括：
电话控制
呼叫、座席代表和呼叫活动控制呼叫、座席代表和呼叫活动控制
一个座席代表桌面应用程序
一个脚本编写工具
联系人管理
客户服务中心监督和管理，以及统计分析。
其它广泛应用于客户服务系统的组成部分包括：自动座席代表（被称为交互式语音响应 (IVR) 单元），智能呼叫路由，包括基于技能的路由，呼叫记录，向外呼叫活动的预测算法和网络实现。
一些特殊的移动电信需求是：执行客户划分的数据库行销系统，联系人管理和用于管理客户交互的工作流程系统，以及与客户列表的结合以实现通过 ANI 进行客户识别。
为了建立一种成功的环境，集成是极为重要的。虽然最好的客户服务系统可能会成功实施，但通常来说，与客户服务系统或整个企业中业已存在的原有系统/业务应用进行集成，总是有必要的。
电话控制可以实现语音和数据之间的同步，它提供屏幕弹出和软电话性能。软电话是指，不用话机而只通过座席代表桌面执行所有电话功能的能力。电话控制是通过特定的，通向客户服务中心的 PABX 交换网关实现。
座席代表桌面应用程序可使座席代表能执行诸如‘登录’和‘就绪’这样的操作。例如，“呼叫连接”事件触发器，提示该应用程序在座席代表工作站启动一个会话。座席代表工作站由软件电话和相关的呼叫应用程序构成。
脚本编写工具是为开发交互脚本而设计的。在与客户交互时，交互脚本引导和驱动座席代表的行为。除了语言指令和表达式，它还可能在其中嵌入电话和联系人管理活动，以及用于设计交互流程的图形工具。
客户服务中心的表现需要受监控，这个任务通常由客户服务中心的班长负责。班长的职责是：必须能够监控所有的呼叫活动、座席代表、班和呼叫，并且能够执行必要的行动纠正反常或不希望出现的情况。此外，与某一呼叫活动行为相关的统计信息也很重要。
在移动电信客户服务中心，实施自动化的服务至关重要。这是一种通过自助服务来降低成本的方法。移动电话使用者的一些问题是，可否用自动化系统轻易解决问题（例如，查询预付款帐户上的现金余额）。这种自助服务可通过使用 IVR 系统执行。
如果作为一个前端设备使用，IVR 能统筹使用从呼叫中获取的信息（例如 ANI � 自动号码识别，广泛应用于鉴别正在呼叫的客户）并能为客户提供信息，确定最好的服务，甚至代表客户服务。进一步讲，就是根据每个服务代表的技能确定策略和规则，以吻合客户的品位。
在某些情况下，出于质量管理的需要或安全目的，记录代表和客户之间的交谈是有必要的。当新的服务代表加入客户服务中心时，这些谈话也可用于对他们的培训活动。这种交谈的记录通常被称为呼叫记录。
如前所述，IVR 是执行客户自助服务时的一个选择。另一个普遍的自助服务领域是因特网，通过公司的网站可为客户提供方便的渠道，以便以较低的成本获取得大量各种各样的信息和服务。对于任何自助服务来说关键的一点是，当客户需要自助服务时，他就能得到帮助和辅助。这可以通过网站上的一个联系按钮实现，通过该按纽可与客户服务中心的服务代表提供的人工辅助服务建立直接的连接。从按下按纽那刻起，客户和服务代表便能通过推送和拉回页面，以及协助表单填写进行协作。
作为公司对客户的前端界面，客户服务中心必须在联系时自动提供客户信息。这就需要客户服务中心与拥有重要客户信息和智能的企业应用程序的集成达到一个较高的水平。
决定系统规模
在部署客户服务中心时，要解决的一个难题是：要定义需要多少资源，才能在提供最合适的服务水平的同时，投资最小、资源利用率最高并保证所有者的总成本最低？为合理决定客户服务中心系统规模，需要估计客户服务中心客户使用量的预期值，以及处理这些联系需要的资源。
估计联系人和座席代表的数量
经验显示，在一个正规的移动电信公司中，每天的联系量与客户数量成正比。两个个案研究是：葡萄牙的 Telecel Vodafone 和巴西的 Telesp Celular。
Telecel Vodafone
Telesp Celular
客户数量
190 万
460 万
联系量/日
50000
120000
每日呼叫的客户百分比 (%)
2.6%
2.6%
根据上面的表格我们可以预测，每天联系客户服务中心的客户数量占整个客户群的 2.6%。当然，如果首次执行这样一个系统，百分比值会比表中的比值高一些，但会趋近这个比值并稳定在该水平。
为决定客户服务中心需要多少座席代表，再看一下同样的例子：
Telecel Vodafone
Telesp Celular
客户数量
190 万
460 万
座席代表数量
618
1462
比率（客户：座席代表）
3074：1
3146：1
根据该模式，我们可决定：在一个满负荷工作的移动电信呼叫中心，我们需要为大约 3100 个客户配备一名客户服务座席代表。
为进行排班管理，通过时间预览联系工作量的分布
在规划客户服务中心规模时，最困难的问题之一是：通过时间估计呼叫分配。通过一个 24 x 7 的工作安排，移动电信公司必须按天估计他们将要处理的联系量。下图显示一个移动电信公司工作日典型的联系分布：
根据这些数字，可以安排排班并在整个工作期间维持同样的服务质量，从而优化使用的座席代表数量，减少花在座席代表上的费用。这些数字会因各种因素变化，但是如果在开始时估计得比较精确，便可根据以后客户服务系统的实际运行数据进行微调。
使用 IVR 来降低座席代表工作量并路由呼叫
在移动电信业中，当公司想要为其客户提供一种服务时，使用语音信道是十分方便的。从获得信息到执行股票交易，电信公司使用他们的电话设施为客户提供越来越有效的方式，让客户通过电话进行有意义的操作。
给客户服务中心内的座席代表分配任务，让他们接听定义好的和重复性的客户呼叫，这样做费用昂贵，并且会降低客户对服务的使用率。IVR 通过为客户提供直接与公司进行联系的自动方式，从而解决了这个问题。这种方式不仅不要求人力资源还能增加客户服务系统的呼叫能力。
一些能较好的，能说明使用 IVR 进行自助服务的例子是：
预付款过程的信息
为你的电话改变价格计划
启动漫游
语音记录系统
要求打印的发票
自动帐单支付
其它有关 IVR 的重要用法是：与客户交互，以便确定如何更有效地将其呼叫路由给一个座席代表，从而得到正确的技能。在 Telecel Vodafone，当客户服务中心超负荷运行时，这种机制用于减少座席代表转接和鼓励客户利用自动系统的优势。
通过使用这种策略，客户服务中心可以自动应答来话呼叫中的 40%，因此减少了需要应答客户联系的座席代表的数量。要决定一个 IVR 系统的规模，需要对我们自动提供的交互类型有充分的认识。
Telecel Vodafone
Telesp Celular
客户数量
190 万
460 万
IVR 呼叫的比例
40%
20%
IVR 的数量
214
300
比率（客户：IVR）
8878：1
15,333：1
这组数字显示，为了从 IVR 系统中获得最佳的响应，公司应该为大约每 10000 个客户部署一个 IVR。
优化座席代表
为优化座席代表呼叫处理和质量服务交付，客户服务系统应该能支持一些基本的流程。
第一个流程是将座席代表组成班。当把座席代表组成为不同班后，他们便建立起一种集体感，并在他们自已与其它班之间建立起竞争意识。这种意识会引导他们表现得更好，目的是比其它班取得更好的业绩。客户服务系统能将每个班的表现生成一个报告，这点非常重要。安装可以实时报告各班表现的显示墙板，可用来协助测评他们的表现。班的大小，在很大程度上取决于活动座席代表的人数，但应控制在 4 至 10 人之间。
第二个流程是设定班长，班长有责任监控服务质量并且保证其它座席代表行为的正确性。这些班长应该配备时刻监控服务水平和队列长度的联机监控工具。客户服务系统应该能让班长在座席代表的表现降到某一警戒线下时设置警报。班长数量可根据先前分析过的案例确定：
Telecel Vodafone
Telesp Celular
客户数量
190 万
460 万
座席代表数量
618
1462
班长数量
50
88
比率（座席代表：班长）
12.3 : 1
16.6 : 1
根据描述，我们可以估计，在一个满负荷工作的客户服务中心，座席代表数量应该在 12 至 17 人之间。具体数量取决于期望的服务质量，同时也取决于班的组织。
部署电子邮件和网上协作
客户服务系统其它的基本渠道是电子邮件和网络协作。这两个渠道会影响决定所需座席代表的数量规模以及他们的技能。但与语音相比，这些渠道有不同的特性：
电子邮件是一个脱机渠道，意味着在 24 个小时到 3 天内的任何时候收到回应都是可接收的。这基本上表明座席代表能在高峰时段以后回复电子邮件，而高峰时段他们在需要时可以全身心地投入语音服务。
尽管网上协作是个联机渠道，但不像语音那样对路由时间要求苛刻。这是因为客户控制着浏览器，并且在其等待连接协作时，可执行其它操作。
基于这些原因，电子邮件和网上协作不会影响服务水平，并且通常对客户服务中心需要的座席代表数影响也不大。但是，上述陈述仅当客户服务系统允许所有的联系渠道进行统一排队时，才成立。这样，才能让座席代表利用呼叫间隙的全部时间来处理网上协作和电子邮件。
常规体系结构
对于一个移动电信公司来说，实现一个客户服务解决方案意味着多个系统层、技术和解决方案。第一层是基础结构层，包括所有语音和数据结构，即交换或 PABX，以及数据网络部分，这些对于向客户服务中心内所有人员发送语音和数据是必需的。
第二层是交互层，包括处理所有媒体交互所需的全部系统和技术。该层典型的技术是 CTI（计算机电话集成）、IVR（交互式语音应答）、ACD（自动呼叫分配器）、电子邮件服务器等。以上两层体现客户着眼于公司的途径。
第三和第四层体现公司着眼于客户的途径。第三层是处理层，第四层是分析层。处理层与 CRM（客户关系管理）解决方案相联系，在处理层构造了所有与客户联系的过程；分析层主要进行数据信息的处理（例如，数据挖掘），目的是检索和使用尽可能多的有关客户习惯的信息，并将它们转换为收益。
在客户服务中心范围内，为客户联系体验提供改进和对联系渠道提供效率的层是交互层。因此，下面部分主要说明这个层。
基础结构层
该层包括用于向所有客户服务中心相关联的所有用户传递语音和数据的所有必要组件。这些位置可以单独设在一个建筑物内，也可设在几个建筑物内。面对面座席代表的办公室可位于客户服务中心内的不同办公室，从那里座席代表通过语音或电子邮件与客户联系。对于移动电信公司来说，第一层通常已经建立。同时，支持客户服务系统的数据网络通常已经部署，使已有的系统能够互相通信。
交互层
在该层处理所有的交互，因此在这里有几个非常重要的组件。下图描述了实施多媒体客户服务系统需要的主要组件。
该图未直接论及交互，但是我们可以想到在这种系统实施过程中进行的各种交互。例如，如果客户服务分支部门也设座席代表，那么利用这种体系结构就能进行面对面的交互。
图中，座席代表提供语音和电子邮件交互服务。IVR 提供语音自助服务交互，而网络服务器提供网络自助服务交互。
CTI 功能的出现将自助和辅助交互连接起来。该功能允许将呼叫从 IVR 无缝转移至座席代表，而网络协作服务器可让一个座席代表能够请求与另一个座席代表进行实时共同浏览会话。事务部门的座席代表也可执行同样操作，以应答更复杂、更耗时的请求。
交互分类
客户服务系统必须能够管理与客户的交互。如果是客户联系公司，那么此类交互被称为呼入；如果是公司联系客户，则称为呼出。
一个标准的客户服务系统应该能处理“呼入”交互，此外还能：
自动处理呼叫，无需人工座席代表干预
有效地将呼叫路由到最适合的人工座席代表处，并且向他提供全部所需的信息以快速解决客户的问题
追踪进行的全部活动以生成适当的管理报告
一个典型的呼入交互将按下图描述进行处理：
图 1 – 呼入交互
①客户呼叫服务（DNIS –被叫号码识别业务）
②呼叫到达业务交换机并通知服务器（ANI –自动号码识别）
③呼叫到达业务交换机，但没有可用的座席代表来处理呼叫，通知服务器，呼叫在队列里等待
④呼叫被分配至最适合的座席代表，同时通知服务器
⑤座席代表接收呼叫，并弹出适当屏幕
在“呼出”交互中，一个标准的客户服务系统应该预装有一个用于执行的联系人列表，然后自动生成呼叫并且将呼叫分配至可用的座席代表，如下图所示：
图 2 - 呼出
①数据库中选择联系人
②交换机发出呼叫初始化请求
③拨打呼叫
④形成成功的呼叫并通知服务器
⑤呼叫到达分机并通知服务器
⑥座席代表接收呼叫并弹出与联系人数据相关的屏幕
交换和 ACD
这些组件处理语音业务并执行交换操作。交换用于对不同网络（如 PSTN——公共交换电话网络）的接入和拨出，这里指的不同网络可以是不同的固定电话网络，或电信公司移动网络。在客户服务中心内，所有的语音都通过交换机处理。
通常，ACD 是一个与交换机连接的特殊组件，它允许呼叫分配，更重要的是能够进行队列处理。通过使用一个 ACD 或是一个类 ACD 组件（如多媒体路由器），这些呼叫（收听音乐或公司告示）便被置于一个队列。
电话与头戴送受话器
处理语音的座席代表使用电话和头戴送受话器与客户交谈。为了更好地从 CTI 应用控制电话，电话分机最好是数字式的。尽管在一些服务中可以使用模拟电话，但其中的一些功能必需是可用的。（这与 CTI 本身无关，而与使用的模拟协议有关。）
CTI 服务器
该服务器总是与交换机相连，并且将电话和计算机集成在一起。通过使用该技术，应用程序可向交换机发送命令（例如“拨打此号”），以及从交换机接收事件（例如“分机号 X 已挂起”）。通过这两类操作，应用程序能完全控制交换机并由此完全控制语音交互。为了 CTI 服务器和交换机都能够对 CTI 应用程序作出响应，交换机制造商提供了 CTI 服务器和交换机本身所需的软件。该 CTI 服务器能够，并且通常和其它组件一样与同一网络相连。
交互（辅助）服务器
交互（辅助）服务器是客户服务系统体系结构的主要组件，控制所有的客户交互以及它们在座席代表间的分配。其主要功能是：
呼叫活动管理；
座席代表和班管理；
渠道/交互管理；
基本的交互分配；
联系人管理；
网关管理。
呼叫活动管理，即控制服务或呼叫活动创建、呼叫活动参数、呼叫活动状态（不管是运行还是结束）、以及呼叫活动类型（不管是语音呼入呼叫活动还是电子邮件呼叫活动，或两者兼有）。从事呼叫活动的座席代表和班也受交互服务器控制。
除了控制座席代表和班工作的呼叫活动之外，交互服务器同样控制座席代表和班状态，例如就绪无交互、就绪带语音交互、在短处理过程中或因某种原因产生的未就绪。交互也有状态，可以是已传递、处于队列、等待某人处理、正在服务和完成状态。交互服务器也控制状态。
与交互有关的是存在于交互服务器中的，在呼叫活动层段定义和控制的基本分配规则。一个呼入语音交互，触发在呼叫活动定义中与 DNIS 相关参数匹配的呼叫活动。一个呼入电子邮件交互，触发在呼叫定义中与“给”子句相关参数匹配的呼叫活动。邮件过滤同样受交互服务器控制，以自动丢弃或溢出异常的电子邮件信息。
联系人管理由该引擎和数据库服务器共同承担。进行联系时，信息从交互资料库加载并将所做的修改存回其中。存储在数据库中的业务信息可被传递到业务应用中。
交互服务器与联系人管理有关，对于专门进行呼出联系人列表管理来说，控制从联系人列表启动呼出联系的过程。
交互服务器管理，并与各类渠道中涉及的所有网关通话，如电子邮件网关、PABX 网关和网上协作网关。语音网关包含了一种便于测试和培训的特殊网关，它是具有类似交换机行为的模拟器。
下图显示了交互服务器中更重要的进程以及这些进程之间的关系。特殊组件“多媒体路由器”中包含了智能路由器的特性。对此我们将做进一步的阐述。
交互服务器的物理配置取决于交互中心的实施要求。一台单独的计算机可能要安装所有与服务器相关的组件，如服务器本身，电话网关和数据库管理系统。另一种方法是，每个组件可以安装在一台独立的计算机上并通过网络相连。
多媒体路由器
多媒体路由器可使智能路由规则和基于技能的路由规则能应用于所有呼入交互，而与呼入使用何种渠道无关。这表明，客户服务系统应该象电话呼叫和网络协作请求一样，路由电子邮件信息。它保证所有的呼入交互在最短的时间段内，在最适合的座席代表那里得到最恰当的服务，并且客户服务中心能针对客户与其联系使用的不同渠道，提供一致的服务。
一个多媒体路由器的主要特性是：
多媒体路由选择；
智能路由选择或（和）基于技能的路由选择；
队列管理——障碍；
对于移动电信公司，路由能力极其重要。由于采用 Vip 处理，应该能通过每次交互的可用数据对交互进行路由。该数据取决于使用的媒体，通常一个语音呼叫包括 ANI（对移动电信很重要），一个电子邮件呼叫包括“发件人”子句、主题，甚至还包括邮件正文，一个包括了以前填入的客户信息的网络协作请求。
一些信息用于识别客户和分析其历史记录和需求。其它的信息可用于预计客户联系的原因并将呼叫直接路由至合适的座席代表，以优化资源和呼叫中心的时间。
呼出呼叫发生器
呼出呼叫发生器的主要功能是，自动操作和在拨号过程中增加智能。由于拨号统筹使用客户信息，用于决定实现成功联系的最佳时间并且还考虑到了人力资源，因此它是任何客户服务中心最重要的操作之一。由于有自动拨号器，故无需人工拨号，也无需花费时间搜索电话号码和管理失败的应答，如占线、无应答、传真、机器应答等等。
呼出呼叫发生器应该定义拨号规则的概念。拨号规则是由呼叫活动或联系人设置，它定义何时以及用哪个电话号码与客户联系。例如，客户在其办公室内的最佳联系时间可能是上午 9:00 到中午 12:00，而在午餐期间最好是拨打他的移动电话。
拨号规则对不同时区有不同的处理方法，所以绝对不会在违反常理的时间联系客户。比如，如果要联系的人采用 GMT 时间而客户服务中心采用 EST 时间，则由拨号器做相关的计算。举例来说，如果某次联系的拨号规则定于下午 14:00 和 18:00 (GMT) 之间，则拨号器在考虑客户服务中心和联系人的时区后，在上午 9:00 和下午 13:00 (EST) 之间进行操作。呼出呼叫发生器根据拨号规则和时区来决定联系。
在利用上述功能决定进行哪种联系后，呼出呼叫发生器向交互服务器发送真正的拨号命令。完成这一操作的方式取决于拨号器的另一特性——步进模式。呼出呼叫发生器能执行 3 种步进模式：预览拨号、增强拨号和预测拨号。
当服务代表需要在联系前了解客户概况时，使用预览拨号。这种功能广泛用于债务追缴，在这种情况下，对客户信息掌握的熟悉度和精确程度对于联系成功具有重要意义。在该步进模式中，座席代表通过他的桌面应用程序请求拨号命令。
增强拨号是最常用的步进模式，它仅在适当的就绪状态——服务代表可利用时，发出呼叫。该模式保证，在呼叫客户时呼叫总是到达一位服务代表，并且系统自动设置呼叫。该步进模式的弊端是降低了服务代表的表现，因为在拨号、振铃和不成功提示音提示——这些过程中耗费了大量时间。
预测拨号是当前最先进的步进模式，主要用于在短时间内联系大量客户。服务代表可将其时间用于应答呼叫，而不会将大把时间花在不成功的呼叫上。进一步，他们在拨号和振铃阶段也不会浪费时间。因此，服务代表有更多时间用于处理呼叫。
下图显示的是一个涉及呼出呼叫的时段，描述了服务代表的有效时段和无效时段。
一般来讲，每个座席代表被分配数个呼叫，其中可能有些呼叫不成功。同时，预测算法预测座席代表何时能提供服务。根据两种测算 � 联系成功的概率及服务代表在某一时间可用的概率，可计算出呼叫数。概率不断更新以实现最优性能。最优性能旨在充分利用服务代表的时间。在使用预测拨号的呼叫活动中，平均每小时的通话时间可达到 55 分钟；而使用增强拨号，平均每小时的通话时间一般为 25 分钟。
以下两个图显示增强拨号（图 1 中任务是连续的）和预测拨号（图 2 中有些任务是预测的）的区别。
在上例中，仅尝试便取得成功。
在此例中，执行了两次拨号，成功概率为 50%。
预测模式中，呼出发生器的主要功能是，计算服务代表在某一时间可提供服务的概率。为实现如此高的业绩，预测拨号器需要知道所有不成功的呼叫。这种能力通常由被称为分类器的组件来完成，分类器可与交换机或与预测拨号器本身连接。
由于在预测模式中加载的联系人数大于可用的服务代表数，因此联系可能在座席代表可用于处理呼叫前应答电话。根据呼叫活动的配置，呼出呼叫发生器能够：
立即断开呼叫；
将呼叫置于呼叫活动保持队列。
立即断开的呼叫被认为是干扰呼叫。置于保持队列中的呼叫要等待座席代表状态变为可用。即使呼叫仅在队列中保持几秒钟，一个保持队列也能显著提高预测拨号性能。有些联系人可能决定不再等待而挂机 � 我们称这些呼叫为放弃的呼叫 � 或者是因为呼出呼叫发生器因保持时间超时而决定挂机。我们将这些呼叫也称为干扰呼叫。
根据呼叫活动类型的不同，干扰呼叫率的期望值通常在 1% 和 5% 之间。
预测自动拨号最适合有 10 个或更多座席代表的呼叫活动。
基于座席代表的预测拨号最适合只有少量座席代表的呼叫活动。它与自动预测拨号类似；按每个呼叫活动进行统计，但按每个座席代表拨打呼叫。该模式需要座席代表的交互以决定何时拨打呼叫，也就是说，当服务器要拨打一个新呼叫时，就有一个可视的指示器为座席代表提供显示。座席代表可以点击该可视指示器，表明准备就绪或延迟拨号。座席代表也可在任何时间点击该可视指示器期待拨号。
预测平均通话时间最适合于呼叫时间短，通话时间变化小的呼叫活动。例如，只有简短脚本（如短时的调查）的呼叫活动。预测平均通话时间利用呼叫平均持续时间长短确定何时拨打呼叫。
数据库服务器
该组件包含了整个系统的数据数据库。典型的数据库系统是，可以与公司内其它数据系统连接的关系数据库系统。交互服务器不间断地访问数据库，以跟踪了解所有交互、座席代表、班和呼叫活动的情况。除了管理信息，所有关于客户和客户交互的信息均存储在这里。这些信息可用于显示关于客户服务的控制信息，还可以为其他应用（如分析过程）提供反馈信息，从而能够研究客户及其行为。
IVR
一个 IVR 系统可以让客户通过语音菜单和按键电话控制来进行自助服务。当将它用作决定路由选择的信息收集器时，同样能帮助优化辅助服务水平。
自助解决方案，一般通过指引客户进行操作的语音菜单来实现。通过这些应用类型，它也可能转到辅助服务。辅助服务也是一种由服务代表来执行的混合解决方案，它可以自动执行（基于特殊情况），如客户错误使用菜单；或根据客户请求执行，如转移到话务员的特殊语音菜单选项。业务应用可以只使用或者主要使用 IVR，用少量座席代表去处理复杂情况。例如，在 IVR 处理时刻表查询时，座席代表可以出售火车票。
实施前端和路由解决方案是为了在服务正式开始前了解客户。有时，可以直接通过网络收集这些信息，这样客户和 IVR 之间的交互就没有必要了。不管通过哪种方法收集信息，关键是路由策略，例如 VIP 服务，或将以前的呼叫者连接到同一个人工座席代表。IVR 应用经常是客户与企业联系的第一个接触点，并且它能为呼叫者提供有关客户服务中心的路由决定和呼叫者概况的重要信息。
有一些固定的 IVR 应用，对于诸如偶然事件和劝导服务十分重要。偶然事件服务，用于避免严重和异常情况发生时的峰值期。如移动网络小区在大面积的范围内中断。客户受到 IVR 的状态警告，这可能会阻止他们在队列中等待。当服务超载时，使用劝导服务。在这种情况下，客户可以选择留下信息、要求回叫或继续等待。另一个例子（尽管不可能在所有国家出现），使用 IVR 应用来直接呼叫客户，提醒客户他们的发票过期未付。
座席代表的座席与应用程序
座席代表的座席由工作站和一个配有头戴接受话器的电话构成。根据客户服务中心的环境，座席代表使用浏览器或视窗界面运行客户服务应用程序。两种环境具有相同功能，对它们的选择取决于几个因素 � 例如公司的政策、响应时间、已开发的和再次使用的应用程序等。
座席代表界面应有以下主要特性：
座席代表界面系统允许，登录或注销、就绪或未就绪进行交互、打开或关闭呼叫活动操作；
控制屏幕弹出的呼叫活动应用程序；
保证交互和座席代表的正确状态；
可轻松定制，以反映座席代表需要，和移动电信公司为客户提供的新呼叫活动；
允许具有初级培训的座席代表进行工作，增加座席代表产出量。
为了让座席代表能同时服务于一个或多个呼叫活动，（不考虑媒体和呼叫方向）她/他必须登录系统并让自己就绪。如果交互出现并分配给该座席代表，或者系统产生交互并分配给该座席代表，则出现一个屏幕弹出，且座席代表应用程序与相应的呼叫活动定义的应用程序共同载入。座席代表应该具有执行所有媒体操作的功能，例如软电话，这样座席代表就不需要使用电话或访问其它应用程序。
在实时情况下，座席代表同时接收联系人，语音和应用程序，并且根据应用程序脚本控制与联系人交谈。在交谈结束时，他们应该完成应用程序并且进入就绪状态以进行下一次交互。
呼叫活动的应用程序——也被称为脚本，是在呼叫活动基础上定义的，它们指引座席代表完成与客户对话的整个过程。脚本通常是一系列页，包含了客户信息、产品或服务数据、与其他页的链接，以及用于指导座席代表进行交互的文本对话。屏幕显示与座席代表交互保持一致。
对于移动电信公司，这种脚本的迅速部署非常关键，这是因为流程应该迅速适应新产品和新服务。如果班长发现座席代表按照脚本操作有困难，那么作为班长应能对脚本做些修改。
邮件服务器
邮件服务器处理电子邮件并且与交互服务器相连，以便向客户服务中心内的座席代表分配某些电子邮件（根据“收件人”子句）。客户服务中心无需拥有一个单独的电子邮件服务器，只有一些特定地址的电子邮件才能通过交互服务器。用于客户服务中心的邮件服务器均采用标准协议——使用 POP3 协议接收电子邮件，使用 POP 协议发送电子邮件。
网络服务器
网络服务器应该包括所有将电信公司展现给因特网用户的网页。为使网上协作成为可能，该体系结构中的网络服务器，应能处理网上协作服务器要求对其访问的请求。
网上协作服务器
网上协作服务器应该成为连接辅助服务（通常需要通过客户服务中心实现）与自助服务（通常需要通过因特网实现）之间的桥梁。
网上协作服务器解决了业务应用中的两个关键的问题：网站放弃和客户指引。
如果没有一种与客户服务代表联系的途径，即使是一个设计出色的网站，也会出现网站放弃。因此，协作有助于加强保持客户。通过指引客户使用自助服务应用，网上协作能够解放客户服务中心的座席代表，使其集中精力于其它更重要的任务，从而显著降低运营成本。
网上协作的方式可以从回呼请求（立即或稍后）开始，也可从文本交谈请求开始。在这两种情况下，辅助服务请求都转给客户服务中心，然后分配给与客户协作的座席代表。
当客户按下“与我们联系”按钮时，就产生一个协作请求，且此请求被分配给一个可用的座席代表。座席代表接收状态页，并能看到请求的细节和联系人的详情。
处理层与分析层
最上面的两层负责客户服务阶段实施的所有过程，以及负责分析结果信息和服务表现。
处理层直接映射到座席代表使用的应用程序。例如，工作流程处理、信息处理和索赔处理。支持这些处理的应用程序可以从零开始开发、或根据现有的客户服务模板开发。然而，下面的交互层能处理所做的选择，这点极为重要。简言之，规范和开放的体系结构应该就位以容纳任意选择。鉴于移动电信公司的特性和快速开展的服务，对于他们来说，最佳选择是拥有一个能迅速发展和部署新功能的系统。
分析层是一套提供信息的专门工具，目的是为了改进服务、进行增加销售或交叉销售、提前主动联系客户进行销售或得到更多与客户相关的信息、甚至可根据可用产品和服务重新定义公司的策略。数据仓库和数据挖掘工具可用作帮助定义策略，即它们可对某些呼出呼叫活动输入客户联系人。该信息可存储于交互服务器，并在一个呼出呼叫活动设置后，自动载入联系人并传递给已受过培训的座席代表。
