텔레포니

텔레포니의 경우, 착신 음성 통화 처리는 통화가 고객지원센터에 어떻게 들어왔는지(아래의 수신 메커니즘 참조) 및 진입점과 연결된 Webex CC 흐름에 따라 결정됩니다.

통화에 응답하고 추가 작업을 Webex CC 흐름 정의에 따라 수행합니다. 이 정의는 대기열에 넣고 상담원에게 라우팅하기 전에 통화를 처리하는 동안 수행할 작업을 프로그래밍 방식으로 표현한 것입니다. 또는 흐름 자체가 상담원에게 호전환하지 않고 통화를 처리할 수 있습니다.

Webex CC의 흐름 작성기를 사용하면 개발자가 흐름을 정의하고 통화가 Webex CC에 도착하는 진입점에 할당할 수 있습니다.

이러한 구성 엔티티 및 해당 사용법은 구성 엔티티 에서다룹니다.

Flow Builder에 대한 자세한 내용은 IVR System 에 대한 다음 섹션에서 다룹니다.

이메일 및 메시징

CC Webex 관점에서 Webex Connect는 최종 사용자가 컨택 센터에 접속하는 데 사용할 수 있는 모든 디지털 채널(전자 메일, 메시징 채널)에 대한 수신 및 송신 기능을 제공합니다.

Webex Connect 흐름

• 상호 작용이 대기열에 저장되고 상담원에게 라우팅될 때까지 이러한 상호 작용의 처리를 결정합니다. 여기에는 모든 형태의 메시징 및 이메일 상호 작용에 대한 자동 처리 및 BOT 처리가 포함됩니다.

• 들어오는 상호 작용에 비즈니스 논리를 적용합니다.

• 대기 전에 연결을 처리합니다.

• 흐름 자체는 실제 에이전트로 전송하지 않고 상호 작용을 처리할 수 있습니다.

Webex CC에서 지원하는 메시징 채널은 다음과 같습니다.

• Web App / 모바일 앱 채팅

• WhatsApp

• Facebook Messenger

• SMS

Webex CC에서 지원하는 전자 메일 채널은 다음과 같습니다.

• Gmail

• 오피스365

수신 메커니즘

이 섹션에서는 상호 작용이 Webex CC에 들어갈 수 있는 메커니즘을 설명합니다. 미디어 유형에 따라 상호 작용이 Webex CC에 도달하는 메커니즘이 다릅니다.

예를 들어 텔레포니에는 PSTN 연결, 전화 번호 구성 및 통화를 Webex CC로 라우팅하는 데 필요한 물리적 인프라 프로비저닝이 있습니다.

이메일/메시징 채널의 경우 수신 구성은 Webex Connect에서 수행되어야 하며 여기에는 이메일/메시징 계정 프로비저닝 및 Webex Connect 흐름 구성이 포함됩니다.

착신 음성

음성 통화의 경우 일반적인 시나리오는 사용자가 PSTN 전화 번호로 전화를 건 다음 고객지원센터에 연결되는 것입니다. 수신 관점에서 PSTN에서 Webex CC로 통화를 라우팅하는 메커니즘이 필요합니다.

그림 1 에서는 Webex CC에 대한 음성 통화 수집을 보여 줍니다.

Webex CC의 음성 수신 서비스는 SIP를 사용하여 타사 통화 제어를 수행하고 수신 통화에 응답할 뿐만 아니라 호전환, 전화회의 및 기타 통화 제어 작업을 수행합니다.

Webex CC에서 통화의 논리적 진입점은 'Entrypoint'라는 구성 엔티티입니다. 음성 수신의 경우 Entrypoint의 주요 구성은 연결된 전화 번호이며, 일반적으로 선택한 PSTN 공급자로부터 얻은 유효한 PSTN 전화 번호입니다.

이렇게 하면 전화 번호에서 수신 통화를 감지하고, 통화를 진입점에 연결하고, 진입점의 다른 구성 매개 변수를 사용하여 상호 작용에 대해 트리거되어야 하는 Webex CC 흐름 정의에 따라 통화를 처리할 수 있습니다.

참고:

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로 수집되는 증가하는 동시 음성 통화를 처리할 수 있도록 수평으로 확장 가능합니다.

음성 에지 인프라에 대한 보안 고려 사항

아래 표에는 음성 에지 인프라에 대한 연결 옵션에 대한 세부 정보가 있습니다.

자세한 내용은 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 를 참조하십시오.

IVR 시스템

진입점과 연결된 전화 번호로 수신되는 모든 음성 통화는 Webex CC에서 응답하고 진입점과 연결된 Webex CC 흐름 실행이 시작됩니다.

Webex CC Flow Builder는 관리자 또는 IVR 로직을 설계하고 구현하는 모든 사람이 이러한 빌딩 블록을 결합하여 Flow 정의를 만들 수 있도록 활동이라는 프로그래밍 구문/연산자 및 기능 블록을 제공합니다.

Flow가 지원하는 프로그래밍 구문은 다음과 같습니다.

• 선언 및 설정 변수 – 흐름 실행과 관련된 상태

  • 변수의 값을 설정하는 Pebble 표현식

• 조건부 검사

• 루핑 – 조건문 및 Go To 사용(활동을 함께 연결하는 기능)

• REST API 호출

• 데이터 구문 분석 – JSON, TOML XML 일반적으로 API 응답을 구문 분석하는 데 사용됩니다.

• 작곡 활동

Flow가 제공하는 대표적인 활동은 다음과 같습니다. 메시지 재생 사용자 데이터 수집 다른 대상/전화 번호로 통화 호전환 가상 상담사에게 통화 보내기 상담원이 응답할 수 있도록 통화를 대기열에 넣습니다.

활성 상태인 모든 통화에 대해 흐름 실행 인스턴스도 통화가 종료될 때까지 활성 상태이므로 흐름이 동시에 실행됩니다.

흐름 실행의 각 인스턴스는 호출에 의해 흐름과 관련된 데이터/상태에 대해 격리된 환경을 제공합니다.

또한 통화의 전체 주기 동안 Flow는 발생하는 특정 이벤트에 응답하고 이벤트를 처리할 수 있도록 합니다. 예를 들어 상담원이 통화에 응답하면 이벤트 처리기가 Agent Desktop 인터페이스에서 화면 팝업을 트리거할 수 있습니다.

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는 Control Hub에 사전 구성된 가상 상담사에게 상호 작용을 전환하기 위한 활동을 제공합니다Webex.

통화가 가상 에이전트에 연결되면 사용자에게 대화 IVR 환경을 제공하고 활동은 통화 종료 또는 에이전트로의 통화 에스컬레이션으로 끝납니다.

에스컬레이션의 경우 통화를 대기열에 넣은 다음 상담원이 응답하도록 흐름을 구성할 수 있습니다.

인바운드 디지털 상호 작용

수신 상호 작용의 전자 메일 및 메시징 채널의 경우, Webex CC는 Webex Connect를 활용하여 자산, 플로우를 프로비저닝하고 수신 상호 작용을 처리한 다음 Webex Connect 흐름이 상호 작용을 명시적으로 대기열에 넣으면 상호 작용을 Webex CC로 라우팅하여 상담원이 처리할 수 있도록 합니다.

그림 2 는 Webex CC에서 이메일, 메시징 상호 작용의 수집을 보여줍니다.

가상 에이전트 / BOT 통합

이메일 및 메시징/소셜 채널 상호 작용의 경우 가상 상담원/BOT 처리는 Webex Connect 흐름에서 구성됩니다.

Virtual Agents for Voice에서처럼, BOT 처리가 결과적으로 에스컬레이션으로 끝나면 상호 작용이 대기열에 추가되고 에이전트에게 라우팅됩니다.

에이전트 선택

Webex CC의 대기열은 다음 상담사 선택 알고리즘을 지원합니다.

• 가장 오랫동안 사용할 수 있는 상담원 라우팅

• 기술 기반 라우팅

  • 가장 오랫동안 사용 가능한 상담사(LAA)

  • BAA(Best Available Agent)

상담사는 팀을 통해 대기열에 연결됩니다.

대기열에 통화 분산 그룹이 추가될 때까지 대기가 구성된 순차적 방식으로 대기열에 여러 통화 배포 그룹(각 그룹에는 하나 이상의 팀이 있음)을 할당하여 시간이 진행됨에 따라 일치하는 상담원에 대한 검색 공간이 추가 통화 배포 그룹으로 확장되도록 할 수 있습니다.

직무 기반 라우팅의 경우 대기열과 연결된 직무 요구 사항 일치 상담원 중에서 LAA 또는 BAA 구성을 기반으로 상담원이 선택됩니다.

음성/텔레포니 관련 추가 기능

에이전트 기반 라우팅(음성/텔레포니 채널에만 해당)

활동 QueueToAgent를 사용하는 CC Flow Webex 상담사 ID를 기반으로 선택한 상담사에게 직접 상호 작용을 라우팅할 수 있습니다.

상담원이 상호 작용을 처리할 수 없는 경우 상담원별 대기열에 상호 작용을 지정보류하고 상담원이 사용 가능해질 때까지 기다릴 수 있습니다

고급 대기열 정보

CC Flow Webex GetQueueInfo 활동을 사용하여 PIQ(대기열 위치), EWT(예상 대기 시간), 대기열에서 사용할 수 있는 상담원 수와 같은 대기열에 대한 실시간 정보를 가져올 수 있으며 연결을 대기열에 넣을지 여부를 결정하는 데 사용할 수 있습니다.

무료 콜백

활동 콜백Webex 사용하는 CC Flow를 통해 고객이 대기열에서 위치를 유지하면서 통화를 끊을 수 있으며, 대기열의 가상 상호 작용이 상담원에게 라우팅될 때 콜백을 받을 수 있습니다.

오버플로 처리

Webex CC는 CBT(용량 기반 팀)를 사용한 오버플로 처리를 지원합니다.

CBT는 용량 및 해당 용량을 지원하는 연결된 외부 DN이 있는 일반 팀과 같습니다. 대기열 통화 분배 주기에서 다른 팀과 함께 구성할 수 있습니다.

일반적으로 구성된 모든 통화 분산 그룹이 상호 작용을 처리하는 데 사용할 수 있는 일치하는 에이전트를 찾지 못한 후에도 사용 가능한 상담원이 없는 경우 오버플로로 작동하도록 마지막 주기로 구성됩니다.

Agent Desktop 작업

상담원이 Webex CC Agent Desktop에 로그인할 때 상담원은 상담원에게 걸려오는 전화를 연결할 수 있는 전화 번호를 지정합니다. 상담원이 Cisco Webex Calling 사용자인 경우 PSTN 전화나 휴대폰 또는 내선 번호가 될 수 있습니다.

이 번호는 통화를 라우팅할 수 있는 유효한 전화 번호여야 합니다. 그렇지 않은 경우 상담원은 수신 통화를 받을 수 없습니다.

상담원이 처리하는 상호 작용 유형에 따라 상담원 데스크톱의 위젯은 특정 미디어 제어 작업을 수행할 수 있는 기능을 제공합니다.

예를 들어, 전화에 응답하면 상담원은 통화와 관련된 다음 작업을 수행할 수 있습니다.

• 통화를 보류로 전환

• 상담 통화를 시작하고

  • 다른 전화 번호(예: 상담원 전화 번호)/진입 지점으로 통화 호전환

  • 다른 상담원과 통화하기

• 통화를 다른 대기열로 호전환

• 통화 종료

Agent Desktop을 통해 관리자는 데스크톱 기능을 확장하고 상담원이 효율적인 방식으로 작업을 수행하는 데 필요한 위젯의 통합 모음으로 만들어 사용자 정의 위젯을 추가할 수 있습니다.

데스크탑 아키텍처

Agent Desktop은 웹 구성 요소 아키텍처에 기반을 두고 작성된 위젯을 호스팅하는 마이크로 프론트엔드 기반의 단일 페이지 애플리케이션입니다. 모든 표준/재고 위젯은 API 또는 서버 측 푸시 메커니즘에서 검색한 데이터로 구동됩니다.

이는 일반적으로 호출에 대한 응답이 WebSocket 연결을 통해 데스크톱에 오는 비동기 API입니다.

Webex CC는 Agent Desktop Cisco CI(Common Identity)로 사용자를 인증하고 토큰은 모든 API 호출에 전달됩니다. 사용자 정의 위젯의 경우에도 인증 모델을 기반으로 하며, 사용자 정의 위젯의 인증 모델이 CI와 통합된 경우 상담사에게 SSO(Single Sign-On) 환경을 제공합니다.

에이전트가 상호 작용의 일부가 되면 해당 상호 작용 상태 또는 관련 데이터에 대한 모든 업데이트도 WebSocket 연결을 통해 데스크톱으로 푸시됩니다.

연결 및 대기 시간에 대한 데스크톱의 복원력

비동기 API 및 서버 측 푸시를 사용하면 확장이 가능하며 WebSocket 인터페이스에 대한 연결 손실이 감지되고 데스크톱이 다시 연결하고 다시 로그인하려고 시도합니다.

그림 2 는 Webex CC의 에이전트 데스크톱 아키텍처를 보여줍니다.

고객 온보딩

Webex Control Hub는 파트너와 고객이 고객을 온보딩하고 기능을 활성화하거나 구성하기 위해 사용하는 기본 인터페이스입니다.

Control Hub에서 조직 및 고객지원센터 기능이 구축되면 고객이 선택한 제품에 따라 모든 고객지원센터 기능을 프로비저닝하는 나머지 단계를 수행하는 Webex CC에서 워크플로우가 트리거됩니다.

모든 컨택 센터 프로비저닝은 관련된 단계를 선언적으로 정의할 수 있는 BPM 워크플로우 엔진을 사용하여 수행되며, 전체 프로비저닝 단계를 장애에 탄력적으로 적용하고 데이터 무결성을 보장합니다.

그림 1 은 Webex CC의 프로비저닝 워크플로를 보여줍니다.

구성 엔티티

조직 내에서 범위가 지정되는 Webex CC의 주요 구성 엔터티는 다음과 같습니다.

사이트

사이트는 하나 이상의 팀, 사용자(상담원/감독자)가 위치한 위치를 의미합니다.

모든 사용자와 팀은 사이트에 속해야 합니다.

팀

사용자 그룹입니다. 팀은 대기열을 통해 상담사에게 상호 작용을 배포하는 데 사용됩니다.

모든 팀이 사이트에 속해야 합니다.

상담원

Agent Desktop에 로그인하고 Webex CC에 구성된 미디어 유형의 상호 작용을 처리할 수 있는 사용자입니다.

관리자

슈퍼바이저는 팀에 할당되어 상담원을 모니터링/코치할 수 있고 슈퍼바이저가 할당된 팀에 속한 팀의 팀 수준 상태 및 상담원 통계에 액세스할 수 있습니다.

서비스 대기열

대기열은 상담사가 사용 가능해질 때까지 대기하는 동안 상호 작용이 보류될 수 있는 논리적 엔티티로, 상담사에게 라우팅됩니다.

대기열은 상담원의 검색 공간인 팀에 매핑됩니다. 경과 시간 임계값을 기반으로 검색 공간에 다른 팀을 추가하여 검색 공간을 확장할 수 있습니다.

진입점

진입점은 상호 작용이 Webex CC로 들어오는 수신 지점을 나타내는 논리적 엔터티입니다. 텔레포니의 경우 주로 통화가 도착하는 전화 번호에 매핑되고 이메일/메시징 채널의 경우 진입점은 Webex Connect의 자산 구성을 가리킵니다.

흐름

진입점과 연결된 흐름(라우팅 전략을 통해)으로, 상호 작용 처리와 관련된 단계를 결정합니다.

비텔레포니 채널(이메일, 메시징/소셜)의 경우 흐름은 Webex Connect의 자산 구성의 일부로 선택됩니다.

다중 사이트 고객지원센터에 대한 액세스 제어

Webex CC 관리자는 특정 사이트, 팀, 대기열 및 진입점에 대한 액세스 권한이 있는 사용자 프로필을 구성할 수 있습니다. 또한 사이트 및 팀의 계층적 특성으로 인해 특정 사이트에 대한 액세스가 제공되면 사용자는 해당 사이트 또는 이러한 팀의 명시적으로 지정된 하위 집합에 속하는 팀 또는 날짜만 액세스할 수 있습니다.

대기열 및 진입점의 경우 조직 수준에서 전역이므로 다양한 지리적 위치(특정 상담원 및 팀이 있는 사이트)에 대해 별도의 진입점 및 대기열을 구성할 수 있으며 슈퍼바이저/사용자가 특정 사이트에 대해 적용 가능한 엔티티에 액세스할 수 있습니다.

그림 2 에서는 주요 구성 엔티티와 이러한 엔티티를 참조하는 사용자 프로필을 보여 줍니다.

이러한 엔티티에 대한 액세스를 제한하는 것 외에도, Webex CC 관리자는 사용자가 관리 인터페이스에서 액세스할 수 있는 특정 기능/모듈을 제어할 수 있으므로 Webex CC 관리 인터페이스의 섹션/기능뿐만 아니라 특정 엔티티에 대한 관리/구성 권한을 가진 사용자를 보유할 수 있습니다.

데스크탑 내장 커넥터: CRM 애플리케이션을 기본 인터페이스로 사용

이 작업 모드에서는 상담원이 CRM 콘솔에 기본 애플리케이션으로 로그인합니다.

Webex CC는 컨택 센터에 로그인하고 CC가 라우팅한 컨택 센터 상호 작용을 Webex수신하는 데 주로 사용되는 임베디드 애플리케이션(임베디드 데스크톱 애플리케이션 또는 임베디드 소프트폰이라고도 함)입니다.

통화 또는 대화 요청을 받으면 CRM 통합은 CRM 콘솔에서 다음 작업을 수행합니다

• ANI 또는 기타 통화 관련 데이터에 연결된 고객 레코드를 화면에 표시합니다.

• 통화 메타데이터를 고객 레코드에 활동 노트로 게시

• 상담원이 CRM 내의 연락처를 클릭하고 고객에게 아웃바운드 통화를 시작하여 "클릭하여 전화 걸기"를 허용할 수 있습니다

• CRM의 기본 보고를 위해 CRM 보고 테이블에 통화 레코드 게시

• Agent Desktop 및 통화 제어(데스크톱 앱의 포함 및 축소된 버전)의 전체 기능을 제공합니다.

CRM과의 기본 통합 모드는 CC Desktop 응용 프로그램을 별도의 iFrame Webex 포함하는 것입니다.

또한 Webex CC Desktop 응용 프로그램은 사용자 지정 헤드리스 위젯(사용자 인터페이스 없음)을 실행하고 백그라운드에서 실행하며 기본 CRM 시스템과 상호 작용하여 에이전트를 대신하여 자동화된 작업을 수행합니다.

상호 작용은 헤드리스 위젯이 사용하는 두 개의 SDK에 의해 구동됩니다.

• Webex CC Desktop JS SDK: 상담원 및 문의 작업에 대한 이벤트 리스너를 등록하기 위해 Webex CC에서 제공하는 JavaScript SDK입니다.

• CRM JS SDK: CRM을 사용하여 REST API 호출을 추상화하는 CRM에 적용할 수 있는 CRM 클라이언트 SDK입니다. 예를 들어 salesforce의 경우 Salesforce에서 제공하는 CTI JS 라이브러리를 사용하여 작업을 수행하고 CRM 내에서 이벤트를 수신합니다.

그림 1 은 CRM 임베디드 Webex CC 데스크탑 및 커넥터 아키텍처를 보여줍니다

Webex CC는 위에서 언급한 통합을 위해 다음과 같은 CRM 솔루션을 지원합니다.

• Salesforce

• 서비스나우

• 마이크로소프트 다이내믹스 365

• 젠 데스크

• 프레시데스크

자세한 내용은 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10를 참조하세요 .

CRM 커넥터, 기능 집합 및 변경 로그를 활성화하기 위해 Webex CC 데스크탑 레이아웃을 구성하는 방법에 대한 자세한 내용은 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations를 참조하십시오 .

CRM 커넥터의 글로벌 가용성

CRM 커넥터는 Webex CC가 작동하는 모든 지역 및 지역에서 사용할 수 있습니다.

탄력적인 확장성 및 성능

Webex CC는 CRM 애플리케이션과 AWS CloudFront CDN의 Webex CC 데스크톱 간의 양방향 통신을 가능하게 하는 사용자 지정 위젯을 호스팅하여 가용 영역 및 리전 전반에 걸쳐 위젯 AWS의 고가용성을 보장합니다.

모든 CRM 통합 관련 계산은 상담원이 CRM 응용 프로그램에 포함된 CC 데스크톱과 함께 CRM 응용 프로그램을 사용하는 브라우저에서 Webex 발생합니다.

보안

CRM 커넥터는 Webex CC 상담원 데스크톱 레이아웃을 통해 호출되고 선택적 매개 변수는 데스크톱 레이아웃을 통해 위젯으로 전달되어 기능을 켜고 끕니다.

예를 들어 Salesforce 작업 위젯을 활성화하기 위해 관리자는 데스크톱 레이아웃 매개 변수 설정 sfdcWidgetEnabled를 true로 설정할 수 있습니다.

패키지 설치

통합이 양방향으로 작동하려면 CRM 콘솔에 포함된 응용 프로그램이 설치되어 있어야 합니다. 이는 iFrame 내에서 데스크톱 애플리케이션 로드를 지원하기 위한 것입니다.

모든 Desktop Embedded 커넥터는 CRM 마켓플레이스에서 사용할 수 있습니다.

예를 들어

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

마켓플레이스 응용 프로그램 설치는 필요한 플러그 인을 활성화하고 필요한 XML 파일을 CRM 콘솔로 가져와서 CRM에서 통화 레코드 보고를 지원합니다.

IVR에서 HTTPs 커넥터를 통한 흐름 통합

Webex CC 흐름 빌더는 Control Hub에서 구성되고 Webex CC 흐름에서 사용되는 HTTP 커넥터를 사용하여 Webex CC Webex 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

Edge의 음성 인프라

음성 에지 구성 요소를 사용하면 고객 네트워크/PSTN 통신업체의 SIP 트렁크를 종료할 수 있으며, 에지 구성 요소에 연결할 수 있는 허용 목록에 있는 IP 수를 기준으로 활성화됩니다.

컴퓨팅 인프라 보안

Webex CC 컴퓨팅 인스턴스는 AWS에서 프로비저닝되고 서비스는 여러 네임스페이스가 있는 Kubernetes 클러스터에서 포드로 실행되며 각 네임스페이스에 대한 액세스는 별도의 자격 증명으로 제한됩니다.

모든 인프라 프로비저닝은 수동 단계 없이 코드를 사용하여 수행되며 자격 증명에 수동으로 액세스할 수 없습니다.

특정 서비스/팀 집합에 대해 구성된 특정 경로가 있는 중앙 자격 증명 저장소가 있으며, 자격 증명 저장소 자체에 대한 액세스는 빌드 및 배포 시스템에서 비밀로 제한되고 구성됩니다.

인프라 구성 요소 / 서비스는 AWS VPC 외부에 직접 노출되지 않으며 공개적으로 노출 된 인터페이스 만 API 게이트웨이를 사용하여 제어 및 관리되는 API 및 WebSocket 서버입니다.

이 외에도 로그, 메트릭, 배포 세부 정보, 빌드 상태 및 테스트 결과를 보는 데 사용되는 개발자가 사용하는 특정 내부 시스템 및 인터페이스가 있으며, 이러한 시스템은 역할 및 그룹을 사용하여 보호되고 Cisco 내부 인증 시스템과 통합됩니다.

사용자 인터페이스에 대한 인증 및 권한 부여

다양한 고객지원센터 사용자(에이전트, 감독자, 관리자, 분석가)가 사용하는 모든 사용자 인터페이스는 Cisco Common Identity 기반 베어러 토큰 인증(OAuth 흐름)으로 보호됩니다.

권한 부여는 토큰을 얻은 사용자의 역할과 토큰에 할당된 범위를 사용하여 수행됩니다.

전송 중인 데이터

배포된 서비스/인프라 구성 요소의 인터페이스는 외부 수신 트래픽에 직접 노출되지 않습니다.

Http API를 사용하여 서비스를 선택하면 게이트웨이를 통해 해당 인터페이스를 노출하고 모든 수신 https(WebSocket의 인터페이스 포함)는 ALB에서 종료되고 http를 통한 내부 트래픽은 서비스로 라우팅됩니다.

모든 나가는 상호 작용은 https / TLS (비 http 프로토콜의 경우)를 통해 이루어집니다.

VPC 내부에서 http / 사용자 지정 TCP 프로토콜을 통한 서비스 간의 내부 통신은 일반 TCP 소켓을 통해 이루어집니다.

미사용 데이터

저장되는 모든 데이터는 스토리지 계층에서 암호화됩니다. 또한 VPC 외부에 있는 데이터 스토어는 비밀 저장소에 안전하게 저장 및 관리되는 자격 증명을 사용하여 보호되고 액세스 제어 및 권한 부여됩니다.

그림 1 은 전송 및 미사용에 대한 데이터 흐름 및 보안 모델을 보여줍니다.

최종 사용자 PII 데이터

상호 작용을 처리하기 위한 프로그래밍 방식 컨트롤러인 Webex CC Flow를 사용하여 사용자 데이터를 수집할 수 있으며, 이 데이터는 '민감한 데이터 포함'이라는 태그가 지정된 흐름 변수에 할당할 수 있습니다. 이러한 데이터의 값은 암호화되며 데이터 전송 경로의 어떤 서비스도 이 데이터에 액세스할 수 없습니다.

또한 이러한 데이터는 Webex CC 보고 데이터 저장소에 유지되지 않으며 로그/메시징 인프라는 암호화된 데이터를 가지며 일반 텍스트 데이터는 Webex CC 내의 어디에도 저장되지 않습니다.

고객지원센터 상담원/슈퍼바이저 PII 데이터

컨택 센터 사용자 관련 데이터는 로그에서 수정되지만 Webex CC 데이터 저장소에서 데이터 분석 및 시각화에 사용할 수 있습니다.

규모 요인

Webex CC의 경우 척도에 영향을 미치는 요소는 다음과 같습니다.

• 로그인한 동시 상담원 수

• 진행 중인 동시 상호 작용 수

  • 이러한 상호 작용에 대해 수행되는 작업

• 슈퍼바이저/상담원이 상호 작용 처리 외에 수행하는 동시 작업 수입니다

• 생성 및 유지되는 데이터의 볼륨

확장을 가능하게 하는 아키텍처 측면

Webex CC의 설계 및 설계 기반이 되는 원칙에 따라 다양한 서비스 및 플랫폼 구성 요소에 대해 프로비저닝된 인프라에서 적용하는 한도 내에서 필요에 따라 솔루션을 동적으로 확장할 수 있습니다.

이벤트 기반 아키텍처

Webex CC의 서비스는 메시지를 사용하여 통신하고 중요한 메시지 처리 흐름에는 차단 IO 작업이 포함되지 않으며 메시지 처리에 필요한 상태는 메시지를 처리하는 서비스의 인스턴스로 지역화됩니다.

상태 비저장 서비스(또는 외부화된 상태)

상태 비저장 서비스는 서비스의 추가 인스턴스를 쉽게 추가/제거하여 탄력성을 가능하게 합니다. 본질적으로 상태 저장 인 특정 서비스가 있으며 상태 저장소를 외부화했으며 인프라는 자동 재조정 / 상태 전송 / 상태를 필요로하는 인스턴스로 상태 지역화를 통해 이러한 서비스의 인스턴스 수에 대한 동적 변경을 지원합니다.

탄력적인 인프라

모든 서비스는 쿠버네티스에서 실행되며, 쿠버네티스 노드라고도 하는 인프라는 사용량에 따라 자동으로 확장되며, 이를 통해 미리 구성된 최대 높은 임계값까지 더 많은 컴퓨팅 노드를 동적으로 추가할 수 있습니다.

하중 투영 및 정기 검증

모든 서비스는 성능 특성에 대해 벤치마킹되며 크기 조정 패턴은 서비스 수준에서 유효성이 검사됩니다.

추가적인 지속적인 검증, 최대 부하 및 내구성 테스트는 병목 현상을 식별하고, 인프라 리소스 사용에 대한 높은 임계값을 업데이트하고, 게임 당일에 대비할 수 있도록 하는 규모에 영향을 미치는 속성의 예상 성장에 맞게 조정된 테스트 매개 변수를 사용하여 수행됩니다.

텔레포니

텔레포니의 경우, 착신 음성 통화 처리는 통화가 고객지원센터에 어떻게 들어왔는지(아래의 수신 메커니즘 참조) 및 진입점과 연결된 Webex CC 흐름에 따라 결정됩니다.

통화에 응답하고 추가 작업을 Webex CC 흐름 정의에 따라 수행합니다. 이 정의는 대기열에 넣고 상담원에게 라우팅하기 전에 통화를 처리하는 동안 수행할 작업을 프로그래밍 방식으로 표현한 것입니다. 또는 흐름 자체가 상담원에게 호전환하지 않고 통화를 처리할 수 있습니다.

Webex CC의 흐름 작성기를 사용하면 개발자가 흐름을 정의하고 통화가 Webex CC에 도착하는 진입점에 할당할 수 있습니다.

이러한 구성 엔티티 및 해당 사용법은 구성 엔티티 에서다룹니다.

Flow Builder에 대한 자세한 내용은 IVR System 에 대한 다음 섹션에서 다룹니다.

이메일 및 메시징

CC Webex 관점에서 Webex Connect는 최종 사용자가 컨택 센터에 접속하는 데 사용할 수 있는 모든 디지털 채널(전자 메일, 메시징 채널)에 대한 수신 및 송신 기능을 제공합니다.

Webex Connect 흐름

• 상호 작용이 대기열에 저장되고 상담원에게 라우팅될 때까지 이러한 상호 작용의 처리를 결정합니다. 여기에는 모든 형태의 메시징 및 이메일 상호 작용에 대한 자동 처리 및 BOT 처리가 포함됩니다.

• 들어오는 상호 작용에 비즈니스 논리를 적용합니다.

• 대기 전에 연결을 처리합니다.

• 흐름 자체는 실제 에이전트로 전송하지 않고 상호 작용을 처리할 수 있습니다.

Webex CC에서 지원하는 메시징 채널은 다음과 같습니다.

• Web App / 모바일 앱 채팅

• WhatsApp

• Facebook Messenger

• SMS

Webex CC에서 지원하는 전자 메일 채널은 다음과 같습니다.

• Gmail

• 오피스365

수신 메커니즘

이 섹션에서는 상호 작용이 Webex CC에 들어갈 수 있는 메커니즘을 설명합니다. 미디어 유형에 따라 상호 작용이 Webex CC에 도달하는 메커니즘이 다릅니다.

예를 들어 텔레포니에는 PSTN 연결, 전화 번호 구성 및 통화를 Webex CC로 라우팅하는 데 필요한 물리적 인프라 프로비저닝이 있습니다.

이메일/메시징 채널의 경우 수신 구성은 Webex Connect에서 수행되어야 하며 여기에는 이메일/메시징 계정 프로비저닝 및 Webex Connect 흐름 구성이 포함됩니다.

착신 음성

음성 통화의 경우 일반적인 시나리오는 사용자가 PSTN 전화 번호로 전화를 건 다음 고객지원센터에 연결되는 것입니다. 수신 관점에서 PSTN에서 Webex CC로 통화를 라우팅하는 메커니즘이 필요합니다.

그림 1 에서는 Webex CC에 대한 음성 통화 수집을 보여 줍니다.

Webex CC의 음성 수신 서비스는 SIP를 사용하여 타사 통화 제어를 수행하고 수신 통화에 응답할 뿐만 아니라 호전환, 전화회의 및 기타 통화 제어 작업을 수행합니다.

Webex CC에서 통화의 논리적 진입점은 'Entrypoint'라는 구성 엔티티입니다. 음성 수신의 경우 Entrypoint의 주요 구성은 연결된 전화 번호이며, 일반적으로 선택한 PSTN 공급자로부터 얻은 유효한 PSTN 전화 번호입니다.

이렇게 하면 전화 번호에서 수신 통화를 감지하고, 통화를 진입점에 연결하고, 진입점의 다른 구성 매개 변수를 사용하여 상호 작용에 대해 트리거되어야 하는 Webex CC 흐름 정의에 따라 통화를 처리할 수 있습니다.

참고:

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로 수집되는 증가하는 동시 음성 통화를 처리할 수 있도록 수평으로 확장 가능합니다.

음성 에지 인프라에 대한 보안 고려 사항

아래 표에는 음성 에지 인프라에 대한 연결 옵션에 대한 세부 정보가 있습니다.

자세한 내용은 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 를 참조하십시오.

IVR 시스템

진입점과 연결된 전화 번호로 수신되는 모든 음성 통화는 Webex CC에서 응답하고 진입점과 연결된 Webex CC 흐름 실행이 시작됩니다.

Webex CC Flow Builder는 관리자 또는 IVR 로직을 설계하고 구현하는 모든 사람이 이러한 빌딩 블록을 결합하여 Flow 정의를 만들 수 있도록 활동이라는 프로그래밍 구문/연산자 및 기능 블록을 제공합니다.

Flow가 지원하는 프로그래밍 구문은 다음과 같습니다.

• 선언 및 설정 변수 – 흐름 실행과 관련된 상태

  • 변수의 값을 설정하는 Pebble 표현식

• 조건부 검사

• 루핑 – 조건문 및 Go To 사용(활동을 함께 연결하는 기능)

• REST API 호출

• 데이터 구문 분석 – JSON, TOML XML 일반적으로 API 응답을 구문 분석하는 데 사용됩니다.

• 작곡 활동

Flow가 제공하는 대표적인 활동은 다음과 같습니다. 메시지 재생 사용자 데이터 수집 다른 대상/전화 번호로 통화 호전환 가상 상담사에게 통화 보내기 상담원이 응답할 수 있도록 통화를 대기열에 넣습니다.

활성 상태인 모든 통화에 대해 흐름 실행 인스턴스도 통화가 종료될 때까지 활성 상태이므로 흐름이 동시에 실행됩니다.

흐름 실행의 각 인스턴스는 호출에 의해 흐름과 관련된 데이터/상태에 대해 격리된 환경을 제공합니다.

또한 통화의 전체 주기 동안 Flow는 발생하는 특정 이벤트에 응답하고 이벤트를 처리할 수 있도록 합니다. 예를 들어 상담원이 통화에 응답하면 이벤트 처리기가 Agent Desktop 인터페이스에서 화면 팝업을 트리거할 수 있습니다.

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는 Control Hub에 사전 구성된 가상 상담사에게 상호 작용을 전환하기 위한 활동을 제공합니다Webex.

통화가 가상 에이전트에 연결되면 사용자에게 대화 IVR 환경을 제공하고 활동은 통화 종료 또는 에이전트로의 통화 에스컬레이션으로 끝납니다.

에스컬레이션의 경우 통화를 대기열에 넣은 다음 상담원이 응답하도록 흐름을 구성할 수 있습니다.

인바운드 디지털 상호 작용

수신 상호 작용의 전자 메일 및 메시징 채널의 경우, Webex CC는 Webex Connect를 활용하여 자산, 플로우를 프로비저닝하고 수신 상호 작용을 처리한 다음 Webex Connect 흐름이 상호 작용을 명시적으로 대기열에 넣으면 상호 작용을 Webex CC로 라우팅하여 상담원이 처리할 수 있도록 합니다.

그림 2 는 Webex CC에서 이메일, 메시징 상호 작용의 수집을 보여줍니다.

가상 에이전트 / BOT 통합

이메일 및 메시징/소셜 채널 상호 작용의 경우 가상 상담원/BOT 처리는 Webex Connect 흐름에서 구성됩니다.

Virtual Agents for Voice에서처럼, BOT 처리가 결과적으로 에스컬레이션으로 끝나면 상호 작용이 대기열에 추가되고 에이전트에게 라우팅됩니다.

에이전트 선택

Webex CC의 대기열은 다음 상담사 선택 알고리즘을 지원합니다.

• 가장 오랫동안 사용할 수 있는 상담원 라우팅

• 기술 기반 라우팅

  • 가장 오랫동안 사용 가능한 상담사(LAA)

  • BAA(Best Available Agent)

상담사는 팀을 통해 대기열에 연결됩니다.

대기열에 통화 분산 그룹이 추가될 때까지 대기가 구성된 순차적 방식으로 대기열에 여러 통화 배포 그룹(각 그룹에는 하나 이상의 팀이 있음)을 할당하여 시간이 진행됨에 따라 일치하는 상담원에 대한 검색 공간이 추가 통화 배포 그룹으로 확장되도록 할 수 있습니다.

직무 기반 라우팅의 경우 대기열과 연결된 직무 요구 사항 일치 상담원 중에서 LAA 또는 BAA 구성을 기반으로 상담원이 선택됩니다.

음성/텔레포니 관련 추가 기능

에이전트 기반 라우팅(음성/텔레포니 채널에만 해당)

활동 QueueToAgent를 사용하는 CC Flow Webex 상담사 ID를 기반으로 선택한 상담사에게 직접 상호 작용을 라우팅할 수 있습니다.

상담원이 상호 작용을 처리할 수 없는 경우 상담원별 대기열에 상호 작용을 지정보류하고 상담원이 사용 가능해질 때까지 기다릴 수 있습니다

고급 대기열 정보

CC Flow Webex GetQueueInfo 활동을 사용하여 PIQ(대기열 위치), EWT(예상 대기 시간), 대기열에서 사용할 수 있는 상담원 수와 같은 대기열에 대한 실시간 정보를 가져올 수 있으며 연결을 대기열에 넣을지 여부를 결정하는 데 사용할 수 있습니다.

무료 콜백

활동 콜백Webex 사용하는 CC Flow를 통해 고객이 대기열에서 위치를 유지하면서 통화를 끊을 수 있으며, 대기열의 가상 상호 작용이 상담원에게 라우팅될 때 콜백을 받을 수 있습니다.

오버플로 처리

Webex CC는 CBT(용량 기반 팀)를 사용한 오버플로 처리를 지원합니다.

CBT는 용량 및 해당 용량을 지원하는 연결된 외부 DN이 있는 일반 팀과 같습니다. 대기열 통화 분배 주기에서 다른 팀과 함께 구성할 수 있습니다.

일반적으로 구성된 모든 통화 분산 그룹이 상호 작용을 처리하는 데 사용할 수 있는 일치하는 에이전트를 찾지 못한 후에도 사용 가능한 상담원이 없는 경우 오버플로로 작동하도록 마지막 주기로 구성됩니다.

Agent Desktop 작업

상담원이 Webex CC Agent Desktop에 로그인할 때 상담원은 상담원에게 걸려오는 전화를 연결할 수 있는 전화 번호를 지정합니다. 상담원이 Cisco Webex Calling 사용자인 경우 PSTN 전화나 휴대폰 또는 내선 번호가 될 수 있습니다.

이 번호는 통화를 라우팅할 수 있는 유효한 전화 번호여야 합니다. 그렇지 않은 경우 상담원은 수신 통화를 받을 수 없습니다.

상담원이 처리하는 상호 작용 유형에 따라 상담원 데스크톱의 위젯은 특정 미디어 제어 작업을 수행할 수 있는 기능을 제공합니다.

예를 들어, 전화에 응답하면 상담원은 통화와 관련된 다음 작업을 수행할 수 있습니다.

• 통화를 보류로 전환

• 상담 통화를 시작하고

  • 다른 전화 번호(예: 상담원 전화 번호)/진입 지점으로 통화 호전환

  • 다른 상담원과 통화하기

• 통화를 다른 대기열로 호전환

• 통화 종료

Agent Desktop을 통해 관리자는 데스크톱 기능을 확장하고 상담원이 효율적인 방식으로 작업을 수행하는 데 필요한 위젯의 통합 모음으로 만들어 사용자 정의 위젯을 추가할 수 있습니다.

데스크탑 아키텍처

Agent Desktop은 웹 구성 요소 아키텍처에 기반을 두고 작성된 위젯을 호스팅하는 마이크로 프론트엔드 기반의 단일 페이지 애플리케이션입니다. 모든 표준/재고 위젯은 API 또는 서버 측 푸시 메커니즘에서 검색한 데이터로 구동됩니다.

이는 일반적으로 호출에 대한 응답이 WebSocket 연결을 통해 데스크톱에 오는 비동기 API입니다.

Webex CC는 Agent Desktop Cisco CI(Common Identity)로 사용자를 인증하고 토큰은 모든 API 호출에 전달됩니다. 사용자 정의 위젯의 경우에도 인증 모델을 기반으로 하며, 사용자 정의 위젯의 인증 모델이 CI와 통합된 경우 상담사에게 SSO(Single Sign-On) 환경을 제공합니다.

에이전트가 상호 작용의 일부가 되면 해당 상호 작용 상태 또는 관련 데이터에 대한 모든 업데이트도 WebSocket 연결을 통해 데스크톱으로 푸시됩니다.

연결 및 대기 시간에 대한 데스크톱의 복원력

비동기 API 및 서버 측 푸시를 사용하면 확장이 가능하며 WebSocket 인터페이스에 대한 연결 손실이 감지되고 데스크톱이 다시 연결하고 다시 로그인하려고 시도합니다.

그림 2 는 Webex CC의 에이전트 데스크톱 아키텍처를 보여줍니다.

고객 온보딩

Webex Control Hub는 파트너와 고객이 고객을 온보딩하고 기능을 활성화하거나 구성하기 위해 사용하는 기본 인터페이스입니다.

Control Hub에서 조직 및 고객지원센터 기능이 구축되면 고객이 선택한 제품에 따라 모든 고객지원센터 기능을 프로비저닝하는 나머지 단계를 수행하는 Webex CC에서 워크플로우가 트리거됩니다.

모든 컨택 센터 프로비저닝은 관련된 단계를 선언적으로 정의할 수 있는 BPM 워크플로우 엔진을 사용하여 수행되며, 전체 프로비저닝 단계를 장애에 탄력적으로 적용하고 데이터 무결성을 보장합니다.

그림 1 은 Webex CC의 프로비저닝 워크플로를 보여줍니다.

구성 엔티티

조직 내에서 범위가 지정되는 Webex CC의 주요 구성 엔터티는 다음과 같습니다.

사이트

사이트는 하나 이상의 팀, 사용자(상담원/감독자)가 위치한 위치를 의미합니다.

모든 사용자와 팀은 사이트에 속해야 합니다.

팀

사용자 그룹입니다. 팀은 대기열을 통해 상담사에게 상호 작용을 배포하는 데 사용됩니다.

모든 팀이 사이트에 속해야 합니다.

상담원

Agent Desktop에 로그인하고 Webex CC에 구성된 미디어 유형의 상호 작용을 처리할 수 있는 사용자입니다.

관리자

슈퍼바이저는 팀에 할당되어 상담원을 모니터링/코치할 수 있고 슈퍼바이저가 할당된 팀에 속한 팀의 팀 수준 상태 및 상담원 통계에 액세스할 수 있습니다.

서비스 대기열

대기열은 상담사가 사용 가능해질 때까지 대기하는 동안 상호 작용이 보류될 수 있는 논리적 엔티티로, 상담사에게 라우팅됩니다.

대기열은 상담원의 검색 공간인 팀에 매핑됩니다. 경과 시간 임계값을 기반으로 검색 공간에 다른 팀을 추가하여 검색 공간을 확장할 수 있습니다.

진입점

진입점은 상호 작용이 Webex CC로 들어오는 수신 지점을 나타내는 논리적 엔터티입니다. 텔레포니의 경우 주로 통화가 도착하는 전화 번호에 매핑되고 이메일/메시징 채널의 경우 진입점은 Webex Connect의 자산 구성을 가리킵니다.

흐름

진입점과 연결된 흐름(라우팅 전략을 통해)으로, 상호 작용 처리와 관련된 단계를 결정합니다.

비텔레포니 채널(이메일, 메시징/소셜)의 경우 흐름은 Webex Connect의 자산 구성의 일부로 선택됩니다.

다중 사이트 고객지원센터에 대한 액세스 제어

Webex CC 관리자는 특정 사이트, 팀, 대기열 및 진입점에 대한 액세스 권한이 있는 사용자 프로필을 구성할 수 있습니다. 또한 사이트 및 팀의 계층적 특성으로 인해 특정 사이트에 대한 액세스가 제공되면 사용자는 해당 사이트 또는 이러한 팀의 명시적으로 지정된 하위 집합에 속하는 팀 또는 날짜만 액세스할 수 있습니다.

대기열 및 진입점의 경우 조직 수준에서 전역이므로 다양한 지리적 위치(특정 상담원 및 팀이 있는 사이트)에 대해 별도의 진입점 및 대기열을 구성할 수 있으며 슈퍼바이저/사용자가 특정 사이트에 대해 적용 가능한 엔티티에 액세스할 수 있습니다.

그림 2 에서는 주요 구성 엔티티와 이러한 엔티티를 참조하는 사용자 프로필을 보여 줍니다.

이러한 엔티티에 대한 액세스를 제한하는 것 외에도, Webex CC 관리자는 사용자가 관리 인터페이스에서 액세스할 수 있는 특정 기능/모듈을 제어할 수 있으므로 Webex CC 관리 인터페이스의 섹션/기능뿐만 아니라 특정 엔티티에 대한 관리/구성 권한을 가진 사용자를 보유할 수 있습니다.

데스크탑 내장 커넥터: CRM 애플리케이션을 기본 인터페이스로 사용

이 작업 모드에서는 상담원이 CRM 콘솔에 기본 애플리케이션으로 로그인합니다.

Webex CC는 컨택 센터에 로그인하고 CC가 라우팅한 컨택 센터 상호 작용을 Webex수신하는 데 주로 사용되는 임베디드 애플리케이션(임베디드 데스크톱 애플리케이션 또는 임베디드 소프트폰이라고도 함)입니다.

통화 또는 대화 요청을 받으면 CRM 통합은 CRM 콘솔에서 다음 작업을 수행합니다

• ANI 또는 기타 통화 관련 데이터에 연결된 고객 레코드를 화면에 표시합니다.

• 통화 메타데이터를 고객 레코드에 활동 노트로 게시

• 상담원이 CRM 내의 연락처를 클릭하고 고객에게 아웃바운드 통화를 시작하여 "클릭하여 전화 걸기"를 허용할 수 있습니다

• CRM의 기본 보고를 위해 CRM 보고 테이블에 통화 레코드 게시

• Agent Desktop 및 통화 제어(데스크톱 앱의 포함 및 축소된 버전)의 전체 기능을 제공합니다.

CRM과의 기본 통합 모드는 CC Desktop 응용 프로그램을 별도의 iFrame Webex 포함하는 것입니다.

또한 Webex CC Desktop 응용 프로그램은 사용자 지정 헤드리스 위젯(사용자 인터페이스 없음)을 실행하고 백그라운드에서 실행하며 기본 CRM 시스템과 상호 작용하여 에이전트를 대신하여 자동화된 작업을 수행합니다.

상호 작용은 헤드리스 위젯이 사용하는 두 개의 SDK에 의해 구동됩니다.

• Webex CC Desktop JS SDK: 상담원 및 문의 작업에 대한 이벤트 리스너를 등록하기 위해 Webex CC에서 제공하는 JavaScript SDK입니다.

• CRM JS SDK: CRM을 사용하여 REST API 호출을 추상화하는 CRM에 적용할 수 있는 CRM 클라이언트 SDK입니다. 예를 들어 salesforce의 경우 Salesforce에서 제공하는 CTI JS 라이브러리를 사용하여 작업을 수행하고 CRM 내에서 이벤트를 수신합니다.

그림 1 은 CRM 임베디드 Webex CC 데스크탑 및 커넥터 아키텍처를 보여줍니다

Webex CC는 위에서 언급한 통합을 위해 다음과 같은 CRM 솔루션을 지원합니다.

• Salesforce

• 서비스나우

• 마이크로소프트 다이내믹스 365

• 젠 데스크

• 프레시데스크

자세한 내용은 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10를 참조하세요 .

CRM 커넥터, 기능 집합 및 변경 로그를 활성화하기 위해 Webex CC 데스크탑 레이아웃을 구성하는 방법에 대한 자세한 내용은 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations를 참조하십시오 .

CRM 커넥터의 글로벌 가용성

CRM 커넥터는 Webex CC가 작동하는 모든 지역 및 지역에서 사용할 수 있습니다.

탄력적인 확장성 및 성능

Webex CC는 CRM 애플리케이션과 AWS CloudFront CDN의 Webex CC 데스크톱 간의 양방향 통신을 가능하게 하는 사용자 지정 위젯을 호스팅하여 가용 영역 및 리전 전반에 걸쳐 위젯 AWS의 고가용성을 보장합니다.

모든 CRM 통합 관련 계산은 상담원이 CRM 응용 프로그램에 포함된 CC 데스크톱과 함께 CRM 응용 프로그램을 사용하는 브라우저에서 Webex 발생합니다.

보안

CRM 커넥터는 Webex CC 상담원 데스크톱 레이아웃을 통해 호출되고 선택적 매개 변수는 데스크톱 레이아웃을 통해 위젯으로 전달되어 기능을 켜고 끕니다.

예를 들어 Salesforce 작업 위젯을 활성화하기 위해 관리자는 데스크톱 레이아웃 매개 변수 설정 sfdcWidgetEnabled를 true로 설정할 수 있습니다.

패키지 설치

통합이 양방향으로 작동하려면 CRM 콘솔에 포함된 응용 프로그램이 설치되어 있어야 합니다. 이는 iFrame 내에서 데스크톱 애플리케이션 로드를 지원하기 위한 것입니다.

모든 Desktop Embedded 커넥터는 CRM 마켓플레이스에서 사용할 수 있습니다.

예를 들어

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

마켓플레이스 응용 프로그램 설치는 필요한 플러그 인을 활성화하고 필요한 XML 파일을 CRM 콘솔로 가져와서 CRM에서 통화 레코드 보고를 지원합니다.

IVR에서 HTTPs 커넥터를 통한 흐름 통합

Webex CC 흐름 빌더는 Control Hub에서 구성되고 Webex CC 흐름에서 사용되는 HTTP 커넥터를 사용하여 Webex CC Webex 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

Edge의 음성 인프라

음성 에지 구성 요소를 사용하면 고객 네트워크/PSTN 통신업체의 SIP 트렁크를 종료할 수 있으며, 에지 구성 요소에 연결할 수 있는 허용 목록에 있는 IP 수를 기준으로 활성화됩니다.

컴퓨팅 인프라 보안

Webex CC 컴퓨팅 인스턴스는 AWS에서 프로비저닝되고 서비스는 여러 네임스페이스가 있는 Kubernetes 클러스터에서 포드로 실행되며 각 네임스페이스에 대한 액세스는 별도의 자격 증명으로 제한됩니다.

모든 인프라 프로비저닝은 수동 단계 없이 코드를 사용하여 수행되며 자격 증명에 수동으로 액세스할 수 없습니다.

특정 서비스/팀 집합에 대해 구성된 특정 경로가 있는 중앙 자격 증명 저장소가 있으며, 자격 증명 저장소 자체에 대한 액세스는 빌드 및 배포 시스템에서 비밀로 제한되고 구성됩니다.

인프라 구성 요소 / 서비스는 AWS VPC 외부에 직접 노출되지 않으며 공개적으로 노출 된 인터페이스 만 API 게이트웨이를 사용하여 제어 및 관리되는 API 및 WebSocket 서버입니다.

이 외에도 로그, 메트릭, 배포 세부 정보, 빌드 상태 및 테스트 결과를 보는 데 사용되는 개발자가 사용하는 특정 내부 시스템 및 인터페이스가 있으며, 이러한 시스템은 역할 및 그룹을 사용하여 보호되고 Cisco 내부 인증 시스템과 통합됩니다.

사용자 인터페이스에 대한 인증 및 권한 부여

다양한 고객지원센터 사용자(에이전트, 감독자, 관리자, 분석가)가 사용하는 모든 사용자 인터페이스는 Cisco Common Identity 기반 베어러 토큰 인증(OAuth 흐름)으로 보호됩니다.

권한 부여는 토큰을 얻은 사용자의 역할과 토큰에 할당된 범위를 사용하여 수행됩니다.

전송 중인 데이터

배포된 서비스/인프라 구성 요소의 인터페이스는 외부 수신 트래픽에 직접 노출되지 않습니다.

Http API를 사용하여 서비스를 선택하면 게이트웨이를 통해 해당 인터페이스를 노출하고 모든 수신 https(WebSocket의 인터페이스 포함)는 ALB에서 종료되고 http를 통한 내부 트래픽은 서비스로 라우팅됩니다.

모든 나가는 상호 작용은 https / TLS (비 http 프로토콜의 경우)를 통해 이루어집니다.

VPC 내부에서 http / 사용자 지정 TCP 프로토콜을 통한 서비스 간의 내부 통신은 일반 TCP 소켓을 통해 이루어집니다.

미사용 데이터

저장되는 모든 데이터는 스토리지 계층에서 암호화됩니다. 또한 VPC 외부에 있는 데이터 스토어는 비밀 저장소에 안전하게 저장 및 관리되는 자격 증명을 사용하여 보호되고 액세스 제어 및 권한 부여됩니다.

그림 1 은 전송 및 미사용에 대한 데이터 흐름 및 보안 모델을 보여줍니다.

최종 사용자 PII 데이터

상호 작용을 처리하기 위한 프로그래밍 방식 컨트롤러인 Webex CC Flow를 사용하여 사용자 데이터를 수집할 수 있으며, 이 데이터는 '민감한 데이터 포함'이라는 태그가 지정된 흐름 변수에 할당할 수 있습니다. 이러한 데이터의 값은 암호화되며 데이터 전송 경로의 어떤 서비스도 이 데이터에 액세스할 수 없습니다.

또한 이러한 데이터는 Webex CC 보고 데이터 저장소에 유지되지 않으며 로그/메시징 인프라는 암호화된 데이터를 가지며 일반 텍스트 데이터는 Webex CC 내의 어디에도 저장되지 않습니다.

고객지원센터 상담원/슈퍼바이저 PII 데이터

컨택 센터 사용자 관련 데이터는 로그에서 수정되지만 Webex CC 데이터 저장소에서 데이터 분석 및 시각화에 사용할 수 있습니다.

규모 요인

Webex CC의 경우 척도에 영향을 미치는 요소는 다음과 같습니다.

• 로그인한 동시 상담원 수

• 진행 중인 동시 상호 작용 수

  • 이러한 상호 작용에 대해 수행되는 작업

• 슈퍼바이저/상담원이 상호 작용 처리 외에 수행하는 동시 작업 수입니다

• 생성 및 유지되는 데이터의 볼륨

확장을 가능하게 하는 아키텍처 측면

Webex CC의 설계 및 설계 기반이 되는 원칙에 따라 다양한 서비스 및 플랫폼 구성 요소에 대해 프로비저닝된 인프라에서 적용하는 한도 내에서 필요에 따라 솔루션을 동적으로 확장할 수 있습니다.

이벤트 기반 아키텍처

Webex CC의 서비스는 메시지를 사용하여 통신하고 중요한 메시지 처리 흐름에는 차단 IO 작업이 포함되지 않으며 메시지 처리에 필요한 상태는 메시지를 처리하는 서비스의 인스턴스로 지역화됩니다.

상태 비저장 서비스(또는 외부화된 상태)

상태 비저장 서비스는 서비스의 추가 인스턴스를 쉽게 추가/제거하여 탄력성을 가능하게 합니다. 본질적으로 상태 저장 인 특정 서비스가 있으며 상태 저장소를 외부화했으며 인프라는 자동 재조정 / 상태 전송 / 상태를 필요로하는 인스턴스로 상태 지역화를 통해 이러한 서비스의 인스턴스 수에 대한 동적 변경을 지원합니다.

탄력적인 인프라

모든 서비스는 쿠버네티스에서 실행되며, 쿠버네티스 노드라고도 하는 인프라는 사용량에 따라 자동으로 확장되며, 이를 통해 미리 구성된 최대 높은 임계값까지 더 많은 컴퓨팅 노드를 동적으로 추가할 수 있습니다.

하중 투영 및 정기 검증

모든 서비스는 성능 특성에 대해 벤치마킹되며 크기 조정 패턴은 서비스 수준에서 유효성이 검사됩니다.

추가적인 지속적인 검증, 최대 부하 및 내구성 테스트는 병목 현상을 식별하고, 인프라 리소스 사용에 대한 높은 임계값을 업데이트하고, 게임 당일에 대비할 수 있도록 하는 규모에 영향을 미치는 속성의 예상 성장에 맞게 조정된 테스트 매개 변수를 사용하여 수행됩니다.

텔레포니

텔레포니의 경우, 착신 음성 통화 처리는 통화가 고객지원센터에 어떻게 들어왔는지(아래의 수신 메커니즘 참조) 및 진입점과 연결된 Webex CC 흐름에 따라 결정됩니다.

통화에 응답하고 추가 작업을 Webex CC 흐름 정의에 따라 수행합니다. 이 정의는 대기열에 넣고 상담원에게 라우팅하기 전에 통화를 처리하는 동안 수행할 작업을 프로그래밍 방식으로 표현한 것입니다. 또는 흐름 자체가 상담원에게 호전환하지 않고 통화를 처리할 수 있습니다.

Webex CC의 흐름 작성기를 사용하면 개발자가 흐름을 정의하고 통화가 Webex CC에 도착하는 진입점에 할당할 수 있습니다.

이러한 구성 엔티티 및 해당 사용법은 구성 엔티티 에서다룹니다.

Flow Builder에 대한 자세한 내용은 IVR System 에 대한 다음 섹션에서 다룹니다.

이메일 및 메시징

CC Webex 관점에서 Webex Connect는 최종 사용자가 컨택 센터에 접속하는 데 사용할 수 있는 모든 디지털 채널(전자 메일, 메시징 채널)에 대한 수신 및 송신 기능을 제공합니다.

Webex Connect 흐름

• 상호 작용이 대기열에 저장되고 상담원에게 라우팅될 때까지 이러한 상호 작용의 처리를 결정합니다. 여기에는 모든 형태의 메시징 및 이메일 상호 작용에 대한 자동 처리 및 BOT 처리가 포함됩니다.

• 들어오는 상호 작용에 비즈니스 논리를 적용합니다.

• 대기 전에 연결을 처리합니다.

• 흐름 자체는 실제 에이전트로 전송하지 않고 상호 작용을 처리할 수 있습니다.

Webex CC에서 지원하는 메시징 채널은 다음과 같습니다.

• Web App / 모바일 앱 채팅

• WhatsApp

• Facebook Messenger

• SMS

Webex CC에서 지원하는 전자 메일 채널은 다음과 같습니다.

• Gmail

• 오피스365

수신 메커니즘

이 섹션에서는 상호 작용이 Webex CC에 들어갈 수 있는 메커니즘을 설명합니다. 미디어 유형에 따라 상호 작용이 Webex CC에 도달하는 메커니즘이 다릅니다.

예를 들어 텔레포니에는 PSTN 연결, 전화 번호 구성 및 통화를 Webex CC로 라우팅하는 데 필요한 물리적 인프라 프로비저닝이 있습니다.

이메일/메시징 채널의 경우 수신 구성은 Webex Connect에서 수행되어야 하며 여기에는 이메일/메시징 계정 프로비저닝 및 Webex Connect 흐름 구성이 포함됩니다.

착신 음성

음성 통화의 경우 일반적인 시나리오는 사용자가 PSTN 전화 번호로 전화를 건 다음 고객지원센터에 연결되는 것입니다. 수신 관점에서 PSTN에서 Webex CC로 통화를 라우팅하는 메커니즘이 필요합니다.

다음 그림에서는 Webex CC에 대한 음성 통화 수집을 설명합니다.

Webex CC의 음성 수신 서비스는 SIP를 사용하여 타사 통화 제어를 수행하고 수신 통화에 응답할 뿐만 아니라 호전환, 전화회의 및 기타 통화 제어 작업을 수행합니다.

Webex CC에서 통화의 논리적 진입점은 'Entrypoint'라는 구성 엔티티입니다. 음성 수신의 경우 Entrypoint의 주요 구성은 연결된 전화 번호이며, 일반적으로 선택한 PSTN 공급자로부터 얻은 유효한 PSTN 전화 번호입니다.

이렇게 하면 전화 번호에서 수신 통화를 감지하고, 통화를 진입점에 연결하고, 진입점의 다른 구성 매개 변수를 사용하여 상호 작용에 대해 트리거되어야 하는 Webex CC 흐름 정의에 따라 통화를 처리할 수 있습니다.

참고:

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로 수집되는 증가하는 동시 음성 통화를 처리할 수 있도록 수평으로 확장 가능합니다.

음성 에지 인프라에 대한 보안 고려 사항

아래 표에는 음성 에지 인프라에 대한 연결 옵션에 대한 세부 정보가 있습니다.

자세한 내용은 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를 참조하십시오 .

IVR 시스템

진입점과 연결된 전화 번호로 수신되는 모든 음성 통화는 Webex CC에서 응답하고 진입점과 연결된 Webex CC 흐름 실행이 시작됩니다.

Webex CC Flow Builder는 관리자 또는 IVR 로직을 설계하고 구현하는 모든 사람이 이러한 빌딩 블록을 결합하여 Flow 정의를 만들 수 있도록 활동이라는 프로그래밍 구문/연산자 및 기능 블록을 제공합니다.

Flow가 지원하는 프로그래밍 구문은 다음과 같습니다.

• 선언 및 설정 변수 – 흐름 실행과 관련된 상태

  • 변수의 값을 설정하는 Pebble 표현식

• 조건부 검사

• 루핑 – 조건문 및 Go To 사용(활동을 함께 연결하는 기능)

• REST API 호출

• 데이터 구문 분석 – JSON, TOML XML 일반적으로 API 응답을 구문 분석하는 데 사용됩니다.

• 작곡 활동

Flow가 제공하는 대표적인 활동은 다음과 같습니다. 메시지 재생 사용자 데이터 수집 다른 대상/전화 번호로 통화 호전환 가상 상담사에게 통화 보내기 상담원이 응답할 수 있도록 통화를 대기열에 넣습니다.

활성 상태인 모든 통화에 대해 흐름 실행 인스턴스도 통화가 종료될 때까지 활성 상태이므로 흐름이 동시에 실행됩니다.

흐름 실행의 각 인스턴스는 호출에 의해 흐름과 관련된 데이터/상태에 대해 격리된 환경을 제공합니다.

또한 통화의 전체 주기 동안 Flow는 발생하는 특정 이벤트에 응답하고 이벤트를 처리할 수 있도록 합니다. 예를 들어 상담원이 통화에 응답하면 이벤트 처리기가 Agent Desktop 인터페이스에서 화면 팝업을 트리거할 수 있습니다.

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는 Control Hub에 사전 구성된 가상 상담사에게 상호 작용을 전환하기 위한 활동을 제공합니다Webex.

통화가 가상 에이전트에 연결되면 사용자에게 대화 IVR 환경을 제공하고 활동은 통화 종료 또는 에이전트로의 통화 에스컬레이션으로 끝납니다.

에스컬레이션의 경우 통화를 대기열에 넣은 다음 상담원이 응답하도록 흐름을 구성할 수 있습니다.

인바운드 디지털 상호 작용

수신 상호 작용의 전자 메일 및 메시징 채널의 경우, Webex CC는 Webex Connect를 활용하여 자산, 플로우를 프로비저닝하고 수신 상호 작용을 처리한 다음 Webex Connect 흐름이 상호 작용을 명시적으로 대기열에 넣으면 상호 작용을 Webex CC로 라우팅하여 상담원이 처리할 수 있도록 합니다.

다음 그림에서는 Webex CC에서 이메일, 메시징 상호 작용의 수집을 보여 줍니다.

가상 에이전트 / BOT 통합

이메일 및 메시징/소셜 채널 상호 작용의 경우 가상 상담원/BOT 처리는 Webex Connect 흐름에서 구성됩니다.

Virtual Agents for Voice에서처럼, BOT 처리가 결과적으로 에스컬레이션으로 끝나면 상호 작용이 대기열에 추가되고 에이전트에게 라우팅됩니다.

에이전트 선택

Webex CC의 대기열은 다음 상담사 선택 알고리즘을 지원합니다.

• 가장 오랫동안 사용할 수 있는 상담원 라우팅

• 기술 기반 라우팅

  • 가장 오랫동안 사용 가능한 상담사(LAA)

  • BAA(Best Available Agent)

상담사는 팀을 통해 대기열에 연결됩니다.

대기열에 통화 분산 그룹이 추가될 때까지 대기가 구성된 순차적 방식으로 대기열에 여러 통화 배포 그룹(각 그룹에는 하나 이상의 팀이 있음)을 할당하여 시간이 진행됨에 따라 일치하는 상담원에 대한 검색 공간이 추가 통화 배포 그룹으로 확장되도록 할 수 있습니다.

직무 기반 라우팅의 경우 대기열과 연결된 직무 요구 사항 일치 상담원 중에서 LAA 또는 BAA 구성을 기반으로 상담원이 선택됩니다.

음성/텔레포니 관련 추가 기능

에이전트 기반 라우팅(음성/텔레포니 채널에만 해당)

활동 QueueToAgent를 사용하는 CC Flow Webex 상담사 ID를 기반으로 선택한 상담사에게 직접 상호 작용을 라우팅할 수 있습니다.

상담원이 상호 작용을 처리할 수 없는 경우 상담원별 대기열에 상호 작용을 지정보류하고 상담원이 사용 가능해질 때까지 기다릴 수 있습니다

고급 대기열 정보

CC Flow Webex GetQueueInfo 활동을 사용하여 PIQ(대기열 위치), EWT(예상 대기 시간), 대기열에서 사용할 수 있는 상담원 수와 같은 대기열에 대한 실시간 정보를 가져올 수 있으며 연결을 대기열에 넣을지 여부를 결정하는 데 사용할 수 있습니다.

무료 콜백

활동 콜백Webex 사용하는 CC Flow를 통해 고객이 대기열에서 위치를 유지하면서 통화를 끊을 수 있으며, 대기열의 가상 상호 작용이 상담원에게 라우팅될 때 콜백을 받을 수 있습니다.

오버플로 처리

Webex CC는 CBT(용량 기반 팀)를 사용한 오버플로 처리를 지원합니다.

CBT는 용량 및 해당 용량을 지원하는 연결된 외부 DN이 있는 일반 팀과 같습니다. 대기열 통화 분배 주기에서 다른 팀과 함께 구성할 수 있습니다.

일반적으로 구성된 모든 통화 분산 그룹이 상호 작용을 처리하는 데 사용할 수 있는 일치하는 에이전트를 찾지 못한 후에도 사용 가능한 상담원이 없는 경우 오버플로로 작동하도록 마지막 주기로 구성됩니다.

Agent Desktop 작업

상담원이 Webex CC Agent Desktop에 로그인할 때 상담원은 상담원에게 걸려오는 전화를 연결할 수 있는 전화 번호를 지정합니다. 상담원이 Cisco Webex Calling 사용자인 경우 PSTN 전화나 휴대폰 또는 내선 번호가 될 수 있습니다.

이 번호는 통화를 라우팅할 수 있는 유효한 전화 번호여야 합니다. 그렇지 않은 경우 상담원은 수신 통화를 받을 수 없습니다.

상담원이 처리하는 상호 작용 유형에 따라 상담원 데스크톱의 위젯은 특정 미디어 제어 작업을 수행할 수 있는 기능을 제공합니다.

예를 들어, 전화에 응답하면 상담원은 통화와 관련된 다음 작업을 수행할 수 있습니다.

• 통화를 보류로 전환

• 상담 통화를 시작하고

  • 다른 전화 번호(예: 상담원 전화 번호)/진입 지점으로 통화 호전환

  • 다른 상담원과 통화하기

• 통화를 다른 대기열로 호전환

• 통화 종료

Agent Desktop을 통해 관리자는 데스크톱 기능을 확장하고 상담원이 효율적인 방식으로 작업을 수행하는 데 필요한 위젯의 통합 모음으로 만들어 사용자 정의 위젯을 추가할 수 있습니다.

데스크탑 아키텍처

Agent Desktop은 웹 구성 요소 아키텍처에 기반을 두고 작성된 위젯을 호스팅하는 마이크로 프론트엔드 기반의 단일 페이지 애플리케이션입니다. 모든 표준/재고 위젯은 API 또는 서버 측 푸시 메커니즘에서 검색한 데이터로 구동됩니다.

이는 일반적으로 호출에 대한 응답이 WebSocket 연결을 통해 데스크톱에 오는 비동기 API입니다.

Webex CC는 Agent Desktop Cisco CI(Common Identity)로 사용자를 인증하고 토큰은 모든 API 호출에 전달됩니다. 사용자 정의 위젯의 경우에도 인증 모델을 기반으로 하며, 사용자 정의 위젯의 인증 모델이 CI와 통합된 경우 상담사에게 SSO(Single Sign-On) 환경을 제공합니다.

에이전트가 상호 작용의 일부가 되면 해당 상호 작용 상태 또는 관련 데이터에 대한 모든 업데이트도 WebSocket 연결을 통해 데스크톱으로 푸시됩니다.

연결 및 대기 시간에 대한 데스크톱의 복원력

비동기 API 및 서버 측 푸시를 사용하면 확장이 가능하며 WebSocket 인터페이스에 대한 연결 손실이 감지되고 데스크톱이 다시 연결하고 다시 로그인하려고 시도합니다.

다음 그림은 Webex CC의 상담원 데스크톱 아키텍처를 보여줍니다.

고객 온보딩

Webex Control Hub는 파트너와 고객이 고객을 온보딩하고 기능을 활성화하거나 구성하기 위해 사용하는 기본 인터페이스입니다.

Control Hub에서 조직 및 고객지원센터 기능이 구축되면 고객이 선택한 제품에 따라 모든 고객지원센터 기능을 프로비저닝하는 나머지 단계를 수행하는 Webex CC에서 워크플로우가 트리거됩니다.

모든 컨택 센터 프로비저닝은 관련된 단계를 선언적으로 정의할 수 있는 BPM 워크플로우 엔진을 사용하여 수행되며, 전체 프로비저닝 단계를 장애에 탄력적으로 적용하고 데이터 무결성을 보장합니다.

다음 그림에서는 Webex CC의 프로비저닝 워크플로를 보여 줍니다.

구성 엔티티

조직 내에서 범위가 지정되는 Webex CC의 주요 구성 엔터티는 다음과 같습니다.

사이트

사이트는 하나 이상의 팀, 사용자(상담원/감독자)가 위치한 위치를 의미합니다.

모든 사용자와 팀은 사이트에 속해야 합니다.

팀

사용자 그룹입니다. 팀은 대기열을 통해 상담사에게 상호 작용을 배포하는 데 사용됩니다.

모든 팀이 사이트에 속해야 합니다.

상담원

Agent Desktop에 로그인하고 Webex CC에 구성된 미디어 유형의 상호 작용을 처리할 수 있는 사용자입니다.

관리자

슈퍼바이저는 팀에 할당되어 상담원을 모니터링/코치할 수 있고 슈퍼바이저가 할당된 팀에 속한 팀의 팀 수준 상태 및 상담원 통계에 액세스할 수 있습니다.

서비스 대기열

대기열은 상담사가 사용 가능해질 때까지 대기하는 동안 상호 작용이 보류될 수 있는 논리적 엔티티로, 상담사에게 라우팅됩니다.

대기열은 상담원의 검색 공간인 팀에 매핑됩니다. 경과 시간 임계값을 기반으로 검색 공간에 다른 팀을 추가하여 검색 공간을 확장할 수 있습니다.

진입점

진입점은 상호 작용이 Webex CC로 들어오는 수신 지점을 나타내는 논리적 엔터티입니다. 텔레포니의 경우 주로 통화가 도착하는 전화 번호에 매핑되고 이메일/메시징 채널의 경우 진입점은 Webex Connect의 자산 구성을 가리킵니다.

흐름

진입점과 연결된 흐름(라우팅 전략을 통해)으로, 상호 작용 처리와 관련된 단계를 결정합니다.

비텔레포니 채널(이메일, 메시징/소셜)의 경우 흐름은 Webex Connect의 자산 구성의 일부로 선택됩니다.

다중 사이트 고객지원센터에 대한 액세스 제어

Webex CC 관리자는 특정 사이트, 팀, 대기열 및 진입점에 대한 액세스 권한이 있는 사용자 프로필을 구성할 수 있습니다. 또한 사이트 및 팀의 계층적 특성으로 인해 특정 사이트에 대한 액세스가 제공되면 사용자는 해당 사이트 또는 이러한 팀의 명시적으로 지정된 하위 집합에 속하는 팀 또는 날짜만 액세스할 수 있습니다.

대기열 및 진입점의 경우 조직 수준에서 전역이므로 다양한 지리적 위치(특정 상담원 및 팀이 있는 사이트)에 대해 별도의 진입점 및 대기열을 구성할 수 있으며 슈퍼바이저/사용자가 특정 사이트에 대해 적용 가능한 엔티티에 액세스할 수 있습니다.

다음 그림에서는 주요 구성 엔티티와 이러한 엔티티를 참조하는 사용자 프로파일을 보여 줍니다.

이러한 엔티티에 대한 액세스를 제한하는 것 외에도, Webex CC 관리자는 사용자가 관리 인터페이스에서 액세스할 수 있는 특정 기능/모듈을 제어할 수 있으므로 Webex CC 관리 인터페이스의 섹션/기능뿐만 아니라 특정 엔티티에 대한 관리/구성 권한을 가진 사용자를 보유할 수 있습니다.

데스크탑 내장 커넥터: CRM 애플리케이션을 기본 인터페이스로 사용

이 작업 모드에서는 상담원이 CRM 콘솔에 기본 애플리케이션으로 로그인합니다.

Webex CC는 컨택 센터에 로그인하고 CC가 라우팅한 컨택 센터 상호 작용을 Webex수신하는 데 주로 사용되는 임베디드 애플리케이션(임베디드 데스크톱 애플리케이션 또는 임베디드 소프트폰이라고도 함)입니다.

통화 또는 대화 요청을 받으면 CRM 통합은 CRM 콘솔에서 다음 작업을 수행합니다

• ANI 또는 기타 통화 관련 데이터에 연결된 고객 레코드를 화면에 표시합니다.

• 통화 메타데이터를 고객 레코드에 활동 노트로 게시

• 상담원이 CRM 내의 연락처를 클릭하고 고객에게 아웃바운드 통화를 시작하여 "클릭하여 전화 걸기"를 허용할 수 있습니다

• CRM의 기본 보고를 위해 CRM 보고 테이블에 통화 레코드 게시

• Agent Desktop 및 통화 제어(데스크톱 앱의 포함 및 축소된 버전)의 전체 기능을 제공합니다.

CRM과의 기본 통합 모드는 CC Desktop 응용 프로그램을 별도의 iFrame Webex 포함하는 것입니다.

또한 Webex CC Desktop 응용 프로그램은 사용자 지정 헤드리스 위젯(사용자 인터페이스 없음)을 실행하고 백그라운드에서 실행하며 기본 CRM 시스템과 상호 작용하여 에이전트를 대신하여 자동화된 작업을 수행합니다.

상호 작용은 헤드리스 위젯이 사용하는 두 개의 SDK에 의해 구동됩니다.

• Webex CC Desktop JS SDK: 상담원 및 문의 작업에 대한 이벤트 리스너를 등록하기 위해 Webex CC에서 제공하는 JavaScript SDK입니다.

• CRM JS SDK: CRM을 사용하여 REST API 호출을 추상화하는 CRM에 적용할 수 있는 CRM 클라이언트 SDK입니다. 예를 들어 salesforce의 경우 Salesforce에서 제공하는 CTI JS 라이브러리를 사용하여 작업을 수행하고 CRM 내에서 이벤트를 수신합니다.

다음 그림은 CC 데스크탑 및 커넥터 아키텍처Webex 포함된 CRM을 보여줍니다

Webex CC는 위에서 언급한 통합을 위해 다음과 같은 CRM 솔루션을 지원합니다.

• Salesforce

• 서비스나우

• 마이크로소프트 다이내믹스 365

• 젠 데스크

• 프레시데스크

자세한 내용은 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10를 참조하세요 .

CRM 커넥터, 기능 집합 및 변경 로그를 활성화하기 위해 Webex CC 데스크탑 레이아웃을 구성하는 방법에 대한 자세한 내용은 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations를 참조하십시오 .

CRM 커넥터의 글로벌 가용성

CRM 커넥터는 Webex CC가 작동하는 모든 지역 및 지역에서 사용할 수 있습니다.

탄력적인 확장성 및 성능

Webex CC는 CRM 애플리케이션과 AWS CloudFront CDN의 Webex CC 데스크톱 간의 양방향 통신을 가능하게 하는 사용자 지정 위젯을 호스팅하여 가용 영역 및 리전 전반에 걸쳐 위젯 AWS의 고가용성을 보장합니다.

모든 CRM 통합 관련 계산은 상담원이 CRM 응용 프로그램에 포함된 CC 데스크톱과 함께 CRM 응용 프로그램을 사용하는 브라우저에서 Webex 발생합니다.

보안

CRM 커넥터는 Webex CC 상담원 데스크톱 레이아웃을 통해 호출되고 선택적 매개 변수는 데스크톱 레이아웃을 통해 위젯으로 전달되어 기능을 켜고 끕니다.

예를 들어 Salesforce 작업 위젯을 활성화하기 위해 관리자는 데스크톱 레이아웃 매개 변수 설정 sfdcWidgetEnabled를 true로 설정할 수 있습니다.

패키지 설치

통합이 양방향으로 작동하려면 CRM 콘솔에 포함된 응용 프로그램이 설치되어 있어야 합니다. 이는 iFrame 내에서 데스크톱 애플리케이션 로드를 지원하기 위한 것입니다.

모든 Desktop Embedded 커넥터는 CRM 마켓플레이스에서 사용할 수 있습니다.

예를 들어

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

마켓플레이스 응용 프로그램 설치는 필요한 플러그 인을 활성화하고 필요한 XML 파일을 CRM 콘솔로 가져와서 CRM에서 통화 레코드 보고를 지원합니다.

IVR에서 HTTPs 커넥터를 통한 흐름 통합

Webex CC 흐름 빌더는 Control Hub에서 구성되고 Webex CC 흐름에서 사용되는 HTTP 커넥터를 사용하여 Webex CC Webex 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

Edge의 음성 인프라

음성 에지 구성 요소를 사용하면 고객 네트워크/PSTN 통신업체의 SIP 트렁크를 종료할 수 있으며, 에지 구성 요소에 연결할 수 있는 허용 목록에 있는 IP 수를 기준으로 활성화됩니다.

컴퓨팅 인프라 보안

Webex CC 컴퓨팅 인스턴스는 AWS에서 프로비저닝되고 서비스는 여러 네임스페이스가 있는 Kubernetes 클러스터에서 포드로 실행되며 각 네임스페이스에 대한 액세스는 별도의 자격 증명으로 제한됩니다.

모든 인프라 프로비저닝은 수동 단계 없이 코드를 사용하여 수행되며 자격 증명에 수동으로 액세스할 수 없습니다.

특정 서비스/팀 집합에 대해 구성된 특정 경로가 있는 중앙 자격 증명 저장소가 있으며, 자격 증명 저장소 자체에 대한 액세스는 빌드 및 배포 시스템에서 비밀로 제한되고 구성됩니다.

인프라 구성 요소 / 서비스는 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 작업이 포함되지 않으며 메시지 처리에 필요한 상태는 메시지를 처리하는 서비스의 인스턴스로 지역화됩니다.

상태 비저장 서비스(또는 외부화된 상태)

상태 비저장 서비스는 서비스의 추가 인스턴스를 쉽게 추가/제거하여 탄력성을 가능하게 합니다. 본질적으로 상태 저장 인 특정 서비스가 있으며 상태 저장소를 외부화했으며 인프라는 자동 재조정 / 상태 전송 / 상태를 필요로하는 인스턴스로 상태 지역화를 통해 이러한 서비스의 인스턴스 수에 대한 동적 변경을 지원합니다.

탄력적인 인프라

모든 서비스는 쿠버네티스에서 실행되며, 쿠버네티스 노드라고도 하는 인프라는 사용량에 따라 자동으로 확장되며, 이를 통해 미리 구성된 최대 높은 임계값까지 더 많은 컴퓨팅 노드를 동적으로 추가할 수 있습니다.

하중 투영 및 정기 검증

모든 서비스는 성능 특성에 대해 벤치마킹되며 크기 조정 패턴은 서비스 수준에서 유효성이 검사됩니다.

추가적인 지속적인 검증, 최대 부하 및 내구성 테스트는 병목 현상을 식별하고, 인프라 리소스 사용에 대한 높은 임계값을 업데이트하고, 게임 당일에 대비할 수 있도록 하는 규모에 영향을 미치는 속성의 예상 성장에 맞게 조정된 테스트 매개 변수를 사용하여 수행됩니다.

텔레포니

텔레포니의 경우, 착신 음성 통화 처리는 통화가 고객지원센터에 어떻게 들어왔는지(아래의 수신 메커니즘 참조) 및 진입점과 연결된 Webex CC 흐름에 따라 결정됩니다.

통화에 응답하고 추가 작업을 Webex CC 흐름 정의에 따라 수행합니다. 이 정의는 대기열에 넣고 상담원에게 라우팅하기 전에 통화를 처리하는 동안 수행할 작업을 프로그래밍 방식으로 표현한 것입니다. 또는 흐름 자체가 상담원에게 호전환하지 않고 통화를 처리할 수 있습니다.

Webex CC의 흐름 작성기를 사용하면 개발자가 흐름을 정의하고 통화가 Webex CC에 도착하는 진입점에 할당할 수 있습니다.

이러한 구성 엔티티 및 해당 사용법은 구성 엔티티 에서다룹니다.

Flow Builder에 대한 자세한 내용은 IVR System 에 대한 다음 섹션에서 다룹니다.

이메일 및 메시징

CC Webex 관점에서 Webex Connect는 최종 사용자가 컨택 센터에 접속하는 데 사용할 수 있는 모든 디지털 채널(전자 메일, 메시징 채널)에 대한 수신 및 송신 기능을 제공합니다.

Webex Connect 흐름

• 상호 작용이 대기열에 저장되고 상담원에게 라우팅될 때까지 이러한 상호 작용의 처리를 결정합니다. 여기에는 모든 형태의 메시징 및 이메일 상호 작용에 대한 자동 처리 및 BOT 처리가 포함됩니다.

• 들어오는 상호 작용에 비즈니스 논리를 적용합니다.

• 대기 전에 연결을 처리합니다.

• 흐름 자체는 실제 에이전트로 전송하지 않고 상호 작용을 처리할 수 있습니다.

Webex CC에서 지원하는 메시징 채널은 다음과 같습니다.

• Web App / 모바일 앱 채팅

• WhatsApp

• Facebook Messenger

• SMS

Webex CC에서 지원하는 전자 메일 채널은 다음과 같습니다.

• Gmail

• 오피스365

수신 메커니즘

이 섹션에서는 상호 작용이 Webex CC에 들어갈 수 있는 메커니즘을 설명합니다. 미디어 유형에 따라 상호 작용이 Webex CC에 도달하는 메커니즘이 다릅니다.

예를 들어 텔레포니에는 PSTN 연결, 전화 번호 구성 및 통화를 Webex CC로 라우팅하는 데 필요한 물리적 인프라 프로비저닝이 있습니다.

이메일/메시징 채널의 경우 수신 구성은 Webex Connect에서 수행되어야 하며 여기에는 이메일/메시징 계정 프로비저닝 및 Webex Connect 흐름 구성이 포함됩니다.

착신 음성

음성 통화의 경우 일반적인 시나리오는 사용자가 PSTN 전화 번호로 전화를 건 다음 고객지원센터에 연결되는 것입니다. 수신 관점에서 PSTN에서 Webex CC로 통화를 라우팅하는 메커니즘이 필요합니다.

다음 그림에서는 Webex CC에 대한 음성 통화 수집을 설명합니다.

Webex CC의 음성 수신 서비스는 SIP를 사용하여 타사 통화 제어를 수행하고 수신 통화에 응답할 뿐만 아니라 호전환, 전화회의 및 기타 통화 제어 작업을 수행합니다.

Webex CC에서 통화의 논리적 진입점은 'Entrypoint'라는 구성 엔티티입니다. 음성 수신의 경우 Entrypoint의 주요 구성은 연결된 전화 번호이며, 일반적으로 선택한 PSTN 공급자로부터 얻은 유효한 PSTN 전화 번호입니다.

이렇게 하면 전화 번호에서 수신 통화를 감지하고, 통화를 진입점에 연결하고, 진입점의 다른 구성 매개 변수를 사용하여 상호 작용에 대해 트리거되어야 하는 Webex CC 흐름 정의에 따라 통화를 처리할 수 있습니다.

참고:

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로 수집되는 증가하는 동시 음성 통화를 처리할 수 있도록 수평으로 확장 가능합니다.

음성 에지 인프라에 대한 보안 고려 사항

아래 표에는 음성 에지 인프라에 대한 연결 옵션에 대한 세부 정보가 있습니다.

자세한 내용은 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를 참조하십시오 .

IVR 시스템

진입점과 연결된 전화 번호로 수신되는 모든 음성 통화는 Webex CC에서 응답하고 진입점과 연결된 Webex CC 흐름 실행이 시작됩니다.

Webex CC Flow Builder는 관리자 또는 IVR 로직을 설계하고 구현하는 모든 사람이 이러한 빌딩 블록을 결합하여 Flow 정의를 만들 수 있도록 활동이라는 프로그래밍 구문/연산자 및 기능 블록을 제공합니다.

Flow가 지원하는 프로그래밍 구문은 다음과 같습니다.

• 선언 및 설정 변수 – 흐름 실행과 관련된 상태

  • 변수의 값을 설정하는 Pebble 표현식

• 조건부 검사

• 루핑 – 조건문 및 Go To 사용(활동을 함께 연결하는 기능)

• REST API 호출

• 데이터 구문 분석 – JSON, TOML XML 일반적으로 API 응답을 구문 분석하는 데 사용됩니다.

• 작곡 활동

Flow가 제공하는 대표적인 활동은 다음과 같습니다. 메시지 재생 사용자 데이터 수집 다른 대상/전화 번호로 통화 호전환 가상 상담사에게 통화 보내기 상담원이 응답할 수 있도록 통화를 대기열에 넣습니다.

활성 상태인 모든 통화에 대해 흐름 실행 인스턴스도 통화가 종료될 때까지 활성 상태이므로 흐름이 동시에 실행됩니다.

흐름 실행의 각 인스턴스는 호출에 의해 흐름과 관련된 데이터/상태에 대해 격리된 환경을 제공합니다.

또한 통화의 전체 주기 동안 Flow는 발생하는 특정 이벤트에 응답하고 이벤트를 처리할 수 있도록 합니다. 예를 들어 상담원이 통화에 응답하면 이벤트 처리기가 Agent Desktop 인터페이스에서 화면 팝업을 트리거할 수 있습니다.

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는 Control Hub에 사전 구성된 가상 상담사에게 상호 작용을 전환하기 위한 활동을 제공합니다Webex.

통화가 가상 에이전트에 연결되면 사용자에게 대화 IVR 환경을 제공하고 활동은 통화 종료 또는 에이전트로의 통화 에스컬레이션으로 끝납니다.

에스컬레이션의 경우 통화를 대기열에 넣은 다음 상담원이 응답하도록 흐름을 구성할 수 있습니다.

인바운드 디지털 상호 작용

수신 상호 작용의 전자 메일 및 메시징 채널의 경우, Webex CC는 Webex Connect를 활용하여 자산, 플로우를 프로비저닝하고 수신 상호 작용을 처리한 다음 Webex Connect 흐름이 상호 작용을 명시적으로 대기열에 넣으면 상호 작용을 Webex CC로 라우팅하여 상담원이 처리할 수 있도록 합니다.

다음 그림에서는 Webex CC에서 이메일, 메시징 상호 작용의 수집을 보여 줍니다.

가상 에이전트 / BOT 통합

이메일 및 메시징/소셜 채널 상호 작용의 경우 가상 상담원/BOT 처리는 Webex Connect 흐름에서 구성됩니다.

Virtual Agents for Voice에서처럼, BOT 처리가 결과적으로 에스컬레이션으로 끝나면 상호 작용이 대기열에 추가되고 에이전트에게 라우팅됩니다.

에이전트 선택

Webex CC의 대기열은 다음 상담사 선택 알고리즘을 지원합니다.

• 가장 오랫동안 사용할 수 있는 상담원 라우팅

• 기술 기반 라우팅

  • 가장 오랫동안 사용 가능한 상담사(LAA)

  • BAA(Best Available Agent)

상담사는 팀을 통해 대기열에 연결됩니다.

대기열에 통화 분산 그룹이 추가될 때까지 대기가 구성된 순차적 방식으로 대기열에 여러 통화 배포 그룹(각 그룹에는 하나 이상의 팀이 있음)을 할당하여 시간이 진행됨에 따라 일치하는 상담원에 대한 검색 공간이 추가 통화 배포 그룹으로 확장되도록 할 수 있습니다.

직무 기반 라우팅의 경우 대기열과 연결된 직무 요구 사항 일치 상담원 중에서 LAA 또는 BAA 구성을 기반으로 상담원이 선택됩니다.

음성/텔레포니 관련 추가 기능

에이전트 기반 라우팅(음성/텔레포니 채널에만 해당)

활동 QueueToAgent를 사용하는 CC Flow Webex 상담사 ID를 기반으로 선택한 상담사에게 직접 상호 작용을 라우팅할 수 있습니다.

상담원이 상호 작용을 처리할 수 없는 경우 상담원별 대기열에 상호 작용을 지정보류하고 상담원이 사용 가능해질 때까지 기다릴 수 있습니다

고급 대기열 정보

CC Flow Webex GetQueueInfo 활동을 사용하여 PIQ(대기열 위치), EWT(예상 대기 시간), 대기열에서 사용할 수 있는 상담원 수와 같은 대기열에 대한 실시간 정보를 가져올 수 있으며 연결을 대기열에 넣을지 여부를 결정하는 데 사용할 수 있습니다.

무료 콜백

활동 콜백Webex 사용하는 CC Flow를 통해 고객이 대기열에서 위치를 유지하면서 통화를 끊을 수 있으며, 대기열의 가상 상호 작용이 상담원에게 라우팅될 때 콜백을 받을 수 있습니다.

오버플로 처리

Webex CC는 CBT(용량 기반 팀)를 사용한 오버플로 처리를 지원합니다.

CBT는 용량 및 해당 용량을 지원하는 연결된 외부 DN이 있는 일반 팀과 같습니다. 대기열 통화 분배 주기에서 다른 팀과 함께 구성할 수 있습니다.

일반적으로 구성된 모든 통화 분산 그룹이 상호 작용을 처리하는 데 사용할 수 있는 일치하는 에이전트를 찾지 못한 후에도 사용 가능한 상담원이 없는 경우 오버플로로 작동하도록 마지막 주기로 구성됩니다.

Agent Desktop 작업

상담원이 Webex CC Agent Desktop에 로그인할 때 상담원은 상담원에게 걸려오는 전화를 연결할 수 있는 전화 번호를 지정합니다. 상담원이 Cisco Webex Calling 사용자인 경우 PSTN 전화나 휴대폰 또는 내선 번호가 될 수 있습니다.

이 번호는 통화를 라우팅할 수 있는 유효한 전화 번호여야 합니다. 그렇지 않은 경우 상담원은 수신 통화를 받을 수 없습니다.

상담원이 처리하는 상호 작용 유형에 따라 상담원 데스크톱의 위젯은 특정 미디어 제어 작업을 수행할 수 있는 기능을 제공합니다.

예를 들어, 전화에 응답하면 상담원은 통화와 관련된 다음 작업을 수행할 수 있습니다.

• 통화를 보류로 전환

• 상담 통화를 시작하고

  • 다른 전화 번호(예: 상담원 전화 번호)/진입 지점으로 통화 호전환

  • 다른 상담원과 통화하기

• 통화를 다른 대기열로 호전환

• 통화 종료

Agent Desktop을 통해 관리자는 데스크톱 기능을 확장하고 상담원이 효율적인 방식으로 작업을 수행하는 데 필요한 위젯의 통합 모음으로 만들어 사용자 정의 위젯을 추가할 수 있습니다.

데스크탑 아키텍처

Agent Desktop은 웹 구성 요소 아키텍처에 기반을 두고 작성된 위젯을 호스팅하는 마이크로 프론트엔드 기반의 단일 페이지 애플리케이션입니다. 모든 표준/재고 위젯은 API 또는 서버 측 푸시 메커니즘에서 검색한 데이터로 구동됩니다.

이는 일반적으로 호출에 대한 응답이 WebSocket 연결을 통해 데스크톱에 오는 비동기 API입니다.

Webex CC는 Agent Desktop Cisco CI(Common Identity)로 사용자를 인증하고 토큰은 모든 API 호출에 전달됩니다. 사용자 정의 위젯의 경우에도 인증 모델을 기반으로 하며, 사용자 정의 위젯의 인증 모델이 CI와 통합된 경우 상담사에게 SSO(Single Sign-On) 환경을 제공합니다.

에이전트가 상호 작용의 일부가 되면 해당 상호 작용 상태 또는 관련 데이터에 대한 모든 업데이트도 WebSocket 연결을 통해 데스크톱으로 푸시됩니다.

연결 및 대기 시간에 대한 데스크톱의 복원력

비동기 API 및 서버 측 푸시를 사용하면 확장이 가능하며 WebSocket 인터페이스에 대한 연결 손실이 감지되고 데스크톱이 다시 연결하고 다시 로그인하려고 시도합니다.

다음 그림은 Webex CC의 상담원 데스크톱 아키텍처를 보여줍니다.

고객 온보딩

Webex Control Hub는 파트너와 고객이 고객을 온보딩하고 기능을 활성화하거나 구성하기 위해 사용하는 기본 인터페이스입니다.

Control Hub에서 조직 및 고객지원센터 기능이 구축되면 고객이 선택한 제품에 따라 모든 고객지원센터 기능을 프로비저닝하는 나머지 단계를 수행하는 Webex CC에서 워크플로우가 트리거됩니다.

모든 컨택 센터 프로비저닝은 관련된 단계를 선언적으로 정의할 수 있는 BPM 워크플로우 엔진을 사용하여 수행되며, 전체 프로비저닝 단계를 장애에 탄력적으로 적용하고 데이터 무결성을 보장합니다.

다음 그림에서는 Webex CC의 프로비저닝 워크플로를 보여 줍니다.

구성 엔티티

조직 내에서 범위가 지정되는 Webex CC의 주요 구성 엔터티는 다음과 같습니다.

사이트

사이트는 하나 이상의 팀, 사용자(상담원/감독자)가 위치한 위치를 의미합니다.

모든 사용자와 팀은 사이트에 속해야 합니다.

팀

사용자 그룹입니다. 팀은 대기열을 통해 상담사에게 상호 작용을 배포하는 데 사용됩니다.

모든 팀이 사이트에 속해야 합니다.

상담원

Agent Desktop에 로그인하고 Webex CC에 구성된 미디어 유형의 상호 작용을 처리할 수 있는 사용자입니다.

관리자

슈퍼바이저는 팀에 할당되어 상담원을 모니터링/코치할 수 있고 슈퍼바이저가 할당된 팀에 속한 팀의 팀 수준 상태 및 상담원 통계에 액세스할 수 있습니다.

서비스 대기열

대기열은 상담사가 사용 가능해질 때까지 대기하는 동안 상호 작용이 보류될 수 있는 논리적 엔티티로, 상담사에게 라우팅됩니다.

대기열은 상담원의 검색 공간인 팀에 매핑됩니다. 경과 시간 임계값을 기반으로 검색 공간에 다른 팀을 추가하여 검색 공간을 확장할 수 있습니다.

진입점

진입점은 상호 작용이 Webex CC로 들어오는 수신 지점을 나타내는 논리적 엔터티입니다. 텔레포니의 경우 주로 통화가 도착하는 전화 번호에 매핑되고 이메일/메시징 채널의 경우 진입점은 Webex Connect의 자산 구성을 가리킵니다.

흐름

진입점과 연결된 흐름(라우팅 전략을 통해)으로, 상호 작용 처리와 관련된 단계를 결정합니다.

비텔레포니 채널(이메일, 메시징/소셜)의 경우 흐름은 Webex Connect의 자산 구성의 일부로 선택됩니다.

다중 사이트 고객지원센터에 대한 액세스 제어

Webex CC 관리자는 특정 사이트, 팀, 대기열 및 진입점에 대한 액세스 권한이 있는 사용자 프로필을 구성할 수 있습니다. 또한 사이트 및 팀의 계층적 특성으로 인해 특정 사이트에 대한 액세스가 제공되면 사용자는 해당 사이트 또는 이러한 팀의 명시적으로 지정된 하위 집합에 속하는 팀 또는 날짜만 액세스할 수 있습니다.

대기열 및 진입점의 경우 조직 수준에서 전역이므로 다양한 지리적 위치(특정 상담원 및 팀이 있는 사이트)에 대해 별도의 진입점 및 대기열을 구성할 수 있으며 슈퍼바이저/사용자가 특정 사이트에 대해 적용 가능한 엔티티에 액세스할 수 있습니다.

다음 그림에서는 주요 구성 엔티티와 이러한 엔티티를 참조하는 사용자 프로파일을 보여 줍니다.

이러한 엔티티에 대한 액세스를 제한하는 것 외에도, Webex CC 관리자는 사용자가 관리 인터페이스에서 액세스할 수 있는 특정 기능/모듈을 제어할 수 있으므로 Webex CC 관리 인터페이스의 섹션/기능뿐만 아니라 특정 엔티티에 대한 관리/구성 권한을 가진 사용자를 보유할 수 있습니다.

데스크탑 내장 커넥터: CRM 애플리케이션을 기본 인터페이스로 사용

이 작업 모드에서는 상담원이 CRM 콘솔에 기본 애플리케이션으로 로그인합니다.

Webex CC는 컨택 센터에 로그인하고 CC가 라우팅한 컨택 센터 상호 작용을 Webex수신하는 데 주로 사용되는 임베디드 애플리케이션(임베디드 데스크톱 애플리케이션 또는 임베디드 소프트폰이라고도 함)입니다.

통화 또는 대화 요청을 받으면 CRM 통합은 CRM 콘솔에서 다음 작업을 수행합니다

• ANI 또는 기타 통화 관련 데이터에 연결된 고객 레코드를 화면에 표시합니다.

• 통화 메타데이터를 고객 레코드에 활동 노트로 게시

• 상담원이 CRM 내의 연락처를 클릭하고 고객에게 아웃바운드 통화를 시작하여 "클릭하여 전화 걸기"를 허용할 수 있습니다

• CRM의 기본 보고를 위해 CRM 보고 테이블에 통화 레코드 게시

• Agent Desktop 및 통화 제어(데스크톱 앱의 포함 및 축소된 버전)의 전체 기능을 제공합니다.

CRM과의 기본 통합 모드는 CC Desktop 응용 프로그램을 별도의 iFrame Webex 포함하는 것입니다.

또한 Webex CC Desktop 응용 프로그램은 사용자 지정 헤드리스 위젯(사용자 인터페이스 없음)을 실행하고 백그라운드에서 실행하며 기본 CRM 시스템과 상호 작용하여 에이전트를 대신하여 자동화된 작업을 수행합니다.

상호 작용은 헤드리스 위젯이 사용하는 두 개의 SDK에 의해 구동됩니다.

• Webex CC Desktop JS SDK: 상담원 및 문의 작업에 대한 이벤트 리스너를 등록하기 위해 Webex CC에서 제공하는 JavaScript SDK입니다.

• CRM JS SDK: CRM을 사용하여 REST API 호출을 추상화하는 CRM에 적용할 수 있는 CRM 클라이언트 SDK입니다. 예를 들어 salesforce의 경우 Salesforce에서 제공하는 CTI JS 라이브러리를 사용하여 작업을 수행하고 CRM 내에서 이벤트를 수신합니다.

다음 그림은 CC 데스크탑 및 커넥터 아키텍처Webex 포함된 CRM을 보여줍니다

Webex CC는 위에서 언급한 통합을 위해 다음과 같은 CRM 솔루션을 지원합니다.

• Salesforce

• 서비스나우

• 마이크로소프트 다이내믹스 365

• 젠 데스크

• 프레시데스크

자세한 내용은 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10를 참조하세요 .

CRM 커넥터, 기능 집합 및 변경 로그를 활성화하기 위해 Webex CC 데스크탑 레이아웃을 구성하는 방법에 대한 자세한 내용은 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations를 참조하십시오 .

CRM 커넥터의 글로벌 가용성

CRM 커넥터는 Webex CC가 작동하는 모든 지역 및 지역에서 사용할 수 있습니다.

탄력적인 확장성 및 성능

Webex CC는 CRM 애플리케이션과 AWS CloudFront CDN의 Webex CC 데스크톱 간의 양방향 통신을 가능하게 하는 사용자 지정 위젯을 호스팅하여 가용 영역 및 리전 전반에 걸쳐 위젯 AWS의 고가용성을 보장합니다.

모든 CRM 통합 관련 계산은 상담원이 CRM 응용 프로그램에 포함된 CC 데스크톱과 함께 CRM 응용 프로그램을 사용하는 브라우저에서 Webex 발생합니다.

보안

CRM 커넥터는 Webex CC 상담원 데스크톱 레이아웃을 통해 호출되고 선택적 매개 변수는 데스크톱 레이아웃을 통해 위젯으로 전달되어 기능을 켜고 끕니다.

예를 들어 Salesforce 작업 위젯을 활성화하기 위해 관리자는 데스크톱 레이아웃 매개 변수 설정 sfdcWidgetEnabled를 true로 설정할 수 있습니다.

패키지 설치

통합이 양방향으로 작동하려면 CRM 콘솔에 포함된 응용 프로그램이 설치되어 있어야 합니다. 이는 iFrame 내에서 데스크톱 애플리케이션 로드를 지원하기 위한 것입니다.

모든 Desktop Embedded 커넥터는 CRM 마켓플레이스에서 사용할 수 있습니다.

예를 들어

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

마켓플레이스 응용 프로그램 설치는 필요한 플러그 인을 활성화하고 필요한 XML 파일을 CRM 콘솔로 가져와서 CRM에서 통화 레코드 보고를 지원합니다.

IVR에서 HTTPs 커넥터를 통한 흐름 통합

Webex CC 흐름 빌더는 Control Hub에서 구성되고 Webex CC 흐름에서 사용되는 HTTP 커넥터를 사용하여 Webex CC Webex 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

Edge의 음성 인프라

음성 에지 구성 요소를 사용하면 고객 네트워크/PSTN 통신업체의 SIP 트렁크를 종료할 수 있으며, 에지 구성 요소에 연결할 수 있는 허용 목록에 있는 IP 수를 기준으로 활성화됩니다.

컴퓨팅 인프라 보안

Webex CC 컴퓨팅 인스턴스는 AWS에서 프로비저닝되고 서비스는 여러 네임스페이스가 있는 Kubernetes 클러스터에서 포드로 실행되며 각 네임스페이스에 대한 액세스는 별도의 자격 증명으로 제한됩니다.

모든 인프라 프로비저닝은 수동 단계 없이 코드를 사용하여 수행되며 자격 증명에 수동으로 액세스할 수 없습니다.

특정 서비스/팀 집합에 대해 구성된 특정 경로가 있는 중앙 자격 증명 저장소가 있으며, 자격 증명 저장소 자체에 대한 액세스는 빌드 및 배포 시스템에서 비밀로 제한되고 구성됩니다.

인프라 구성 요소 / 서비스는 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 작업이 포함되지 않으며 메시지 처리에 필요한 상태는 메시지를 처리하는 서비스의 인스턴스로 지역화됩니다.

상태 비저장 서비스(또는 외부화된 상태)

상태 비저장 서비스는 서비스의 추가 인스턴스를 쉽게 추가/제거하여 탄력성을 가능하게 합니다. 본질적으로 상태 저장 인 특정 서비스가 있으며 상태 저장소를 외부화했으며 인프라는 자동 재조정 / 상태 전송 / 상태를 필요로하는 인스턴스로 상태 지역화를 통해 이러한 서비스의 인스턴스 수에 대한 동적 변경을 지원합니다.

탄력적인 인프라

모든 서비스는 쿠버네티스에서 실행되며, 쿠버네티스 노드라고도 하는 인프라는 사용량에 따라 자동으로 확장되며, 이를 통해 미리 구성된 최대 높은 임계값까지 더 많은 컴퓨팅 노드를 동적으로 추가할 수 있습니다.

하중 투영 및 정기 검증

모든 서비스는 성능 특성에 대해 벤치마킹되며 크기 조정 패턴은 서비스 수준에서 유효성이 검사됩니다.

추가적인 지속적인 검증, 최대 부하 및 내구성 테스트는 병목 현상을 식별하고, 인프라 리소스 사용에 대한 높은 임계값을 업데이트하고, 게임 당일에 대비할 수 있도록 하는 규모에 영향을 미치는 속성의 예상 성장에 맞게 조정된 테스트 매개 변수를 사용하여 수행됩니다.