- 主页
- /
- 文章
Webex Contact Center 体系结构
Webex Contact Center利用基于云的微服务架构,为所有客户渠道提供统一的体验。本文详细介绍了基于云的设计,概述了功能组件、集成、部署选项、安全协议和合规性方面的考虑因素。
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
图 1 说明了 Webex CC 的逻辑架构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
图 1 说明了将语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
图 1 说明了队列和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
图 2 说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
图 1 说明了 Webex CC 中的置备工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
图 2 说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
图 1 说明了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
图 1 显示了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
*有关下一代媒体服务的区域可用性的更多信息,请参阅 下一代语音媒体平台。
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
图 1 说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
图 1 显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
图 1 说明了 Webex CC 的逻辑架构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
图 1 说明了将语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
图 1 说明了队列和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
图 2 说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
图 1 说明了 Webex CC 中的置备工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
图 2 说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
图 1 说明了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
图 1 显示了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
*有关下一代媒体服务的区域可用性的更多信息,请参阅 下一代语音媒体平台。
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
图 1 说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
图 1 显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
图 1 说明了 Webex CC 的逻辑架构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
图 1 说明了将语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
图 1 说明了队列和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
图 2 说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
图 1 说明了 Webex CC 中的置备工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
图 2 说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
图 1 说明了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
图 1 显示了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
*有关下一代媒体服务的区域可用性的更多信息,请参阅 下一代语音媒体平台。
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
图 1 说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
图 1 显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
图 1 说明了 Webex CC 的逻辑架构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
图 1 说明了将语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
图 1 说明了队列和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
图 2 说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
图 1 说明了 Webex CC 中的置备工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
图 2 说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
图 1 说明了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
图 1 显示了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
*有关下一代媒体服务的区域可用性的更多信息,请参阅 下一代语音媒体平台。
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
图 1 说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
图 1 显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
图 1 说明了 Webex CC 的逻辑架构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
图 1 说明了将语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
图 1 说明了队列和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
图 2 说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
图 1 说明了 Webex CC 中的置备工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
图 2 说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
图 1 说明了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
图 1 显示了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
*有关下一代媒体服务的区域可用性的更多信息,请参阅 下一代语音媒体平台。
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
图 1 说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
图 1 显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
图 1 说明了 Webex CC 的逻辑架构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
图 1 说明了将语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
图 1 说明了队列和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
图 2 说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
图 1 说明了 Webex CC 中的置备工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
图 2 说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
图 1 说明了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
图 1 显示了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
*有关下一代媒体服务的区域可用性的更多信息,请参阅 下一代语音媒体平台。
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
图 1 说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
图 1 显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
下图说明了 Webex CC 的逻辑体系结构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
下图说明了语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
下图说明了排队和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
下图说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
下图说明了 Webex CC 中的预配置工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
下图展示了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
下图说明了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
下图说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
下图显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
下图说明了 Webex CC 的逻辑体系结构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
下图说明了语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
下图说明了排队和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
下图说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
下图说明了 Webex CC 中的预配置工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
下图展示了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
下图说明了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
下图说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
下图显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
下图说明了 Webex CC 的逻辑体系结构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
下图说明了语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
MPLS 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
下图说明了排队和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
下图说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
下图说明了 Webex CC 中的预配置工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
下图展示了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
Microsoft 动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
可以使用互联网或 Amazon Web Services(AWS)Direct Connect 建立与 AWS 托管 Webex 联系人中心的连接。 借助 AWS Direct Connect,数据通过客户内部部署网络与联络中心之间的专用网络连接 Webex 从而改善了连接。 有关更多详细信息,请参阅 适用于 Webex 联系人中心的 AWS Direct Connect。
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
下图说明了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
下图说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
下图显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
下图说明了 Webex CC 的逻辑体系结构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
下图说明了语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
下图说明了排队和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
下图说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
下图说明了 Webex CC 中的预配置工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
下图展示了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
下图说明了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
下图说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
下图显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center(Webex CC)是一种联络中心即服务(CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余 Cisco Webex 集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构 Webex 如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端直接聊天,例如 WhatsApp,Facebook Messenger,Apple Business Chat,来自 Twitter 的直接消息
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化 IVR 系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
下图说明了 Webex CC 的逻辑体系结构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的 Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍 IVR 系统。
电子邮件和消息传递
从 Webex CC 的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex 连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex 机制。根据媒体类型,交互到达 CC Webex 机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
下图说明了语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源 IP 地址) IPSec 虚拟专用网络(VPN)或基于通用路由封装(GRE)的 IPSec 站点到站点(S2S) SRTP/SIP TLS |
专用连接 |
Mpls 点对点(P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答,并开始执行与入口点关联的 Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量–与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环–使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据–JSON、TOML XML 通常用于解析 API 响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置 Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式 IVR 体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。
下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
下图说明了排队和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置(PIQ)、估计等待时间(EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队(CBT)进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop 运营
当代理登录到 CC Agent Desktop Webex 时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop 使用 Cisco Common Identity(CI)对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步 API 和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
下图说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
下图说明了 Webex CC 中的预配置工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex 入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
下图展示了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理(CRM)系统集成的模式。
-
桌面嵌入式连接器
-
通过 IVR 中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM 应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC 是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击 CRM 中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供 Agent Desktop 和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个 CRM 的 CRM 客户端 SDK,它使用 CRM 抽象出 REST API 调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
微软动态 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在 CRM 市场上有空。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过 IVR 中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和 IVR 中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展 Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他 API 集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
下图说明了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过 https / TLS(对于非 http 协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通 TCP 套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
下图说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在 CC Webex 任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在 Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于 Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC 的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
下图显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
Cisco Webex Contact Center (Webex CC) 是一种联络中心即服务 (CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余Cisco Webex集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构Webex如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端(如WhatsApp,Facebook Messenger,Apple Messages for Business)直接聊天。
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化IVR系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
下图说明了 Webex CC 的逻辑体系结构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器Webex允许开发人员定义流并将其分配给调用通过 CC 到达Webex入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍IVR系统。
电子邮件和消息传递
从Webex CC的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
-
适用于企业的 Apple Message 消息
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex机制。根据媒体类型,交互到达 CC Webex机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
下图说明了语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余 – 支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源IP地址) IPSec 虚拟专用网络 (VPN) 或基于通用路由封装 (GRE) 的IPSec 站点到站点 (S2S) SRTP/SIP TLS |
专用连接 |
MPLS 点对点 (P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过Webex抄送来应答,并开始执行与入口点关联的Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现IVR逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量 – 与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环 – 使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据 – JSON、TOML XML通常用于解析API响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
|
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式IVR体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到Webex CC。
下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
下图说明了排队和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理 (LAA)
-
最佳可用代理 (BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置 (PIQ)、估计等待时间 (EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队 (CBT) 进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop运营
当代理登录到 CC Agent Desktop Webex时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop使用 Cisco Common Identity (CI) 对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步API和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
下图说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流Webex该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
下图说明了 Webex CC 中的预配置工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以Agent Desktop和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
下图展示了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理 (CRM) 系统集成的模式。
-
桌面嵌入式连接器
-
通过IVR中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收Webex CC路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击CRM中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供Agent Desktop和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个CRM的CRM客户端SDK,它使用CRM抽象出REST API调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
下图说明了 CRM 嵌入式Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
Microsoft Dynamics 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行Webex并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在CRM市场上有空。
例如
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的XML文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过IVR中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和IVR中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
有关详细信息,请参阅 在 Webex 联系人中心配置语音呼出活动模式。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他API集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
可以使用互联网或 Amazon Web Services (AWS) Direct Connect 建立与 AWS 托管Webex联系人中心的连接。 借助 AWS Direct Connect,数据通过客户内部部署网络与联络中心之间的专用网络连接Webex从而改善了连接。 有关更多详细信息,请参阅 适用于Webex联系人中心的 AWS Direct Connect。
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
下图说明了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过https / TLS(对于非http协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通TCP套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
下图说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在CC报告数据存储Webex并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在CC Webex任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
下图显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
简介
Cisco Webex Contact Center (Webex CC) 是一种联络中心即服务 (CCaaS),使组织能够在整个客户旅程中实现更智能、主动和个性化的交互。
Webex CC 是作为云原生解决方案从头开始架构、设计和开发的,具有以下核心架构原则。
-
服务:独立的服务集,每个服务为其用户提供一小组有凝聚力的功能。
-
事件驱动:所有服务都使用消息传递相互通信,但在 Web 应用程序中除外,其中应用程序在特定用例中使用 https 接口(REST API、通过 WebSocket 接口推送数据)。
-
无状态/外部化状态:服务部署在 Kubernetes 中,在 docker 容器中运行,能够自动扩展并弹性地应对一个或多个服务实例的故障。
-
可观察:所有服务以及支持部署此类服务的基础设施组件都可以使用标准机制进行观察,以测量、检测和防止影响联络中心功能的情况,并在发生中断时快速排除故障和恢复服务。
-
隔离/松散耦合:每项服务都可以独立构建、验证和部署/更新,无需停机即可实现联络中心功能。
Webex CC 服务部署在 AWS 中,并由云原生平台提供支持,该平台可实现以下功能:
-
跨多个可用区的基础架构服务和应用程序的可用性
-
基础架构服务和应用程序的弹性,支持动态扩展功能
-
系统构建和部署方式内置了安全性,传输中的数据和静态数据以及 Webex CC 具有的安全性/合规性认证受到保护。
-
用于电话/语音集成的可扩展且安全的边缘基础架构
-
通过主动监控和警报实现可观测性,使联络中心服务对客户具有高可用性。
-
与其余Cisco Webex集成,用于用户身份验证/授权、管理和提供联络中心功能。
本文档的后续部分将扩展上述每种功能以及 CC 体系结构Webex如何实现这些功能。
逻辑体系结构
联络中心解决方案必须具备的核心功能是使客户能够通过常用的通信方式轻松联系组织,并以快速有效的方式解决查询/问题。
但是,为了确保实现这一基本原则,使用联络中心的组织必须有权访问多种幕后功能。 这些是:
-
客户开始交互的机制
-
将电话呼叫连接到联络中心系统的已发布和运营电话号码
-
客户可以向其发送电子邮件的电子邮件地址以及检测新电子邮件的机制。
-
客户能够通过各种数字渠道联系,包括但不限于
-
从网站/应用程序聊天
-
通过流行的消息客户端(如WhatsApp,Facebook Messenger,Apple Messages for Business)直接聊天。
-
-
-
能够检测新交互并有效处理它们
-
这些将包括自动化IVR系统,用于电话/聊天的虚拟代理,内置可编程性以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须将交互上报给代理,该代理具有处理交互的最佳技能。
-
-
座席能够指示处理交互的可用性,主管能够监控、指导座席并获取可实现高效交互的操作指标。
-
管理员能够配置和预配置各种联络中心功能,使代理和主管能够按预期执行其任务。
除此之外,现代企业还需要增加功能来优化联络中心运营,并访问可视化和跟踪关键运营指标的数据和见解。
此外,能够与专门的联络中心生态系统功能集成,例如运行主动的自动呼出呼叫、使用 AI 增强座席和主管体验、检测和了解客户旅程以主动向座席提前向座席提供数据,这些都是联络中心解决方案发展方式的明显差异化因素。
关于消费模式,其中联络中心产品作为云交付的软件服务使用,确保可用性、可靠性和自动化临时规模要求的能力需要最先进的监控和警报机制,从而能够持续验证和检测即将发生的问题,并防止/最大限度地减少对客户运营的影响。
下图说明了 Webex CC 的逻辑体系结构。
功能部件
以下各节介绍 Webex CC 的各种功能组件。
交互管理
Webex CC 支持电话、电子邮件和消息传递(社交渠道)作为用户与联系人中心交互的各种渠道。
对于所有通道,初始处理可以由系统完成,然后交互可以升级到代理。
媒体类型
电话
对于电话服务,入站语音呼叫处理取决于呼叫进入联系人中心的方式(请参阅下面的入口机制)以及与入口点关联的Webex CC 流。
呼叫得到应答,并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式,或者流本身可以处理呼叫而无需转移到代理。
CC 中的流构建器Webex允许开发人员定义流并将其分配给调用通过 CC 到达Webex入口点。
配置实体 中介绍了这些配置实体及其用法。
有关流生成器的更多信息,将在下一节 中介绍IVR系统。
电子邮件和消息传递
从Webex CC的角度来看,Webex Connect 为所有数字渠道(电子邮件、消息传递渠道)提供入口和出口功能,最终用户可以使用这些功能联系联系人中心。
Webex连接流
-
决定此类交互的处理方式,直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。
-
将业务逻辑应用于传入交互。
-
在排队前处理联系。
-
流本身可以处理交互,而无需转移到实时代理。
Webex CC 支持的消息传递通道包括:
-
Web App / 移动应用聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
-
适用于企业的 Apple Message 消息
Webex CC 支持的电子邮件通道包括:
-
Gmail
-
Office365
入口机制
本节介绍交互可以进入 CC Webex机制。根据媒体类型,交互到达 CC Webex机制也不同。
例如,在电话服务中,需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。
对于电子邮件/消息传递通道,入口配置必须在 Webex Connect 中完成,它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。
入站语音
对于语音呼叫,一种典型的场景是用户拨打 PSTN 电话号码,然后将其连接到联系人中心。 从入口角度来看,这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。
下图说明了语音呼叫引入 Webex CC。
Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制,应答传入呼叫以及执行转接、会议和其他呼叫控制操作。
Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口,入口点的关键配置是与其关联的电话号码,通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。
这样就可以检测电话号码上的传入呼叫,将呼叫关联到入口点,并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。
注意:
有关 PSTN 连接选项的更多详细信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对,并且可以添加更多 SBC 来扩展要支持的并发呼叫量。
VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。
对于地理冗余 – 支持跨区域的多个对互连的 VPOP SBC 网状网络。
对于语音入口服务,它们可以水平扩展,以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。
语音边缘基础架构的安全注意事项
下表提供了有关语音边缘基础结构的连接选项的详细信息。
连接 |
类型 |
---|---|
公共互联网 |
直接(带有列入白名单的源IP地址) IPSec 虚拟专用网络 (VPN) 或基于通用路由封装 (GRE) 的IPSec 站点到站点 (S2S) SRTP/SIP TLS |
专用连接 |
MPLS 点对点 (P2P) 视频接口 SD-WAN 专用 WAN 数据中心交叉连接 Equinix 交换矩阵连接 |
IVR 系统
进入与入口点关联的电话号码的每个语音呼叫都会通过Webex抄送来应答,并开始执行与入口点关联的Webex CC 流。
Webex CC Flow Builder 提供编程构造/运算符和功能块(称为活动),以便管理员或设计和实现IVR逻辑的任何人都可以组合这些构建块并创建 Flow 定义。
Flow 支持的编程结构包括:
-
声明和设置变量 – 与流执行关联的状态
-
用于设置变量值的 Pebble 表达式
-
-
条件检查
-
循环 – 使用条件和转到(能够将活动链接在一起)
-
调用 REST API
-
解析数据 – JSON、TOML XML通常用于解析API响应。
-
撰写活动
Flow 提供的一组具有代表性的活动包括:
-
播放消息
-
收集用户数据
-
将呼叫转接到另一个目标/电话号码
-
将呼叫发送到虚拟代理
-
将呼叫排队,以便代理应答。
对于每个处于活动状态的调用,流执行的实例也会处于活动状态,直到调用结束,从而导致并发执行流。
流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。
在呼叫的整个生命周期中,flow 还支持响应发生的某些事件并处理它们 - 例如,当呼叫由代理应答时,事件处理程序可以在代理桌面界面中触发屏幕弹出。
虚拟代理支持
Flow 提供一项活动,用于将交互移交给虚拟代理,该代理已在 Control Hub 中预先配置Webex。
呼叫连接到虚拟代理后,它将为用户提供对话式IVR体验,并且活动以呼叫终止或将呼叫升级为代理而结束。
在升级的情况下,可以将流程配置为将呼叫排队,然后由代理应答。
入站数字交互
对于传入交互的电子邮件和消息传递通道,Webex CC 利用 Webex Connect 来预配置资产,利用流来处理传入的交互,然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到Webex CC。
下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。
虚拟代理/BOT 集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT 处理是在 Webex Connect 流中配置的。
与语音虚拟代理一样,如果 BOT 处理结果以升级告终,则交互将排队并路由到代理。
路由和排队
Webex CC 使用流中定义的自动处理程序处理传入联系人,流可能决定将联系人排队到队列/直接排队给代理(特定于代理的队列 - 仅支持电话/语音交互)。
在排队时,如果代理有空,代理将被预约,交互将路由到代理。 如果有空没有代理,交互将保留在队列中,Flow 将继续使用附加到队列活动的处理程序来对待客户。
当代理变得有空时,处理程序将被中断,并为代理提供交互。
下图说明了排队和路由体系结构。
代理选择
Webex CC 中的队列支持以下代理选择算法:
-
最长可用代理路由
-
基于技能的路由
-
最长可用代理 (LAA)
-
最佳可用代理 (BAA)
-
代理通过团队与队列关联。
可以按顺序为队列分配多个呼叫通讯组(每个组有一个或多个组),并配置等待将呼叫通讯组添加到队列中,以便随着时间的推移,匹配代理的搜索空间扩展到其他呼叫通讯组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据 LAA 或 BAA 配置选择一个代理。
特定于语音/电话的附加功能
基于代理的路由(仅适用于语音/电话通道)
Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。
如果代理没有有空来处理交互,则可以将交互停放在特定于代理的队列中,等待代理成为有空
高级队列信息
Webex CC Flow 使用活动 GetQueueInfo,可以获取队列的实时信息,例如队列中的位置 (PIQ)、估计等待时间 (EWT)、队列中有空的代理数量,并可用于决定是否将联系人排队。
礼貌回电
Webex CC Flow 使用活动回呼,使客户在保持队列中的位置的同时断开呼叫连接,并在队列中的虚拟交互路由到代理时接收回调。
溢出处理
Webex CC 支持使用基于容量的团队 (CBT) 进行溢出处理。
CBT 类似于具有容量的常规团队,以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。
通常,此周期配置为最后一个周期,以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后,如果没有有空代理,它也会充当溢出。
Agent Desktop运营
当代理登录到 CC Agent Desktop Webex时,代理会指定一个电话号码,代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号(如果代理是 Cisco Webex Calling 用户)。
请注意,此号码必须是可以路由呼叫的有效电话号码。 否则,代理将无法收到传入呼叫。
根据代理正在处理的交互类型,代理桌面上的小组件提供执行特定媒体控制操作的功能。
例如,呼叫被应答后,代理可以执行以下与该呼叫相关的操作。
-
将呼叫置于保持状态
-
发起咨询呼叫和
-
将呼叫转接到另一个电话号码(例如代理电话号码)/入口点
-
会议其他代理进行呼叫
-
-
将呼叫转接到另一个队列
-
结束呼叫
代理桌面允许管理员在其中添加自定义小组件,方法是扩展桌面功能,使其成为代理以高效方式完成工作所需的小组件的统一集合。
桌面体系结构
代理桌面是一个基于微前端的单页应用程序,它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。
这些通常是异步 API,其中调用的响应通过 WebSocket 连接来到桌面。
Webex CC Agent Desktop使用 Cisco Common Identity (CI) 对用户进行身份验证,令牌将传递到所有 API 调用。 对于自定义小组件,基于身份验证模型,如果自定义小组件的身份验证模型与 CI 集成,它将为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。
桌面对连接性和延迟的弹性
异步API和服务器端推送可实现扩展,并检测到与 WebSocket 接口的任何连接丢失,并且桌面尝试重新连接并重新登录。
下图说明了 Webex CC 中的代理桌面体系结构。
管理和配置
引导客户
Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。
在 Control Hub 中预配置组织和联络中心功能后,它将在 CC 中触发工作流Webex该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。
所有联系人中心配置都是使用 BPM 工作流引擎完成的,该引擎支持以声明性方式定义所涉及的步骤,并使整个预配置步骤能够抵御故障并确保数据完整性。
下图说明了 Webex CC 中的预配置工作流。
配置实体
Webex CC 中的关键配置实体(作用域在组织内)包括:
站点
站点是指一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队都必须属于一个站点。
小组
一组用户。 团队用于通过队列向代理分发交互。
每个团队都必须属于一个站点。
座席
可以登录以Agent Desktop和处理在 Webex CC 中配置的媒体类型之间的交互的用户。
主管
主管被分配到团队,可以监控/指导代理,并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。
队列
队列是一个逻辑实体,可以在其中进行交互,同时等待代理有空,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。
入口点
入口点是一个逻辑实体,表示交互进入 CC Webex入口点。对于电话服务,这主要映射到呼叫到达的电话号码,对于电子邮件/消息传递通道,入口点指向 Webex Connect 中的资产配置。
流
与入口点关联的流(通过路由策略),它决定处理交互所涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),在 Webex Connect 中,选择 Flow 作为资产配置的一部分。
多站点联络中心的访问控制
Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外,由于网站和团队的等级性质,一旦提供了对特定网站的访问权限,用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织级别是全局的,因此对于不同的地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块,从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。
报告和分析
Webex CC 使用一系列实时流处理服务处理各种服务在交互生命周期中生成的离散事件,并生成一组定义的实时数据集,这些数据集发布到订阅的客户端。
此外,这些事件被进一步处理、转换和聚合,生成的数据集被持久化,然后通过数据消费 API 以及报告和数据可视化界面 - 分析器进行检索。
下图展示了 Webex CC 中的数据处理和消费接口
集成
与 WxCC 的所有外部集成都是使用标准发布的 API,以增强和增强客户可以使用的功能。
Webex CC 中有空的 API 接口类型为:
-
REST API
-
服务器端推送使用
-
网络钩子
-
WebSocket 消息
-
CRM 集成
Webex CC 支持两种与客户关系管理 (CRM) 系统集成的模式。
-
桌面嵌入式连接器
-
通过IVR中的 HTTPs 连接器进行流集成
桌面嵌入式连接器:CRM应用程序作为主要接口
在这种操作模式下,代理作为主应用程序登录到 CRM 控制台。
Webex CC是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软件电话),主要用于登录联系人中心并接收Webex CC路由的联络中心交互。
收到呼叫或对话请求后,CRM 集成在 CRM 控制台上执行以下操作
-
弹出与 ANI 或其他呼叫相关数据关联的客户记录。
-
将呼叫元数据作为活动注释发布到客户记录中
-
允许座席“点击呼叫”,方法是单击CRM中的联系人并向客户发起出站呼叫
-
将呼叫记录发布到 CRM 报告表中,以便在 CRM 上进行主要报告。
-
提供Agent Desktop和呼叫控制(桌面应用程序的嵌入式和缩小版)的全部功能
与 CRM 集成的主要模式是Webex CC 桌面应用程序嵌入单独的 iFrame 中。
此外,Webex CC 桌面应用程序运行在后台运行的自定义无头小部件(无用户界面),与底层 CRM 系统交互以代表代理执行自动化操作。
交互由无头小部件使用的两个 SDK 提供支持。
-
Webex CC 桌面 JS SDK:这是 Webex CC 提供的 JavaScript SDK,用于注册代理和联系人操作的事件侦听器。
-
CRM JS SDK:这是适用于每个CRM的CRM客户端SDK,它使用CRM抽象出REST API调用。 例如,对于 salesforce,Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。
下图说明了 CRM 嵌入式Webex CC 桌面和连接器体系结构
Webex CC 支持以下用于上述集成的 CRM 解决方案:
-
Salesforce
-
服务现在
-
Microsoft Dynamics 365
-
Zendesk
-
Freshdesk
有关更多详细信息,请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。
有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 连接器的全球可用性
CRM 连接器在运行 CC 的所有地理位置和区域中有空Webex。
弹性规模和性能
Webex CC 托管自定义小组件,该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和Webex CC 桌面之间的双向通信,确保小组件 AWS 跨可用区和区域的高可用性。
所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行Webex并在 CRM 应用程序中嵌入了 CC 桌面。
安全
CRM 连接器通过 Webex CC 代理桌面布局调用,可选参数通过桌面布局传递到小组件中,以打开和关闭功能。
例如,要启用 Salesforce actions Widget,管理员可以开启桌面布局参数,将 sfdcWidgetEnabled 设置为 true。
软件包安装
要使集成双向工作,CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。
所有桌面嵌入式连接器都在CRM市场上有空。
例如
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市场应用程序安装会激活所需的插件并将所需的XML文件导入 CRM 控制台,以支持在 CRM 上报告呼叫记录。
通过IVR中的 HTTPs 连接器进行流集成
Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器Webex CC 和 CRM 系统之间的双向数据流。
这些主要用于语音交互中的个性化和IVR中的自定义路由。
默认情况下,Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器Webex Control Hub 上。
有关 HTTP 连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 连接器:
-
Salesforce IVR HTTP 连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
去话活动管理
Webex CC 使用 Acqueon 的营销活动管理解决方案支持出站预览广告系列。
有关详细信息,请参阅 在 Webex 联系人中心配置语音呼出活动模式。
员工优化
Webex CC 支持来自领先行业供应商的工作流程优化和质量管理解决方案。
扩展Agent Desktop
Webex CC 代理和主管桌面通过在桌面中开发和运行自定义小组件来扩展桌面功能。
有关更多详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他接口
有关可在 Webex CC 中执行的其他API集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC 部署在 AWS 中,目前在以下区域有空
-
US
-
美国东部 N 弗吉尼亚州
-
美国-西北加利福尼亚(仅限语音媒体入口)
-
-
加拿大
-
中央
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
可以使用互联网或 Amazon Web Services(AWS)Direct Connect 建立与 AWS 托管Webex联系人中心的连接。 借助 AWS Direct Connect,数据通过客户内部部署网络与联络中心之间的专用网络连接Webex从而改善了连接。 有关更多详细信息,请参阅 适用于Webex联系人中心的 AWS Direct Connect。
电话的多区域连接
为了实现代理和客户遍布多个地理位置的全球性组织,Webex CC 支持将媒体保留在本地区域内,适用于运行语音媒体边缘和入口服务的区域。
下图说明了使用区域媒体进行的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC 服务(AWS 区域) |
Media Edge(Voice POP) |
下一代媒体服务(AWS 区域)* |
---|---|---|---|
US |
弗吉尼亚州北部 |
纽约 洛杉矶 |
弗吉尼亚州北部 北加州 |
加拿大 |
中央 |
温哥华 多伦多 |
中央 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
浦那 海德拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全和隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止,这是基于允许连接到边缘组件的白名单 IP 启用的。
计算基础架构安全性
Webex CC 计算实例在 AWS 中预置,服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行,并且对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都是使用代码完成的(无需手动步骤),并且无法手动访问任何凭据。
有一个中央凭据存储,其中包含为一组特定的服务/团队配置的特定路径,并且对凭据存储本身的访问受到限制,并在生成和部署系统中配置为机密。
没有任何基础设施组件/服务直接暴露在 AWS VPC 外部,只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器,
除此之外,开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与思科内部身份验证系统集成。
用户界面的身份验证和授权
各种联络中心用户(代理、主管、管理员、分析师)使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证(OAuth 流)的保护。
授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。
数据安全
传输中的数据
所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。
选择服务,使用 http API 通过网关公开这些接口,所有传入的 http(包括 WebSocket 的 http)在 ALB 中终止,并且通过 http 的内部流量路由到服务。
所有传出交互都通过https / TLS(对于非http协议)。
在 VPC 内部,服务之间的内部通信(通过 http/自定义 TCP 协议)通过普通TCP套接字进行。
静态数据
存储的所有数据都在存储层加密。 此外,VPC 外部的数据存储受到保护,并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。
下图说明了传输和静态的数据流和安全模型。
数据隐私
最终用户 PII 数据
Webex CC Flow 是用于处理交互的编程控制器,可用于收集用户数据,这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的,数据传输路径中的任何服务都无法访问此数据。
此外,此类数据永远不会保留在CC报告数据存储Webex并且日志/消息传递基础结构将具有加密数据,并且明文数据不会存储在CC Webex任何地方。
联络中心代理/主管 PII 数据
联系人中心用户相关数据在日志中被编辑,但在Webex CC 数据存储中有空用于数据分析和可视化。
可扩展性
规模因素
对于Webex CC,影响规模的因素包括:
-
并发登录的代理数
-
正在进行的交互的并发数
-
对这些交互执行的操作
-
-
主管/代理在处理交互之外执行的操作并发数
-
生成并保留的数据量
实现规模化的架构方面
Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。
事件驱动架构
Webex CC 中的服务使用消息进行通信,关键消息处理流不涉及任何阻塞 IO 操作,并且处理消息所需的状态已本地化为正在处理消息的服务实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的,这些服务具有外部化的状态存储,并且基础结构也支持动态更改此类服务的实例数,并自动重新平衡/状态传输/将状态本地化为需要状态的实例。
弹性基础架构
在 Kubernetes 中运行的所有服务和基础设施(也称为 Kubernetes 节点)会根据使用情况自动扩展,这样可以动态添加更多计算节点,直至达到预先配置的最大高阈值。
荷载预测和定期验证
所有服务都针对性能特征进行了基准测试,并在服务级别验证了扩展模式。
进行进一步的连续验证、峰值负载和耐久性测试,并根据规模影响属性的预计增长调整测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值并为比赛日做好准备。
可靠性和可用性
事件驱动架构和无状态服务可实现复原能力和弹性。 但是,为了确保在功能受到影响之前检测到故障并进行处理,Webex CC 采用了以下策略。
-
基础架构的可用性和可靠性
-
所有 Webex CC 服务和基础设施组件始终部署在三个 AWS 可用区中。
-
这使 Webex CC 能够灵活应对可用区故障,并且在发生故障时,发生故障的实例将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础结构组件的内部和外部探测,在发生故障时触发警报。
-
从服务和基础结构组件捕获并通过规则引擎处理的指标,该引擎检测匹配规则并触发警报。
-
-
持续验证和警报
-
运行定期测试,任何故障都会导致触发警报
-
这些警报会创建主动事件,并作为影响客户的真实事件进行处理。
-
这样可以预先防止影响客户,并有助于提高系统可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,支持快速可靠地构建、验证和部署 Webex CC 中的服务/服务更改。
-
如果需要部署更改以响应故障,则能够执行完全自动化的部署 - 从代码到生产环境,并进行所有必需的验证,可降低风险并最大限度地减少解决问题的时间。
-
-
-
断路器和终止开关
-
系统的各个部分/Webex CC的某些功能可以有选择地为所有客户或部分客户禁用,以最大程度地减少故障的级联效应。
-
这样可以最大限度地减少故障表面,并为客户提供核心联络中心功能。
-
-
监控和故障检测
下图显示了针对 Webex CC 的持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测到区域内的任何大规模中断,并采取必要的步骤来确保向该区域中的客户恢复服务。
根据灾难恢复和管理流程,将记录、验证和定期更新恢复步骤。
Webex CC 服务部署在一个 AWS 区域内的三个独立可用区中。 每个可用区是区域中不同的物理位置,具有独立的实用程序。
如果 AWS 区域完全发生故障,Webex CC 依靠 AWS 来恢复该区域,对于涉及整个区域的长时间中断,Webex CC 数据中心将预置在新的 AWS 区域中,并还原关键客户配置和数据,以便联络中心可供新 AWS 区域中的客户运行。
这涉及自动化,但需要手动干预以触发流程,以及监控和确保恢复所需的配置和数据,以使联络中心为客户运行。
合规性和认证
Webex Contact 拥有广泛的安全认证列表。 这些认证会定期更新。
-
PCI DSS QSA
-
凯克
-
HIPAA & HITECH
-
CSA 星级 1 级
-
CSA 星级 2(第三方独立评估)
-
SOC2
-
ISO27001(国际信息安全标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(侧重于保护云中个人数据的安全标准)
-
ISO27701(数据隐私扩展程序)
-
C5 德国标准,展示针对网络攻击的操作安全性
介绍
Cisco Webex Contact Center (Webex CC)是一种Contact Center as a Service (CCaaS),可帮助组织在整个客户旅程中实现更智能、更主动和个性化的交互。
Webex CC从头开始,作为云原生解决方案构建、设计和开发,具有以下核心架构原则。
-
服务:独立的一组服务,每个服务为其用户提供一小组有凝聚力的功能。
-
活动驱动:所有服务通过消息传递相互通信,但应用程序在特定用例中使用https接口(REST API、通过WebSocket接口推送数据)的Web应用程序除外。
-
无状态/外部化状态:服务部署在Kubernetes中,在docker容器中运行,具有自动扩展的能力,并能够应对一个或多个服务实例的故障。
-
可观察:可以使用标准机制来衡量、检测和预防影响联络中心功能的情况,以及在发生故障时快速故障排除和恢复服务,从而能够观察到所有服务和支持部署此类服务的基础设施组件。
-
隔离/松散耦合:可以独立构建、验证和部署/更新每一项服务,无需停机时间用于联系中心功能。
Webex CC服务在AWS中部署,由云原生平台提供支持,支持以下功能:
-
跨多个可用区提供基础架构服务和应用程序
-
基础架构服务和应用程序的弹性支持动态扩展功能
-
在构建和部署系统的方式中内置了安全功能,数据在传输中受到保护,并通过Webex CC提供的安全/合规认证。
-
用于电话/语音集成的可扩展且安全的边缘基础设施
-
通过主动监控和提醒的可观察性,为客户提供高可用性联系中心服务。
-
与其他Cisco Webex集成,用于用户验证/授权、管理和配置联系人中心功能。
本文档的后续部分扩展了上述每个功能以及Webex CC架构如何实现相同的功能。
逻辑架构
联系中心解决方案必须具备的核心功能,使客户能够通过常用的沟通方式轻松与组织联系,并快速高效地解决查询/问题。
但是,为了确保这一基本原则得以实现,使用联络中心的组织必须能够访问多个幕后功能。这些是:
-
客户开始互动的机制
-
将电话呼叫连接到呼叫中心系统的已发布和操作电话号码
-
客户可以向其发送电子邮件的电子邮件地址,以及检测新传入电子邮件的机制。
-
使客户能够通过各种数字渠道取得联系,包括但不限于
-
通过网站/应用程序聊天
-
通过WhatsApp、Facebook Messenger、Apple Messages for Business等流行消息客户端直接聊天。
-
-
-
能够检测新交互并有效处理它们
-
其中包括自动化IVR系统、内置可编程的电话/聊天虚拟代理,以定义处理交互所涉及的工作流程。
-
最后,如果需要,必须向代理上报交互,该代理具有最佳技能来处理交互。
-
-
代理可以指示处理交往的可用性,并且主管可以监控、指导代理并获取可实现高效交往的操作指标。
-
管理员能够配置和提供各种联系人中心功能,使代理和主管能够按预期执行任务。
除此之外,现代企业还需要增加功能以优化接触中心运营,访问可视化并跟踪关键运营指标的数据和见解。
此外,能够与专业联系中心生态系统功能集成,例如运行主动的自动出站呼叫、增强使用AI的代理和主管体验、检测和了解客户向代理前主动提供数据的旅程,是联系中心解决方案不断发展的明显区别因素。
在消费模式中,接触中心产品作为云交付软件服务消费时,确保可用性、可靠性和自动化的临时扩展要求需要最先进的监控和警报机制,从而能够持续验证和检测即将出现的问题,并防止/最小化对客户运营的影响。
下图示了Webex CC的逻辑架构。
功能组件
以下章节介绍了Webex CC的各种功能组件。
交互管理
Webex CC支持电话、电子邮件和消息传递(社交渠道),作为用户可以与联系人中心交互的多种渠道。
对于所有通道,系统可以进行初始处理,然后交互可以上报到代理。
媒体类型
电话
对于电话,入站语音呼叫处理取决于呼叫如何进入联系中心(请参阅下面的输入机制)以及与入口点关联的Webex CC Flow。
呼叫得到响应,并根据Webex CC Flow定义执行进一步的操作-这是在处理呼叫时要执行的操作的程序化表示,该操作是在排队和路由到代理之前执行,或者Flow本身可以在不向代理传输的情况下处理该呼叫。
Webex CC中的Flow Builder允许开发人员定义流并将其分配给呼叫通过Webex CC到达的入口点。
配置实体中涵盖了这些配置实体及其使用情况。
有关Flow Builder的更多信息,请参见即将发布的 IVR系统部分。
电子邮件和消息传递
从Webex CC的角度来看,Webex Connect为所有数字渠道(电子邮件、消息传递渠道)提供入站和出站功能,最终用户可以使用这些渠道联系到联系中心。
Webex Connect流程
-
决定此类交互的处理,直到这些交互被排队并路由给代理。这包括针对所有形式的消息和电子邮件交互的自动处理和机器人处理。
-
将业务逻辑应用于传入的交互。
-
排队前先处理联系人。
-
Flow本身可以处理没有传输到实时代理的交互。
Webex CC支持的消息通道包括:
-
网络应用程序/移动应用程序聊天
-
WhatsApp
-
Facebook Messenger
-
短信
-
Apple企业消息
Webex CC支持的电子邮件渠道包括:
-
Gmail
-
Office365
入门机制
本部分介绍了交互可以进入Webex CC的机制。根据媒体类型,交互到达Webex CC的机制是不同的。
例如,在电话中,需要为启用PSTN连接、配置电话号码以及将呼叫路由到Webex CC所需的物理基础设施配置。
对于电子邮件/消息传递渠道,必须在Webex Connect中完成入门配置,它涉及电子邮件/消息传递帐户配置和Webex Connect流程配置。
入站语音
对于语音呼叫,典型场景是用户拨打PSTN电话号码,然后连接到呼叫中心。从入门的角度来看,这需要一个机制来路由呼叫从PSTN到Webex CC。
下图显示了对Webex CC的语音呼叫摄入。
Webex CC中的语音输入服务使用SIP执行第三方呼叫控制,并回答传入呼叫,并执行传输、会议和其他呼叫控制操作。
Webex CC中呼叫的逻辑入口点是名为“入口点”的配置实体。对于语音输入,Entrypoint的关键配置是与其关联的电话号码,通常是从所选的PSTN提供商获得的有效的PSTN电话号码。
这允许检测电话号码上的传入呼叫,将呼叫关联到Entrypoint,并使用入口点的其他配置参数来处理呼叫,以便根据应为交互触发的Webex CC Flow定义。
注:
有关PSTN连接选项的更多信息,请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
语音边缘基础设施的可扩展性和可用性
Webex CC VPOP基础架构包括多余的SIP SBC,确保高可用性,并且可以添加更多SBC以扩展要支持的并发呼叫量。
VPOP可以处理的最大并发呼叫取决于正在运行的SBC的数量以及正在发送的呼叫。
对于地域冗余-支持跨区域多个对互连的VPOP SBC网格。
对于语音输入服务,它们可以横向扩展,以处理需要输入到Webex CC的并发语音呼叫。
语音边缘基础设施的安全注意事项
下表详细介绍了与Voice Edge基础架构的连接选项。
连接性 |
类型 |
---|---|
公共互联网 |
直接(带有白名单的源IP地址) IPSec虚拟专用网络(VPN)或IPSec over Generic Routing Encapsulation (GRE) 站点对站点(S2S) srtp/sip tls |
私有连接 |
MPLS 点对点(P2P) vpls SD-WAN 私人WAN 数据中心交叉连接 Equinix面料连接 |
IVR系统
每次拨入与Entrypoint关联的电话号码的语音呼叫,都会由Webex CC接听,并开始执行与Entrypoint关联的Webex CC流。
Webex CC Flow Builder提供编程构件/操作员和功能块(称为活动),因此管理员或任何设计和实施IVR逻辑的人员都可以将这些构建块组合并创建Flow定义。
Flow支持的编程构造包括:
-
声明和设置变量-与流程执行关联的状态
-
用于设置变量的值的Pebble表达式
-
-
有条件检查
-
循环-使用条件和转至(能够将活动链在一起)
-
调用REST API
-
解析数据–通常用于解析API响应的JSON、TOML、XML。
-
组成活动
Flow供应的一组代表性活动包括:
-
播放消息
-
收集用户数据
-
将呼叫转至其他目的地/电话号码
-
将呼叫发送到虚拟代理
-
排队呼叫以便由代理响应。
对于每个处于活动状态的呼叫,流执行实例也处于活动状态,直到呼叫结束,导致流并发执行。
每个流执行实例为与流相关的数据/状态和呼叫提供隔离环境。
在整个呼叫的整个生命周期中,流还允许响应和处理某些发生的事件——例如,当呼叫由代理响应时,事件处理器可以在代理桌面界面中触发屏幕弹出窗口。
有关Webex CC Flow的更多信息,请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。
虚拟代理支持
Flow提供一项活动,以将交互传递给在Webex Control Hub中预先配置的虚拟代理。
呼叫连接到虚拟代理后,它为用户提供会话IVR体验,活动要么结束呼叫终止,要么将呼叫上报给代理。
如果发生上报,可以配置流程为呼叫,然后由代理接听。
入站数字交互
对于传入交互的电子邮件和消息传递渠道,Webex CC使用Webex Connect配置资产、流处理传入交互,然后在Webex Connect流明确排队交互时,将交互路由到Webex CC,以便由代理处理。
下图说明了Webex CC中的电子邮件和消息交互。
虚拟代理/BOT集成
对于电子邮件和消息传递/社交渠道交互,虚拟代理/BOT处理在Webex Connect流程中配置。
与Virtual Agent for Voice一样,如果BOT处理以升级为结果结束,则交互会排队并路由到代理。
路由和排队
Webex CC处理流程中定义的与自动处理器的入站联系人,流程可能会决定将联系人排队到队列/直接到代理(代理特定队列-仅支持电话/语音交互)。
在排队时,如果代理可用,代理将保留,并且交互将路由到代理。如果没有可用的代理,交互将停在队列上,Flow将继续使用连接到队列活动的处理器来处理客户。
当代理可用时,处理程序被中断,并且向代理提供交互。
下图说明了队列和路由架构。
代理选择
Webex CC中的队列支持以下代理选择算法:
-
最长的可用代理路由器
-
基于熟练的路由技术
-
最长可用代理(LAA)
-
最佳可用代理(BAA)
-
代理通过Teams与队列关联。
队列可以分配多个呼叫分发组(每个组有一个或多个团队),并按顺序配置等待将呼叫分发组添加到队列,以便匹配代理的搜索空间随着时间推移扩展到其他呼叫分发组。
对于基于技能的路由,在与队列关联的技能要求匹配代理中,根据LAA或BAA配置选择代理。
针对语音/电话的其他功能
基于代理的路由方式(仅适用于语音/电话频道)
使用Activity QueueToAgent,Webex CC Flow可以根据代理ID将交互直接路由到所选代理。
如果代理无法处理交互,可以停在代理特定的队列中,等待代理可用
高级队列信息
使用GetQueueInfo活动,Webex CC Flow可以获取队列中的实时信息,如队列中的位置(PIQ)、预估等待时间(EWT)、队列中可用的代理数量,并可用于确定是否为联系人队列。
礼貌回调
使用Activity Callback,Webex CC Flow允许客户断开呼叫连接,同时保持队列中的位置,并在队列中的虚拟交互路由到代理时收到回调。
溢流处理
Webex CC支持使用基于容量的团队(CBT)进行溢出处理。
CBT就像一个拥有容量的常规团队,以及提供该容量的相关外部DN。可以在“队列呼叫分配”循环中与其他团队一起配置。
通常,这被配置为上一个周期,因此即使所有已配置的呼叫分发组找不到用于处理交互的可用匹配代理,如果没有代理可用,它也会作为溢出。
代理桌面操作
当代理登录Webex CC代理桌面时,代理指定可以连接到该代理的传入呼叫的电话号码。如果代理是Cisco Webex呼叫用户,则可以是PSTN电话、移动电话或分机号码。
请注意,此号码必须是可以路由呼叫的有效电话号码。否则,代理无法接收传入的呼叫。
根据代理正在处理的交互类型,代理桌面中的小部件提供了执行某些媒体控制操作的能力。
例如,一旦呼叫得到响应,代理可以执行与呼叫相关的以下操作。
-
暂停呼叫
-
发起咨询呼叫和
-
将呼叫转至其他电话号码(例如代理电话号码)/入口点
-
呼叫中的其他代理会议
-
-
将呼叫转至其他队列
-
结束呼叫
代理桌面允许管理员通过扩展桌面功能并使其成为代理高效完成工作所需的小部件统一集合,从而允许管理员在此添加自定义小部件。
桌面架构
代理桌面是一个基于微前端的单页应用程序,它托管基于Web组件架构构建的小部件。所有标准/库存widget均由API或服务器端推送机制检索的数据提供支持。
这些通常是异步API,其中呼叫的响应通过WebSocket连接到达桌面。
Webex CC Agent Desktop使用Cisco Common Identity (CI)验证用户,并将令牌传递给所有API呼叫。对于自定义小部件,基于身份验证模型,如果自定义小件的身份验证模型与CI集成,则为代理提供单点登录体验。
一旦代理成为交互的一部分,对该交互状态或相关数据的所有更新也将通过WebSocket连接推送到桌面。
桌面对连接和延迟的恢复力
异步API和服务器端推送支持缩放,并检测到WebSocket接口的任何连接损失,桌面尝试重新连接和重新登录。
下图示了Webex CC中的代理桌面架构。
管理和配置
接洽客户
Webex Control Hub是合作伙伴和客户用于启动客户以及启用或配置功能的主要界面。
在Control Hub中配置了组织和联系人中心功能后,它将在Webex CC中触发一个工作流,该工作流将按照客户选择的产品配置所有联系人中心功能中的其余步骤。
所有联系人中心配置都使用BPM工作流引擎完成,该引擎支持声明性方式来定义所涉及的步骤,并使整个配置步骤具有应对故障的弹性,并确保数据完整性。
下图示了Webex CC中的配置工作流。
配置实体
Webex CC中的关键配置实体在组织中范围为:
站点
站点表示一个或多个团队、用户(代理/主管)所在的位置。
每个用户和团队必须属于某个站点。
团队
一组用户。团队用于通过队列向代理分发交互。
每个团队必须属于某个站点。
代理
可以登录到Agent Desktop并处理Webex CC中配置的跨媒体类型的交互的用户。
主管
主管被分配到团队,并且可以监控/指导代理人,并有权访问属于主管被分配的团队的人员的团队级别状态和代理统计数据。
队列
队列是一个逻辑实体,可以在等待代理可用时保持交互,然后路由到代理。
队列映射到团队,作为代理的搜索空间,能够根据已过的时间阈值通过向搜索空间添加其他团队来扩展搜索空间。
入口点
Entrypoint是一个逻辑实体,代表交互进入Webex CC的入口点。对于电话,这主要映射到呼叫到达的电话号码以及电子邮件/消息传递渠道,Entrypoint指向Webex Connect中的资产配置。
流程
与入口点相关的流程(通过路由策略),该流程决定处理交互中涉及的步骤。
对于非电话渠道(电子邮件、消息传递/社交),将选择Flow作为Webex Connect中的“资产”配置的一部分。
多站点联系中心的访问控制
Webex CC管理员可以配置具有访问特定站点、团队、队列和入口点的用户配置文件。此外,由于站点和团队的分层性质,一旦提供对特定站点的访问权限,用户只能访问属于这些站点或此类团队中明确指定的子集的团队或与团队相关的日期。
对于队列和入口点,它们在组织层面上是全局性的,因此对于不同地理位置(特定代理和团队所在的站点),可以配置单独的入口点和队列,并且主管/用户可以访问适用于特定站点的实体。
下图说明了引用这些实体的关键配置实体和用户配置文件。
除了限制对这些实体的访问之外,Webex CC管理员还可以控制用户在管理界面中可以访问的特定功能/模块,从而允许用户对特定实体的管理/配置权限以及Webex CC管理界面中的部分/功能。
报告与分析
Webex CC使用一系列实时流处理服务,处理在交互生命周期中由各种服务产生的离散事件,并生成一组定义的实时数据集,这些数据集发布给订阅客户。
此外,这些事件将进一步处理、转换和汇总,并持续生成的数据集,然后通过数据消耗API和报告和数据可视化接口– Analyzer检索这些数据。
下图示了Webex CC中的数据处理和消费接口
集成
所有与WxCC的外部集成,以增强和增强客户可以使用的功能,都使用标准发布的API。
Webex CC中可用的API接口类型如下:
-
REST API
-
使用服务器端推送
-
Webhook
-
WebSocket消息
-
CRM集成
Webex CC支持与客户关系管理(CRM)系统的两种集成模式。
-
桌面嵌入式连接器
-
通过IVR中的HTTP(S)连接器流集成
桌面嵌入式连接器:CRM应用程序作为主要界面
在此操作模式下,代理以主要应用程序身份登录CRM控制台。
Webex CC是一种嵌入式应用程序(也称为嵌入式桌面应用程序或嵌入式软电话),主要用于登录联系人中心并接收Webex CC路由的联系人中心交互。
在收到呼叫或对话请求后,CRM集成在CRM控制台上执行以下操作
-
屏幕弹出与ANI或其他呼叫相关数据的客户记录。
-
呼叫后元数据作为客户记录上的活动注释
-
允许代理单击CRM中的“联系人”并向客户发起出站呼叫,“单击以呼叫”
-
将呼叫记录发布到CRM报告表中,以便在CRM上进行主要报告。
-
提供Agent桌面和呼叫控制的完整功能(桌面应用程序的嵌入式和迷你版)
与CRM集成的主要模式是将Webex CC桌面应用程序嵌入单独的iFrame中。
此外,Webex CC Desktop应用程序在后台运行一个自定义无头小部件(无用户界面),与底层CRM系统交互,以代表代理执行自动操作。
交互由无头小部件使用的两个SDK提供支持。
-
Webex CC Desktop JS SDK:这是Webex CC提供的JavaScript SDK,用于为代理和联系人操作注册事件侦听器。
-
crm js SDK:这是适用于CRM的CRM客户端SDK,它将REST API呼叫与CRM进行抽象。例如,对于salesforce,Salesforce提供的CTI JS库用于在CRM中执行操作和监听活动。
下图说明了嵌入式Webex CC桌面和连接器架构
Webex CC支持上述整合的以下CRM解决方案:
有关配置Webex CC桌面布局以启用CRM连接器、功能集和changelogs的更多信息,请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM连接器的全球可用性
CRM连接器可在运行Webex CC的所有地理区域和地区提供。
弹性尺度和性能
Webex CC托管自定义小部件,可在AWS CloudFront CDN中的CRM应用程序和Webex CC桌面之间实现双向通信,确保跨可用区域和区域的AWS小部件的高可用性。
所有CRM集成特定计算都发生在浏览器上,其中代理使用CRM应用程序与Webex CC桌面嵌入在CRM应用程序中。
安全性
CRM连接器通过Webex CC代理桌面布局调用,可选参数通过桌面布局传递到小部件中,以便打开和关闭功能。
例如,要启用Salesforce操作小部件,管理员可以打开桌面布局参数设置sfdcWidgetEnabled为true。
软件包安装
要实现双向的集成,CRM控制台需要安装嵌入式应用程序。这是为了支持在iFrame中加载桌面应用程序。
所有Desktop Embedded连接器都在CRM市场上可用。
例如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
Marketplace应用程序安装会激活所需的插件,并将所需的XML文件导入到CRM控制台中,以支持在CRM上报告呼叫记录。
通过IVR中的HTTP(S)连接器流集成
Webex CC Flow构建器支持Webex CC和CRM系统之间的双向数据流,使用HTTP(S)连接器在Webex Control Hub中配置,并在Webex CC Flow上使用。
这些主要用于IVR中的语音交互和自定义路由中的自定义。
默认情况下,Webex CC支持Control Hub上的Salesforce HTTP Connector。其他CRM连接器可以在Webex Control Hub上添加为自定义连接器。
有关HTTP连接器的更多信息,请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP连接器:
-
Salesforce IVR HTTP连接器(内置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP连接器(自定义): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
出站活动管理
Webex CC使用Acqueon的竞选管理解决方案支持出站预览活动。
有关详细信息,请参阅在Webex Contact Center中配置语音出站活动模式。
工作团队优化
Webex CC支持来自领先行业供应商的工作流优化及质量管理解决方案。
扩展代理桌面
Webex CC代理和主管桌面通过开发和运行桌面中的自定义组件来扩展桌面功能。
有关详细信息,请访问 https://developer.webex-cx.com/documentation/guides/desktop。
其他API
有关可以在Webex CC中执行的其他API集成的详细信息,请访问 https://developer.webex-cx.com/documentation/getting-started/。
部署和连接
Webex CC已部署在AWS中,目前在以下区域可用
-
US
-
美国东弗吉尼亚州
-
美国西加利福尼亚州(仅限语音媒体入口)
-
-
加拿大
-
中部
-
-
英国
-
伦敦
-
-
欧洲
-
法兰克福
-
-
亚太地区
-
东京
-
悉尼
- 新加坡
-
可以使用Internet或Amazon Web Services (AWS) Direct Connect建立与AWS托管的Webex Contact Center的连接。借助AWS Direct Connect,数据通过客户内部网络和Webex Contact Center之间的专用网络连接交付,从而改善了连接。有关详细信息,请参阅 AWS Direct Connect for Webex Contact Center。
电话的多区域连接
为了使全球组织能够在多个地理位置拥有代理和客户,Webex CC支持将媒体保留在本地区域内,适用于正在运行语音媒体边缘和入门服务的区域。
下图显示了区域媒体的多区域部署。
媒体边缘和入口服务部署在以下区域。
地理区域 |
Webex CC服务(AWS区域) |
媒体边缘(语音POP) |
下一代媒体服务(AWS区域)* |
---|---|---|---|
US |
弗吉尼亚N |
纽约 洛杉矶 |
弗吉尼亚N N加利福尼亚州 |
加拿大 |
中部 |
温哥华 多伦多 |
中部 |
巴西 |
圣保罗 里约热内卢 |
||
欧洲 |
法兰克福 |
法兰克福 阿姆斯特丹 |
法兰克福 |
英国 |
伦敦 |
伦敦 |
伦敦 |
印度 |
普纳 海得拉巴 |
孟买 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
东京 |
东京 大阪 |
东京 |
澳大利亚 |
悉尼 |
墨尔本 悉尼 |
悉尼 |
安全与隐私
基础设施安全
边缘的语音基础架构
语音边缘组件允许来自客户网络/PSTN运营商的SIP trunks终止,并且根据允许连接到边缘组件的白名单Ips启用了此功能。
计算基础设施安全
Webex CC计算实例在AWS中配置,服务在Kubernetes集群中作为pods运行,该集群具有多个命名空间,对每个命名空间的访问受到单独的凭证限制。
所有基础架构配置都使用代码完成,无需手动步骤,并且无法手动访问任何凭证。
有一个中央证书商店,为特定服务/团队配置了特定路径,对证书商店本身的访问受到限制,并配置为构建和部署系统中的秘密。
没有基础架构组件/服务直接暴露在AWS VPC之外,只有公开暴露的接口是使用API网关进行控制和管理的API和WebSocket服务器。
除此之外,开发人员使用的某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果,这些系统和接口使用角色和组进行保护,并与Cisco内部验证系统集成。
用户接口的验证和授权
各种联系人中心用户(代理、主管、管理员、分析师)使用的所有用户界面均受基于Cisco Common Identity的持有人令牌验证(OAuth流)保护。
授权使用获取令牌的用户角色和分配给令牌的范围来完成。
数据安全
正在传输的数据
部署的服务/基础设施组件的任何接口均未直接暴露于外部传入流量。
选择服务,使用http API通过网关暴露这些接口,所有传入的https(包括WebSocket的)在ALB中终止,通过http的内部流量将路由到服务。
所有外接交互都通过https/TLS(对于非http协议)。
在VPC内部,服务之间的内部通信(通过http/自定义TCP协议)通过普通的TCP套接字进行。
静态数据
存储的所有数据均在存储层加密。此外,这些不在VPC之外的数据存储受到保护,具有凭证的访问控制和授权安全地存储和管理在秘密存储中。
下图说明了传输以及静止的数据流和安全模型。
数据隐私权
最终用户PII数据
Webex CC Flow是用于处理交互的编程控制器,可用于收集用户数据,可将其分配给流程变量,专门标记为“包含敏感数据”。此类数据的值已加密,数据传输路径中没有任何服务可访问此数据。
此外,此类数据永远不会持续在Webex CC报告数据存储中,日志/消息传递基础设施将具有加密数据,清晰文本数据不会存储在Webex CC中的任何位置。
联系中心代理/主管个人身份信息(PII)数据
与联系人中心用户相关的数据在日志中编辑,但可用于Webex CC数据存储中的数据分析和可视化。
可扩展性
比例因子
对于Webex CC,影响比例的因素包括:
-
同时登录的代理人数量
-
正在进行的并行交互次数
-
针对这些交往执行的操作
-
-
在处理交往之外的主管/代理执行的并行操作数
-
生成和持续的数据量
实现规模化的建筑方面
Webex CC构建和设计的原则使解决方案能够在为各种服务和平台组件配置的基础设施强制执行的范围内根据需要动态扩展。
活动驱动架构
Webex CC中的服务使用消息和关键消息处理流进行通信,不涉及任何阻断IO操作,处理消息所需的状态将本地化到正在处理消息的服务的实例。
无状态服务(或外部化状态)
无状态服务通过轻松添加/删除服务的其他实例实现弹性。有些服务本质上是有状态的,有些服务具有外部化状态存储,并且基础设施也支持通过自动重新平衡/状态转移/本地化状态到需要状态的实例数量动态变化。
弹性基础设施
所有在Kubernetes和基础架构中运行的服务,即Kubernetes节点的自动根据使用情况进行扩展,这可以动态地添加更多计算机节点,达到预配置的最高阈值。
负载投影和定期验证
所有服务均针对性能特征进行基准测试,并且扩展模式已在服务级别得到验证。
进行进一步的持续验证、峰值负载和耐力测试,并根据规模影响属性的预测增长调整了测试参数,从而能够识别瓶颈,计划更新基础设施资源使用的高阈值,并为比赛日做好准备。
可靠性和可用性
活动驱动的架构和无状态服务可实现弹性和弹性。但是,为了确保在功能受到影响之前检测到故障并采取行动,Webex CC采用以下策略。
-
基础架构可用性和可靠性
-
所有Webex CC服务和基础架构组件始终在三个AWS可用区域中部署。
-
这使Webex CC能够应对可用区故障,如果出现故障,将自动替换为较新的实例。
-
-
-
持续监控和警报
-
服务和基础设施组件的内部和外部探头,在故障时触发警报。
-
从服务和基础设施组件捕获并通过规则引擎处理指标,检测匹配规则并触发警报。
-
-
持续验证和警报
-
正在运行定期测试,任何故障都会导致触发警报
-
这些警报会产生主动事件,并作为影响客户的真实事件处理。
-
这会预先影响客户,并有助于提高系统的可用性和可靠性。
-
-
-
持续集成和交付
-
这是工程流程和交付管道,可在Webex CC中快速可靠地构建、验证和部署服务/更改服务。
-
完全自动化部署(从代码到生产环境,以及所有必需的验证)的能力,可以降低风险,并最大限度地减少解决问题的时间,如果需要部署更改以应对失败。
-
-
-
断路器和终止开关
-
对于所有客户或特定客户,可选择性地禁用系统/Webex CC的某些功能,以最大限度减少故障的层叠效应。
-
这样可以最大限度地减少故障表面并实现核心联系中心功能提供给客户。
-
-
监控和故障检测
下图为Webex CC提供了持续监控、验证和警报机制。
业务连续性和灾难恢复
灾难恢复和业务连续性流程可确保检测区域内任何大规模停机情况,并实施必要的步骤,以确保恢复向该区域已加入的客户提供的服务。
根据灾难恢复和管理流程,对恢复的步骤进行记录、验证并定期更新。
Webex CC服务部署在AWS区域内的三个独立可用区中。每个可用区域是该区域的不同物理位置,具有独立的实用程序。
如果AWS区域完全失败,Webex CC会依靠AWS恢复该区域,如果发生涉及整个区域的长时间停机,则Webex CC数据中心将在新的AWS区域中配置,并恢复关键客户配置和数据,以便新的AWS区域中的客户能够使用联系人中心。
这涉及自动化,但需要手动干预来触发该流程,以及监控并确保恢复所需的配置和数据,以使联系中心为客户正常运行。
合规性和认证
Webex Contact拥有大量安全认证列表。这些证书定期更新。
-
pci dss qsa
-
凯克
-
HIPAA & HITECH
-
CSA星级1级
-
CSA星级2级(第三方独立评估)
-
SOC2
-
ISO27001(信息安全国际标准)
-
ISO27017(云服务提供商的安全标准)
-
ISO27018(专注于保护云中的个人数据的安全标准)
-
ISO27701(数据隐私扩展)
-
C5德国标准,展示针对网络攻击的操作安全性
有关更多详细信息,请参阅 Webex Contact Center Service隐私数据表 。