이 문서에서
dropdown icon
대기열
    dropdown icon
    개요
      대기열의 종류
    dropdown icon
    기술 기반이 아닌 대기열
      팀 배정을 통한 비기술 기반 대기열
      에이전트 할당이 포함된 비기술 기반 대기열
    dropdown icon
    스킬 기반 대기열
      대기열에 할당된 기술 기준
      흐름도에 할당된 기술 요구 사항
    dropdown icon
    큐 구성
      기술 기반 대기열을 설정하세요
      기술 기반이 아닌 대기열을 설정하세요
dropdown icon
라우팅
    dropdown icon
    라우팅 개념
      에이전트 과잉 시나리오
      연락처 과잉 시나리오
      혼합된 멀티미디어 프로필
    dropdown icon
    라우팅 패턴
      기술 기반
      기술 기반이 아닌 라우팅
      에이전트 기반 라우팅
dropdown icon
Flow의 큐잉 및 라우팅 기능
    Flow의 큐잉 및 라우팅 기능
    dropdown icon
    대기열 활동
      대기열 연락처
      상담원 연결 대기열
      통화 분배 그룹 확대
    dropdown icon
    대기열 정보 활동
      대기열 정보 가져오기
      고급 대기열 정보
    dropdown icon
    통화 제어 활동
      발신자 번호 표시 설정
      녹화 제어
      블라인드 전송
      브리지드 트랜스퍼
      접점 분리
      연락처 우선순위 설정
    dropdown icon
    콜백 활동
      수신
      콜백 일정 예약
      통화 진행 분석
Webex Contact Center에서 라우팅 및 대기열 이해하기
list-menu이 문서에서
list-menu피드백이 있습니까?

이 문서에서는 Webex Contact Center가 문의를 처리하고 안내하는 방식에 대한 개요를 제공합니다. 에이전트로 들어오는 상호 작용. 이는 스킬 기반 대기열과 같은 다양한 유형의 대기열을 다룹니다. 기술 기반이 아닌 경로 설정 방식과 최장 가용 경로, 순환 경로, 최적 가용 경로 등의 경로 설정 방식이 있습니다. 또한 관리자가 상호 작용을 관리하고, 상담원을 할당하고, 제어하는 데 도움이 되는 흐름 활동에 대해서도 설명합니다. 통화 흐름을 파악하고 실시간 대기열 업데이트를 받아 운영 및 고객 만족도를 향상시키세요. 환경을 경험하십시오.

대기 중
만들기

개요

Webex Contact Center에서 대기열은 전화, 채팅, 이메일 또는 소셜 채널과 같은 들어오는 상호 작용을 위한 지주 영역으로 사용됩니다. 연락처는 에이전트에게 자동으로 배포되거나 에이전트에게 핸들링을 위해 수동으로 픽업할 때까지 대기열에 주차됩니다. 또한 기술 기반 라우팅, 우선 순위 관리 및 공정 워크로드 배포와 같은 기능을 지원합니다.

감독자는 큐를 사용하여 다양한 작업을 관찰하고 컨택 센터에서 작업을 처리하는 방법을 향상시킬 수 있습니다.

큐를 효과적으로 사용하는 주요 이점 중 일부는 다음과 같습니다.

  • 더 나은 고객 경험: 대기 시간을 관리하고 고객이 도움을 줄 수 있음을 알립니다.
  • 효율성 증대: 통화가 질서 있게 처리되도록 하여 혼돈과 오해를 줄입니다.
  • 연락처의 공정한 분포: 모든 단일 에이전트 과부하를 방지하기 위해 에이전트 간에 통화를 균등하게 배포합니다.
  • 우선 순위 처리: VIP 고객 또는 긴급한 문제와 같은 특정 통화의 우선순위를 정할 수 있습니다.

큐의 종류

Webex Contact Center는 동일한 기능을 가진 모든 미디어 유형에 걸쳐 모든 크기와 복잡성의 컨택 센터에 대한 다양한 사용 사례를 지원하는 여러 유형의 큐를 지원합니다.

연락처를 라우팅할 때 에이전트 기술을 고려하는 대기열이 있고 그렇지 않은 대기열이 있습니다. 이러한 대기열은 또한 에이전트가 연락처에서 작업하기 위해 어떻게 연관되어 있는지에 따라 다릅니다.

대기에는 두 가지 광범위한 범주가 있습니다.

  • 비기술 기반 큐
  • 기술 기반 큐

비기술 기반 큐

비기술 기반 대기열은 에이전트와 관련된 기술을 고려하지 않습니다. 다음 옵션으로 기술 기반 큐를 구성할 수 있습니다.

  • 팀 과제
  • 에이전트 지정

팀 할당이 있는 비기술 기반 큐

팀 할당과 함께 기술 기반 쿼리에서 에이전트를 팀으로 구성하고 이러한 팀을 결합하여 CDG(Call Distribution Group)를 구성할 수 있습니다. 통화 흐름을 관리하기 위해 각 그룹 간의 시간 지연을 설정할 수 있습니다.

Call Distribution Groups는 구성된 시간 간격을 통해 이 큐에서 연락처에서 작업할 자격이 되는 여러 수준의 에이전트를 정의하는 데 도움이 됩니다. 연락처는 팀의 수준에 따라 에이전트에게 할당됩니다. 에이전트가 없는 경우, 연락처는 다음 팀 그룹을 포함하도록 확장하기 전에 미리 구성된 기간 동안 주차됩니다. 이 과정은 에이전트를 사용할 수 있거나 모든 그룹이 확인될 때까지 계속됩니다.

다음과 같은 유형의 팀을 설정할 수 있습니다.

  • 개별 팀: 에이전트는 특정 조직 기능을 나타낼 수 있는 팀으로 구성될 수 있으며, 그런 다음 큐의 일부가 되어 이러한 팀의 에이전트로 연락처를 라우팅할 수 있습니다. 에이전트를 여러 팀에 태그하여 효율적인 라우팅을 위해 다양한 큐에서 연락처를 처리할 수 있습니다.
  • 용량 기반 팀: 용량 기반 팀(Capacity-based Team, CBT)은 음성 통화를 용량 기반 직접 번호(DN)로 지시하는 기능으로, 용량이 동시에 얼마나 많은 통화를 처리할 수 있는지를 결정합니다. 이 기능을 사용하면 에이전트가 시스템에 로그인할 필요 없이 전화 번호로 전화를 라우팅할 수 있으며, 전통적인 콜센터 에이전트가 아닌 음성 메일, 응답 기계 또는 사냥 그룹에 의해 응답되는 시나리오에 적합합니다. 이 설정에서는 팀에 지정된 특정 에이전트가 없으며 Webex Contact Center Agent Desktop을 사용하지 않습니다.

Webex Contact Center에서 팀 배정을 통한 비기술 기반 큐가 어떻게 작동하는지에 대한 워크플로우 다이어그램

이 예제에는 세 개의 콜 배포 그룹이 있으며, 이는 구성된 시간 간격에 걸쳐 팀간에 더 많은 에이전트로 확장하는 것을 의미합니다.

첫 번째 통화 배포 그룹은 TEAM을 포함합니다 1즉, Which has 3구성된 에이전트 – A1틀: A, A2그리고 A5...

두 번째 통화 분포 그룹에는 3 에이전트가 구성된 팀 2(A2, A3, 및 A4)가 포함됩니다.

세 번째(및 최종) 호출 분포 그룹에는 에이전트가 2 구성된 TEAM 3이 포함되어 있습니다 – A6 및 A7.

연락처가 대기열되면 시스템은 첫 번째 Call Distribution Group에서 일치하는 에이전트를 먼저 검색합니다. 에이전트가 발견되지 않으면, 다음 그룹으로 표적 확장을 만들기 전에 설정된 기간 동안 연락처를 주차한다. 이것은 기존 팀에 새로운 팀을 추가합니다. 이 과정은 일치하는 것을 발견하거나 모든 그룹이 확장될 때까지 반복됩니다.

'Check Agent Availability'라는 기능이 현재 그룹에서 일치하는 에이전트가 없는 경우 연락처가 후속 Call Distribution Group으로 즉시 확장됩니다. 이는 흐름에서 <3.1.1>항에 대한 Queue Contact 활동 내에서 활성화될 수 있습니다.

이 설정은 다음과 같은 시나리오를 수행합니다.

  1. A는 TEAM2 과 TEAM에 1 속한다2. A2 팀이 에이전트 데스크탑에 1 로그인하도록 선택하는 경우, 시스템은 TEAM의2 일부분을 1 고려하므로 첫 번째 콜 배포 그룹만 고려합니다.
  2. 그러나 A5는 TEAM 1에 속하며, 현재 로그인한 조직의 다른 팀의 일부일 수도 있습니다. 따라서 A5는 팀 1의 일부로 간주되지 않으며 이 대기열과 관련이 없습니다.

팀 할당이 있는 대기열은 에이전트가 로그인 중에 팀을 선택하여 대기열 사이를 이동할 수 있는 강력한 기능을 제공합니다.

사용 가능한 라우팅 패턴:

에이전트 배정이 있는 비기술 기반 큐

비기술 기반 큐는 에이전트 풀이 큐에 직접 할당되는 큐의 유형입니다. 그들에게 할당된 에이전트의 풀을 간접적으로 결정하는 다른 큐 유형과는 달리, 이러한 큐는 관리자가 직접 또는 수동으로 에이전트를 선택할 수 있게 한다. 예를 들어, 팀 기반 할당 큐는 로그인 팀을 기반으로 에이전트를 할당하고 기술 기반 할당 큐는 필요한 기술을 기반으로 에이전트를 일치시킵니다. 반면, 관리자는 이러한 큐에 에이전트를 직접 추가하여 큐의 일부가 될 수 있습니다. 이것은 시스템 기반 할당에 의존하지 않고 에이전트 할당을 관리하는 간단한 방법을 제공합니다.This provides a simple way to manage agent allocation without relying on system-driven assignments.

에이전트 할당이 있는 큐는 에이전트 풀 간의 연락처를 배포하는 데 도움이 되는 간단하면서도 효과적인 라우팅 알고리즘을 제공합니다.Queues with agent assignment provides simple but effective routing algorithms that help distribute contacts between agents pool. 그들은 연락처를 라우팅하는 에이전트의 기술을 고려하지 않습니다. 그러나 에이전트는 각 큐 내에서 주문할 수 있으며, 이는 연락처를 라우팅할 때 고려됩니다. 이러한 맥락에서, 팀은 주로 에이전트 큐 협회 및 연락처 라우팅 결정의 요인이 아닌 관리자를 위한 조직 구성으로 기능합니다.

이러한 유형의 대기열은 에이전트의 정적 할당과 에이전트-대기열 연관 관리가 운영 제어를 위해 실행 가능하고 바람직하며, 라우팅 알고리즘의 선택은 에이전트 간의 작업 분배에 적합하다. 이러한 큐는 또한 여러 유형의 고객 문의가 사전 생성된 전문 에이전트 세그먼트에 의해 제공 될 수있는 전문 전문 지식이 필요한 시나리오에 특히 유용합니다.

그러나 복잡한 접촉 센터 조직은 이러한 큐에서 에이전트 배정을 수동으로 관리하는 것이 어려울 수 있습니다. 동적 라우팅 및 에이전트 큐 연결을 제공하는 다른 큐 유형에서 더 많은 이점을 얻을 수 있습니다.

Webex Contact Center에서 에이전트 할당이 있는 비 기술 기반 큐 예제가 어떻게 작동하는지 보여주는 워크플로우 다이어그램

이 예에서, 꼬리는 A4, A9, A7등과 같은 특정 순서로 매핑된 에이전트 세트가 있습니다. 이 순서는 에이전트에 들어오는 연락처와 일치하는 특정 라우팅 알고리즘에서 역할을 합니다.This order plays a role in specific routing algorithms that match incoming contacts to agents. 시스템은 가용성 및 선택한 라우팅 알고리즘에 따라 이러한 에이전트와의 연락처와 일치합니다.

팀 할당이 있는 대기와는 달리 시간 간격에 따른 목표 확장의 개념은 없다. 설정된 에이전트가 이 연락처를 라우팅할 수 없는 경우, 공원 시간 초과 전에 연락처를 처리할 수 있도록 이러한 에이전트 중 하나가 사용할 수 있을 때까지 대기열에 주차한다. 대상 확장은 이러한 대기에는 적용되지 않습니다.

사용 가능한 라우팅 패턴:

기술 기반 큐

기술 기반 대기열은 연락처가 적절한 기술을 가진 에이전트에게 라우팅될 수 있는 능력을 제공합니다.

다음 유형의 기술 기반 옵션을 구성할 수 있습니다.

큐에 할당된 기술 기준

관리자는 큐에 기술 기준을 할당할 수 있습니다. 기술 기준이 있는 기술 기반 큐를 통해 관리자는 큐에서 필요한 기술을 직접 구성할 수 있습니다. 직속 기술 프로필을 통해 대기열에 필요한 모든 기술을 가진 조직의 모든 에이전트는 암묵적으로 이 대기열의 일부가 됩니다.

이 설정을 사용하면 관리자가 기술 덕택에 큐에 에이전트를 매핑하는 라이브 뷰를 가질 수 있습니다. 높은 볼륨 또는 낮은 볼륨과 같은 상황에서, 관리자는 필요에 따라 에이전트 풀을 확장하거나 축소하기 위해 큐 및 에이전트 스킬 프로파일의 필요한 기술을 조정하는 것을 고려할 수 있습니다.

이 유형의 큐는 팀 할당 기반 큐와 다릅니다. 콜 배포 그룹 설정이 없으므로 팀이 큐에 관련된 에이전트에서 역할이 없음을 의미합니다. 또한, 필요한 기술은 팀 기반 스킬 큐와 달리 이 큐에서 정적으로 구성됩니다 (정적 또는 변수) 필요한 기술을 주입하는 팀 기반 스킬 큐와 달리. 따라서 기술적으로 기술은 접촉 자체가 아니라 대기열의 일부이다.

큐의 기술 기준을 완전히 충족하는 조직의 모든 에이전트(직속 기술 프로파일에서 기술을 갖는 것)는 암시적으로 이 큐와 연관된다. 팀은 이러한 대기열과 에이전트 관계에서 어떠한 역할도 하지 않습니다. 이러한 에이전트는 관리 및 운영 목적을 위해 모든 팀의 일부가 될 수 있습니다.

이 대기열에 있는 모든 연락처는 대기열 자체에 정의된 기술 기준을 자동으로 가정합니다. 개별 연락처는 팀 할당과 함께 기술 기반 대기열과 달리 자신의 기술 요구 사항/기준을 정의하거나 재정의할 수 없습니다.

Webex Contact Center에서 기술 기준과 기술 기반 큐가 어떻게 작동하는지 보여주는 워크플로우 다이어그램

이 예에서,

  • 에이전트 A1, A3 및 A7만 대기열에 구성된 기술 기준을 완전히 충족하므로 이러한 에이전트만 이 대기열에 관련될 것입니다.
  • 기준을 부분적으로 충족하는 에이전트 A2, A4 및 A6 또는 관련 기술이 부족한 A5는 이 대기열과 관련될 수 없습니다.

큐의 기술 기준을 충족하도록 에이전트의 스킬 프로파일(reskilling)을 업데이트하면 해당 에이전트가 이 큐의 일부가 됩니다. 또한, 더 많은 (또는 더 적은) 에이전트가 업데이트된 기술 기준을 충족하도록 큐 기술 기준 자체를 업데이트하면 이 큐에서 에이전트를 자동으로 및 동적으로 추가 (또는 제거합니다).

팀 할당이 있는 대기와는 달리 시간 간격에 따른 목표 확장의 개념은 없다. 연락처가 관련 에이전트와 일치할 수 없는 경우, 공원 시간 초과 전에 연락처를 처리할 수 있도록 이러한 에이전트 중 하나가 사용할 수 있을 때까지 대기열에 주차됩니다.

기술 기반 큐는 에이전트 협회에 대한 기술 및 큐의 관리가 실현 가능하고 운영 제어를 위해 바람직할 때 가장 적합합니다. 또한 라우팅 알고리즘의 선택이 에이전트 간의 작업 분배에 적합할 때 적합합니다. 이러한 큐는 또한 다양한 유형의 고객 문의가 사전 유래 된 전문 에이전트의 세그먼트에 의해 제공 될 수있는 특정 기술을 필요로하는 시나리오에 특히 유용합니다.

복잡한 컨택 센터 조직은 각 에이전트가 수동으로 목록에 추가되어야 하는 에이전트 할당 큐와 비교하여 기술 기반 큐에서 에이전트 할당 큐를 더 쉽게 관리할 수 있으며, 이는 특히 더 큰 조직의 경우 까다로운 일입니다.

흐름에서 할당된 기술 요구 사항

흐름에 할당된 기술 요구 사항이 있는 기술 기반 큐는 Webex Contact Center의 팀 할당 기반 큐의 한 유형으로, Call Distribution Groups라고 합니다. 이러한 구성된 팀에 로그인된 에이전트는 또한 연락처의 기술 요구 사항을 완전히 충족하는 경우 팀이 대기열에 구성되는 통화 배포 그룹 수준에 따라 이 대기열에 있는 연락처를 할당합니다.

이러한 큐 내에서 에이전트 팀은 서로 구성 가능한 시간 지연으로 콜 배포 그룹으로 그룹화됩니다.Within such queue, agent teams are grouped into Call Distribution Groups with configurable time delay between them. 연락처에 에이전트가 없는 경우 요청이 주차되고 지연 후 라우팅은 다음 Call Distribution Group으로 확장됩니다. 이 과정은 에이전트가 배정되거나 모든 그룹이 소진될 때까지 계속됩니다. 한편, 이전에 확인된 그룹의 에이전트가 이 프로세스 중에 사용할 수 있게 되면 해당 에이전트가 선택됩니다.

에이전트는 에이전트에 직접 할당된 기술 프로필을 통해 기술을 습득합니다. 에이전트 기술은 가입 시 팀 선택에 따라 결정됩니다.

각 연락처는 가장 적합한 에이전트를 선택하는 데 사용할 수 있는 에이전트의 기술과 일치하는 흐름의 기술 요구 사항을 선택적으로 지정할 수 있습니다.

또한, 연락처는 설정된 시간 간격에서 기술 이완을 지정할 수도 있습니다. 이것들은 설정된 시간 간격으로 연락처의 원래 기술 요구 사항을 덮어쓰는 기술 요구 사항의 수정된 세트입니다. 이를 통해 연락처는 대기열에 주차하는 동안 기술 요구 사항을 수정하여 더 많은 에이전트가 이러한 이완된 기술 요구 사항과 일치할 수 있도록 합니다.

Call Distribution Groups를 통한 목표 확장은 기술 이완 사이클과 동시에 발생할 수 있습니다. 이는 모두 적격한 에이전트와 주차된 접촉을 더 빨리 일치시키는 것을 목표로 하여 전체 대기 시간을 줄이고 대기열의 서비스 수준을 향상시킵니다.

Webex Contact Center에서 팀 배정을 통한 기술 기반 큐가 어떻게 작동하는지 보여주는 워크플로우 다이어그램.

팀 할당이 있는 비숙련 된 대기처럼, 그것은 "목표 확장" 즉, 구성된 시간 간격에 걸쳐 팀간에 더 많은 에이전트로 확장할 수 있는 세 개의 콜 배포 그룹을 가지고 있다.

  • 첫 번째 통화 배포 그룹에는 TEAM이 포함됩니다. 1즉, Which has 3구성된 에이전트 – A1틀: A, A2그리고 A5...
  • 두 번째 통화 분포 그룹에는 3 에이전트가 구성된 팀 2(A2, A3, 및 A4)가 포함됩니다.
  • 세 번째(및 최종) 호출 분포 그룹에는 에이전트가 2 구성된 TEAM 3이 포함되어 있습니다 – A6 및 A7.

그러나 주목해야 할 중요한 두 가지가 있습니다.

  • 이 대기열에 도달하는 모든 접촉은 흐름을 통해 기술 요구 사항과 기술 이완을 정의합니다.
  • 에이전트는 기술을 구성할 수 있습니다(기술 프로파일을 통해 – 직접 또는 로그인한 팀에서 상속됨).

A2는 TEAM 1 및 TEAM 2의 일부로 구성되지만, 로그인 중에 이 에이전트가 만든 팀에 따라 현재 세션에서 해당 팀의 일부로 간주되며, 따라서 해당 팀에서 스킬 프로파일(그리고 스킬 값)을 상속합니다(이 에이전트에 대한 직접 스킬 프로파일 구성으로 재정의되지 않는 한).

이것은 팀 할당이 있는 대기열에 의해 제공되는 강력한 기능입니다. 여기서 에이전트는 단순히 로그인 중에 팀을 선택하여 대기열 사이를 이동할 수 있습니다.

선택한 팀에서 스킬 프로파일 설정을 상속할 수 있는 능력과 함께, 에이전트는 다른 스킬 세트와 함께 작업할 수 있습니다.

이 예에서,

  • 연락처는 초기 기술 요구 사항(sk_1 >= 6)과 설정된 시간 간격 후 기술 이완(sk_1 >= 3)으로 대기됩니다.
  • 모든 호출 분포군의 모든 에이전트에는 대기된 연락처의 초기 기술 요구 사항을 충족하는 기술이 있는 A1, A3, A6 및 A7만 있습니다.
  • 나머지 에이전트는 기술(sk_1)을 가지고 있지만 기술 요구 사항을 충족시키지 못하거나(예: A2 in TEAM 1 및 A4 in TEAM 2), 또는 전혀 이 기술을 가지고 있지 않습니다(예: A5, A2 in TEAM 2).
  • 시간이 지남에 따라 기술 이완에 따라 A2 및 A4는 또한 접촉의 "편안한" 기술 요구 사항을 충족시킵니다.

이 대기열에 있는 모든 연락처에 대해, 시스템은 접촉의 현재 기술 요구 사항을 완전히 충족하는 첫 번째 통화 분포 그룹 내에서 일치하는 에이전트를 찾으려고 시도합니다. 일치하는 에이전트가 발견되지 않으면 대상 확장이 두 번째 통화 분포 그룹에 발생하기 전에 설정된 기간 동안 연락처가 주차됩니다.If no matching agent is found, the contact is parked for the configured duration before the target expansion occurs to the second call distribution group. 두 번째 통화 분포 그룹에 구성된 모든 팀은 첫 번째 그룹의 기존 팀에 추가됩니다. 이제 시스템은 확장된 그룹 내에서 일치하는 에이전트를 찾으려고 시도합니다. 이 일이 일어나는 동안 기술 이완은 또한 구성된 시간 간격으로 연락처의 기술 요구 사항을 업데이트하고 시스템은 업데이트 된 기술 요구 사항을 사용하여 현재 통화 분포 그룹의 사용 가능한 에이전트와 일치합니다.

이는 모든 구성된 호출 분포 그룹이 확장되고 이전에 일치하는 에이전트가 발견되지 않는 한 모든 기술 이완이 적용될 때까지 계속됩니다.

사용 가능한 라우팅 패턴:

큐 설정

기술 기반 큐 설정

큐에 기술 기준 지정
  • 기술을 만들고, 필요한 경우 동적 기술을 만듭니다.
  • 생성 스킬 프로파일...
  • 에이전트에게 스킬 프로파일을 직접 할당합니다.
  • 에이전트에게 다이나믹 스킬을 직접 할당합니다. 동적 기술은 기술 프로파일을 통해 할당되지 않습니다.
  • 전화 또는 채팅 또는 이메일 또는 소셜 채널 유형으로 큐를 생성합니다.
  • Control Hub의 대기열에 기술 및 동적 기술 요구 사항을 할당합니다.Assign skills and dynamic skills requirements to queues in Control Hub.
  • 대기열에 있는 연락처를 처리할 수 있는 에이전트 목록을 봅니다.
  • 라우팅 알고리즘 LAA 또는 BAA를 선택합니다. BAA의 경우, 필요한 경우 능숙도 기술 및 능숙도 동적 기술에 대한 가중치를 구성합니다.
  • 흐름에서 Queue Contact 활동을 추가하고 이 큐를 선택합니다.
큐에 기술 요구 사항 지정
  1. 기술을 만들고, 필요한 경우 동적 기술을 만듭니다.
  2. 생성 스킬 프로파일...
  3. Skill 프로필을 에이전트 또는 팀에 직접 할당합니다.
  4. 에이전트에게 다이나믹 스킬을 직접 할당합니다. 동적 기술은 기술 프로파일을 통해 할당되지 않습니다.
  5. 생성하기 ...
  6. 팀에 에이전트를 추가하십시오.
  7. 전화 또는 채팅 또는 이메일 또는 소셜 채널 유형으로 큐를 만듭니다.
  8. 단일 CDG 또는 여러 CDG에서 큐에 팀을 추가합니다.
  9. LAA 또는 BAA 라우팅 패턴을 선택합니다.
  10. 흐름에서 Queue Contact 활동을 추가하고 Skills-Based Routing이 구성되는 큐를 선택합니다. 자세한 내용은 다음을 참조하십시오. 꼬리 연락처...
  11. Queue Contact 활동에서 기술, 동적 기술 및 기술 이완을 할당합니다. BAA의 경우, 필요한 경우 능숙도 기술 및 능숙도 동적 기술에 대한 가중치를 구성합니다.
  12. 다음 통화 배포 그룹 또는 마지막 통화 배포 그룹으로 빠르게 이동하려면 대기열에 있는 통화 배포 활동을 확장합니다.

비 기술 기반 큐 설정

큐에 팀 할당하기
  • 생성하기 ...
  • 팀에 에이전트를 추가하십시오.
  • 전화 또는 채팅 또는 이메일 또는 소셜 채널 유형으로 큐를 만듭니다.
  • 단일 CDG 또는 여러 CDG에서 큐에 팀을 추가합니다.
  • LAA 중 라우팅 패턴을 선택합니다.
  • 흐름에서 Queue Contact 활동을 추가하고 이 큐를 선택합니다.
  • 다음 통화 배포 그룹 또는 마지막 통화 배포 그룹으로 빠르게 이동하려면 대기열에 있는 통화 배포 활동을 확장합니다.
큐 흐름에 에이전트 지정
  • 전화 또는 채팅 또는 이메일 또는 소셜 채널 유형으로 큐를 만듭니다.
  • 큐에 에이전트를 직접 추가합니다(참고: 기술이나 팀은 이 유형의 대기열에 사용되지 않습니다.)
  • Circular 또는 Linear 또는 Longest Available 에이전트와 같은 라우팅 패턴을 선택합니다.
만들기
라우팅
만들기

라우팅 개념

에이전트 과잉 시나리오

에이전트 잉여 시나리오는 대기열에 있는 연락처보다 더 많은 사용 가능한 에이전트가 있을 때 발생합니다. 이 경우, 고객 상호 작용(접촉)이 대기될 때, 시스템은 이 특정 연락처에 대한 일치하는 에이전트를 즉시 찾으려고 시도하고, 일치하는 에이전트가 발견되는 경우, 연락처를 대기열에 주차하고 나중에 일치하는 에이전트가 제공될 때까지 기다릴 필요가 없습니다.

연락처가 Call Distribution Group을 통해 또는 기술 이완을 통해 확장을 겪을 때마다, 시스템은 이 특정 연락처에 대한 일치하는 에이전트를 즉시 찾으려고 다시 시도합니다.

특정 연락처에 대한 매칭 에이전트를 찾는 것은 큐에서 구성된 라우팅 패턴을 사용합니다.Finding a matching agent for a specific contact uses the configured routing pattern in the queue.

Webex Contact Center는 다양한 유형의 대기열에 걸쳐 여러 라우팅 패턴을 제공하여 조직이 대기 시간을 최소화하고 에이전트 워크로드의 균형을 맞추며 고객이 특정 요구 사항을 충족하는 데 필요한 기술을 가진 에이전트와 연결되도록 함으로써 고객 서비스를 최적화할 수 있습니다. 라우팅 패턴에 대한 자세한 정보는 라우팅 패턴 섹션을 참조하십시오.

Contact Surplus 시나리오

Contact Surplus 라우팅은 들어오는 고객 상호 작용(또는 연락처)의 수가 사용 가능한 에이전트를 초과할 때 발생합니다. 이 상황은 종종 피크 시간 또는 접촉 부피의 예상치 못한 파동 중에 발생합니다. 접촉 잉여 라우팅의 주요 목표는 이러한 오버플로를 효율적으로 관리하여 과도한 수요에도 불구하고 고객 서비스 표준이 유지되도록 하는 것입니다. 특정 채널에서 사용할 수 있게 된 에이전트의 경우, 접촉 잉여 라우팅은 이 에이전트와 관련된 모든 대기열에 있는 모든 연락처들 중에서 적절한 연락처를 찾고 할당합니다.

제한된 에이전트 가용성을 사용하여 효율적으로 연락처 라우팅을 수행하는 주요 전략은 다음과 같습니다.

  • 큐 랭킹

    큐 순위를 사용하면 관리자가 큐의 상대적 중요성을 지정할 수 있습니다.Queue ranking enables administrators to specify the relative importance of queues. 관리자는 큐 랭킹을 정의하여 각 팀별로 팀별로 호출이 대기로부터 팀으로 로그인한 에이전트로 라우팅되는 순서를 설정할 수 있습니다.

    예를 들어, 팀 A에 로그인된 에이전트가 "청구"와 "판매"라는 두 개의 대기열과 관련이 있다고 생각해 보십시오. 관리자는 대기열 순위를 사용하여 "청구" 대기열에 더 높은 순위를 지정할 수 있으므로 연락처가 대기열에 들어올 때 "청구"의 연락처는 "판매" 대기열에 있는 연락처보다 팀 A의 에이전트로 라우팅됩니다. "Billing" queue가 "Sales" queue보다 높은 queue 순위가 있기 때문에 "Billing" queue가 "Sales" queue보다 높은 queue 순위가 있기 때문에 "Sales" queue가 기다릴 수 있습니다. "청구" 대기열에 더 이상 대기 연락처가 없는 경우에만, 팀 A의 에이전트는 "판매"(및 기타) 대기열에 있는 연락처로 라우팅됩니다.

    다음은 큐 순위의 중요한 특성 중 일부입니다.

      • 순위가 일부 대기에만 할당되는 경우, 해당 대기에서의 호출은 순위가 지정되지 않은 대기에서의 호출보다 우선합니다.If a rank is assigned to only some of the queues, those queues in the calls that no rank is specified.
      • 큐 랭킹은 모든 미디어 유형에 걸쳐 최대 50 큐로 설정될 수 있으며 1 및 501의 값이 가장 높은 순위입니다.
      • 동일한 순위를 여러 큐에 할당할 수 있습니다.
      • 큐 랭킹을 사용하도록 설정하면 명시적인 랭킹이 할당되지 않은 큐는 모든 랭킹된 큐보다 낮게 처리됩니다.
      • Queue Ranking은 동일한 미디어 유형에서 작동합니다.

        예를 들어, Queue Sale이 순위가 2 있는 음성 미디어 유형 대기이고 Queue Billing Support가 Team A에 대한 1 순위가 있는 채팅 대기인 경우, Team A의 음성 채널에서 사용할 수 있는 에이전트는 2순위가 있더라도 음성 통화를 먼저 받습니다.

        그러나 Team B - 큐 랭킹이 있는 큐 신용 카드 2 및 큐 랭킹이 있는 큐 직불 카드 1에 대한 두 개의 채팅 큐를 고려하십시오. 그런 다음 Team B에서 이용 가능한 에이전트가 Queue Debit Card에서 먼저 연락처를 제공합니다.

      • 대기열 순위는 용량 기반 팀에는 적용되지 않습니다.

  • 연락처 우선 순위

    연락처가 대기될 때, 우선 순위는 1(가장 높은)부터 10(가장 낮은, 기본값)까지 범위의 계층 적 중요성을 지정함으로써 정의될 수 있습니다. 이 우선 순위를 지정하면 특정 연락처가 조직의 중요성, 긴급성 또는 전략적 가치에 따라 더 빠르게 처리됩니다. 에이전트가 에이전트와 관련된 모든 대기열에 대해 주차된 모든 연락처 중 다음 연락처를 처리할 수 있는 경우, 모든 대기열에 대한 가장 높은 우선 연락처가 에이전트로 라우팅됩니다(기술 매칭 및 기타 기준이 충족되는 경우).

    명시적 우선 순위가 없는 대기중인 연락처의 경우, 10(최저)의 기본 우선 순위가 고려됩니다. 동일한 우선 순위가 있는 여러 연락처들 중에서 가장 긴 기간 동안 대기하는 연락처는 먼저 이용 가능하고 적합한 에이전트에게 라우팅됩니다.

  • 가장 긴 대기 연락처

    이것은 에이전트가 관련된 모든 큐에서 가장 긴 대기 접촉이 에이전트로 라우팅되도록 보장하는 기본 전략입니다.

    이것은 동일한 큐 랭킹과 동일한 연락처 우선 순위가 있는 큐에 걸쳐 여러 연락처가 처리될 때 연락처를 라우팅하도록 결정하는 궁극적인 기준입니다.This is the ultimate criterion that determines the contact to be routed when multiple contacts across queue with the same queue rank and the same contact priority are waiting to be processed.

본질적으로, 방금 사용 가능하게 된 에이전트에 대한 접촉 잉여 라우팅은 다음과 같은 단일 연락처를 선택하는 것을 의미합니다.

  • 에이전트가 사용할 수 있는 미디어 유형과 동일하다
  • 이 에이전트와 관련된 대기열 중 하나에 주차되어 있습니다.
  • 기술 요구 사항(있는 경우)이 모두 이 에이전트에 의해 충족됩니다.
  • 에이전트 팀에서 구성된 다른 대기보다 순위가 높은 대기열에 주차한다.
  • 이러한 모든 연락처들 중에서 가장 높은 우선순위를 가지고 있다.
  • 같은 우선 순위가 있는 연락처들 사이에서 가장 오래된 대기중인 연락처입니다.

연락처 과잉 시나리오를 보여주는 위의 예에서, 에이전트 A1가 TEAM 1에 로그인되어 여러 미디어 유형에 대한 연락처를 처리할 수 있게 되었습니다.

A1는 3 큐(Q1, Q2Q3와 관련이 있습니다. TEAM은 1또한 queue 랭킹을 정의했습니다. Q (음악)1가장 높은 순위에 올랐으며, Q (음악)2그리고 Q (음악)3각각.

이 모든 대기에는 이미 연락처가 주차되어 있으며, 각 연락처에 대한 기술 요구 사항과 우선 순위가 정의되어 있습니다.

이제 접촉 잉여의 시나리오는 다음과 같이 작동합니다.

  • 이 대기열을 가로질러 주차된 모든 연락처들 중에서 4연락처를 라우팅할 수 있습니다. A (축구 선수)1분류: C2,분류: C7(Queue에서) 2) 및 분류: C3,분류: C8(Queue에서) 3).

    이러한 접촉의 기술 요구 사항만 4 전적으로 A1의 기술에 의해 충족됩니다.

  • 이러한 4 연락처들 중에서, QUEUE의 QUEUE 2 (즉, C2, C7)의 2 연락처에게 우선 순위가 주어진다.

    QUEUE가 가장 높은 순위의 1 대기열이지만, 그들의 기술 요구 사항이 A에 의해 충족되지 않기 때문에 주차된 연락처는 A로1 라우팅될 수 없습니다1.

  • 사이 분류: C2그리고 분류: C7가장 높은 우선 순위 연락처는 분류: C7... 마지막 선택은 C입니다7, 그리고 시스템은 그것을 A입니다1.

    이것은 C2 가 더 일찍 대기했음에도 불구하고, 접촉 우선 순위가 대기된 시간보다 우선하기 때문이다.

혼합된 멀티미디어 프로필

멀티미디어 프로필 구성을 통해 Webex Contact Center는 에이전트가 다양한 미디어 유형(음성, 채팅, 이메일 및 소셜)에 걸쳐 연락처를 제공할 수 있도록 합니다. 이 구성에 따라 에이전트는 미디어 유형별로 프로비저닝된 채널을 얻습니다.

에이전트에 라우팅된 모든 연락처는 에이전트가 해당 연락처에서 작업하는 한 해당 미디어 유형의 채널을 소비합니다. 에이전트는 하나의 음성 채널만 가질 수 있지만 다른 미디어 유형으로 최대 5개의 채널을 가질 수 있습니다.

멀티미디어 프로필의 블렌드 라우팅 설정을 통해 관리자는 각 에이전트에 대해 서로 다른 채널을 동시에 사용할 수 있는 방법을 제어할 수 있습니다. 이를 통해 조직은 고객에게 헌신적 인 관심을 제공하고 서비스 품질을 높이고 고객 경험을 개선하며 전환율을 높일 수 있습니다. 또한, 조직은 일부 채널에서 고르지 않은 부하를 경험할 때 미디어 채널에 걸쳐 부하를 균형을 맞출 수 있어 에이전트를 효율적으로 활용할 수 있습니다.

세 가지 선택이 있습니다.

  • 배타적

  • 혼합

  • 실시간 혼합

비음성 연락처를 처리할 때, 에이전트는 음성 채널을 사용할 수 있는 한 에이전트 데스크탑에서 수동 외부 음성 통화를 시작할 수 있습니다. 이것은 모든 멀티미디어 프로필 유형에 적용됩니다.

멀티미디어 프로필 구성에 대한 자세한 내용은 다음을 참조하십시오. 멀티미디어 프로필 관리...

라우팅 패턴

기술 기반

Webex Contact Center의 기술 기반 라우팅 패턴은 언어 능력 또는 기술 전문 지식과 같은 질문을 해결하는 데 필요한 특정 기술을 기반으로 에이전트와 직접 수신 고객 상호 작용합니다. 이러한 패턴은 각 고객이 가장 자격을 갖춘 에이전트와 연결하여 서비스 효율성과 고객 만족도를 향상시킵니다. 이러한 혜택에는 처리 시간 감소, 해상도 향상, 고객 요구와 전문성을 조정하여 에이전트 리소스의 최적화된 사용이 포함됩니다.

기술 기반 라우팅은 에이전트가 기술 프로필에서 받는 기술 및 에이전트에 직접 할당되는 동적 기술을 사용할 수 있습니다. 동적 스킬은 에이전트의 스킬 프로필과 독립적으로 변경할 수 있는 에이전트 속성을 나타냅니다.Dynamic Skills represents agent attributes that can change independently of an agent's skill profile.

기술 기반 라우팅 패턴이 사용될 때, 먼저 접촉의 기술 요구 사항(흐름에 할당됨) 또는 큐에 할당된 기술 기준이 기술 및 동적 기술이 이러한 요구 사항/기준을 완전히 충족하는 사용 가능한 에이전트를 필터링하는 데 사용됩니다. 그런 다음 필터링되는 에이전트 중에서 구성된 라우팅 패턴에 따라 연락처에 대해 단일 하나가 선택됩니다.Then, among agents that are filtered, one one is selected for the contact based on the routing pattern configured.

최고의 사용 가능한 라우팅의 경우 능숙도 기술 및 능숙도 동적 기술은 에이전트 선택에 사용되는 점수에 영향을 미치기 위해 가중치를 사용할 수도 있습니다. 가중치는 사용 가능한 가장 긴 라우팅에 영향을 미치지 않습니다. 이 패턴은 에이전트 적합성을 결정하기 위해 기술과 동적 기술을 사용합니다.

최장 사용 가능

가장 긴 사용 가능한 기술 기반 라우팅 패턴은 그 기술이 접촉 기술 요구 사항 / 큐 기술 기준을 완전히 충족하고, 그 큐에서 모든 자격 있는 에이전트 중 마지막 접촉을 처리 한 이후 가장 긴 사용할 수 있는 에이전트에 대한 접촉을 라우팅합니다.

이 라우팅 패턴은 가장 오랫동안 사용 가능한 사람들에게 상호 작용을 할당하여 작업 부하 불균형을 방지함으로써 에이전트 간에 작업을 균등하게 분배하는 데 도움이 됩니다. 이는 업무 분배의 공정성을 유지하는 데 도움이 되며, 다른 사람들이 자유로워지는 동안 어떤 에이전트도 과부하가 없도록 보장한다.

위의 예에서, 능숙도 스킬이 다양한 능숙도 스킬이 있는 4 에이전트가 있습니다.

"Longest Available" 라우팅 패턴이 있는 기술 기반 대기열에 있는 연락처를 고려하십시오.

  • 상기 기술 요구 사항을 flow를 통해 할당하는 경우, 또는
  • 기술 기반 큐에서 위의 기술 기준이 구성되는 경우

이 시나리오에서는:

  • 연락처 기술 요구 사항 / 큐 기술 기준을 완전히 충족하는 에이전트만 라우팅에 대해 고려됩니다. 에이전트 A1, A2A4 만이 접촉 기술 요구 사항/큐 기술 기준을 전적으로 충족합니다.

    에이전트 A는3 자격이 없습니다. In the case of 큐에 할당된 기술 기준,A (축구 선수)3Queue와 관련이 없습니다.

  • 다음 중 A (축구 선수)1,A (축구 선수)2그리고 A (축구 선수)4연락처는 가장 긴 사용 가능한 에이전트로 라우팅됩니다 – A1지금까지 이용 가능했던 사람 10분, A보다 긴2또는 A4...

    연락처에 A1 가 할당됨에 따라, A1는 더 이상 모든 미디어 채널에서 사용할 수 있는 가장 긴 에이전트가 되지 않는다.

  • 동일한 기술 요구 사항에 대한 다음 연락처는 다음 가장 긴 사용 가능한 에이전트 인 A2로 라우팅됩니다.

이 라우팅 패턴은 다음 유형의 기술 기반 큐에서 지원됩니다.

최저가 제공

최상의 기술 기반 라우팅 패턴은 고객 상호 작용이 가능한 가장 자격을 갖춘 에이전트에게 전달되도록 보장합니다. 이 패턴은 에이전트 사이에 필요한 기술의 존재뿐만 아니라 이러한 기술의 능숙도 수준을 평가하여 각 접촉에 대해 가장 자격을 갖춘("최고") 에이전트를 결정하기 위해 기술 점수를 계산합니다.

이 패턴 필터는 기술이 접촉 기술 요구 사항 / 큐 기술 기준을 완전히 충족하는 사용 가능한 에이전트를 필터링합니다. 그런 다음, 접촉 기술 요구 사항 / 큐 기술 기준에 언급 된 모든 기술의 능숙도 값을 사용하여 각 적합한 에이전트에 대한 점수를 계산합니다. 기술 점수가 가장 높은 에이전트는 각 접촉에 대해 "최고의" 에이전트로 간주됩니다.

효과적으로, 접촉 기술 요구 사항 / 큐 기술 기준과 일치하는 에이전트의 기술 값의 합계가 점수를 결정합니다.

이해해야 할 몇 가지 핵심 사항:

  • 일반적으로 실제 스킬 값은 점수 계산에 사용됩니다. 왜냐하면 스킬 점수가 더 높은 스킬 점수가 더 강한 매치를 나타내기 때문입니다. 기술 요구 사항이 보다 적은(<=) 조건을 사용하는 경우를 제외하고, 에이전트의 특정 기술 값은 점수 계산에 반전됩니다. 즉, effective_skill_value = (10) minus (actual_skill_value). 이것은 낮은 점수가 더 강한 경기를 나타낼 수 있도록 하기 위해 수행됩니다.
  • 자격 있는 여러 에이전트가 동일한 점수가 있는 경우, 그 중 가장 긴 에이전트가 선택됩니다.
  • 능숙도 기술만 점수 계산에 고려됩니다. 접촉 기술 요구 사항 / 큐 기술 기준의 불리언, 텍스트 또는 엔넘 스킬은 점수 계산에 고려되지 않습니다.

위의 예에서, 능숙도 스킬이 다양한 능숙도 스킬이 있는 네 명의 에이전트가 있습니다.

"Best Available" 라우팅 패턴이 있는 기술 기반 대기열에 있는 연락처를 고려하십시오.

  • 상기 기술 요구 사항을 flow를 통해 할당하는 경우, 또는
  • 상기 기술 기준은 기술 기반 대기열에 구성됩니다.

이 시나리오에서는:

  • 연락처 기술 요구 사항 / 큐 기술 기준을 완전히 충족하는 에이전트만 라우팅에 대해 고려됩니다. 에이전트 A1, A2A4 만이 접촉 기술 요구 사항/큐 기술 기준을 전적으로 충족합니다.

    에이전트 A는3 자격이 없습니다. In the case of 큐에 할당된 기술 기준,A (축구 선수)3Queue와 관련이 없습니다.

  • A1, A2A4 중 점수 계산은 전문 기술만 고려되는 접촉 기술 요구 사항 / 큐 기술 기준을 기반으로 시스템에 의해 수행됩니다.

    연락처 기술 요구 사항 / 큐 기술 기준에서 언급 한 기술만 점수 계산에 고려됩니다, 에이전트는 추가 / 다른 능력 기술을 가질 수 있습니다.

    또한 (<=) 조건이 사용되는 경우 점수 계산에서 기술 값의 역전형을 주의하십시오.

  • 점수에 따라 가장 적합한 에이전트이기 때문에2 연락처는 A로 라우팅됩니다. 만약 A가2 사용 가능하지 않거나 바쁘다면, 연락처는 두 번째로 높은 점수를 받은 다음 가장 적합한 에이전트로 라우팅됩니다.

    그러나 다음 최고 점수가 2 있는 A1A4 에이전트가 있습니다. 접촉은 A1A4 사이의 가장 긴 사용 가능한 에이전트로 라우팅됩니다.

이 라우팅 패턴은 다음 유형의 기술 기반 큐에서 지원됩니다.

비기술 기반 라우팅

또한 Webex Contact Center는 에이전트의 특정 기술 또는 전문 지식을 고려하지 않고 들어오는 고객 상호 작용을 배포하는 데 중점을 둔 다양한 비기술 기반 라우팅 패턴을 지원합니다. 기술 기반 라우팅 패턴과 달리 에이전트 기술을 고려하거나 라우팅에 대한 기술 요구 사항 / 기준을 정의하기 위해 연락처 또는 큐를 필요로하지 않습니다. 오히려 가용성, 워크로드 배포 및 미리 정의된 시퀀스와 같은 요인을 우선시하여 개별 에이전트 역량이 아닌 운영 논리에 기반한 연락처를 효율적으로 처리할 수 있습니다. 이러한 패턴은 상호 작용이 상대적으로 균일하거나 특별한 취급이 필요하지 않은 환경에서 특히 유용합니다.

최장 사용 가능

가장 긴 사용 가능한 라우팅 패턴은 사용 가능한 모든 에이전트에 대한 마지막 접촉을 처리한 이후 가장 긴 사용 가능한 대기열에 있는 해당 에이전트에 대한 접촉을 라우팅합니다.The Longest Available routing pattern routes a contact to that agent in the queue that agent who has been handling their last contact across all agents that are available and associated with that queue.

이 라우팅 패턴은 가장 오랫동안 유휴 상태였던 에이전트에게 상호 작용을 할당함으로써 공정하고 균형 잡힌 워크로드 분포를 보장합니다. 워크로드 불균형을 방지함으로써 어떤 에이전트도 과부하가 되지 않도록 합니다. 이 접근법은 안정적인 접촉 흐름의 기간 동안 특히 효과적이며, 에이전트 풀 전반에 걸쳐 일관된 참여를 유지한다.

에이전트는 모든 미디어 유형에 대한 접촉을 제공받을 때 모든 채널에서 "가장 오래 사용할 수 있는" 위치를 잃습니다. 이것은 에이전트가 접촉을 처리한 후에, 모든 미디어 유형 대기열의 다음 연락처가 해당 대기열에 있는 다음 가장 긴 사용 가능한 에이전트에 할당된다는 것을 의미합니다.

위의 예에서, 에이전트 A1 는 사용 가능한 가장 긴 에이전트(위치 1)입니다. 이 에이전트가 먼저 로그인한 상태이거나 다른 에이전트보다 더 긴 연락처를 할당하지 않았습니다.

에이전트 A2 (위치 2)와 A3 (위치 3)도 사용할 수 있지만, A1 후에 로그인했거나 연락처를 처리했습니다. 모든 에이전트는 이 라우팅 패턴을 갖는 두 개의 대기열과 관련이 있습니다.

다음 시나리오를 고려하십시오.

  • 시간 T0, 음성 접촉 C1을 대기하고 가장 긴 에이전트, 즉, A1로 라우팅한다.

    By Virtue의 A (축구 선수)1할당되는 중 분류: C1,A (축구 선수)1더 이상 모든 미디어 채널에서 사용 가능한 가장 긴 에이전트가 아닙니다.

  • 시간 T1, 채팅 접촉 C2가 대기하고, 현재 A2인 가장 긴 에이전트로 라우팅된다.
  • 마지막으로, 시간 T2, 또 다른 음성 접촉 C3가 대기하고 A3로 라우팅됩니다.

    A (축구 선수)1그리고 A (축구 선수)2최근 연락처는 - 이 시점에서, 그것은 A (축구 선수)3가장 오래 기다려온 분입니다.

Webex Contact Center의 고도로 분산된 아키텍처로 인해 이러한 연락처가 동시에 동일한 대기열에 있을 때 가장 긴 단일 에이전트가 여러 연락처를 라우팅할 수 있는 작은 가능성이 있습니다.

이 라우팅 패턴은 다음 유형의 비 기술 기반 큐에서 지원됩니다.

원형

원형 라우팅 패턴은 라운드 로빈 순서로 사용 가능한 에이전트 그룹 사이에 들어오는 연락처를 분배합니다. 접촉이 대기될 때, 시스템은 미리 결정된 시퀀스에 기초하여 대기열에 있는 다음 가능한 에이전트에게 이를 할당한다.

프로세스는 구성된 순서로 에이전트로 시작됩니다. 첫 번째 수신 연락처는 해당 시퀀스에서 첫 번째 사용 가능한 에이전트에 할당됩니다. 후속 연락처의 경우, 시스템은 다음 사용 가능한 에이전트를 선택하고, 정의된 큐 순서에서 중단된 위치에서 계속합니다. 이 패턴은 반복되며, 에이전트를 통해 순환하지만 항상 마지막으로 선택된 에이전트의 위치 후에 시작됩니다.

이 접근법은 에이전트 간에 공정하고 균등하게 연락처를 분배하는 데 효과적입니다. 이는 단일 에이전트가 연락처에 압도되지 않고 모든 에이전트가 일관되게 상호 작용을 처리할 수 있는 동등한 기회를 갖도록 보장하는 데 도움이 됩니다. 그러나, 서큘러 라우팅 패턴은 현재 워크로드 또는 특정 접촉을 처리하는 에이전트의 능력에 영향을 미칠 수 있는 기타 요인을 고려하지 않습니다.

위의 예에서, 에이전트는 다음과 같은 순서로 원형 대기열로 구성된다. A 3 → A4 → A5 → A6 → A1 → A2.

먼저, 시작 위치는 구성된 순서의 첫 번째 에이전트(A3)입니다. 연락처가 이 큐에서 에이전트로 라우팅될 때, 위치는 원 주위를 이동하며, 지정된 순서로 다음 에이전트에 배치되어 마지막 연락처가 라우팅된 에이전트에 배치됩니다.

다음 시나리오를 고려하십시오.

  • 첫 번째 접촉(C1)이 대기하고, 에이전트 A3로 라우팅된다.

    포인터는 구성된 순서 즉, A에서 다음 에이전트로 업데이트됩니다. 4

  • 두 번째 접촉(C2)이 대기될 때, 시스템은 A4 즉, A4 → A5 → A6 → A1 → A2 → A로 시작하는 사용 가능한 에이전트를 찾기 시작한다3.

    그러나, A4A5는 사용할 수 없습니다(로그인이 되지 않거나 유휴 상태이거나 이 미디어 유형의 다른 연락처와 완전히 바쁠 수도 있음), 그래서 C2는 다음 사용 가능한 에이전트 인 A6로 라우팅됩니다. 포인터는 구성된 순서 즉, A에서 다음 에이전트로 업데이트됩니다. 1

  • 마찬가지로, 제3의 접촉(분류: C3) 로 A (축구 선수)1네 번째 접촉 (분류: C4) 라우팅된 A (축구 선수)2... 포인터는 다시 A에서3 있습니다.

    이 논리는 계속되고, 접촉은 "원형" / "라운드 로빈" 패턴에서 사용 가능한 에이전트 사이에 분배된다.

대기열에 주차된 연락처가 있는 경우, 에이전트 잉여 시나리오는 이 미디어 유형에서 사용할 수 있는 다음 에이전트와 가장 높은 우선 순위, 가장 오래된 연락처와 일치합니다.

이것은 이 큐의 기존 위치 값을 고려하거나 영향을 주지 않으며, 이는 연락처 잉여 라우팅이 에이전트와 성공적으로 일치할 때만 업데이트됩니다.

이 라우팅 패턴은 다음 유형의 비 기술 기반 큐에서 지원됩니다.

위쪽 아래로

하향식 라우팅 패턴은 사용 가능한 에이전트 그룹과 순차적 순서로 들어오는 연락처를 분배합니다. 접촉이 대기될 때, 시스템은 항상 처음부터 순서가 지정된 에이전트 목록을 통과하고 해당 시퀀스에서 첫 번째 사용 가능한 에이전트(연락처의 미디어 유형에 대한 무료 사용 가능한 채널을 가지고 있음)와의 접촉과 일치한다.

이것은 대기중인 모든 접촉에 대해 발생합니다. 연락처는 항상 맨 위(처음 구성된 에이전트)에서 시작하여 일치하는 에이전트가 발견될 때까지 목록을 아래로 진행하려고 합니다.

원형 라우팅 패턴과 달리, 마지막으로 선택한 에이전트의 위치에 따라 시작점을 동적으로 변경하는 "포인터"는 없습니다.

이 접근법은 관리자가 결정한 일부 편향/선호도에 따라 주문된 에이전트 간에 연락처를 배포하는 데 효과적입니다. 상단의 에이전트가 항상 아래 에이전트에 대한 연락처를 처리하는 것을 선호하는지 확인하는 데 도움이 됩니다. 그러나 하향식 라우팅 패턴은 현재 워크로드 또는 특정 연락처를 처리하는 에이전트의 능력에 영향을 미칠 수 있는 기타 요인을 고려하지 않습니다.

위의 예에서, 에이전트는 다음 순서로 하향식 대기열로 구성됩니다. A 3 → A4 → A5 → A6 → A1 → A2.

즉, 관리자는 모든 연락처를 가능한 경우 첫 번째 에이전트(A3)로 라우팅하고, 그렇지 않으면 다음 에이전트(A4)로 구성되는 순서대로 라우팅하기를 원합니다.

다음 시나리오를 고려하십시오.

  • 첫 번째 접촉(C1)이 대기하고, A3 순서의 최상위에 있기 때문에 에이전트 A3로 라우팅된다.
  • 두 번째 접촉(C2)이 대기되었을 때, 라우팅은 순서의 상단에서 다시 한번 시도된다(항상 A3로 시작).

    A3이 미디어 유형에 대해 더 많은 채널 용량이 있는 경우, C2 또한 A3로 라우팅됩니다. 그러나 이 미디어 유형에서 A3 가 완전히 바쁠 경우, 라우팅은 목록 아래로 진행됩니다4.

  • 그러나, A4A5는 사용할 수 없습니다(로그인된 상태이거나 유휴 상태이거나 이 미디어 유형의 다른 연락처와 완전히 바쁠 수도 있음), 그래서 C2은 하향식 순서로 다음 사용 가능한 에이전트인 A6로 라우팅됩니다.
  • 마찬가지로, 세 번째 접촉(C3)은 A3에서 아래쪽으로 라우팅하려고 시도된다. 첫 번째 매칭 에이전트는 A입니다1.

    이 논리는 순서의 맨 아래까지 접촉자가 사용 가능한 에이전트를 찾을 때까지 계속되며, 이 경우 대기열에 주차됩니다.

이 라우팅 패턴은 다음 유형의 비 기술 기반 큐에서 지원됩니다.

에이전트 기반 라우팅

에이전트 기반 라우팅은 지정된("선호") 에이전트에 직접 연락처를 라우팅하거나 대기하는 기능입니다. 에이전트의 이메일 주소 또는 에이전트 ID가 있는 에이전트 조회 기능은 선호하는 에이전트에 대한 연락처를 라우팅합니다. 흐름에서 에이전트에 대한 Queue To Agent 활동은 에이전트 기반 라우팅을 달성하는 데 도움이 됩니다. 자세한 내용은 다음을 참조하십시오. 에이전트에게 대기열활동.

연락처는 일반적으로 Webex Contact Center 외부의 외부 응용 프로그램에서 관리될 수 있는 하나 이상의 선호하는 에이전트에 매핑을 가질 수 있습니다. 연락처를 위한 선호 에이전트 검색은 다음 HTTP 요청외부 응용 프로그램에서 매핑을 검색하는 활동. 선호하는 에이전트와의 연락처를 라우팅하거나 주차하려면 에이전트의 Webex Contact Center ID 또는 이메일 주소를 사용하여 에이전트로의 Queue To Agent 활동을 구성하십시오. 또한 해당 선호 에이전트가 즉시 이용할 수 없는 경우 해당 연락처를 선호 에이전트에 대해 주차할 수 있습니다.

에이전트 기반 라우팅은 다음 시나리오에서 유용합니다.

  • 선호 에이전트 라우팅: 고객은 전용 에이전트 또는 관계 임원에게 연락처를 할당할 수 있습니다. 이러한 시나리오에서 에이전트 기반 라우팅은 연락처를 선호하는 에이전트로 직접 라우팅합니다.In such scenarios, the Agent-based Routing routes the contacts directly to that preferred agent.
  • 마지막 에이전트 라우팅: 연락처가 에이전트와 상호 작용하기 위해 연락처 센터를 여러 번 호출할 때, 에이전트 기반 라우팅은 해당 연락처를 처리한 마지막 에이전트로 라우팅할 수 있습니다.

두 사용 사례 모두에서 연락처 및 에이전트 매핑의 세부 사항은 Webex Contact Center 외부에 저장됩니다.

만들기
흐름에서 대기 및 라우팅 기능
만들기

Flow에서 큐잉 및 라우팅 기능

Webex Contact Center에서 광범위한 라우팅, 대기열 및 통화 제어 기능이 흐름을 통해 조정될 수 있습니다.

Flow Designer에서 제공되는 다양한 흐름 활동 및 이벤트 핸들러를 흐름에 배치하여 인바운드 및 아웃바운드 연락처의 라이프사이클을 효과적으로 관리할 수 있습니다.

플로우 설정과 사용에 대한 자세한 내용은 다음을 참조하십시오. Flow Designer를 사용하여 플로우 구축 및 관리...

대기 중인 활동

대기열 연락처

Queue Contact 활동은 조직의 활성 인바운드 큐에 대한 연락처를 queue 할 수 있는 기능을 제공하여 해당 큐에 있는 올바른 에이전트에게 매칭하고 라우팅할 수 있습니다.

대기열의 다음 측면은 이 활동을 통해 관리될 수 있습니다.

  • Priority - 대기중인 연락처에 1(가장 높은)에서 10(가장 낮은, 기본값)까지 범위의 계층적 중요성을 부여합니다.
  • Skill Requirements - 기술 기반 대기열에 있는 에이전트가 충족해야 하는 기술 기준을 설정하여 연락처를 라우팅할 자격이 있는 것으로 간주합니다.
  • Skill Relaxations - 에이전트를 찾을 가능성을 높이기 위해 일정 기간 후에 이전에 설정된 기술 요구 사항을 조정, 수정 또는 제거합니다.
  • Check Agent Availability - 시스템이 사용 가능한 에이전트가 없는 모든 콜 배포 그룹을 통해 즉시 확장하여 대기 시간을 피할 수 있도록 허용합니다.

보기 라우팅연락처 라우팅에서 우선 순위, 기술 구성 및 에이전트 가용성이 어떻게 역할을 하는지에 대한 자세한 내용은.

Queue Contact 활동이 성공적으로 연락처를 대기시키면,

  • 일치하는 에이전트가 이미 사용 가능한 경우, 시스템은 에이전트에 연락처를 라우팅하려고 시도합니다.

    이를 방해하는 Main flow 실행 및 추가 이벤트는 해당 이벤트가 발생할 수 있습니다. Event Flows설정된 경우.

  • 일치하는 에이전트가 발견되지 않으면, 연락처는 대기열에 주차되고 일치하는 에이전트가 사용할 수 있을 때까지 기다립니다.

    그런 다음 흐름 실행은 Queue Contact 활동 후에 부착된 활동으로 계속되며, 이는 다음과 같은 기능을 제공합니다.

    • 대기중인 고객에게 미리 구성된 음악을 재생합니다. PlayMusic 활동.
    • 고객의 요청에 따라 콜백 등록(Register a callback based on the customer’s request) Callback 활동.
    • Re-queue 즉, 현재 큐에서 연락처를 제거하고 새 큐에 추가 - 다른 큐에 연결 Queue Contact 또는 Queue to Agent 활동.

일치하는 에이전트를 사용할 수 있게 되면, 시스템은 에이전트에 연락처를 라우팅하려고 시도합니다.

성공할 때, 이것이 방해가 된다. Main flow 실행 및 추가 이벤트는 해당 이벤트가 발생할 수 있습니다. Event Flows설정된 경우.

Queue Contact 활동은 다음과 같은 경우에 작동합니다.

  • 연락처는 지정되지 않고 에이전트에게 라우팅할 준비가 되어 있습니다.
  • 큐, 기술 및 기타 흐름 구성이 올바르게 설정됩니다.
  • 연락처는 25 입력 포인트 및 큐 전환의 허용 한도 내에 남아 있습니다.
  • 연락처는 성공적인 라우팅 20 시도의 허용 한도 내에 남아 있습니다.

대체 라우팅 또는 추가 취급이 필요한 연락처를 우아하게 관리하기 위해 오류 처리 경로를 구성하십시오.

이러한 경우 액티비티는 실패를 초래하고 흐름 실행은 다음과 같이 이동한다. Error Handling 경로.

Skill Requirements, Skill Relaxations 및 Check Agent Availability와 같은 기능은 팀 할당과 함께 대기열이 선택되는 경우에만 Queue Contact 활동에서 사용할 수 있습니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > Queue Contact...

에이전트에게 대기열

에이전트 Queue to Agent 활동은 Webex Contact Center에서 고유한 에이전트 ID 또는 이메일 주소를 검색하여 선호하는 에이전트에 직접 연락처를 쿼리할 수 있는 기능을 제공합니다.

대기열의 다음 측면은 이 활동을 통해 관리될 수 있습니다.

  • Priority - 동일한 에이전트에 대해 대기된 연락처에 더 높은/더 낮은 중요성을 부여합니다.
  • Reporting Queue - 녹화 및 기본 음악-in-queue와 같은 구성에 사용할 대기열을 식별하고 연락처의 보고 목적을 확인합니다.
  • Recovery Queue - 지정된 선호 에이전트로 연락처를 라우트할 수 없을 때 폴백으로 사용할 대기열을 식별합니다.

Queue To Agent 활동이 성공적으로 연락처를 대기시키면,

  • 에이전트가 이미 사용 가능한 경우, 연락처는 에이전트로 라우팅됩니다.

    이를 방해하는 Main flow 실행 및 추가 이벤트는 해당 이벤트가 발생할 수 있습니다. Event Flows설정된 경우.

  • 에이전트가 이용 가능하지만, 거절을 선택하거나, 응답하지 않거나, 연락처를 받지 못하는 경우, 제공된 복구 큐로 이동한다.

    복구 대기열에 있는 연락처는 기술 지원 없이 가장 긴 사용 가능한 에이전트로 라우팅됩니다.

  • 에이전트가 사용할 수 없는 경우 "Park Contact If Agent Unavailable" 옵션은 selected, 연락처는 주차되고 에이전트가 이용 가능할 때까지 기다립니다.

    그런 다음 흐름 실행은 Queue To Agent 액티비티 후 부착된 액티비티로 계속되며, 이는 다음과 같은 기능을 제공합니다.

    • 대기중인 고객에게 미리 구성된 음악을 재생합니다. PlayMusic 활동.
    • Callback 활동.
    • Re-queue 즉, 현재 큐에서 연락처를 제거하고 새 큐에 추가 - 다른 큐에 연결 Queue to Agent 또는 Queue Contact 활동.

    에이전트를 사용할 수 있게 되면, 시스템은 에이전트에 연락처를 라우팅하려고 시도합니다.

    이를 방해하는 Main flow 실행 및 추가 이벤트는 해당 이벤트가 발생할 수 있습니다. Event Flows설정된 경우.

  • 에이전트가 사용할 수 없는 경우 "Park Contact If Agent Unavailable" 옵션은 not selectedQueuing은 실패합니다.

에이전트에 대한 Queue To Agent 활동은 다음과 같은 경우에 작동합니다.

  • 연락처는 지정되지 않고 에이전트에게 라우팅할 준비가 되어 있습니다.
  • 선호 에이전트 ID 또는 이메일 주소가 유효합니다.
  • 보고 큐 및 복구 큐가 올바르게 구성됩니다.The reporting queue and recovery queue are configured correctly.
  • 선호하는 에이전트가 로그인되어 있고, 사용할 수 있으며, 연락처를 처리할 준비가 되어 있습니다.

선호하는 에이전트를 사용할 수 없을 때 연락처가 원활하게 라우팅되도록 복구 대기열을 구성합니다.

이러한 경우 액티비티는 실패를 초래하고 흐름 실행은 다음과 같이 이동한다. Error Handling 경로.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 플로우 빌드 및 관리 > 에이전트로 큐...

Call Distribution Group 확장

Escalate Call Distribution Group 활동은 다음에 대해서만 지원됩니다. queues with team assignment그리고 업데이트 할 수 있는 능력을 제공합니다. Call Distribution Group 설정된 대기 시간 후 다음 그룹에 자동 확장 업데이트가 발생하기를 기다리는 대신 즉시 연락할 수 있습니다. 이를 통해 연락처가 대기중인 모든 자격 있는 에이전트에게 신속하게 라우팅될 수 있습니다.

Escalate Call Distribution Group 활동을 사용하여 연락처를 다음과 같이 확장할 수 있습니다.

  • Next Group—다음 통화 배포 그룹에 추가된 팀 세트를 확장합니다.
  • Last Group—대기열에 대해 구성된 모든 호출 배포 그룹에 매핑된 모든 팀을 포함하도록 팀 세트를 확장합니다.

Escalate Call Distribution Group 활동은 다음과 같은 경우에 작동합니다.

  • 연락처는 이미 대기중이며 확장할 준비가 되어 있습니다.
  • 연락처는 호출 분포 그룹을 사용하는 대기열에 대기됩니다.The contact is queued in a queue that uses calls distribution groups.

표준 라우팅을 사용하는 큐의 경우, 큐의 구성된 라우팅 동작을 통해 연락처를 계속 배포합니다.For queues that use standard routing, continue distributing contacts through the queue's configured routing behavior.

이러한 경우 액티비티는 실패를 초래하고 흐름 실행은 다음과 같이 이동한다. Error Handling 경로.

연락처가 3개의 통화 분포 그룹을 갖는 대기열에 대기하고, 각각 30 초 후 업데이트되는 경우를 생각해 보십시오.

팀에서 사용할 수 있는 에이전트는 없다 CDG 1CDG 2, 그리고 에이전트를 사용할 수 있는 TEAM 3 마지막 호출 분포 그룹에 속합니다.

Escalate Call Distribution Group 활동이 흐름에서 사용되지 않을 때, 아래에 설명된 것처럼 긴 대기 시간이 발생합니다.

Escalate Call Distribution Group 활동을 사용하여 대기 시간을 낮출 수 있습니다.

에 기초하여 Next Group 또는 Last Group 옵션 선택, 연락처에 대한 대기 시간이 크게 감소됩니다, 아래 그림과 같이:

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > 콜 배포 그룹 확장...

대기열 정보 활동

큐 정보 얻기

Get Queue Info 활동은 다음과 같은 주어진 연락처에 대한 실시간 큐 정보를 가져오는 기능을 제공합니다.

  • 큐에 있는 접촉자의 현재 위치( The current position in queue)PIQ또는 아직 대기하지 않은 경우 잠재적 위치.
  • 예상 대기 시간 (EWT또는 작업이 응답을 받기 전에 대기열에 대기하는 것으로 추정되는 시간.
  • 연락처의 현재 통화 배포 그룹 내에서 로그인하거나 사용할 수 있는 에이전트 수.
  • 선택한 대기열에 대해 모든 Call Distribution Groups에 로그인하거나 사용할 수 있는 에이전트 수입니다.
  • 대기열에 있는 가장 오래된 연락처를 기다리는 시간

이러한 세부 사항은 흐름 실행에서 활동 출력 변수로 사용할 수 있습니다.These details are made available in the flow execution as activity output variables.

활동 사용, 각 큐 세부사항에 대한 자세한 정의 및 계산 방법에 대한 자세한 내용은 다음을 참조하십시오. 플로우 빌드 및 관리 > 큐 정보 받기...

큐 정보를 사용하는 방법 중 일부는 다음과 같습니다.

  • 연락처의 위치를 대기열에 발표하고 고객이 라우팅을 기다리는 동안 예상 대기 시간을 고객에게 알립니다.
  • 예상 대기 시간이 너무 길면 콜백을 고객에게 등록할 수 있는지 여부를 결정하기 위해.
  • 현재 CDG에 매핑된 팀에서 에이전트가 없는 경우 다음 CDG(Call Distribution Group)로의 연락처를 확장하기 위해.

Get Queue Info 활동은 선택한 변수가 유효한 대기열로 해결될 때 작동합니다.The Get Queue Info activity works when the selected variable resolves to a valid queue.

선택한 변수가 검증이 필요하거나 사용 가능한 대기열에 해결되지 않는 경우를 우아하게 관리하도록 오류 처리 경로를 설정합니다.Configure the Error Handling path to graceful manage cases where the selected variable needs validation or does not resolve to an available queue.

다음 경우, 현재 통화 배포 그룹에 대한 실시간 큐 정보는 적용되지 않습니다.
  • Get Queue Info 활동이 실행될 때 연락처가 아직 대기되지 않았습니다.
  • 연락처는 호출 분포 그룹의 개념을 지원하지 않는 대기열에 대기됩니다.

이러한 경우, 이러한 출력 필드에서 -1 의 값은 이 정보가 적용되지 않음을 나타냅니다.

고객이 대기열에 있는 모든 15 초를 보낸 후 대기열에 있는 긴 EWT에 대해 알려야 하는 예제 시나리오를 고려하십시오.

이는 다음과 같이 흐름에서 Get Queue Info 활동을 사용하여 달성할 수 있습니다.

고급 큐 정보

고급 큐 정보(Advanced Queue Info) 활동은 주어진 연락처에 대한 실시간 큐 정보를 가져올 수 있는 기능을 제공하며, 다음과 같이 연락처의 기술 기준을 고려합니다.

  • 큐에 있는 접촉자의 현재 위치( The current position in queue)PIQ또는 아직 대기하지 않은 경우 잠재적 위치.
  • 지정된 기술 기준과 일치하는 연락처의 현재 통화 분포 그룹 내에서 로그인 또는 이용 가능한 에이전트 수.
  • 선택한 대기열에 대해 모든 호출 분포 그룹에서 로그인하거나 사용할 수 있는 에이전트 수가 주어진 기술 기준과 일치합니다.
  • 연락처가 제공된 대기열에 주차되는 현재 통화 분포 그룹.
  • 제공된 대기열에 있는 통화 분포 그룹의 총 수입니다.The total number of calls distribution groups in a given queue.

이러한 세부 사항은 흐름 실행에서 활동 출력 변수로 사용할 수 있습니다.These details are made available in the flow execution as activity output variables.

활동 사용, 각 큐 세부사항에 대한 자세한 정의 및 계산 방법에 대한 자세한 내용은 다음을 참조하십시오. 플로우 빌드 및 관리 > 고급 큐 정보...

고급 큐 정보를 사용하는 방법 중 일부는 다음과 같습니다.

  • 고객이 라우팅을 기다리는 동안 연락처의 위치를 고객에게 알리기 위해.
  • 다음 호출 분배 그룹에 대한 연락처를 확대하려면, 기술 기준과 일치하는 에이전트가 현재 호출 분배 그룹에 매핑된 팀에서 사용할 수 없는 경우.
  • 고객에 대해 콜백을 등록할 수 있는지 여부를 결정하기 위해, 기술 기준과 일치하는 에이전트가 모든 콜 배포 그룹에 로그인되어 있지 않은 경우.

Advanced Queue Info 활동은 다음과 같은 경우에 작동합니다.

  • 큐 정보는 큐 레벨 기술 기준이 아닌 흐름 내에서 기술 요구 사항이 구성된 큐에 대해 요청됩니다.
  • 연락처가 이미 대기된 경우, 연락처가 현재 대기중인 동일한 대기열에 대한 정보가 요청됩니다.
  • 연락처는 선호하는 에이전트에게 직접 연결되지 않은 대기열에 대기됩니다.

이러한 요구 사항을 충족하지 않는 요청을 관리하기 위해 오류 처리 경로를 구성하십시오.

이러한 경우 액티비티는 실패를 초래하고 흐름 실행은 다음과 같이 이동한다. Error Handling 경로.

기술 기준을 충족하는 에이전트가 없는 경우 고객이 콜백 수신에 대해 통보해야 하는 예제 시나리오를 고려해 보십시오.

이는 다음과 같이 흐름에서 고급 큐 정보 활동을 사용하여 달성할 수 있습니다.

통화 제어 활동

발신자 ID 설정

발신자 ID 설정 활동은 통화 중에 표시되어야 하는 발신자 ID를 정의하는 데 사용됩니다. 설정 발신자 ID 활동은 이벤트 흐름의 끝을 표시하는 터미널 활동으로 PreDial 이벤트 흐름에서만 사용해야 합니다.

세트 발신자 ID 활동은 DNIS(Dialed Number Identification Service), 운영 유형 또는 참가자 유형을 기반으로 필요한 자동 번호 식별(ANI)를 구성할 수 있습니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > 발신자 ID 설정...

레코딩 컨트롤

기록 제어 활동은 발신자의 기록 동의를 캡처하기 위해 메뉴 활동과 함께 사용하도록 설계되었습니다. 이를 통해 녹화가 시작되기 전에 명시적 동의가 필요한 규정 또는 정책을 준수하고 이 단계를 워크플로우에 원활하게 통합할 수 있습니다.

Menu IVR 액티비티는 사용자의 동의를 Boolean 변수에 캡처해야 하며, 이 변수는 Recording Control 액티비티에 입력으로 할당됩니다. 고객이 동의 보고서에 사용자 동의를 보고해야 하는 경우, 동의 값은 보고할 수 있는 전역 변수에 저장되어야 합니다. 또는, 보고가 필요하지 않은 경우 로컬 변수를 사용할 수 있습니다.Alternatively, a local variable can be used if reporting is not required. 이 접근법은 세입자와 고객에게 변수를 효과적으로 관리하고 활용하는 데 있어 유연성을 향상시킵니다.

이 활동이 흐름에 추가되면 사용자의 동의가 테넌트 수준 또는 큐 수준 또는 기록 일정 수준 구성 설정보다 우선합니다.When this activity is added to the flow, the user's consent takes precedence over the tenant level or queue level or recording schedule level configuration settings.

우선 순위는 다음과 같습니다.

  • 사용자 동의가 흐름에서 예 인 경우, 테넌트 또는 큐 또는 기록 일정 수준에서 설정된 기록 구성에 관계없이 호출이 기록됩니다.If the user consent is Yes in the flow, then the call is recorded, regardless of recording configuration set at the tenant or queue or recording schedule level.
  • 사용자가 활동에 대한 응답으로 동의하지 않는 경우, 테넌트 또는 대기열 또는 기록 일정 수준에서 설정된 기록 구성에 관계없이 호출이 기록되지 않습니다.If the user does not agree as response to the activity, then the call is not recorded, regardless of the recording configuration set at the tenant or queue or recording schedule level.
  • 레코딩 제어 활동이 흐름에서 구성되지 않지만 테넌트 또는 큐 또는 레코딩 스케줄과 같은 다른 레벨 중 하나에서 예 로 설정된 경우 호출이 기록됩니다.If the Recording Control activity is not configured in the flow, but a configuration is set to Yes at any other level such as tenant or queue or recording schedule, then the call is recorded.
  • 레코딩 제어 활동이 흐름에서 구성되지 않고 테넌트, 큐 및 레코딩 스케줄과 같은 모든 수준에서 구성이 No로 설정되면 호출이 기록되지 않습니다.If the recording Control activity is not configured in the flow, and a configuration is set to No at all levels such as tenant, queue, and recording schedule, the call is not recorded.

이 기록 제어는 아래와 같이 설명할 수 있다:

또한 Continue On Transfer, Pause Resume Enabled, Pause Duration 및 기타 등의 녹음 구성은 테넌트, 큐 또는 녹음 일정 레벨을 포함하여 기존 계층에 따라 계속 적용됩니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 플로우 빌드 및 관리 > 레코딩 컨트롤...

블라인드 전송

눈가림 전송은 IVR 시스템을 통해 접촉이 외부 다이얼 번호(DN)로 효율적으로 라우팅되어 에이전트 침범의 필요성을 없애는 과정입니다.

맹검 전송 활동은 통화가 외부 또는 제3자 DN로 전송되어야 할 때 사용됩니다. 이것은 터미널 활동이므로 전송이 실행되면 흐름이 종료됩니다.

블라인드 전송 활동은 쿼리를 위해 흐름이 실행될 때 지원되지 않습니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > Blind Transfer...

교량 전송

브리지드 전송(Bridged Transfer) 활동을 통해 연락처가 외부 목적지로 일시적으로 전송될 수 있으며, 흐름이 통화에 대한 통제를 유지합니다. 외부 목적지는 외부 브리지 또는 IVR(Interactive Voice Response) 서비스가 될 수 있습니다.

외부 목적지가 호출을 종료할 때, 호출 흐름은 에이전트에게 대기하는 것과 같이 필요에 따라 더 진행됩니다.

Bridge Transfer 활동은 제3자 IVR 또는 ACD(Automatic Call Distribution) 시스템으로 전송하는 동안 접촉을 차단합니다. 연락처가 제3자 시스템에 의해 처리되지 않는 경우, 원래의 대기열로 다시 대기할 수 있으므로 연락처가 워크플로우에 남아 있도록 보장할 수 있습니다.

예를 들어, 연락처 센터에는 Webex Contact Center 에이전트 리소스가 있고 외부 콜센터 또는 PBX(Private Branch Exchange)에 에이전트 리소스가 있다고 가정합니다. 고객은 Webex Contact Center 에이전트의 대기열에 대해 짧은 기간(예: 60 초)을 요청합니다. 그 기간 동안 에이전트를 이용할 수 없는 경우, 그 콜은 접촉을 처리하기 위해 외부 콜센터(암시적 디큐어)로 브리지(암시적 디큐어)가 전달될 수 있다.

  1. Bridged Transfer 활동은 아웃바운드 콜 흐름 및 이벤트 흐름에서 지원되지 않습니다.
  2. 이미 에이전트에 할당된 연락처는 흐름을 통해 브리지 전송을 지원하지 않습니다.Contacts already assigned to an agent is not supported to Bridge Transfer through the flow.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > Bridged Transfer...

연락처 연결 끊기

Disconnect Contact 활동은 흐름에서 직접 활성 연락처를 분리하거나 종료할 수 있는 기능을 제공합니다.

이것은 흐름에 부착된 터미널 활동이며, 에이전트 개입 없이 연락처를 끝낼 때 유용할 수 있으며, 오류 경로 흐름에 적합하거나 고객에 대한 콜백을 등록한 후에 사용할 수 있다.

구성에 따라, 이 활동을 통해 연락처가 종료될 때 포스트 콜 설문 조사 또는 피드백이 트리거됩니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > 연락처 연결 끊기...

연락처 우선 순위 설정

Set Contact Priority 활동은 특정 우선 순위 수준을 연락처에 할당하도록 허용함으로써 흐름 내에서 효과적인 연락처 우선 순위 관리를 용이하게 합니다. 이를 통해 특정 연락처의 중요성이 높거나 낮아 에이전트가 이용 가능할 때 다른 대기 연락처에 비해 적절하게 라우팅되도록 할 수 있습니다. 이러한 유연성을 통해 흐름 전반에 걸쳐 연락처 우선 순위를 정확하게 제어할 수 있습니다.

우선 순위는 1(가장 높은)에서 9(가장 낮은)까지 계층적 중요도 수준을 할당하여 결정된다. 우선 순위가 높은 연락처는 우선 순위가 낮은 연락처보다 우선합니다. 여러 연락처들이 동일한 우선 순위 수준을 공유하면, 가장 오래 기다린 연락처는 먼저 이용 가능하고 적합한 다음 에이전트로 라우팅됩니다. 이 시스템은 더 높은 우선 순위의 연락처들이 그들의 대기 시간에 따라 동등한 우선 순위의 연락처들 사이에서 공정성을 유지하면서 신속한 주의를 받을 수 있도록 보장합니다.

  1. Set Contact Priority 활동은 주 또는 이벤트 흐름 내의 어느 지점에나 배치될 수 있습니다.
  2. 큐잉 활동(Queue Contact 또는 Queue To Agent 등) 전에 연락처 우선 순위 활동이 구성된 경우, 그 우선 순위 설정은 후속 큐잉 활동에서 명시적으로 구성된 모든 우선 순위에 의해 재정의될 수 있습니다. 그러나 다음 대기열 활동이 우선 순위를 지정하지 않으면 이전 Set Contact Priority 활동에 의해 설정된 연락처 우선 순위가 적용됩니다.
  3. 반대로, 대기열 활동(예: Queue Contact 또는 Queue To Agent) 후에 Set Contact Priority 액티비티가 구성되면, 이전 대기열 액티비티에 의해 구성된 우선 순위 설정을 재정의합니다.
  4. Set Contact Priority 활동은 현재 외부 및 캠페인 연락처에 대해 지원되지 않습니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > 연락처 우선 순위 설정...

콜백 활동

수신

콜백(Callback) 활동은 콜백(Callback) 활동을 통해 콜백(Callback)을 요청할 수 있으며, 대기 시간을 줄이고 포기율을 최소화함으로써 고객 만족도를 크게 개선할 수 있습니다. 활성화되면 콜백 활동이 대기열에 작업을 생성하여 사용 가능한 에이전트가 고객의 전화를 반환할 수 있도록 합니다.

흐름 디자이너는 호출이 시작된 곳에서 연락처를 원래 큐에 유지하거나 선호도에 따라 다른 큐에 할당하도록 액티비티를 구성할 수 있습니다.The flow designer can configure the activity to keep the contact in the original queue, where the call originated, or assign it to a different queue based on preferences. 콜백이 원본 큐에 남아 있는 경우, 연락처는 위치, 기술, 우선 순위 및 컨텍스트 데이터를 유지하여 다음 사용 가능한 에이전트에 원활하게 할당할 수 있습니다.If the callback remains in the original queue, the contact maintains its position, skills, priority, and contextual data, allowing for the next available agent. 그러나 다른 큐(queue)가 선택되면, 해당 연락처는 기술이 없고 기본 우선 순위가 있는 선택된 큐의 끝으로 밀려납니다.

이 활동은 또한 고객이 선호하는 에이전트로부터 콜백을 요청할 수 있으며, 경험에 개인적인 접촉을 추가하고 고객 만족도를 높일 수 있습니다. 이는 콜백 액티비티가 흐름에서 QueueToAgent 액티비티를 따르는 경우 달성할 수 있습니다.This can be achieved when the callback activity follows a QueueToAgent activity in the flow. 또한, 콜백 활동은 콜백 프로세스 중에 사용되는 ANI(Automatic Number Identification)를 사용자 정의하기 위한 선택적 구성을 제공합니다. 이 사용자 정의는 브랜드 일관성을 향상시키고 인식 가능한 발신자 ID를 보장함으로써 통화 거부 가능성을 감소시킵니다.

흐름 디자이너는 이벤트 흐름에 CallbackFailed 이벤트를 포함하는 옵션이 있습니다.The flow designer has the option to include a CallbackFailed event in the event flow. 콜백 시도가 실패할 때 이 이벤트는 흐름 디자이너가 특정 간격에서 재시도를 구현할 수 있도록 합니다.This event is triggered when a callback attempt failed, enabling the flow designer to implement retries at specific intervals. 재시도 사이의 지연 또는 간격은 대기 활동을 사용하여 구성할 수 있으며, 최소 재시도 간격은 10 초 및 최대 72 시간입니다. 이 시스템은 대기 활동을 사용하여 최대 14 일 동안 최대 10 재시도 시도를 지원합니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. Build and Manage Flows > 콜백...

콜백 스케줄

예정된 콜백(Scheduled Callback) 활동은 고객에게 특정 미래 날짜와 시간에 콜백(Callback)을 요청하는 편리함을 제공함으로써, 에이전트와의 즉각적인 연결의 필요성을 제거합니다. 이 기능은 고객이 편리한 콜백 창을 선택할 수 있게 하여 인지된 대기 시간을 최소화하고 콜 중복 비율을 줄임으로써 고객 경험을 향상시킵니다.

흐름은 DTMF 프롬프트를 통해 선호하는 날짜 및 시간과 같은 발신자의 입력을 캡처하고 필요한 입력 검증을 수행한 후 액티비티로 전달해야 합니다.

시작하기 전에, 반드시 Callback Default Entry Point Configured under입니다. Channel Settings Control Hub에서 자세한 내용은 다음을 참조하십시오. 콜백 엔트리 포인트 설정하기...

콜백은 인바운드 또는 아웃바운드 등 모든 전화 큐를 사용하여 예약할 수 있습니다. 최상의 결과를 위해, 콜백이 예약되면 현재 호출이 올바르게 종료되도록 예약된 콜백 활동 직후에 연결 해제 활동을 추가하는 것이 좋습니다.To add a Disconnect activity immediately after the Scheduled Callback activity to ensure the current call ends properly once the callback is scheduled. IVR 콜백 일정에 대한 자세한 내용은 다음을 참조하십시오. IVR 콜백 일정...

요청된 미래 날짜와 시간에 콜백이 트리거되면 새로운 통화 또는 상호작용이 생성됩니다.When the callback is triggered at the requested future date and time, a new call or interaction is created. 이 새로운 상호 작용은 콜백 기본 엔트리 포인트에 연결된 표준 흐름을 따릅니다. 콜백 시도가 실패하면, 해당 흐름에서 구성된 경우 CallbackFailed 이벤트 핸들러를 사용하여 콜백을 자동으로 다시 시도할 수 있습니다.If the callback attempt fails, the flow can automatically retry the call using the CallbackFailed event handler if configured in that flow.

액티비티에 입력을 전달하기 전에 다음과 같은 입력 검증을 고려해야 한다.

  1. 날짜 선택—오늘부터 31 미래의 날짜까지 모든 날짜를 선택할 수 있습니다. 날짜는 다음 형식이어야 합니다. YYYY-MM-DD(예: 2025-07-18).
  2. 시간 창 시작 및 종료 시간—선택한 시간은 지금으로부터 최소 30 분부터 시작되어야 하며, 30 분과 8 시간 사이에 지속될 수 있습니다. 24-hour time format(예: 14:30:00.
  3. 시간대 - IANA 형식으로 유효한 시간대를 입력해야 합니다(예: America/New_York그래서 우리는 적절한 시간에 당신을 부를 수 있습니다.

참고 구현은 액티비티와 함께 사용되는 DTMF 프롬프트와 기본 검증을 보여주기 위해 서브 흐름 템플릿의 형태로 제공됩니다.A reference implementation is provided the form of a subflow template to demonstrate the DTMF prompts and basic validations that are used along with the activity. 자세한 내용은 다음을 참조하십시오. 예약된 콜백 서브 흐름 템플릿...

진행 분석 호출

CPA(Call Progress Analysis) 활동을 통해 자동화된 응답 시스템을 감지하고 콜백 통화에서 실시간으로 인간의 목소리를 확인할 수 있습니다.

콜백 시도가 AMD(Answering Machine Detection) 또는 음성 메일이 발생하면, 시스템은 호출이 성공하지 못한 것으로 식별합니다. 응답 기계 감지(AMD)의 결과는 CallbackFailed 이벤트 핸들러의 이유 출력 변수에 캡처됩니다.The result of Answering Machine Detection (AMD) is captured in the reason output variable of the CallbackFailed event handler. 이 출력 변수를 기반으로, 흐름 디자이너는 콜백 재시도를 구성할 수 있습니다.

  1. 호의적인 콜백의 경우, CallProgressAnalysis는 주 흐름에서 콜백 활동 후 지점에 배치될 수 있습니다.For courtesy callback, the CallProgressAnalysis can be placed at a point after the Callback activity in the main flow. 예정된 콜백 또는 개인 예정된 콜백의 경우, 주 흐름에서 NewPhoneContact 후에 배치될 수 있습니다.
  2. 이벤트 흐름에서, 이것은 CallbackFailed 이벤트 핸들러에서만 지원됩니다.
  3. 흐름에서 통화 후 고객 설문조사(피드백 활동)가 구성된 경우, AMD나 음성 메일로 전화가 응답되는 경우에는 시작되지 않습니다. 이는 불필요한 조사를 유발하는 것을 방지합니다.

활동 설정, 사용 및 출력 변수에 대한 자세한 내용은 다음을 참조하십시오. 흐름 빌드 및 관리 > Call Progress Analysis...

만들기
대기열

개요

Webex Contact Center에서 큐는 전화, 채팅, 이메일 또는 소셜 채널과 같은 수신 상호 작용을 위한 대기 영역 역할을 합니다. 문의 사항은 상담원에게 자동으로 배정되거나 상담원이 수동으로 처리하기 전까지 대기열에 보관됩니다. 또한, 이들은 스킬 기반 라우팅, 우선순위 관리 및 공정한 작업 부하 분배와 같은 기능을 지원합니다.

관리자는 대기열을 사용하여 다양한 업무 라인을 관찰하고 컨택 센터에서 작업 처리 방식을 개선할 수 있습니다.

큐를 효과적으로 사용했을 때 얻을 수 있는 주요 이점은 다음과 같습니다.

  • 더 나은 고객 경험: 대기 시간을 관리하고 고객에게 대기열에 있음을 알려주세요.
  • 효율성 향상: 통화가 질서정연하게 처리되도록 하여 혼란과 관리 부실을 줄이십시오.
  • 연락처의 공정한 배분: 특정 상담원에게 과부하가 걸리지 않도록 통화를 상담원들에게 고르게 분배하십시오.
  • 우선 처리: VIP 고객이나 긴급한 문제와 같은 특정 통화에 우선순위를 부여할 수 있습니다.

대기열의 종류

Webex Contact Center는 다양한 유형의 대기열을 지원하여 모든 규모와 복잡성의 컨택 센터에서 모든 미디어 유형에 걸쳐 균일한 기능을 통해 다양한 사용 사례를 구현할 수 있습니다.

상담원의 역량을 고려하여 연락을 배정하는 대기열과 그렇지 않은 대기열이 있습니다. 이러한 대기열은 상담원이 연락처를 처리하기 위해 연결되는 방식에서도 차이가 있습니다.

대기열은 크게 두 가지 유형으로 나뉩니다.

  • 기술 기반이 아닌 대기열
  • 스킬 기반 대기열

기술 기반이 아닌 대기열

스킬 기반이 아닌 대기열은 상담원과 관련된 스킬을 고려하지 않습니다. 스킬 기반이 아닌 대기열은 다음 옵션을 사용하여 구성할 수 있습니다.

  • 팀 과제
  • 에이전트 배정

팀 배정을 통한 비기술 기반 대기열

팀 할당 방식의 비기술 기반 대기열에서는 상담원을 팀으로 구성하고 이러한 팀을 결합하여 통화 분배 그룹(CDG)을 만들 수 있습니다. 통화 흐름을 관리하기 위해 각 그룹 간에 시간 지연을 설정할 수 있습니다.

통화 분배 그룹은 설정된 시간 간격 동안 해당 대기열의 연락처를 처리할 수 있는 자격을 갖춘 상담원을 여러 단계로 정의하는 데 도움이 됩니다. 담당 상담원은 소속 팀의 레벨에 따라 배정됩니다. 상담원이 없는 경우, 연락처는 미리 설정된 기간 동안 보류된 후 다음 팀 그룹을 포함하도록 확장됩니다. 이 과정은 상담원이 연결되거나 모든 그룹에 대한 확인이 완료될 때까지 계속됩니다.

다음과 같은 유형의 팀을 구성할 수 있습니다.

  • 개별 팀: 상담원들은 특정 조직 기능을 대표하는 팀으로 구성될 수 있으며, 이러한 팀은 문의가 해당 팀의 상담원들에게 연결될 수 있도록 대기열의 일부가 될 수 있습니다. 상담원을 여러 팀에 태그하여 다양한 대기열의 문의를 효율적으로 처리할 수 있습니다.
  • 역량 기반 팀: 용량 기반 팀(CBT)은 음성 통화를 용량 기반 직통 번호(DN)로 연결하는 기능으로, 용량은 동시에 처리할 수 있는 통화 수를 결정합니다. 이 시스템은 상담원이 시스템에 로그인할 필요 없이 전화번호로 통화를 연결할 수 있도록 해주므로, 기존 콜센터 상담원 대신 음성 메일, 자동 응답기 또는 헌트 그룹을 통해 통화를 처리하는 시나리오에 적합합니다. 이 설정에서는 팀에 특정 상담원이 배정되지 않으며, Webex Contact Center Agent Desktop을 사용하지 않습니다.

Webex 컨택 센터에서 팀 배정을 통한 비기술 기반 대기열 작동 방식에 대한 워크플로 다이어그램

이 예시에서는 세 개의 통화 분배 그룹이 있으며, 이를 통해 대상 확장이 가능합니다. 즉, 설정된 시간 간격에 따라 여러 팀의 더 많은 상담원에게 서비스를 확대할 수 있습니다.

첫 번째 통화 분배 그룹에는 3명의 상담원(A1, A2, A5)이 구성된 TEAM 1이 포함되어 있습니다.

두 번째 통화 분배 그룹에는 TEAM 2가 포함되어 있으며, 이 그룹에는 A2, A3, A4의 세 명의 상담원이 구성되어 있습니다.

세 번째(그리고 마지막) 통화 분배 그룹에는 TEAM 3이 포함되어 있으며, 이 그룹에는 A6과 A7이라는 두 명의 상담원이 구성되어 있습니다.

문의가 대기열에 추가되면 시스템은 먼저 첫 번째 통화 분배 그룹에서 일치하는 상담원을 검색합니다. 상담원을 찾을 수 없는 경우, 다음 그룹으로 대상 확장을 진행하기 전에 구성된 기간 동안 연락처를 보류합니다. 이는 기존 팀에 새로운 팀을 추가하는 것입니다. 이 과정은 일치하는 항목을 찾을 때까지 또는 모든 그룹이 확장될 때까지 반복됩니다.

'상담원 가용성 확인'이라는 기능은 현재 그룹에서 일치하는 상담원이 없는 경우 해당 연락처를 다음 통화 분배 그룹으로 즉시 확장합니다. 이 기능은 흐름 내의 대기열 연락처 활동 <LINK TO section 3.1.1> 에서 활성화할 수 있습니다.

이러한 설정은 다음과 같은 시나리오를 초래합니다.

  1. A2 는 팀 1과 팀 2에 속합니다. A2가 에이전트 데스크톱에 로그인하기 위해 팀 1을 선택하면 시스템은 A2를 팀 1의 일원으로 간주하여 첫 번째 통화 분배 그룹에만 포함시킵니다.
  2. A5 는 TEAM 1에 속하지만, 현재 로그인한 조직 내 다른 팀에 소속되어 있었을 수도 있습니다. 따라서 A5는 팀 1의 일부로 간주되지 않으며 이 대기열과도 관련이 없습니다.

팀 할당 기능이 있는 대기열은 상담원이 로그인 시 팀을 선택하는 것만으로 대기열 간에 이동할 수 있는 강력한 기능을 제공합니다.

사용 가능한 라우팅 패턴:

에이전트 할당이 포함된 비기술 기반 대기열

비기술 기반 큐는 상담원 풀이 큐에 직접 할당되는 유형의 큐입니다. 다른 대기열 유형과는 달리, 이러한 대기열은 관리자가 에이전트를 직접 수동으로 선택할 수 있도록 합니다. 다른 대기열 유형은 에이전트 풀을 간접적으로 결정하는 반면, 이러한 대기열은 관리자가 에이전트를 직접 수동으로 선택할 수 있도록 합니다. 예를 들어, 팀 기반 배정 대기열은 로그인한 팀을 기준으로 상담원을 배정하고, 기술 기반 배정 대기열은 필요한 기술을 기준으로 상담원을 매칭합니다. 반면 관리자는 에이전트를 이러한 대기열에 직접 추가하여 대기열의 일부로 만들 수 있습니다. 이를 통해 시스템 기반 할당에 의존하지 않고 상담원 할당을 간편하게 관리할 수 있습니다.

상담원 할당 기능을 갖춘 대기열은 간단하면서도 효과적인 라우팅 알고리즘을 제공하여 상담원 풀 간에 문의를 효율적으로 분배할 수 있도록 도와줍니다. 그들은 상담원들이 고객 연결을 담당하는 데 필요한 기술을 고려하지 않습니다. 하지만 상담원들은 각 대기열 내에서 순서를 정할 수 있으며, 이는 문의를 해당 상담원에게 연결할 때 고려됩니다. 이러한 맥락에서 팀은 주로 관리자를 위한 조직적 구성 요소 역할을 하며, 상담원-대기열 연결 및 문의 라우팅 결정에 영향을 미쳐 대기열 관리를 간소화하는 요소는 아닙니다.

이러한 유형의 큐는 에이전트의 정적 할당과 에이전트-큐 연결 관리가 운영 제어에 적합하고, 라우팅 알고리즘 선택이 에이전트 간 작업 분배에 적합한 경우에 가장 적합합니다. 이러한 대기열은 여러 유형의 고객 문의에 대해 전문적인 지식이 필요하고, 미리 구성된 전문가 상담원 그룹이 이러한 문의에 대응할 수 있는 시나리오에서 특히 유용합니다.

하지만 복잡한 컨택센터 조직에서는 이러한 대기열에서 상담원 배정을 수동으로 관리하는 데 어려움을 겪을 수 있습니다. 그들은 동적 라우팅과 에이전트-큐 연결을 제공하는 다른 큐 유형을 사용하는 것이 더 유리할 수 있습니다.

Webex Contact Center에서 상담원 배정이 포함된 비기술 기반 대기열의 작동 방식을 보여주는 워크플로 다이어그램

이 예시에서 대기열에는 A4, A9, A7 등과 같이 특정 순서로 매핑된 에이전트 집합이 있습니다. 이 순서는 수신되는 문의를 상담원과 연결하는 특정 라우팅 알고리즘에서 중요한 역할을 합니다. 이 시스템은 상담원의 가용성과 선택된 라우팅 알고리즘을 기반으로 연락처를 해당 상담원과 연결합니다.

팀 할당이 있는 대기열과 달리 시간 간격에 따른 목표 확장 개념이 없습니다. 구성된 상담원 중 어느 누구도 이 문의를 처리할 수 없는 경우, 해당 문의는 대기열에 보관되며, 대기 시간 초과 전에 이러한 상담원 중 하나가 문의를 처리할 수 있게 될 때까지 기다립니다. 대상 확장 은 이러한 큐에는 적용되지 않습니다.

사용 가능한 라우팅 패턴:

스킬 기반 대기열

기술 기반 대기열은 고객이 필요로 하는 사항을 충족할 수 있는 적절한 기술을 갖춘 상담원에게 연결될 수 있도록 합니다.

다음과 같은 유형의 스킬 기반 옵션을 구성할 수 있습니다.

대기열에 할당된 기술 기준

관리자는 대기열에 기술 기준을 할당할 수 있습니다. 스킬 기준이 있는 스킬 기반 대기열을 통해 관리자는 대기열에서 필요한 스킬을 직접 구성할 수 있습니다. 조직 내에서 필요한 모든 기술을 보유한 에이전트는 직접적인 기술 프로필을 통해 자동으로 이 대기열에 포함됩니다.

이 설정을 통해 관리자는 기술에 따라 상담원이 대기열에 어떻게 매핑되는지 실시간으로 확인할 수 있습니다. 처리량이 많거나 적은 상황에서 관리자는 필요에 따라 상담원 풀을 확장하거나 축소하기 위해 대기열 및 상담원 스킬 프로필에 필요한 스킬을 조정하는 것을 고려할 수 있습니다.

이러한 유형의 대기열은 팀 할당 기반 대기열과 달리 통화 분배 그룹 설정이 없으므로 팀이 상담원과 대기열 연결에 관여하지 않는다는 점에서 차이가 있습니다. 또한, 이 대기열에서는 필요한 기술이 정적으로 구성됩니다. 이는 흐름에 따라 (정적이거나 가변적인) 필요한 기술이 주입되는 팀 기반 기술 대기열과는 대조적입니다. 따라서 기술 관련 사항은 연락 자체보다는 대기열의 일부라고 할 수 있습니다.

해당 조직 내에서 큐의 스킬 기준을 완전히 충족하는(직접적인 스킬 프로필에서 스킬을 보유한) 모든 에이전트는 암묵적으로 이 큐와 연결됩니다. 팀은 이러한 대기열과 상담원 연결에 아무런 역할을 하지 않습니다. 이러한 요원들은 관리 및 운영 목적상 어떤 팀에든 소속될 수 있습니다.

이 대기열에 추가된 모든 연락처는 대기열 자체에 정의된 기술 기준을 자동으로 적용받게 됩니다. 개별 연락처는 자신의 스킬을 정의하거나 재정의할 수 없습니다. requirements/criteria 팀 배정이 있는 실력 기반 대기열과는 다릅니다.

Webex Contact Center에서 스킬 기준을 사용하는 스킬 기반 대기열의 작동 방식을 보여주는 워크플로 다이어그램

이 예시에서는,

  • 대기열에 설정된 기술 기준을 완전히 충족하는 상담원은 A1, A3, A7뿐이므로 이들 상담원만 해당 대기열에 연결됩니다.
  • 자격 기준을 부분적으로 충족하는 A2, A4, A6 요원 또는 관련 기술이 부족한 A5 요원은 이 대기열에 배정될 수 없습니다.

에이전트의 스킬 프로필을 업데이트(재교육이라고 함)하여 대기열의 스킬 기준을 충족시키면 해당 에이전트가 자동으로 동적으로 대기열에 추가됩니다. 또는, 큐의 기술 기준 자체를 업데이트하여 업데이트된 기술 기준을 충족하는 상담원의 수가 늘어나거나 줄어들도록 하면, 해당 큐에서 상담원이 자동으로 동적으로 추가되거나 제거됩니다.

팀 할당이 있는 대기열과 달리 시간 간격에 따른 목표 확장 개념이 없습니다. 연락처를 연결된 상담원과 매칭할 수 없는 경우, 해당 연락처는 대기열에 보관되며, 대기 시간 초과 전에 해당 상담원 중 하나가 연락처를 처리할 수 있게 될 때까지 기다립니다.

스킬 기반 큐는 스킬의 정적 할당과 큐와 에이전트 연결 관리가 운영 제어에 용이하고 바람직한 경우에 가장 적합합니다. 또한, 라우팅 알고리즘 선택이 에이전트 간 작업 분배에 적합한 경우에도 적합합니다. 이러한 대기열은 특히 다양한 유형의 고객 문의에 대해 특정 기술이 필요하고, 사전에 선별된 전문가 상담원 그룹이 해당 문의에 대응할 수 있는 시나리오에서 매우 유용합니다.

복잡한 컨택센터 조직에서는 상담원 배정 방식이 아닌, 스킬 기반 대기열에서 상담원 배정을 관리하는 것이 더 쉬울 수 있습니다. 상담원 배정 방식에서는 각 상담원을 수동으로 목록에 추가해야 하므로 특히 규모가 큰 조직에서는 번거롭습니다.

흐름도에 할당된 기술 요구 사항

웹엑스 컨택센터에서 스킬 요구 사항이 흐름에 따라 할당되는 스킬 기반 대기열은 팀 할당 기반 대기열의 한 유형으로, 통화 분배 그룹이라고 하는 여러 레벨에서 팀 세트가 구성됩니다. 이렇게 구성된 팀에 로그인한 상담원은 해당 팀이 대기열에 구성된 통화 분배 그룹 수준에 따라 이 대기열에서 연락처를 배정받으며, 또한 해당 연락처에 대한 기술 요구 사항을 모두 충족해야 합니다.

이러한 대기열 내에서 상담원 팀은 통화 분배 그룹으로 그룹화되며, 그룹 간 시간 지연은 설정 가능합니다. 해당 문의에 응대할 상담원이 없는 경우 요청은 보류되고, 일정 시간 지연 후 다음 통화 분배 그룹으로 연결됩니다. 이 과정은 담당자가 배정되거나 모든 그룹이 소진될 때까지 계속됩니다. 한편, 이 과정 중에 이전에 확인했던 그룹의 상담원이 사용 가능해지면 해당 상담원이 선택됩니다.

요원은 요원에게 직접 할당된 스킬 프로필을 통해 기술을 습득합니다. 요원의 스킬은 로그인 시 팀 선택에 따라 결정됩니다.

각 담당자는 선택적으로 요구 기술 사항을 지정할 수 있으며, 이는 이용 가능한 상담원의 기술과 비교하여 가장 적합한 상담원을 선택하는 데 사용됩니다.

또한, 연락처는 설정된 시간 간격으로 기술 완화 조건을 지정할 수도 있습니다. 이는 설정된 시간 간격에 따라 해당 연락처의 원래 기술 요구 사항을 덮어쓰는 수정된 기술 요구 사항 세트입니다. 이 기능을 통해 연락처는 대기열에 있는 동안 기술 요구 사항을 수정(일반적으로 "완화"하는 데 사용)할 수 있으므로 완화된 기술 요구 사항을 가진 더 많은 상담원이 매칭될 수 있습니다.

통화 분배 그룹을 통한 대상 확장은 스킬 완화 주기와 동시에 진행될 수 있으며, 둘 다 대기 중인 통화를 적격 상담원과 더 빠르게 연결하여 전체 대기 시간을 줄이고 대기열의 서비스 수준을 향상시키는 것을 목표로 합니다.

Webex Contact Center에서 팀 배정을 통한 스킬 기반 대기열 작동 방식을 보여주는 워크플로 다이어그램.

팀 배정이 있는 일반 대기열과 마찬가지로, 이 시스템에는 "대상 확장", 즉 설정된 시간 간격에 걸쳐 여러 팀의 상담원에게 확장할 수 있는 3개의 통화 분배 그룹이 있습니다.

  • 첫 번째 통화 분배 그룹에는 TEAM 1이 포함되어 있으며, 이 그룹에는 A1, A2, A5의 세 명의 상담원이 구성되어 있습니다.
  • 두 번째 통화 분배 그룹에는 TEAM 2가 포함되어 있으며, 이 그룹에는 A2, A3, A4의 세 명의 상담원이 구성되어 있습니다.
  • 세 번째(그리고 마지막) 통화 분배 그룹에는 TEAM 3이 포함되어 있으며, 이 그룹에는 A6과 A7이라는 두 명의 상담원이 구성되어 있습니다.

하지만 주목해야 할 두 가지 주요 사항이 있습니다.

  • 이 대기열에 추가되는 모든 연락처는 흐름을 통해 필요한 기술 수준과 완화 수준을 정의하게 됩니다.
  • 상담원은 스킬 프로필을 통해 (직접 설정하거나 로그인한 팀으로부터 상속받아) 스킬을 구성할 수 있습니다.

A2는 팀 1과 팀 2 모두에 속하도록 구성되어 있지만, 로그인 시 에이전트가 선택한 팀에 따라 현재 세션에서는 해당 팀의 구성원으로 간주되며, 따라서 해당 팀의 스킬 프로필(및 스킬 값)을 상속받습니다(단, 이 에이전트에 대한 스킬 프로필을 직접 구성하여 재정의한 경우는 제외).

팀 배정 기능을 갖춘 대기열은 상담원이 로그인 시 팀을 선택하는 것만으로 대기열 간에 이동할 수 있도록 해주는 강력한 기능을 제공합니다.

선택한 팀의 스킬 프로필 설정을 상속받을 수 있는 기능과 더불어, 상담원은 다양한 스킬 세트를 활용하여 업무를 수행할 수도 있습니다.

이 예시에서는,

  • 연락처는 초기 기술 요구 사항(sk_1 )과 함께 대기열에 추가됩니다. >= 6) 흐름에서 상승하는 동안, 기술 완화와 함께 (sk_1 ) >= 3) 설정된 시간 간격 후.
  • 모든 통화 분배 그룹의 모든 상담원 중에서 A1, A3, A6, A7만이 대기 중인 연락에 필요한 초기 기술 요건을 충족하는 기술을 보유하고 있습니다.
  • 나머지 요원은 기술(sk_1 )을 가지고 있지만 기술 요구 사항을 충족하지 못하거나(예: TEAM 1의 A2 및 TEAM 2의 A4), 이 기술을 전혀 가지고 있지 않습니다(예: TEAM 2의 A5, A2).
  • 시간이 지남에 따라 기술 요건이 완화되면서 A2 및 A4 자격도 이제 해당 연락처의 "완화된" 기술 요건을 충족하게 되었습니다.

이 대기열에 등록되는 모든 문의에 대해 시스템은 해당 문의의 현재 기술 요구 사항을 완벽하게 충족하는 상담원을 첫 번째 통화 분배 그룹 내에서 찾으려고 시도합니다. 일치하는 상담원을 찾을 수 없는 경우, 대상 확장이 두 번째 통화 분배 그룹으로 이루어지기 전에 구성된 기간 동안 연락처가 보류됩니다. 두 번째 통화 분배 그룹에 구성된 모든 팀은 첫 번째 그룹의 기존 팀에도 추가됩니다. 이제 시스템은 확장된 그룹 내에서 일치하는 에이전트를 찾으려고 시도합니다. 참고로, 이 과정이 진행되는 동안 스킬 완화 기능은 설정된 시간 간격으로 연락처의 스킬 요구 사항을 업데이트하며, 시스템은 업데이트된 스킬 요구 사항을 사용하여 현재 통화 분배 그룹에서 사용 가능한 상담원과 매칭합니다.

이 과정은 구성된 모든 통화 분배 그룹이 확장되고 모든 스킬 완화가 적용될 때까지 계속되며, 그 전에 일치하는 상담원이 발견되면 예외가 적용됩니다.

사용 가능한 라우팅 패턴:

큐 구성

기술 기반 대기열을 설정하세요

대기열에 기술 기준을 할당합니다.
  • 스킬을 생성하고, 필요한 경우 동적 스킬을 생성합니다.
  • 스킬 프로필을 생성합니다.
  • 에이전트에게 스킬 프로필을 직접 할당합니다.
  • 에이전트에게 동적 스킬을 직접 할당하세요. 동적 스킬은 스킬 프로필을 통해 할당되지 않습니다.
  • 전화, 채팅, 이메일 또는 소셜 채널 유형으로 대기열을 생성하세요.
  • 컨트롤 허브의 대기열에 스킬 및 동적 스킬 요구 사항을 할당합니다.
  • 대기 중인 문의를 처리할 수 있는 상담원 목록을 확인하세요.
  • 라우팅 알고리즘으로 LAA 또는 BAA 중 하나를 선택하십시오. BAA의 경우, 필요에 따라 숙련도 기술 및 숙련도 동적 기술에 대한 가중치를 구성하십시오.
  • 흐름에 큐 연락처 활동을 추가하고 이 큐를 선택합니다.
대기열에 기술 요구 사항을 할당합니다.
  1. 스킬을 생성하고, 필요한 경우 동적 스킬을 생성합니다.
  2. 스킬 프로필을 생성합니다.
  3. 에이전트에게 직접 또는 팀에 스킬 프로필을 할당합니다.
  4. 에이전트에게 동적 스킬을 직접 할당하세요. 동적 스킬은 스킬 프로필을 통해 할당되지 않습니다.
  5. 을 만드세요.
  6. 팀에 요원을 추가하세요.
  7. 전화, 채팅, 이메일 또는 소셜 채널 유형으로 대기열을 생성합니다.
  8. 단일 CDG 또는 여러 CDG에 팀을 대기열에 추가하세요.
  9. 라우팅 패턴으로 LAA 또는 BAA 중 하나를 선택하십시오.
  10. 흐름에 큐 연락처 활동을 추가하고 스킬 기반 라우팅이 구성된 큐를 선택합니다. 자세한 내용은 Queue Contact를 참조하세요.
  11. 큐 컨택트 활동에서 스킬, 동적 스킬 및 스킬 이완을 할당합니다. BAA의 경우, 필요에 따라 숙련도 기술 및 숙련도 동적 기술에 대한 가중치를 구성하십시오.
  12. 대기열 이후 흐름에서 통화 분배 활동 에스컬레이션을 사용하여 다음 통화 분배 그룹 또는 이전 그룹으로 빠르게 이동할 수 있습니다.

기술 기반이 아닌 대기열을 설정하세요

팀을 대기열에 배정합니다
  • 을 만드세요.
  • 팀에 요원을 추가하세요.
  • 전화, 채팅, 이메일 또는 소셜 채널 유형으로 대기열을 생성합니다.
  • 단일 CDG 또는 여러 CDG에 팀을 대기열에 추가하세요.
  • 라우팅 패턴으로 LAA를 선택하세요.
  • 흐름에 큐 연락처 활동을 추가하고 이 큐를 선택합니다.
  • 대기열 이후 흐름에서 통화 분배 활동 에스컬레이션을 사용하여 다음 통화 분배 그룹 또는 이전 그룹으로 빠르게 이동할 수 있습니다.
상담원을 대기열 흐름에 할당합니다.
  • 전화, 채팅, 이메일 또는 소셜 채널 유형으로 대기열을 생성합니다.
  • 상담원을 대기열에 직접 추가하세요(참고: 이 유형의 대기열에서는 스킬이나 팀 구성이 사용되지 않습니다.
  • 순환형, 선형 또는 최장 가능 상담원과 같은 라우팅 패턴을 선택하십시오.
라우팅

라우팅 개념

에이전트 과잉 시나리오

상담원 과잉 상황은 대기 중인 고객 수보다 사용 가능한 상담원이 더 많을 때 발생합니다. 이 경우, 고객 응대(연락)가 대기열에 등록되면 시스템은 해당 특정 연락에 맞는 상담원을 즉시 찾으려고 시도하며, 맞는 상담원이 발견되면 해당 연락은 대기열에 보관되지 않고 나중에 맞는 상담원이 배정될 때까지 기다릴 필요가 없습니다.

통화 분배 그룹을 통해 연락처가 확장되거나 스킬 완화가 적용될 때마다 시스템은 해당 연락처에 맞는 상담원을 즉시 다시 찾으려고 시도합니다.

특정 연락처에 맞는 상담원을 찾으려면 대기열에 구성된 라우팅 패턴을 사용합니다.

Webex Contact Center는 다양한 유형의 대기열에 걸쳐 여러 라우팅 패턴을 제공하므로 기업은 대기 시간을 최소화하고 상담원 업무량을 균형 있게 분배하며 고객의 특정 요구 사항을 해결하는 데 필요한 기술을 갖춘 상담원과 연결하여 고객 서비스를 최적화할 수 있습니다. 라우팅 패턴에 대한 자세한 내용은 라우팅 패턴 섹션을 참조하십시오.

연락처 과잉 시나리오

고객 응대 과잉 라우팅은 수신 고객 응대(또는 연락) 수가 가용 상담원 수를 초과할 때 발생합니다. 이러한 상황은 주로 피크 시간대나 예상치 못한 문의량 급증 시에 발생합니다. 문의 과잉 배정의 주요 목표는 이러한 과잉 수요를 효율적으로 관리하여 고객 서비스 표준을 유지하는 것입니다. 특정 채널에서 방금 사용 가능해진 상담원의 경우, 연락처 초과 라우팅 기능은 해당 상담원과 연결된 모든 대기열의 모든 보류된 연락처 중에서 적절한 연락처를 찾아 할당합니다.

제한된 상담원 가용성 속에서 효율적으로 연락 경로를 배정하기 위한 핵심 전략은 다음과 같습니다.

  • 대기열 순위

    큐 순위 지정 기능을 통해 관리자는 큐의 상대적 중요도를 지정할 수 있습니다. 관리자는 팀별로 대기열 순위를 정의하여 팀에 로그인한 상담원에게 통화가 연결되는 순서를 설정할 수 있습니다.

    예를 들어, A팀에 로그인한 상담원이 "청구"와 "영업"이라는 두 개의 대기열에 연결되어 있다고 가정해 보겠습니다. 관리자는 대기열 순위 지정 기능을 사용하여 "청구" 대기열에 더 높은 순위를 부여할 수 있습니다. 이렇게 하면 문의가 대기열에 들어올 때 "청구" 대기열의 문의가 "영업" 대기열의 문의보다 먼저 A팀 소속 상담원에게 연결됩니다. "영업" 대기열에 더 오래되고 우선순위가 높은 연락처가 있더라도 "청구" 대기열의 순위가 "영업" 대기열보다 높기 때문에 이러한 상황이 발생합니다. "청구" 대기열에 더 이상 대기 중인 연락처가 없을 때만, A팀 상담원은 자신이 소속된 "영업" (및 기타) 대기열의 연락처를 배정받게 됩니다.

    다음은 대기열 순위 지정의 중요한 특징 몇 가지입니다.

      • 순위가 지정된 대기열이 일부에 불과한 경우, 순위가 지정되지 않은 대기열의 통화보다 순위가 지정된 대기열의 통화가 우선 처리됩니다.
      • 대기열 순위는 모든 미디어 유형에 걸쳐 최대 50개의 대기열에 대해 설정할 수 있으며, 값은 1에서 50 사이이고 1이 가장 높은 순위입니다.
      • 여러 대기열에 동일한 순위를 지정할 수 있습니다.
      • 큐 순위 지정을 활성화하면 명시적인 순위가 지정되지 않은 큐는 순위가 지정된 모든 큐보다 낮은 순위로 처리됩니다.
      • 큐 랭킹은 동일한 미디어 유형 내에서 작동합니다.

        예를 들어, '판매 대기열'이 순위 2의 음성 미디어 유형 대기열이고 '청구 지원 대기열'이 팀 A의 순위 1의 채팅 대기열인 경우, 순위가 2이더라도 팀 A에서 음성 채널 사용이 가능한 상담원이 음성 통화를 먼저 받게 됩니다.

        하지만 팀 B의 채팅 대기열을 두 개 생각해 보세요. 하나는 대기열 순위 2위의 신용카드 대기열이고, 다른 하나는 대기열 순위 1위의 직불카드 대기열입니다. 그러면 B팀의 가용 상담원들에게 큐 데빗 카드에서 제공하는 연락처가 우선적으로 제공됩니다.

      • 대기열 순위는 용량 기반 팀에는 적용되지 않습니다.

  • 연락처 우선

    연락처가 대기열에 추가되면 1(가장 높음)부터 10(가장 낮음, 기본값)까지의 계층적 중요도를 할당하여 우선순위를 정의할 수 있습니다. 이러한 우선순위 지정은 조직의 중요도, 긴급성 또는 전략적 가치에 따라 특정 문의 사항에 더 신속하게 대응할 수 있도록 보장합니다. 상담원이 연결된 모든 대기열의 보류된 문의 중에서 다음 문의를 처리할 수 있는 상담원이 있는 경우, 모든 대기열에서 가장 우선순위가 높은 문의가 해당 상담원에게 연결됩니다(단, 기술 적합성 및 기타 기준이 충족되는 경우).

    명시적인 우선순위 없이 대기열에 추가된 연락처의 경우, 기본 우선순위인 10(가장 낮음)이 적용됩니다. 우선순위가 같은 여러 문의 사항 중에서 대기 시간이 가장 긴 문의 사항이 이용 가능하고 적합한 상담원에게 우선적으로 연결됩니다.

  • 가장 오래 기다린 연락처

    이는 상담원이 담당하는 모든 대기열 중에서 가장 대기 시간이 긴 문의가 해당 상담원에게 연결되도록 하는 기본적인 전략입니다.

    이는 동일한 대기열 순위와 연락처 우선순위를 가진 여러 연락처가 처리 대기 중일 때, 어떤 연락처를 우선적으로 처리할지 결정하는 최종 기준입니다.

기본적으로, 새로 근무 가능해진 상담원에 대한 연락처 과잉 라우팅은 다음과 같은 조건을 충족하는 단일 연락처를 선택하는 것을 의미합니다.

  • 에이전트가 사용 가능한 미디어 유형과 동일한 미디어 유형입니다.
  • 해당 에이전트와 연결된 대기열 중 하나에 대기 중입니다.
  • 해당 직원의 기술 요구 사항(있는 경우)은 모두 이 에이전트에 의해 충족됩니다.
  • 상담원 팀에 설정된 대로 다른 대기열보다 순위가 높은 대기열에 대기 중입니다.
  • 모든 연락 중에서 가장 높은 우선순위를 갖고 있습니다.
  • 우선순위가 같은 연락처 중 가장 오래된 대기 연락처입니다.

위 예시는 연락량 과잉 상황을 보여주는데, 상담원 A1이 팀 1에 로그인하여 여러 미디어 유형의 연락을 처리할 수 있게 되었습니다.

A1은 3개의 큐와 연결되어 있습니다. – Q1, Q2Q3. TEAM 1 은 또한 Q1 이 가장 높은 순위를 갖고 그 다음으로 Q2Q3 순으로 순위가 매겨지는 대기열 순위를 정의했습니다.

이미 모든 대기열에 연락처가 등록되어 있으며, 각 연락처에 대해 필요한 기술과 우선순위가 정의되어 있습니다.

이제, 계약 과잉 시나리오는 다음과 같이 작동합니다.

  • 이 대기열에 있는 모든 대기 중인 연락처 중에서 A1C2, C7 (대기열 2에서) 및 C3, C8 (대기열 3에서)으로 라우팅될 수 있는 연락처는 4개뿐입니다. 3).

    이 4개 연락처의 기술 요구 사항만 A1의 기술로 완전히 충족됩니다.

  • 이 4개의 연락처 중 QUEUE 2 의 연락처(즉 , C2, C7)가 더 높은 큐 순위를 가지고 있기 때문에 우선순위가 부여됩니다.

    QUEUE 1 이 가장 높은 순위의 대기열이지만 해당 대기열에 대기 중인 연락처는 A1에서 요구하는 기술 조건을 충족하지 못하므로 A1으로 라우팅될 수 없다는 점에 유의하십시오.

  • C2C7사이에서 가장 우선순위가 높은 접촉은 C7입니다. 따라서 최종 선택은 C7이고 시스템은 이를 A1로 라우팅합니다.

    C2 가 이전에 대기열에 추가되었더라도 이는 연락처 우선순위가 대기 시간보다 우선하기 때문에 발생합니다.

혼합된 멀티미디어 프로필

Webex Contact Center는 멀티미디어 프로필 구성을 통해 상담원이 다양한 미디어 유형(음성, 채팅, 이메일 및 소셜)을 통해 고객에게 서비스를 제공할 수 있도록 지원합니다. 이 구성에 따라 에이전트는 미디어 유형별로 프로비저닝된 채널을 받게 됩니다.

상담원에게 연결된 모든 문의는 상담원이 해당 문의를 처리하는 동안 해당 미디어 유형의 채널 하나를 사용합니다. 상담원은 음성 채널은 하나만 가질 수 있지만, 다른 미디어 유형은 최대 5개까지 가질 수 있습니다.

멀티미디어 프로필 의 혼합 라우팅 설정을 사용하면 관리자가 각 에이전트에 대해 서로 다른 채널을 동시에 사용하는 방법을 제어할 수 있습니다. 이를 통해 기업은 고객에게 더욱 세심한 관심을 기울일 수 있으며, 서비스 품질 향상, 고객 경험 개선 및 전환율 증대를 도모할 수 있습니다. 또한, 조직은 일부 채널에서 부하가 불균형하게 발생할 경우 미디어 채널 전반에 걸쳐 부하를 분산하여 상담원을 효율적으로 활용할 수 있습니다.

세 가지 선택지가 있습니다.

  • 배타적

  • 혼합됨

  • 혼합 실시간

음성 통화가 아닌 문의를 처리할 때, 상담원은 음성 채널이 사용 가능한 경우 상담원 데스크톱에서 수동으로 음성 통화를 걸 수 있습니다. 이는 모든 멀티미디어 프로필 유형에 적용됩니다.

멀티미디어 프로필 구성에 대한 자세한 내용은 멀티미디어 프로필 관리를 참조하세요.

라우팅 패턴

기술 기반

Webex Contact Center의 스킬 기반 라우팅 패턴은 문의 해결에 필요한 특정 스킬(예: 언어 능력 또는 기술 전문 지식)을 기준으로 고객 문의를 상담원에게 연결합니다. 이러한 패턴을 통해 각 고객은 가장 적합한 상담원과 연결되어 서비스 효율성과 고객 만족도가 향상됩니다. 이점으로는 처리 시간 단축, 문제 해결률 향상, 상담원의 전문성을 고객 요구에 맞춰 최적화함으로써 상담원 자원을 효율적으로 활용할 수 있다는 점 등이 있습니다.

스킬 기반 라우팅은 상담원이 스킬 프로필에서 받은 스킬과 상담원에게 직접 할당된 동적 스킬을 활용할 수 있습니다. 동적 스킬은 에이전트의 스킬 프로필과 관계없이 변경될 수 있는 에이전트 속성을 나타냅니다.

스킬 기반 라우팅 패턴을 사용할 경우, 먼저 연락처의 스킬 요구 사항(흐름에서 할당됨) 또는 대기열에 할당된 스킬 기준을 사용하여 해당 요구 사항을 충족하는 스킬과 동적 스킬을 보유한 상담원을 필터링합니다. / 기준에 전적으로 동의합니다. 그런 다음 필터링된 상담원 중에서 구성된 라우팅 패턴에 따라 해당 연락을 담당할 상담원 한 명이 선택됩니다.

최적 경로 설정을 위해 숙련도 기술과 동적 숙련도 기술은 가중치를 사용하여 상담원 선택에 사용되는 점수에 영향을 줄 수 있습니다. 가중치는 최장 가능 경로 설정에 영향을 미치지 않습니다. 해당 패턴은 상담원 자격 여부를 판단하기 위해 스킬 및 동적 스킬만 사용합니다.

가장 긴 기간 동안 이용 가능

최장 가능 스킬 기반 라우팅 패턴은 고객의 스킬 요구 사항을 충족하는 스킬을 가진 상담원에게 고객을 연결합니다. / 대기열의 모든 적격 상담원 중에서 마지막 연락을 처리한 이후 가장 오랫동안 대기 중인 상담원을 기준으로 스킬 기준을 완전히 적용합니다.

이 라우팅 패턴은 가장 오랫동안 대기한 상담원에게 상호 작용을 할당함으로써 상담원 간에 업무를 균등하게 분배하여 업무량 불균형을 방지합니다. 이는 업무 분배의 공정성을 유지하는 데 도움이 되며, 어떤 상담원도 과중한 업무에 시달리는 동안 다른 상담원은 자유롭게 일할 수 있도록 보장합니다.

위 예시에서는 숙련도와 비숙련도 기술을 보유한 에이전트가 4명 있으며, 숙련도 기술 값은 각기 다릅니다.

스킬 기반 대기열에 "가장 오래 걸리는" 라우팅 패턴으로 대기 중인 연락처를 생각해 보세요.

  • 위의 기술 요구 사항이 흐름을 통해 할당되거나,
  • 위의 기술 기준이 기술 기반 대기열에 구성됩니다.

이 시나리오에서는 다음과 같습니다.

이 라우팅 패턴은 다음과 같은 유형의 스킬 기반 큐에서 지원됩니다.

최상의 선택

최적의 상담원 연결 패턴은 고객과의 상호 작용이 이용 가능한 상담원 중 가장 적합한 상담원에게 연결되도록 보장합니다. 이 방식은 상담원들이 필요한 기술을 보유하고 있는지 여부뿐만 아니라 해당 기술의 숙련도 수준까지 평가하여 기술 점수를 계산하여 각 문의에 가장 적합한("최고의") 상담원을 결정합니다.

이 패턴은 연락 기술 요건을 충족하는 상담원만 필터링합니다. / 대기열 스킬 기준을 완전히 충족합니다. 그런 다음, 연락 기술 요구 사항에 언급된 모든 기술의 숙련도 값을 사용하여 자격을 갖춘 각 상담원에 대한 점수가 계산됩니다. / 대기열 스킬 기준. 스킬 점수가 가장 높은 상담원이 각 고객 문의에 대해 "최고의" 상담원으로 간주됩니다.

실질적으로, 접촉 기술 요구 사항을 충족하는 상담원의 기술 값의 합계입니다. / 대기열 스킬 기준에 따라 점수가 결정됩니다.

이해해야 할 몇 가지 핵심 사항:

  • 일반적으로 점수 계산에는 실제 스킬 값이 사용됩니다. 스킬 점수가 높을수록 더 강한 매치업을 나타내기 때문입니다. 단, 기술 요구 사항에 '이하' 또는 '같음'이 사용되는 경우는 제외합니다. < =) 조건은 에이전트의 특정 스킬 값이 점수 계산에서 반전된다는 것입니다. effective_skill_value = (10) 마이너스(actual_skill_value). 이는 점수가 낮을수록 더 높은 적합성을 나타내도록 하기 위한 것입니다.
  • 자격을 갖춘 상담원 중 점수가 같은 사람이 여러 명 있을 경우, 그중 가장 오랫동안 근무 가능한 상담원이 선택됩니다.
  • 점수 계산에는 숙련도만 고려됩니다. 연락처 스킬 요구 사항에 부울, 텍스트 또는 열거형 스킬이 포함되어야 합니다. / 대기열 스킬 기준은 점수 계산에 고려되지 않습니다.

위 예시에서는 숙련도와 비숙련도 기술을 보유한 에이전트가 네 명 있으며, 숙련도 기술 값은 각기 다릅니다.

스킬 기반 대기열에 "최적의 이용 가능" 라우팅 패턴으로 대기 중인 연락처를 생각해 보세요.

  • 위의 기술 요구 사항이 흐름을 통해 할당되거나,
  • 위와 같은 기술 기준이 기술 기반 대기열에 구성됩니다.

이 시나리오에서는 다음과 같습니다.

이 라우팅 패턴은 다음과 같은 유형의 스킬 기반 큐에서 지원됩니다.

기술 기반이 아닌 라우팅

Webex Contact Center는 상담원의 특정 기술이나 전문성을 고려하지 않고 고객과의 상호 작용을 분배하는 데 중점을 둔 다양한 비기술 기반 라우팅 패턴도 지원합니다. 기술 기반 라우팅 패턴과 달리, 이러한 패턴은 상담원의 기술을 고려하지 않으며, 연락처 또는 대기열에서 기술 요구 사항을 정의할 필요가 없습니다. / 경로 설정 기준. 오히려 가용성, 업무량 분배, 사전 정의된 순서와 같은 요소를 우선시하여 개별 상담원의 역량보다는 운영 논리에 기반하여 효율적인 연락 처리를 가능하게 합니다. 이러한 패턴은 상호 작용이 비교적 균일하거나 특별한 처리가 필요하지 않은 환경에서 특히 유용합니다.

가장 긴 기간 동안 이용 가능

최장 대기 시간 라우팅 패턴은 대기열에 연결된 모든 상담원 중에서 마지막 상담을 처리한 이후 가장 오랫동안 대기 중인 상담원에게 문의를 연결합니다.

이 라우팅 패턴은 가장 오랫동안 유휴 상태였던 상담원에게 상호 작용을 할당함으로써 공정하고 균형 잡힌 작업 부하 분배를 보장합니다. 업무량 불균형을 방지함으로써, 어떤 상담원도 과부하에 시달리는 동안 다른 상담원은 여유로운 상태를 유지할 수 있도록 합니다. 이 접근 방식은 특히 문의 흐름이 꾸준한 기간 동안 효과적이며, 상담원 전체에 걸쳐 일관된 참여를 유지합니다.

상담원은 특정 미디어 유형의 연락처를 제안받으면 모든 채널에서 "가장 오랫동안 유지해 온" 위치를 잃게 됩니다. 이는 상담원이 문의를 처리한 후, 대기열에 있는 모든 미디어 유형의 다음 문의는 해당 대기열에서 가장 대기 시간이 긴 상담원에게 배정된다는 것을 의미합니다.

위 예시에서 에이전트 A1 은 가장 오랫동안 사용 가능한 에이전트(위치 1)입니다. 즉, 이 에이전트가 가장 먼저 로그인했거나 다른 어떤 에이전트보다 더 오랫동안 연락처가 할당되지 않았습니다.

에이전트 A2 (위치 2) 및 A3 (위치 3)도 이용 가능하지만 이들은 로그인했거나 A1이후의 연락처를 처리했습니다. 모든 상담원은 이러한 라우팅 패턴을 가진 두 개의 큐 모두와 연결되어 있습니다.

다음 시나리오를 고려해 보세요.

  • 시간 T0에 음성 연락처 C1 이 대기열에 추가되고 가장 오랫동안 이용 가능한 상담원에게 연결됩니다. A1.

    A1C1 [에 할당됨에 따라 A1 은 더 이상 모든 미디어 채널에서 가장 오랫동안 사용 가능한 에이전트가 아닙니다.

  • 시간 T1에 채팅 연락처 C2 가 대기열에 추가되고 현재 가장 오래 사용 가능한 상담원인 A2에게 연결됩니다.
  • 마지막으로 시간 T2에 또 다른 음성 연락처 C3 가 대기열에 추가되고 A3로 라우팅됩니다.

    A1A2 는 최근에 연락을 받았습니다. 현재로서는 A3 가 가장 오래 기다리고 있습니다.

Webex Contact Center의 고도로 분산된 아키텍처로 인해, 동일한 대기열에 동시에 접수된 문의가 여러 개 있을 경우, 가장 오랫동안 대기 중인 상담원이 여러 문의를 동시에 처리할 가능성이 있습니다.

이 라우팅 패턴은 다음과 같은 비기술 기반 큐 유형에서 지원됩니다.

순환

순환 라우팅 패턴은 수신되는 연락을 사용 가능한 상담원 그룹에 라운드 로빈 방식으로 배분합니다. 문의가 대기열에 등록되면 시스템은 미리 정해진 순서에 따라 대기열에서 다음으로 사용 가능한 상담원에게 문의를 배정합니다.

이 프로세스는 구성된 순서대로 에이전트가 배치되는 것으로 시작됩니다. 첫 번째 수신 전화는 해당 순서에서 가장 먼저 이용 가능한 상담원에게 배정됩니다. 이후 연락의 경우, 시스템은 정의된 대기열 순서에 따라 다음으로 이용 가능한 상담원을 선택하여 중단된 부분부터 다시 시작합니다. 이 패턴은 에이전트들을 순환하며 반복되지만, 항상 마지막으로 선택된 에이전트의 위치 이후부터 시작합니다.

이 접근 방식은 상담원들에게 연락처를 공정하고 균등하게 배분하는 데 효과적입니다. 이는 특정 상담원이 과도한 문의에 시달리는 것을 방지하고 모든 상담원이 일관되게 응대할 수 있는 동등한 기회를 갖도록 하는 데 도움이 됩니다. 하지만 순환 라우팅 패턴은 현재 업무량이나 상담원이 특정 문의를 처리하는 능력에 영향을 줄 수 있는 기타 요소를 고려하지 않습니다.

위 예시에서 에이전트는 다음과 같은 순서로 원형 큐에 구성됩니다. A3 → A4 → A5 → A6 → A1 → A2.

우선, 시작 위치는 구성된 순서의 첫 번째 에이전트입니다(A3). 이 대기열에서 상담원에게 문의가 연결되면, 상담원의 위치는 원형으로 이동하여 마지막 문의가 연결되었던 상담원 다음으로 설정된 순서에 따라 다음 상담원 위치로 이동합니다.

다음 시나리오를 고려해 보세요.

  • 첫 번째 접촉(C1)이 대기열에 추가되고 에이전트 A3로 라우팅됩니다.

    포인터는 구성된 순서대로 다음 에이전트로 업데이트됩니다. A4.

  • 두 번째 연락(C2)이 대기열에 추가되면 시스템은 A4 부터 사용 가능한 상담원을 찾기 시작합니다. A4 → A5 → A6 → A1 → A2 → A3.

    그러나 A4A5 는 사용할 수 없습니다(로그인조차 되어 있지 않거나, 유휴 상태이거나, 이 미디어 유형의 다른 연락처로 완전히 바쁘기 때문입니다). 따라서 C2 는 다음으로 사용 가능한 상담원인 A6로 연결됩니다. 포인터는 구성된 순서대로 다음 에이전트로 업데이트됩니다. A1.

  • 마찬가지로 세 번째 접점(C3)은 A1로 라우팅되고 네 번째 접점(C4)은 A2로 라우팅됩니다. 포인터가 다시 A3 에 있습니다.

    이러한 논리가 계속 이어지면서, 연락처는 "순환 구조" 내에서 이용 가능한 에이전트들에게 분배됩니다. / "라운드 로빈" 패턴.

대기열에 대기 중인 연락처가 있는 경우, 상담원 과잉 시나리오에서는 해당 미디어 유형에서 사용 가능해지는 다음 상담원을 대기열에 있는 연락처 중 우선순위가 가장 높고 오래된 연락처에 연결합니다.

이는 해당 대기열의 기존 위치 값을 고려하거나 영향을 미치지 않으며, 해당 값은 연락 초과 라우팅이 상담원과 성공적으로 일치할 때만 업데이트됩니다.

이 라우팅 패턴은 다음과 같은 비기술 기반 큐 유형에서 지원됩니다.

탑다운

하향식 라우팅 패턴은 수신되는 연락을 사용 가능한 순서대로 정렬된 상담원 그룹에 배분합니다. 문의가 대기열에 추가되면 시스템은 항상 상담원 목록을 처음부터 순서대로 순회하며 해당 문의에 대해 문의의 미디어 유형에 맞는 사용 가능한 채널이 있는 첫 번째 상담원과 연결합니다.

이는 대기열에 있는 모든 연락처에 대해 발생합니다. 연락처 일치 여부를 확인하기 위해 항상 목록의 맨 위(첫 번째로 구성된 상담원)부터 시작하여 일치하는 상담원을 찾을 때까지 아래로 순차적으로 진행합니다.

원형 라우팅 패턴과 달리, 마지막으로 선택된 에이전트의 위치에 따라 시작 지점을 동적으로 변경하는 "포인터"가 없습니다.

이 접근 방식은 특정 기준에 따라 순서가 정해진 에이전트들 간에 연락처를 배분하는 데 효과적입니다. / 관리자가 정한 선호도. 이는 최상위 상담원이 하위 상담원보다 항상 고객 문의를 우선적으로 처리하도록 보장하는 데 도움이 됩니다. 하지만 하향식 라우팅 패턴은 현재 업무량이나 상담원이 특정 문의를 처리하는 능력에 영향을 미칠 수 있는 기타 요소를 고려하지 않습니다.

위 예시에서 에이전트는 다음과 같은 순서로 상향식 대기열에 구성됩니다. A3 → A4 → A5 → A6 → A1 → A2.

이는 관리자가 모든 연락처를 사용 가능한 경우 첫 번째 상담원(A3)에게, 그렇지 않으면 사용 가능한 경우 다음 상담원(A4)에게 연결하는 등 구성된 순서대로 라우팅하기를 원한다는 의미입니다.

다음 시나리오를 고려해 보세요.

  • 첫 번째 연락(C1)은 대기열에 추가되고 A3에이전트가 주문의 맨 위에 있으므로 A3 에이전트로 라우팅됩니다.
  • 두 번째 접점(C2)이 대기열에 있을 때 라우팅은 순서의 맨 위에서 다시 시도됩니다(항상 A3로 시작).

    A3에 이 미디어 유형에 대한 채널 용량이 더 많으면 C2A3로 라우팅됩니다. 그러나 A3 이 이 미디어 유형에서 완전히 사용 중인 경우 라우팅은 목록을 따라 A4로 진행됩니다.

  • 하지만 A4A5 는 사용 불가능합니다(로그인조차 되어 있지 않거나, 유휴 상태이거나, 해당 미디어 유형의 다른 연락처와 통화 중이기 때문입니다). 따라서 C2 는 상위 순서에 따라 다음으로 사용 가능한 상담원인 A6으로 연결됩니다.
  • 마찬가지로 세 번째 접점(C3)은 A3 에서 아래쪽으로 라우팅을 시도합니다. 첫 번째 매칭 에이전트는 A1입니다.

    이러한 논리는 고객이 주문 맨 아래까지 연락 가능한 상담원을 찾지 못할 때까지 계속되며, 그 경우에는 대기열에 보관됩니다.

이 라우팅 패턴은 다음과 같은 비기술 기반 큐 유형에서 지원됩니다.

에이전트 기반 라우팅

에이전트 기반 라우팅은 지정된 ("선호하는") 에이전트에게 문의를 직접 연결하거나 대기열에 추가하는 기능입니다. 상담원의 이메일 주소 또는 상담원 ID를 사용하여 상담원을 조회하면 해당 상담원에게 문의가 연결됩니다. 흐름 내의 '대기열에서 에이전트로' 활동은 에이전트 기반 라우팅을 구현하는 데 도움이 됩니다. 자세한 내용은 Queue To Agent 활동을 참조하세요.

연락처는 하나 이상의 선호 상담원과 연결될 수 있으며, 이는 일반적으로 Webex Contact Center 외부의 외부 애플리케이션에서 관리될 수 있습니다. 연락처에 대한 선호 에이전트 조회는 외부 애플리케이션에서 매핑을 가져오는 HTTP 요청 활동을 통해 수행됩니다. 선호하는 상담원에게 문의를 연결하거나 보류하려면 상담원의 Webex Contact Center ID 또는 이메일 주소를 사용하여 '상담원에게 대기열' 활동을 구성하십시오. 선호하는 담당자가 즉시 이용 가능하지 않을 경우, 해당 담당자에게 연락을 보류할 수도 있습니다.

에이전트 기반 라우팅은 다음과 같은 시나리오에서 유용합니다.

  • 선호하는 에이전트 라우팅: 고객은 담당 상담원이나 관계 관리 담당자에게 연락 내용을 배정할 수 있습니다. 이러한 시나리오에서 에이전트 기반 라우팅은 연락처를 선호하는 에이전트에게 직접 연결합니다.
  • 마지막 에이전트 라우팅: 고객이 상담원과 통화하기 위해 콜센터에 여러 번 다시 전화를 걸 경우, 상담원 기반 라우팅 기능을 통해 해당 고객을 마지막으로 응대했던 상담원에게 연결할 수 있습니다.

두 사용 사례 모두에서 연락처 세부 정보와 상담원 매핑 정보는 Webex Contact Center 외부에 저장됩니다.

Flow의 큐잉 및 라우팅 기능

Flow의 큐잉 및 라우팅 기능

Webex Contact Center에서는 다양한 라우팅, 대기열 및 통화 제어 기능을 플로우를 통해 구성할 수 있습니다.

플로우 디자이너에서 제공되는 다양한 플로우 활동 및 이벤트 핸들러를 플로우에 배치하여 수신 및 발신 연락처의 수명 주기를 효과적으로 관리할 수 있습니다.

흐름 설정 및 사용에 대한 자세한 내용은 Flow Designer를 사용하여 흐름 구축 및 관리를 참조하세요.

대기열 활동

대기열 연락처

큐 연락처 활동을 통해 조직에서 들어오는 활성 큐에 연락처를 추가하여 해당 큐에서 적절한 상담원에게 연결할 수 있습니다.

이 활동을 통해 대기열의 다음과 같은 측면을 관리할 수 있습니다.

  • 우선순위 - 대기 중인 연락처에 1(가장 높음)부터 10(가장 낮음, 기본값)까지의 계층적 중요도를 할당합니다.
  • 기술 요구 사항 - 기술 기반 대기열에서 상담원이 연락을 연결할 자격이 있다고 간주되기 위해 충족해야 하는 기술 기준을 설정합니다.
  • 스킬 완화 - 일정 시간이 지난 후 이전에 설정된 스킬 요구 사항을 조정, 수정 또는 제거하여 요원을 찾을 확률을 높입니다.
  • 상담원 가용성 확인 - 대기 시간을 방지하기 위해 사용 가능한 상담원이 없는 모든 통화 분배 그룹을 통해 시스템이 즉시 확장할 수 있도록 합니다.

우선순위, 스킬 구성 및 상담원 가용성이 연락처 라우팅에 어떤 역할을 하는지에 대한 자세한 내용은 라우팅을 참조하십시오.

연락처 대기열 작업이 성공적으로 완료되면,

  • 이미 적합한 상담원이 있는 경우, 시스템은 해당 문의를 상담원에게 연결하려고 시도합니다.

    이는 메인 흐름 실행을 중단시키고, 구성된 경우 추가 이벤트가 해당 이벤트 흐름을 트리거할 수 있습니다.

  • 일치하는 상담원을 찾지 못하면 해당 문의는 대기열에 보관되어 적합한 상담원이 배정될 때까지 기다립니다.

    이후 흐름 실행은 큐 접촉 활동 이후에 연결된 활동들을 통해 계속되며, 이를 통해 다음과 같은 기능을 사용할 수 있습니다.

    • 대기열에 있는 고객에게 미리 설정된 음악을 재생하려면 PlayMusic 활동을 연결하세요.
    • 고객 요청에 따라 콜백을 등록하려면 Callback 액티비티를 첨부하세요.
    • 다시 대기열에 추가, 즉 현재 대기열에서 연락처를 제거하고 다른 Queue Contact 또는 Queue to Agent 활동을 연결하여 새 대기열에 추가합니다.

적합한 상담원이 배정되면 시스템은 해당 상담원에게 연락을 연결하려고 시도합니다.

성공하면 이로 인해 메인 흐름 실행이 중단되고 구성된 경우 추가 이벤트가 해당 이벤트 흐름을 트리거할 수 있습니다.

큐 연락 활동은 다음과 같은 경우에 작동합니다.

  • 해당 문의는 아직 담당자가 배정되지 않았으며, 상담원에게 연결될 준비가 되어 있습니다.
  • 대기열, 스킬 및 기타 흐름 구성이 올바르게 설정되었습니다.
  • 접촉 횟수는 허용된 25회 진입 지점 및 대기열 전환 한도 내에 유지됩니다.
  • 해당 연락은 허용된 20회 연결 시도 횟수 제한 내에 있습니다.

대체 경로 또는 추가 처리가 필요한 연락처를 원활하게 처리할 수 있도록 오류 처리 경로를 구성하십시오.

이러한 경우 활동이 실패로 끝나고 흐름 실행은 오류 처리 경로로 이동합니다.

기술 요구 사항, 기술 완화 및 상담원 가용성 확인과 같은 기능은 팀이 지정된 대기열이 선택된 경우에만 대기열 연락 활동에서 사용할 수 있습니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 대기열 연락처.

상담원 연결 대기열

'상담원 연결 대기열' 활동을 사용하면 Webex Contact Center에서 고유한 상담원 ID 또는 이메일 주소를 조회하여 원하는 상담원에게 직접 문의를 연결할 수 있습니다.

이 활동을 통해 대기열의 다음과 같은 측면을 관리할 수 있습니다.

  • 우선순위 - 할당 higher/lower 동일한 상담원에게 연결된 연락처의 중요도.
  • 보고 대기열 - 녹음 및 기본 음악 대기열과 같은 구성 및 연락처의 보고 목적에 사용할 대기열을 식별합니다.
  • 복구 대기열 - 지정된 기본 상담원에게 연결할 수 없는 경우 대체 수단으로 사용할 대기열을 지정합니다.

상담원 대기열 활동이 성공적으로 완료되면,

  • 상담원이 이미 통화 중인 경우, 문의는 해당 상담원에게 연결됩니다.

    이는 메인 흐름 실행을 중단시키고, 구성된 경우 추가 이벤트가 해당 이벤트 흐름을 트리거할 수 있습니다.

  • 상담원이 통화 가능하지만 전화를 거절하거나, 응답하지 않거나, 연락을 받지 못한 경우, 해당 통화는 제공된 복구 대기열로 이동됩니다.

    복구 대기열에서 해당 문의는 기술 지원 없이 가장 대기 시간이 긴 상담원에게 연결됩니다.

  • 상담원이 부재중이고 "Park Contact If Agent Unavailable" 옵션이 선택된 경우, 연락은 보류되고 상담원이 이용 가능해질 때까지 기다립니다.

    이후 흐름 실행은 '대리점 대기' 활동 이후에 연결된 활동들을 통해 계속되며, 이를 통해 다음과 같은 기능을 사용할 수 있습니다.

    • 대기열에 있는 고객에게 미리 설정된 음악을 재생하려면 PlayMusic 활동을 연결하세요.
    • Callback 활동.
    • 다시 대기열에 추가, 즉 현재 대기열에서 연락처를 제거하고 다른 Queue to Agent 또는 Queue Contact 활동을 연결하여 새 대기열에 추가합니다.

    상담원이 이용 가능해지면 시스템은 해당 상담원에게 문의를 연결하려고 시도합니다.

    이는 메인 흐름 실행을 중단시키고, 구성된 경우 추가 이벤트가 해당 이벤트 흐름을 트리거할 수 있습니다.

  • 상담원을 사용할 수 없고 "Park Contact If Agent Unavailable" 옵션이 선택되지 않은 경우 대기열이 실패합니다.

상담원 대기열 활동은 다음과 같은 경우에 작동합니다.

  • 해당 문의는 아직 담당자가 배정되지 않았으며, 상담원에게 연결될 준비가 되어 있습니다.
  • 선호하는 상담원 ID 또는 이메일 주소가 유효합니다.
  • 보고 대기열과 복구 대기열이 올바르게 구성되었습니다.
  • 담당 상담원이 로그인되어 있고, 연락 가능한 상태이며, 문의를 처리할 준비가 되어 있습니다.

선호하는 상담원을 사용할 수 없을 때 문의가 원활하게 연결되도록 복구 대기열을 구성하십시오.

이러한 경우 활동이 실패로 끝나고 흐름 실행은 오류 처리 경로로 이동합니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 에이전트 대기열.

통화 분배 그룹 확대

에스컬레이트 통화 분배 그룹 활동은 팀 할당이 있는 큐 에 대해서만 지원되며, 구성된 대기 시간 후에 다음 그룹으로 자동 확장 업데이트가 발생할 때까지 기다리는 대신 연락처에 대한 통화 분배 그룹 을 즉시 업데이트할 수 있는 기능을 제공합니다. 이를 통해 대기 중인 모든 적격 상담원에게 문의를 신속하게 연결할 수 있습니다.

통화 분배 그룹 에스컬레이션 활동을 사용하면 문의를 다음 담당자에게 에스컬레이션할 수 있습니다.

  • 다음 그룹— 바로 다음 통화 배포 그룹에 추가된 팀을 포함하도록 팀 집합을 확장합니다.
  • 마지막 그룹— 큐에 대해 구성된 모든 통화 분배 그룹에 매핑된 모든 팀을 포함하도록 팀 집합을 확장합니다.

통화 분배 그룹 에스컬레이션 활동은 다음과 같은 경우에 작동합니다.

  • 해당 문의는 이미 접수 대기 중이며, 에스컬레이션 준비가 완료되었습니다.
  • 해당 연락처는 통화 분배 그룹을 사용하는 대기열에 추가됩니다.

표준 라우팅을 사용하는 큐의 경우, 큐에 구성된 라우팅 동작을 통해 연락처를 계속 배포합니다.

이러한 경우 활동이 실패로 끝나고 흐름 실행은 오류 처리 경로로 이동합니다.

예를 들어, 연락처가 30초 간격으로 업데이트되는 3개의 통화 분배 그룹으로 구성된 대기열에 추가되는 시나리오를 생각해 보겠습니다.

CDG 1CDG 2팀에는 상담원이 없으며, 마지막 통화 분배 그룹에 속한 TEAM 3 에는 상담원이 있습니다.

통화 분배 그룹 에스컬레이션 활동을 워크플로에서 사용하지 않으면 아래 그림과 같이 대기 시간이 길어집니다.

대기 시간은 에스컬레이션 통화 분배 그룹 활동을 다음과 같이 사용함으로써 줄일 수 있습니다.

다음 그룹 또는 마지막 그룹 옵션을 선택하면 아래 그림과 같이 연락 대기 시간이 상당히 단축됩니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 통화 분배 그룹 에스컬레이트.

대기열 정보 활동

대기열 정보 가져오기

'대기열 정보 가져오기' 활동은 다음과 같은 특정 연락처에 대한 실시간 대기열 정보를 가져오는 기능을 제공합니다.

  • 연락처의 현재 대기열 위치(PIQ) 또는 아직 대기열에 등록되지 않은 경우 예상되는 위치입니다.
  • 예상 대기 시간(EWT) 또는 작업이 응답되기 전에 큐에서 대기하는 것으로 예상되는 기간입니다.
  • 해당 연락처의 현재 통화 분배 그룹에 로그인했거나 사용 가능한 상담원 수입니다.
  • 선택한 대기열에 대해 모든 통화 분배 그룹에서 로그인했거나 사용 가능한 상담원 수입니다.
  • 대기열에서 가장 오래된 연락처가 기다린 시간입니다.

이러한 세부 정보는 플로우 실행 중에 활동 출력 변수로 제공됩니다.

활동 사용, 각 큐 세부 정보에 대한 자세한 정의 및 계산 방법에 대한 자세한 내용은 흐름 구축 및 관리]를 참조하십시오. > 큐 정보 가져오기.

대기열 정보를 활용하는 몇 가지 방법은 다음과 같습니다.

  • 고객이 연결을 기다리는 동안 대기열에서의 순서와 예상 대기 시간을 고객에게 알려줍니다.
  • 예상 대기 시간이 너무 길 경우 고객에게 콜백 요청을 등록할 수 있는지 여부를 결정합니다.
  • 현재 통화 분배 그룹(CDG)에 연결된 팀에 상담원이 없는 경우, 해당 문의를 다음 CDG로 이관합니다.

Get Queue Info 활동은 선택한 변수가 유효한 큐로 확인될 때 작동합니다.

선택한 변수에 대한 유효성 검사가 필요하거나 사용 가능한 큐로 연결되지 않는 경우를 적절하게 처리할 수 있도록 오류 처리 경로를 구성하십시오.

다음과 같은 경우에는 현재 통화 분배 그룹에 대한 실시간 대기열 정보가 적용되지 않습니다.
  • '대기열 정보 가져오기' 활동이 실행될 때 연락처는 (아직) 대기열에 추가되지 않았습니다.
  • 해당 문의는 통화 분배 그룹 개념을 지원하지 않는 대기열에 대기 중입니다.

이 경우 출력 필드에 -1이라는 값이 표시되면 해당 정보가 적용되지 않음을 의미합니다.

예를 들어, 고객이 대기열에서 15초를 기다릴 때마다 대기 시간이 길어졌음을 알려야 하는 시나리오를 생각해 보겠습니다.

이는 다음과 같이 플로우에서 "큐 정보 가져오기" 활동을 사용하여 수행할 수 있습니다.

고급 대기열 정보

고급 대기열 정보 활동을 통해 특정 연락처에 대한 실시간 대기열 정보를 가져올 수 있으며, 다음과 같은 연락처의 기술 기준도 추가로 고려할 수 있습니다.

  • 연락처의 현재 대기열 위치(PIQ) 또는 아직 대기열에 등록되지 않은 경우 예상되는 위치입니다.
  • 주어진 기술 기준에 부합하는, 해당 연락처의 현재 통화 분배 그룹 내에서 로그인했거나 사용 가능한 상담원 수입니다.
  • 선택한 대기열에 대해 주어진 기술 기준과 일치하는 모든 통화 분배 그룹에서 로그인했거나 사용 가능한 상담원 수입니다.
  • 현재 통화 분배 그룹은 해당 연락처가 지정된 대기열에 대기 중인 위치입니다.
  • 제공된 대기열에 있는 통화 분배 그룹의 총 개수입니다.

이러한 세부 정보는 플로우 실행 중에 활동 출력 변수로 제공됩니다.

활동 사용, 각 큐 세부 정보에 대한 자세한 정의 및 계산 방법에 대한 자세한 내용은 흐름 구축 및 관리]를 참조하십시오. > 고급 대기열 정보.

고급 대기열 정보를 활용하는 몇 가지 방법은 다음과 같습니다.

  • 고객이 연결을 기다리는 동안 대기열에서 자신의 순서를 고객에게 알리기 위한 것입니다.
  • 현재 통화 분배 그룹에 연결된 팀에 해당 기술 기준에 맞는 상담원이 없는 경우, 다음 통화 분배 그룹으로 문의를 이관합니다.
  • 모든 통화 분배 그룹에서 해당 기술 기준에 맞는 상담원이 로그인되어 있지 않은 경우, 고객에게 콜백을 등록할 수 있는지 여부를 결정합니다.

고급 대기열 정보 활동은 다음과 같은 경우에 작동합니다.

  • 큐 정보는 큐 수준의 스킬 기준이 아닌, 워크플로 내에서 스킬 요구 사항이 구성된 큐에 대해 요청됩니다.
  • 연락처가 이미 대기열에 있는 경우, 해당 연락처가 현재 대기 중인 동일한 대기열에 대한 정보가 요청됩니다.
  • 문의는 지정된 상담원에게 바로 연결되는 것이 아니라 대기열에 등록됩니다.

이러한 요구 사항을 충족하지 않는 요청을 관리하도록 오류 처리 경로를 구성하십시오.

이러한 경우 활동이 실패로 끝나고 흐름 실행은 오류 처리 경로로 이동합니다.

고객에게 필요한 기술 기준을 충족하는 상담원이 없는 경우, 콜백이 예정되어 있음을 알려야 하는 상황을 예로 들어 보겠습니다.

이는 다음과 같이 플로우에서 고급 큐 정보 활동을 사용하여 구현할 수 있습니다.

통화 제어 활동

발신자 번호 표시 설정

발신자 번호 설정 활동은 통화 중에 표시될 발신자 번호를 정의하는 데 사용됩니다. 발신자 번호 설정 활동은 사전 다이얼 이벤트 흐름에서 이벤트 흐름의 끝을 나타내는 최종 활동으로만 사용해야 합니다.

발신자 번호 설정 활동을 통해 발신 번호 식별 서비스(DNIS), 운영 유형 또는 참여자 유형에 따라 필요한 자동 번호 식별(ANI)을 구성할 수 있습니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 발신자 번호 표시 설정.

녹화 제어

녹음 제어 활동은 발신자로부터 녹음 동의를 얻기 위해 메뉴 활동과 함께 사용하도록 설계되었습니다. 이를 통해 녹화 시작 전 명시적 동의를 요구하는 규정이나 정책을 준수하고, 해당 단계를 워크플로에 원활하게 통합할 수 있습니다.

메뉴 IVR 활동은 사용자의 동의 여부를 부울 변수에 저장해야 하며, 이 변수는 녹음 제어 활동의 입력으로 사용됩니다. 고객이 동의 보고서에 사용자 동의 여부를 보고해야 하는 경우, 동의 값은 보고 가능한 전역 변수에 저장되어야 합니다. 또는 보고가 필요하지 않은 경우 로컬 변수를 사용할 수 있습니다. 이러한 접근 방식은 임차인과 고객에게 변수를 효과적으로 관리하고 활용하는 데 있어 향상된 유연성을 제공합니다.

이 활동이 워크플로에 추가되면 사용자의 동의가 테넌트 수준, 큐 수준 또는 녹화 일정 수준의 구성 설정보다 우선 적용됩니다.

우선순위는 다음과 같습니다.

  • 사용자 동의 단계에서 '예'를 선택하면 테넌트, 큐 또는 녹음 일정 수준에서 설정된 녹음 구성과 관계없이 통화가 녹음됩니다.
  • 사용자가 해당 활동에 대한 응답으로 동의하지 않으면 테넌트, 큐 또는 녹음 일정 수준에서 설정된 녹음 구성과 관계없이 통화는 녹음되지 않습니다.
  • 만약 녹음 제어 활동이 흐름에 구성되어 있지 않더라도, 테넌트, 큐 또는 녹음 일정과 같은 다른 수준 중 하나라도 '예'로 설정되어 있으면 통화가 녹음됩니다.
  • 만약 녹음 제어 활동이 흐름에 구성되어 있지 않고, 테넌트, 큐, 녹음 일정 등 모든 수준에서 구성이 '아니요'로 설정되어 있으면 통화는 녹음되지 않습니다.

이 녹화 제어 방식은 아래와 같이 설명할 수 있습니다.

또한, '전송 시 계속', '일시 중지 후 재개', '일시 중지 시간' 등의 녹화 구성은 테넌트, 큐 또는 녹화 일정 수준을 포함한 기존 계층 구조에 따라 계속 적용됩니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 녹화 제어.

블라인드 전송

블라인드 트랜스퍼는 상담원 개입 없이 IVR 시스템을 통해 외부 전화번호(DN)로 효율적으로 연결을 전환하는 프로세스입니다.

블라인드 트랜스퍼 기능은 통화를 외부 또는 제3자 DN으로 연결해야 할 때 사용됩니다. 이는 최종 단계 활동이므로, 송금이 실행되면 전체 과정이 종료됩니다.

상담 목적으로 워크플로가 실행될 때 블라인드 전송 활동은 지원되지 않습니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 블라인드 전송.

브리지드 트랜스퍼

브리지드 트랜스퍼(Bridged Transfer) 활동을 사용하면 통화 흐름이 통화 제어권을 유지하면서 연락처를 일시적으로 외부 대상으로 전송할 수 있습니다. 외부 대상은 외부 브리지 또는 대화형 음성 응답(IVR) 서비스일 수 있습니다.

외부 발신자가 통화를 종료하면, 상담원 연결 등 필요한 절차에 따라 통화 흐름이 계속 진행됩니다.

브리지 전송 활동은 연락처를 대기열에서 제거하는 동시에 타사 IVR 또는 자동 통화 분배(ACD) 시스템으로 전송합니다. 제3자 시스템에서 문의를 처리하지 못하는 경우, 해당 문의를 원래 대기열로 다시 추가하여 문의가 적절한 처리를 위해 워크플로 내에 유지되도록 할 수 있습니다.

예를 들어, 컨택 센터에 Webex 컨택 센터 상담원 리소스와 외부 콜센터 또는 사설 교환기(PBX)의 상담원 리소스가 모두 있다고 가정해 보겠습니다. 고객은 웹엑스 컨택센터 상담원 대기열에 잠시(예: 60초) 통화를 등록하려고 합니다. 해당 기간 동안 상담원이 없을 경우, 통화는 외부 콜센터로 자동 이관되어 처리될 수 있습니다(이때 콜백은 암묵적으로 발생합니다).

  1. 브리지드 트랜스퍼(Bridged Transfer) 기능은 아웃바운드 통화 흐름 및 이벤트 흐름에서 지원되지 않습니다.
  2. 이미 상담원에게 배정된 연락처는 해당 흐름을 통해 브리지 전송이 지원되지 않습니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 브리지 전송.

접점 분리

연락처 연결 해제 활동은 흐름에서 직접 활성 연락처를 연결 해제하거나 종료할 수 있는 기능을 제공합니다.

이는 흐름에 첨부된 최종 활동으로, 상담원 개입 없이 연락을 종료하는 데 유용하며, 오류 처리 흐름이나 고객에게 콜백을 요청한 후에 적합합니다.

설정에 따라, 이 활동을 통해 통화가 종료될 때 통화 후 설문 조사 또는 피드백이 실행됩니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 접점을 분리합니다.

연락처 우선순위 설정

연락처 우선순위 설정 활동은 연락처에 특정 우선순위 수준을 할당할 수 있도록 함으로써 워크플로 내에서 효과적인 연락처 우선순위 관리를 용이하게 합니다. 이를 통해 특정 문의에 더 높거나 낮은 중요도를 부여하여 상담원이 이용 가능해지면 대기 중인 다른 문의와 비교하여 적절하게 연결될 수 있습니다. 이러한 유연성을 통해 전체 프로세스에서 연락 우선순위를 정밀하게 제어할 수 있습니다.

우선순위는 1(가장 높음)부터 9(가장 낮음)까지의 계층적 중요도 수준을 할당하여 설정됩니다. 우선순위가 가장 높은 문의는 우선순위가 낮은 문의보다 먼저 처리됩니다. 여러 고객이 동일한 우선순위를 공유하는 경우, 대기 시간이 가장 긴 고객이 다음으로 이용 가능하고 적합한 상담원에게 먼저 연결됩니다. 이 시스템은 우선순위가 높은 문의에 대해 신속한 처리를 보장하는 동시에 대기 시간을 기준으로 우선순위가 같은 문의 간에 공정성을 유지합니다.

  1. 연락처 우선순위 설정 활동은 메인 흐름이나 이벤트 흐름 내 어느 위치에든 배치할 수 있습니다.
  2. '연락처 우선순위 설정' 활동이 '연락처 대기열' 또는 '상담원 대기열'과 같은 대기열 활동보다 먼저 구성된 경우, 후속 대기열 활동에서 명시적으로 구성된 우선순위에 의해 해당 우선순위 설정이 재정의될 수 있습니다. 하지만 후속 대기열 활동에서 우선순위를 지정하지 않으면 이전 연락처 우선순위 설정 활동에서 설정한 연락처 우선순위가 적용됩니다.
  3. 반대로, '연락처 우선순위 설정' 활동이 '연락처 대기열 생성' 또는 '상담원 연결 대기열 생성'과 같은 대기열 생성 활동 이후에 구성된 경우, 이전 대기열 생성 활동에서 구성된 우선순위 설정을 재정의합니다.
  4. 발신 전화 및 캠페인 연락처에 대해서는 연락처 우선순위 설정 기능이 현재 지원되지 않습니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 연락처 우선순위 설정.

콜백 활동

수신

콜백 기능은 발신자가 대기하는 대신 콜백을 요청할 수 있도록 하여 대기 시간을 줄이고 통화 포기율을 최소화함으로써 고객 만족도를 크게 향상시킵니다. 콜백 기능이 활성화되면 대기열에 작업이 생성되어 이용 가능한 상담원이 고객에게 전화를 다시 걸 수 있도록 합니다.

흐름 설계자는 통화가 시작된 원래 대기열에 연락처를 유지하거나 선호도에 따라 다른 대기열로 할당하도록 활동을 구성할 수 있습니다. 콜백 요청이 원래 대기열에 남아 있는 경우, 해당 연락처는 순서, 기술, 우선순위 및 상황 정보를 유지하므로 다음으로 이용 가능한 상담원에게 원활하게 배정될 수 있습니다. 하지만 다른 대기열을 선택하면 해당 연락처는 아무런 기술도 없이 기본 우선순위로 선택된 대기열의 맨 뒤로 밀려납니다.

또한 이 기능을 통해 고객은 원하는 상담원에게 콜백을 요청할 수 있어 개인적인 맞춤 서비스를 제공하고 고객 만족도를 높일 수 있습니다. 이는 콜백 활동이 흐름에서 QueueToAgent 활동 다음에 오는 경우에 달성할 수 있습니다. 또한 콜백 활동은 콜백 프로세스 중에 사용되는 자동 번호 식별(ANI)을 사용자 지정할 수 있는 선택적 구성을 제공합니다. 이러한 맞춤 설정은 브랜드 일관성을 유지하고 발신자 번호를 쉽게 알아볼 수 있도록 하여 통화 거절 가능성을 줄여줍니다.

이벤트 흐름 설계자는 이벤트 흐름에 콜백 실패 이벤트를 포함할 수 있는 옵션을 가지고 있습니다. 이 이벤트는 콜백 시도가 실패할 때 발생하며, 이를 통해 플로우 설계자는 특정 간격으로 재시도를 구현할 수 있습니다. 재시도 간격은 '대기' 활동을 사용하여 구성할 수 있으며, 최소 재시도 간격은 10초, 최대 재시도 간격은 72시간입니다. 이 시스템은 대기 활동을 사용하여 최대 14일 동안 최대 10번의 재시도를 지원합니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 콜백.

콜백 일정 예약

예약 콜백 기능은 고객이 특정 미래 날짜와 시간에 콜백을 요청할 수 있는 편리함을 제공하여 상담원과의 즉각적인 연결 필요성을 없애줍니다. 이 기능은 고객이 편리한 콜백 시간을 선택할 수 있도록 함으로써 고객 경험을 개선하고, 체감 대기 시간을 최소화하며 통화 포기율을 낮춥니다.

해당 흐름은 DTMF 프롬프트를 통해 발신자가 선호하는 날짜 및 시간과 같은 입력을 캡처하고 필요한 입력 유효성 검사를 수행한 후 해당 액티비티로 전달해야 합니다.

시작하기 전에 Control Hub의 채널 설정 에서 콜백 기본 진입점 이 구성되어 있는지 확인하십시오. 자세한 내용은 콜백 진입점 설정을 참조하세요.

콜백 예약은 수신 또는 발신 전화 대기열을 포함한 모든 전화 대기열을 사용하여 진행할 수 있습니다. 최상의 결과를 얻으려면 예약된 콜백 활동 바로 다음에 연결 해제 활동을 추가하여 콜백이 예약되면 현재 통화가 제대로 종료되도록 하는 것이 좋습니다. IVR 콜백 예약에 대한 자세한 내용은 IVR 콜백 예약을 참조하세요.

요청된 미래 날짜 및 시간에 콜백이 트리거되면 새로운 통화 또는 상호 작용이 생성됩니다. 이 새로운 상호 작용은 콜백 기본 진입점과 연결된 표준 흐름을 따릅니다. 콜백 시도가 실패하면 해당 플로우에 구성된 경우 CallbackFailed 이벤트 핸들러를 사용하여 자동으로 호출을 재시도할 수 있습니다.

활동에 입력을 전달하기 전에 다음과 같은 입력 유효성 검사를 고려해야 합니다.

  1. 날짜 선택 - 오늘부터 최대 31일 후까지 원하는 날짜를 선택할 수 있습니다. 날짜는 다음 형식이어야 합니다. YYYY-MM-DD 형식 (예: 2025-07-18).
  2. 시간 범위 시작 및 종료 시간 - 선택하는 시간은 현재 시간으로부터 최소 30분 후부터 시작해야 하며, 30분에서 8시간 사이의 어떤 시간이든 가능합니다. 24시간 형식(예: 14:30:00)을 사용해 주십시오.
  3. 시간대—정확한 시간에 연락드릴 수 있도록 IANA 형식(예: America/New_York)으로 유효한 시간대를 입력해 주세요.

본 예제에서는 해당 활동과 함께 사용되는 DTMF 프롬프트 및 기본 유효성 검사를 보여주는 서브플로우 템플릿 형태의 참조 구현을 제공합니다. 자세한 내용은 예약된 콜백 서브플로우 템플릿을 참조하세요.

통화 진행 분석

통화 진행 분석(CPA) 활동을 통해 콜백 통화에서 자동 응답 시스템과 실제 상담원 음성을 감지할 수 있습니다.

콜백 시도가 자동응답기 감지(AMD) 또는 음성메일로 연결되면 시스템은 해당 통화를 실패로 간주합니다. 자동응답기 감지(AMD) 결과는 CallbackFailed 이벤트 핸들러의 reason 출력 변수에 기록됩니다. 이 출력 변수를 기반으로 흐름 설계자는 콜백 재시도 횟수를 구성할 수 있습니다.

  1. 콜백 요청을 위한 안내 메시지의 경우, CallProgressAnalysis는 메인 플로우의 콜백 활동 이후에 배치할 수 있습니다. 예약된 콜백 또는 개인 예약 콜백의 경우, 메인 흐름에서 NewPhoneContact 다음에 배치할 수 있습니다.
  2. 이벤트 흐름에서 이는 CallbackFailed 이벤트 핸들러에서만 지원됩니다.
  3. 통화 후 고객 설문조사(피드백 활동)가 워크플로에 구성된 경우, 자동응답 시스템(AMD)이나 음성메일로 통화가 연결되면 설문조사가 시작되지 않습니다. 이렇게 하면 불필요한 설문조사가 발생하는 것을 방지할 수 있습니다.

활동 설정, 사용법 및 출력 변수에 대한 자세한 내용은 흐름 구축 및 관리 를 참조하세요. > 통화 진행 분석.

대기 중

개요

Webex Contact Center에서 대기열은 전화 통신, 채팅, 이메일 또는 소셜 채널과 같은 수신 상호 작용을 위한 보류 영역 역할을 합니다. 문의는 상담원에게 자동으로 배포되거나 상담원이 처리를 위해 수동으로 선택할 때까지 대기열에서 대기됩니다. 또한 기술 기반 라우팅, 우선 순위 관리 및 공정한 워크로드 분배와 같은 기능을 지원합니다.

감독자는 대기열을 사용하여 다양한 작업 라인을 관찰하고 컨택 센터에서 작업이 처리되는 방식을 개선할 수 있습니다.

큐를 효과적으로 사용할 경우 얻을 수 있는 몇 가지 주요 이점은 다음과 같습니다.

  • 더 나은 고객 경험: 대기 시간을 관리하고 고객이 도움을 받을 수 있다는 것을 알립니다.
  • 효율성 향상: 통화가 질서 정연하게 처리되도록 하여 혼란과 잘못된 관리를 줄입니다.
  • 연결의 공정한 분배: 단일 상담원에게 과도한 부담을 주지 않도록 상담원 간에 통화를 고르게 분산합니다.
  • 우선 순위 처리: VIP 고객 또는 긴급한 문제와 같은 특정 통화의 우선 순위를 지정할 수 있습니다.

대기열 유형

Webex Contact Center는 균일한 기능을 갖춘 모든 미디어 유형에서 모든 크기와 복잡성의 고객지원센터에 대한 다양한 사용 사례를 사용할 수 있는 여러 유형의 대기열을 지원합니다.

라우팅 연결에서 상담원의 기술을 고려하는 대기열과 그렇지 않은 대기열이 있습니다. 이러한 대기열은 상담원이 연결 작업을 위해 대기열과 연결되는 방식도 다릅니다.

대기열에는 크게 두 가지 범주가 있습니다.

  • 비기술 기반 대기열
  • 기술 기반 대기열

비기술 기반 대기열

비기술 기반 대기열은 상담사와 관련된 기술을 고려하지 않습니다. 다음 옵션을 사용하여 비기술 기반 대기열을 구성할 수 있습니다.

  • 팀 할당
  • 상담사 할당

팀 할당이 있는 비기술 기반 대기열

팀 할당이 있는 비기술 기반 대기열에서는 상담원을 팀으로 구성하고 이러한 팀을 결합하여 CDG(통화 분배 그룹)를 형성할 수 있습니다. 각 그룹 간에 시간 지연을 설정하여 통화 흐름을 관리할 수 있습니다.

통화 분포 그룹은 구성된 시간 간격으로 이 대기열의 연결에 대한 작업을 할 수 있는 여러 수준의 상담사를 정의하는 데 도움이 됩니다. 연결은 팀의 수준에 따라 상담원에게 할당됩니다. 사용 가능한 상담원이 없는 경우 연락처는 다음 팀 그룹을 포함하도록 확장되기 전에 미리 구성된 기간 동안 지정보류됩니다. 이 프로세스는 상담원을 사용할 수 있거나 모든 그룹을 확인할 때까지 계속됩니다.

다음과 같은 유형의 팀을 설정할 수 있습니다.

  • 개별 팀: 상담원을 특정 조직 기능을 나타낼 수 있는 팀으로 구성한 다음 대기열의 일부가 되어 이러한 팀의 상담원에게 연결을 라우팅할 수 있습니다. 효율적인 라우팅을 위해 상담원을 여러 팀에 태그하고 다양한 대기열의 연결을 처리할 수 있습니다.
  • 용량 기반 팀: CBT(용량 기반 팀)는 음성 통화를 용량 기반 직통 번호(DN)로 전달하는 기능으로, 용량에 따라 동시에 처리할 수 있는 통화 수가 결정됩니다. 이 기능을 사용하면 상담원이 시스템에 로그인할 필요 없이 전화를 전화 번호로 라우팅할 수 있으므로 기존의 콜 센터 에이전트가 아니라 음성 메일, 자동 응답 장치 또는 헌트 그룹이 통화에 응답하는 시나리오에 적합합니다. 이 설정에는 팀에 할당된 특정 상담원이 없으며 #을 사용하지 않습니다Webex Contact Center Agent Desktop.

Webex Contact Center에서 팀 할당이 있는 비기술 기반 대기열이 작동하는 방식에 대한 워크플로 다이어그램

이 예에는 대상 확장을 허용하는 세 개의 통화 분산 그룹이 있습니다. 즉, 구성된 시간 간격에 걸쳐 팀 간에 더 많은 상담원으로 확장할 수 있습니다.

첫 번째 통화 분산 그룹에는 A1, A2 및 A5의 3명의 상담원이 구성된 TEAM 1이 포함됩니다.

두 번째 통화 메일 그룹에는 A2, A3 및 A4의 3명의 상담원이 구성된 TEAM 2가 포함되어 있습니다.

세 번째(마지막) 통화 분산 그룹에는 A6과 A7이라는 두 명의 상담원이 구성된 TEAM 3이 포함되어 있습니다.

연락처가 대기 중일 경우 시스템은 먼저 첫 번째 통화 분배 그룹에서 일치하는 상담원을 검색합니다. 상담원을 찾을 수 없는 경우 연결이 구성된 기간 동안 지정보류된 후 대상을 다음 그룹으로 확장합니다. 이렇게 하면 기존 팀에 새 팀이 추가됩니다. 일치하는 항목을 찾거나 모든 그룹이 확장될 때까지 이 프로세스가 반복됩니다.

'상담원 가용성 확인'이라는 기능을 사용하면 현재 그룹에서 일치하는 상담원을 찾을 수 없는 경우 연락처가 즉시 후속 통화 분배 그룹으로 확장됩니다. 이 기능은 흐름의 대기열 연결 활동<LINK TO 섹션 3.1.1>에서 활성화할 수 있습니다.

이 설정으로 인해 다음과 같은 시나리오가 발생합니다.

  1. A2 는 TEAM 1과 TEAM 2에 속합니다. A2가 Agent Desktop에 로그인하기 위해 TEAM 1을 선택하면 시스템에서 A2를 TEAM 1의 일부로 간주하여 첫 번째 통화 분배 그룹으로만 간주합니다.
  2. A5 는 TEAM 1에 속해 있지만 현재 로그인한 조직의 다른 팀에 속해 있을 수도 있습니다. 따라서 A5는 TEAM 1의 일부로 간주되지 않으며 이 대기열과 연결되지 않습니다.

팀 할당이 있는 대기열은 상담원이 로그인 중에 간단히 팀을 선택하여 대기열 사이를 이동할 수 있는 강력한 기능을 제공합니다.

사용 가능한 라우팅 패턴:

상담원이 할당된 비기술 기반 대기열

비기술 기반 대기열은 대기열에 상담원 풀이 직접 할당되는 대기열 유형입니다. 할당된 상담사 풀을 간접적으로 결정하는 다른 대기열 유형과 달리 이러한 대기열을 사용하면 관리자가 직접 및 수동으로 상담사를 선택할 수 있습니다. 예를 들어, 팀 기반 할당 대기열은 로그인한 팀을 기반으로 상담원을 할당하고 기술 기반 할당 대기열은 필요한 기술을 기반으로 상담원을 매칭합니다. 반면 관리자는 직접 상담사를 이러한 대기열에 추가하여 대기열의 일부가 될 수 있습니다. 이를 통해 시스템 기반 할당에 의존하지 않고 상담원 할당을 쉽게 관리할 수 있습니다.

상담원이 할당된 대기열은 상담원 풀 간에 연결을 분배하는 데 도움이 되는 간단하면서도 효과적인 라우팅 알고리즘을 제공합니다. 그들은 라우팅 연결에서 상담원의 기술을 고려하지 않습니다. 그러나 상담원은 각 대기열 내에서 정렬될 수 있으며 이는 상담원에게 문의를 라우팅할 때 고려됩니다. 이러한 맥락에서 팀은 대기열 관리를 단순화하는 상담원-대기열 연결 및 연결 라우팅 결정의 요소라기보다는 주로 슈퍼바이저를 위한 조직적 구성체 역할을 합니다.

이 유형의 대기열은 상담원의 정적 할당 및 상담원-대기열 연결 관리가 실행 가능하고 운영 제어에 적합하며 라우팅 알고리즘 선택이 상담원 간의 작업 분배에 적합한 경우에 가장 적합합니다. 이러한 대기열은 여러 유형의 고객 문의를 위해 사전 작성된 전문 상담원 세그먼트가 제공할 수 있는 전문 지식이 필요한 시나리오에도 특히 유용합니다.

그러나 복잡한 컨택 센터 조직에서는 이러한 대기열의 상담원 할당을 수동으로 관리하기가 어려울 수 있습니다. 또한 동적 라우팅 및 상담원-대기열 연결을 제공하는 다른 대기열 유형에서 더 많은 이점을 얻을 수 있습니다.

Webex Contact Center에 상담원이 할당된 비기술 기반 대기열의 예가 작동하는 방식을 보여 주는 워크플로 다이어그램

이 예에서 대기열에는 A4, A9, A7 등과 같은 특정 순서로 매핑된 에이전트 집합이 있습니다. 이 순서는 수신 연결을 상담원과 일치시키는 특정 라우팅 알고리즘에서 중요한 역할을 합니다. 시스템은 상담원의 가용성과 선택한 라우팅 알고리즘을 기반으로 이러한 상담원의 연결을 일치시킵니다.

팀 할당이 있는 대기열과 달리, 시간 간격에 따른 대상 확장 대한 개념은 없습니다. 구성된 상담원 중 이 연결을 라우팅할 수 있는 상담원이 없는 경우 이러한 상담원 중 한 명이 지정보류 시간 초과 전에 연결을 처리할 수 있을 때까지 대기열에서 지정보류됩니다. 대상 확장 은 이러한 대기열에 적용할 수 없습니다.

사용 가능한 라우팅 패턴:

기술 기반 대기열

기술 기반 대기열은 요구 사항을 충족하는 올바른 기술을 갖춘 상담원에게 연결을 라우팅하는 기능을 제공합니다.

다음과 같은 유형의 기술 기반 옵션을 구성할 수 있습니다.

대기열에 할당된 기술 기준

관리자는 대기열에 기술 기준을 할당할 수 있습니다. 기술 기준이 있는 기술 기반 대기열을 사용하면 관리자가 대기열에서 직접 필요한 기술을 구성할 수 있습니다. 직접 직무 프로파일을 통해 대기열의 모든 필수 기술을 보유한 조직의 모든 상담원은 암시적으로 이 대기열의 일부가 됩니다.

이 설정은 관리자가 기술을 통해 대기열에 매핑되는 상담사를 실시간으로 볼 수 있도록 도와줍니다. 볼륨이 높거나 적은 경우와 같은 상황에서 관리자는 대기열 및 상담원 직무 프로파일의 필요한 기술을 조정하여 필요에 따라 상담원 풀을 확장하거나 축소하는 것을 고려할 수 있습니다.

이 유형의 대기열은 통화 배포 그룹 설정이 없다는 점에서 팀 할당 기반 대기열과는 다릅니다. 즉, 팀이 상담원과 대기열 간 연결에서 아무런 역할도 하지 않습니다. 또한, 흐름이 (정적 또는 가변) 필수 기술을 주입하는 팀 기반 기술 대기열과 달리, 필요한 기술은 이 대기열에서 정적으로 구성됩니다. 따라서 기술적으로 기술은 연락처 자체가 아니라 대기열의 일부입니다.

조직에서 대기열의 직무 기준을 완전히 만족하는 상담원(직접 직무 프로파일의 직무를 가짐)은 암시적으로 이 대기열과 연관됩니다. 팀은 이러한 대기열과의 상담원 연결에서 어떤 역할도 수행하지 않습니다. 이러한 상담원은 관리 및 운영 목적으로 어느 팀에나 속할 수 있습니다.

이 대기열에 대기된 모든 연결은 자동으로 대기열 자체에 정의된 기술 기준을 따릅니다. 개별 연결은 팀 할당이 있는 기술 기반 대기열에서와 달리 자신의 기술 요구 사항/기준을 정의하거나 재정의할 수 없습니다.

Webex Contact Center#에서 직무 기준이 있는 직무 기반 대기열이 작동하는 방식을 보여 주는 워크플로 다이어그램

이 예에서

  • 상담원 A1, A3 및 A7만 대기열에 구성된 직무 기준을 완전히 충족하므로 이러한 상담원만 이 대기열에 연결됩니다.
  • 조건을 부분적으로 충족하는 상담원 A2, A4 및 A6 또는 관련 기술이 부족한 상담원 A5는 이 대기열에 연결할 수 없습니다.

대기열의 직무 기준을 만족하도록 상담원의 직무 프로필을 업데이트(재교육이라고 함)하면 해당 상담원은 자동으로 동적으로 이 대기열의 일부가 됩니다. 또는 더 많은(또는 적은) 상담사가 업데이트된 직무 기준을 충족하도록 대기열 직무 기준 자체를 업데이트하면 이 대기열에서 상담사를 자동으로 동적으로 추가(또는 제거)합니다.

팀 할당이 있는 대기열과 달리, 시간 간격에 따른 대상 확장 대한 개념은 없습니다. 연결을 연결된 상담원과 일치시킬 수 없는 경우 지정보류 시간 제한 전에 이러한 상담원 중 한 명이 연결을 처리할 수 있을 때까지 대기열에 지정보류됩니다.

기술 기반 대기열은 직무를 정적으로 할당하고 대기열을 상담원 연결에 관리하는 것이 실행 가능하고 운영 제어에 적합한 경우에 가장 적합합니다. 또한 라우팅 알고리즘 선택이 상담원 간의 작업 분배에 적합한 경우에도 적합합니다. 이러한 대기열은 다양한 유형의 고객 문의에 대해 사전에 파생된 전문 상담원 세그먼트가 제공할 수 있는 특정 기술을 필요로 하는 시나리오에도 특히 유용합니다.

복잡한 컨택 센터 조직에서는 각 상담원을 목록에 수동으로 추가해야 하는 상담원 할당이 있는 대기열에 비해 기술 기반 대기열에서 상담원 간 할당을 관리하는 것이 더 쉬울 수 있습니다. 이는 특히 대규모 조직의 경우 번거롭습니다.

흐름에 할당된 기술 요구 사항

흐름에서 기술 요구 사항이 할당된 기술 기반 대기열은 Webex Contact Center에 있는 팀 할당 기반 대기열의 한 유형으로, 여기에서 팀 집합이 여러 수준으로 구성되며 통화 배포 그룹이라고 합니다. 이와 같이 구성된 팀에 로그인된 상담원이 연락처의 기술 요구 사항을 완전히 충족하는 경우 해당 팀이 대기열에서 구성한 통화 배포 그룹 수준에 따라 이 대기열의 연락처에 할당됩니다.

이러한 대기열 내에서 상담원 팀은 구성 가능한 시간 지연을 사용하여 통화 분배 그룹으로 그룹화됩니다. 연결에 사용할 수 있는 상담원이 없으면 요청이 지정보류되고 지연 후 라우팅이 다음 통화 분배 그룹으로 확장됩니다. 이 프로세스는 상담원이 할당되거나 모든 그룹이 소진될 때까지 계속됩니다. 한편, 이전에 선택한 그룹의 상담원이 이 프로세스 중에 사용 가능 상태가 되면 해당 상담원이 선택됩니다.

상담원은 상담원에게 직접 할당된 직무 프로파일을 통해 직무를 습득합니다. 상담원 기술은 사인인 도중 선택한 팀에 따라 결정됩니다.

각 연결에서는 필요에 따라 흐름의 기술 요구 사항을 지정할 수 있으며, 이 요구 사항은 사용 가능한 상담원의 직무와 비교하여 가장 적합한 상담원을 선택할 수 있습니다.

또한 연락처에서 구성된 시간 간격으로 기술 완화를 지정할 수도 있습니다. 이는 구성된 시간 간격에 따라 연결의 원래 기술 요구 사항을 덮어쓰는 수정된 기술 요구 사항 집합입니다. 이렇게 하면 더 많은 상담원이 이러한 완화된 기술 요구 사항에 일치하도록 대기열에 지정보류된 동안 연락처가 해당 직무 요구 사항을 수정(일반적으로 "완화"하는 데 사용됨)할 수 있습니다.

통화 분산 그룹을 통한 대상 확장은 직무 완화 주기와 동시에 발생할 수 있습니다. 이 두 가지 모두 지정보류된 연결을 적격 상담원과 더 빨리 일치시켜 전체 대기 시간을 줄이고 대기열의 서비스 수준을 개선하기 위한 것입니다.

Webex Contact Center에서 팀 할당이 있는 기술 기반 대기열이 작동하는 방식을 보여 주는 워크플로 다이어그램입니다.

팀 할당이 있는 비숙련 대기열과 마찬가지로 "대상 확장"을 허용하는 세 개의 통화 분배 그룹이 있습니다. 즉, 구성된 시간 간격 동안 팀 간에 더 많은 상담원으로 확장할 수 있습니다.

  • 첫 번째 통화 메일 그룹에는 3명의 상담원(A1, A2 및 A5)이 구성된 TEAM 1이 포함됩니다.
  • 두 번째 통화 메일 그룹에는 A2, A3 및 A4의 3명의 상담원이 구성된 TEAM 2가 포함되어 있습니다.
  • 세 번째(마지막) 통화 분산 그룹에는 A6과 A7이라는 두 명의 상담원이 구성된 TEAM 3이 포함되어 있습니다.

그러나 주의해야 할 두 가지 주요 사항이 있습니다.

  • 이 대기열에 대기되는 모든 연결은 흐름을 통해 해당 기술 요구 사항 및 기술 완화를 정의합니다.
  • 상담원은 직무를 구성할 수 있습니다(직무 프로파일을 통해 직접 또는 로그인된 팀으로부터 상속됨).

A2는 팀 1과 팀 2 모두의 일부로 구성되지만, 이 상담원이 로그인 중에 선택한 팀에 따라 현재 세션에서는 해당 팀의 일부로 간주되므로 해당 팀으로부터 직무 프로파일(및 직무 값)도 상속됩니다(이 상담원에 대한 직접 직무 프로파일 구성으로 재정의되지 않는 한).

이 기능은 상담원이 로그인하는 동안 간단히 팀을 선택하여 대기열 간을 이동할 수 있는 팀 할당이 있는 대기열에서 제공하는 강력한 기능입니다.

선택한 팀으로부터 직무 프로파일 설정을 상속하는 기능과 더불어 상담원은 다양한 직무 세트를 사용할 수도 있습니다.

이 예에서

  • 연결은 흐름에서 에스컬레이션되는 동안 초기 기술 요구 사항(sk_1 >= 6)으로 대기열에 배치되고 구성된 시간 간격 후에 기술 완화(sk_1 >= 3)됩니다.
  • 모든 통화 배포 그룹의 모든 상담원을 통틀어 A1, A3, A6 및 A7만이 대기 상태에 있는 연결의 초기 기술 요구 사항을 충족하는 기술을 가지고 있습니다.
  • 나머지 상담원은 기술(sk_1)을 가지고 있지만 기술 요구 사항을 충족하지 않거나(예: TEAM 1의 A2 및 TEAM 2의 A4) 이 기술이 전혀 없습니다(예: TEAM 2의 A5, A2).
  • 시간이 지남에 따라 기술 완화 시 추가로 A2 및 A4도 이제 연락처의 "완화된" 기술 요구 사항을 충족합니다.

이 대기열에 대기하는 모든 연락처에 대해 시스템은 첫 번째 통화 배포 그룹에서 연락처의 현재 기술 요구 사항을 완전히 만족하는 일치하는 상담원을 찾으려고 합니다. 일치하는 상담원이 없으면 두 번째 통화 분배 그룹에서 대상 확장이 발생하기 전에 구성된 기간 동안 연결이 지정보류됩니다. 두 번째 통화 분배 그룹에 구성된 모든 팀이 첫 번째 그룹의 기존 팀에도 추가됩니다. 이제 시스템은 확장된 그룹 내에서 일치하는 에이전트를 찾으려고 시도합니다. 이 작업이 진행되는 동안 기술 완화는 구성된 시간 간격으로 연결의 기술 요구 사항도 업데이트하며, 시스템은 업데이트된 기술 요구 사항을 사용하여 현재 통화 분배 그룹의 사용 가능한 상담원과 일치시킵니다.

이 작업은 이전에 일치하는 상담원을 찾지 못한 경우 구성된 모든 통화 메일 그룹이 확장되고 모든 기술 완화가 적용될 때까지 계속됩니다.

사용 가능한 라우팅 패턴:

대기열 구성

기술 기반 대기열 설정

대기열에 기술 기준 할당
  • 스킬 만들기.
  • 기술 프로필을 만듭니다 .
  • 직무 프로파일을 상담원에게 직접 할당합니다.
  • 채널 유형이 텔레포니, 채팅, 전자 메일, 소셜인 대기열을 만듭니다.
  • Control Hub에서 대기열에 스킬 요구 사항을 지정합니다.
  • 대기열의 연결을 처리할 수 있는 상담원 목록 보기
  • 라우팅 알고리즘(LAA 또는 BAA)을 선택합니다.
  • 흐름에 대기열 연결 활동을 추가하고 이 대기열을 선택합니다.
대기열에 기술 요구 사항 할당
  1. 스킬 만들기.
  2. 기술 프로필을 만듭니다 .
  3. 기술 프로파일을 상담원에게 직접 할당하거나 팀에 할당합니다.
  4. 팀을 만듭니다.
  5. 팀에 상담사를 추가합니다.
  6. 채널 유형으로 텔레포니, 채팅, 전자 메일, 소셜 대기열을 만듭니다.
  7. 단일 CDG 또는 여러 CDG의 대기열에 팀을 추가합니다.
  8. 라우팅 패턴(LAA 또는 BAA)을 선택합니다.
  9. 흐름에 대기열 연결 활동을 추가하고 기술 기반 라우팅이 구성된 대기열을 선택합니다. 자세한 내용은 Queue Contact 를 참조하십시오.
  10. 대기열 연결 활동에서 기술 및 기술 완화를 할당합니다.
  11. 흐름 POST 대기열에서 통화 분배 활동 에스칼레이션을 사용하여 다음 통화 분배 그룹 또는 마지막 통화 분배 그룹으로 신속하게 이동할 수 있습니다.

비기술 기반 대기열 설정

대기열에 팀 할당
  • 팀을 만듭니다.
  • 팀에 상담사를 추가합니다.
  • 채널 유형으로 텔레포니, 채팅, 전자 메일, 소셜 대기열을 만듭니다.
  • 단일 CDG 또는 여러 CDG의 대기열에 팀을 추가합니다.
  • 라우팅 패턴 LAA를 선택합니다.
  • 흐름에 대기열 연결 활동을 추가하고 이 대기열을 선택합니다.
  • 흐름 POST 대기열에서 통화 분배 활동 에스컬레이션을 사용하여 다음 통화 분배 그룹 또는 마지막 통화 분배 그룹으로 신속하게 이동합니다.
대기열 흐름에 상담원 할당
  • 채널 유형으로 텔레포니, 채팅, 전자 메일, 소셜 대기열을 만듭니다.
  • 대기열에 직접 상담사 추가(참고: 이 유형의 대기열에서는 스킬과 팀 모두 사용되지 않습니다).
  • 순환, 선형 또는 가장 오랫동안 사용 가능한 상담원과 같은 라우팅 패턴을 선택합니다.

라우팅

라우팅 개념

상담원 초과 시나리오

대기열에 있는 연결 수보다 사용 가능한 상담원 수가 더 많을 때 상담원 잉여 시나리오가 발생합니다. 이 경우 고객 상호 작용(연결)이 대기열에 있는 경우 시스템은 이 특정 연락처에 대해 일치하는 에이전트를 즉시 찾으려고 시도하며, 일치하는 에이전트를 찾으면 연결을 대기열에 지정보류하고 일치하는 에이전트가 나중에 사용할 수 있을 때까지 기다릴 필요가 없습니다.

연결이 통화 분산 그룹을 통해 또는 기술 완화를 통해 확장될 때마다 시스템은 이 특정 연락처에 일치하는 에이전트를 즉시 찾으려고 다시 시도합니다.

특정 연락처에 일치하는 상담원 찾기에는 대기열에 구성된 라우팅 패턴이 사용됩니다.

Webex Contact Center는 다양한 유형의 대기열에 걸쳐 여러 라우팅 패턴을 제공하여 조직이 대기 시간을 최소화하고, 상담원 워크로드의 균형을 조정하고, 고객이 특정 요구 사항을 해결하는 데 필요한 기술을 갖춘 상담원과 연결되도록 하여 고객 서비스를 최적화할 수 있도록 합니다. 라우팅 패턴에 대한 자세한 내용은 라우팅 패턴 섹션을 참조하십시오.

연결 잉여 시나리오

고객 상호 작용(또는 연결)의 수신 수가 사용 가능한 상담원을 초과할 때 고객 잉여 라우팅이 발생합니다. 이러한 상황은 사용량이 가장 많은 시간이나 예기치 않게 접촉량이 급증할 때 자주 발생합니다. 고객 과잉 라우팅의 주요 목표는 이 오버플로를 효율적으로 관리하여 초과 수요에도 불구하고 고객 서비스 표준이 유지되도록 하는 것입니다. 특정 채널에서 방금 대화 가능 상태가 된 상담원의 경우 응답 잉여 라우팅이 이 상담원과 연결된 모든 대기열의 지정보류된 모든 연결 중에서 적절한 연결을 찾아 할당합니다.

제한된 상담원 가용성으로 연결 라우팅을 효율적으로 수행하기 위한 핵심 전략은 다음과 같습니다.

  • 대기열 순위

    대기열 순위를 사용하면 관리자가 대기열의 상대적 중요도를 지정할 수 있습니다. 관리자는 대기열 순위를 정의하여 팀별로 대기열에서 팀에 로그인된 상담원으로 통화가 라우팅되는 순서를 설정할 수 있습니다.

    예를 들어 팀 A에 로그인된 상담사는 "Billing"과 "Sales"라는 두 개의 대기열에 연관되어 있습니다. 관리자는 대기열 순위를 사용하여 "청구" 대기열에 더 높은 순위를 할당할 수 있습니다. 그러면 연결이 대기열에 들어올 때 "청구"의 연결이 "영업" 대기열의 연결보다 먼저 팀 A에 속한 상담원에게 라우팅됩니다. 이는 "판매" 대기열에서 대기 중일 수 있는 오래되고 우선 순위가 높은 연락처가 있더라도 "청구" 대기열의 대기열 순위가 "판매" 대기열보다 높기 때문에 발생합니다. "청구" 대기열에 대기 중인 연락처가 더 이상 없는 경우에만 팀 A의 상담원은 연결된 "영업" 및 기타 대기열에서 연결을 라우팅받습니다.

    다음은 대기열 순위의 몇 가지 중요한 특성입니다.

      • 일부 대기열에만 순위가 할당되면 해당 대기열의 통화가 순위가 지정되지 않은 대기열의 통화보다 우선합니다.
      • 대기열 순위는 모든 미디어 유형에서 최대 50개 대기열에 설정할 수 있으며 값 범위는 1에서 50 사이이며 1이 가장 높은 순위입니다.
      • 여러 대기열에 동일한 순위를 할당할 수 있습니다.
      • 대기열 순위 지정을 활성화하면 명시적 순위가 할당되지 않은 대기열은 순위가 매겨진 모든 대기열보다 낮게 처리됩니다.
      • 대기열 순위는 동일한 미디어 유형 내에서 작동합니다.

        예를 들어 대기열 판매가 순위 2의 음성 미디어 유형 대기열이고 대기열 청구 지원이 팀 A의 순위 1인 채팅 대기열인 경우, 팀 A의 음성 채널에서 사용 가능한 상담원은 순위가 2인 경우에도 먼저 음성 통화를 받습니다.

        그러나 팀 B에 대한 두 개의 채팅 대기열, 즉 대기열 순위가 2인 대기열 신용 카드와 대기열 순위가 1인 대기열 직불 카드가 있다고 가정해 보겠습니다. 그런 다음 팀 B의 사용 가능한 상담원에게 대기열 직불 카드의 연결이 먼저 제공됩니다.

      • 대기열 순위는 용량 기반 팀에는 적용되지 않습니다.

  • 연결 우선 순위

    연락처가 대기열에 있을 때 1(최고)에서 10(최저, 기본값) 범위의 계층적 중요도를 할당하여 우선 순위를 정의할 수 있습니다. 이러한 우선 순위 지정을 통해 조직에 대한 중요성, 긴급성 또는 전략적 가치에 따라 특정 연락처의 주소를 보다 신속하게 처리할 수 있습니다. 상담원이 연결된 모든 대기열에서 지정보류된 모든 연결 중 다음 연결을 처리할 수 있으면 모든 대기열에서 우선 순위가 가장 높은 연결이 해당 상담원에게 라우팅됩니다(기술 일치 등의 다른 기준을 만족하는 경우).

    명시적인 우선 순위 없이 대기열에 있는 연결의 경우 기본 우선 순위 10(최저)이 고려됩니다. 우선 순위가 같은 여러 연결 중에서 대기열에서 가장 오래 대기한 연결은 사용 가능하고 적격한 상담원에게 먼저 라우팅됩니다.

  • 가장 긴 대기 연결

    이것은 상담원이 연결된 모든 대기열에서 가장 오래 대기 중인 연결이 상담원에게 라우팅되도록 하는 기본 전략입니다.

    이 기준은 대기열에서 대기열 순위 및 연결 우선 순위가 같은 여러 연락처가 처리 대기 중인 경우 라우팅할 연결을 결정하는 최종 기준입니다.

기본적으로 방금 대화 가능 상태가 된 상담원에 대한 연락처 잉여 라우팅은 다음과 같은 단일 연락처를 선택하는 것을 의미합니다.

  • 가 상담원을 사용할 수 있는 미디어 유형과 동일한 미디어 유형입니다.
  • 이(가) 이 상담원이 연결된 대기열에 파크되어 있습니다
  • 이 에이전트가 기술 요구 사항(있는 경우)을 모두 충족하는지
  • 가 상담원 팀에 구성된 다른 대기열보다 순위가 높은 대기열에 파크됩니다.
  • 은(는) 이러한 모든 연결 중에서 가장 높은 우선 순위를 갖습니다.
  • 은(는) 우선 순위가 같은 연결 중 가장 오래된 대기 연결

연결 초과 시나리오를 보여주는 위의 예에서 상담원 A1은 TEAM 1에 로그인했으며 여러 미디어 유형의 연결을 처리할 수 있게 되었습니다.

A1은 3개의 대기열(Q1, Q2 및 Q3)과 연결되어 있습니다. 또한 TEAM 1 은 Q1 이 가장 높은 순위의 대기열 순위를 정의한 다음 각각 Q2 Q3 을 정의했습니다 .

각 대기열에 기술 요구 사항 및 우선 순위가 정의된 연결이 이미 모든 대기열에 지정보류되어 있습니다.

이제 연결 초과 시나리오는 다음과 같이 작동합니다.

  • 이러한 대기열에서 지정보류된 모든 연락처 중에서 4개의 연락처만 A1 C2,C7 (대기열 2에서) 및 C3,C8 (대기열 3에서)로 라우팅 될 수 있습니다.

    이 4개의 연락처의 기술 요구 사항만 A1 기술로 완전히 충족됩니다.

  • 대기열 2의 대기열 순위가 더 높으므로 이 4개의 연락처 중에서 QUEUE 2 (즉, C2, C7)의 연락처가 우선합니다.

    대기열 1 이 가장 높은 순위의 대기열이더라도 A1이 직무 요구 사항을 충족하지 않으므로 지정보류된 연결은 A1으로 라우팅할 수 없습니다.

  • C2 C7 사이에서우선 순위가 가장 높은 접촉은 C7 입니다. 따라서 최종 선택은 C7이며 시스템에서 A1 로 라우팅합니다.

    C2 가 더 일찍 대기된 경우에도 연결 우선 순위가 대기 시간보다 우선하기 때문에 이러한 상황이 발생합니다.

혼합 멀티미디어 프로파일

Webex Contact Center을 사용하면 멀티미디어 프로파일 구성을 통해 상담원이 여러 미디어 유형(음성, 채팅, 전자 메일 및 소셜)에 걸쳐 연결 서비스를 제공할 수 있습니다. 이 구성에 따라 상담원은 미디어 유형별로 채널을 프로비저닝받습니다.

상담원에게 라우팅된 모든 연결은 상담원이 해당 연결에서 작업하는 동안 해당 미디어 유형의 채널 하나를 소비합니다. 상담원은 음성 채널을 하나만 가질 수 있지만 기타 미디어 유형의 채널은 최대 5개까지 가질 수 있습니다.

멀티미디어 프로필 혼합 라우팅 설정을 사용하면 관리자가 각 상담원에 대해 서로 다른 채널을 동시에 사용할 수 있는 방법을 제어할 수 있습니다. 이를 통해 조직은 고객에게 전담적인 관심을 제공하여 더 나은 Quality of Service, 향상된 고객 경험 및 더 나은 전환율을 촉진할 수 있습니다. 또한 조직은 일부 채널에서 고르지 않은 부하가 발생할 때 미디어 채널 간에 부하를 분산하여 상담원을 효율적으로 활용할 수 있습니다.

세 가지 선택 사항이 있습니다.

  • 배타적

  • 혼합

  • 혼합 실시간

비음성 연결을 처리할 때 상담원은 음성 채널을 사용할 수 있는 경우 Agent Desktop에서 수동 아웃다이얼 음성 통화를 시작할 수 있습니다. 이는 모든 멀티미디어 프로필 유형에 적용할 수 있습니다.

멀티미디어 프로필 구성에 대한 자세한 내용은 멀티미디어 프로필 관리를 참조하십시오 .

라우팅 패턴

기술 기반

Webex Contact Center의 기술 기반 라우팅 패턴은 언어 숙련도 또는 기술 전문성 등 문의를 해결하는 데 필요한 특정 기술을 기반으로 고객의 수신 상호 작용을 상담원에게 전달합니다. 이러한 패턴을 통해 각 고객은 가장 자격을 갖춘 상담원과 연결되어 서비스 효율성과 고객 만족도를 높일 수 있습니다. 이점으로는 처리 시간 단축, 해결률 향상, 상담원 리소스 사용 최적화, 상담원의 전문성을 고객 요구 사항에 맞춰 최적화하는 것 등이 있습니다.

기술 기반 라우팅 패턴을 사용하는 경우 먼저 연결의 기술 요구 사항(흐름에서 할당됨) 또는 대기열에 할당된 기술 기준을 사용하여 해당 기술이 이러한 요구 사항/기준을 완전히 만족하는 사용 가능한 상담원을 필터링합니다. 그런 다음 필터링된 상담원 중에서 구성된 라우팅 패턴에 따라 연결에 대해 한 명이 선택됩니다.

가장 오래 사용할 수 있음

최장 사용 가능 직무 기반 라우팅 패턴은 연결 기술 요구 사항/대기열 기술 기준을 완전히 충족하는 기술을 보유한 상담원과 해당 대기열에 있는 모든 적격 상담원 중에서 마지막 연결을 처리한 이후 가장 오랫동안 사용 가능한 상담원에게 연결을 라우팅합니다.

이 라우팅 패턴은 가장 오래 사용할 수 있었던 사람들에게 상호 작용을 할당함으로써 작업 부하를 방지함으로써 상담원 간에 작업을 고르게 분산하는 데 도움이 됩니다. 작업 분배의 공정성을 유지하는 데 도움이 되며, 다른 상담원은 자유롭게 작업하는 동안 상담원에게 과도한 부담이 발생하지 않도록 합니다.

위의 예에는 숙련도 직무 값이 서로 다른 숙련도 및 비숙련도 직무를 보유한 4명의 상담원이 있습니다.

어떤 연결이 "가장 오래 사용 가능한" 라우팅 패턴을 가지는 직무 기반 대기열에 대기되어 있다고 가정합시다.

  • 흐름을 통해 위의 기술 요구 사항이 할당된 경우, 또는
  • 기술 기반 대기열에서 위의 기술 기준을 구성합니다.

이 시나리오의 내용은 다음과 같습니다.

  • 연결 기술 요구 사항/대기열 기술 기준을 완전히 충족하는 상담원만 라우팅 대상으로 고려됩니다. 상담원 A1, A2A4 만 연결 기술 요구 사항/대기열 기술 기준을 완전히 충족합니다.

    상담원 A3 은 적합하지 않습니다. 대기열 에 할당된 기술 기준의 경우 A3 은 대기열과 연관되지도 않습니다.

  • A1, A2 A4 중에서 연결이 가장 긴 상담원인 A1에게 라우팅됩니다. 상담원은 A2 또는 A4보다 긴 10분 이상 사용 가능했습니다.

    A1 에게 연결이 할당되었으므로 A1 은 더 이상 모든 미디어 채널을 통틀어 가장 오래 사용할 수 있는 상담원이 아닙니다.

  • 기술 요구 사항이 정확히 동일한 다음 연결은 사용 가능한 시간이 그 다음으로 긴 상담원 인 A2에게 라우팅되는 방식입니다.

이 라우팅 패턴은 다음과 같은 유형의 기술 기반 대기열에서 지원됩니다.

최고의 사용 가능

사용 가능한 최상의 기술 기반 라우팅 패턴은 고객 상호 작용이 가장 자격을 갖춘 상담원에게 전달되도록 합니다. 이 패턴은 상담원 간에 필요한 기술이 있는지뿐만 아니라 이러한 기술의 숙련도 수준도 평가하여 직무 점수를 계산하여 각 연결에 대해 가장 적격한("최상") 상담원을 결정합니다.

이 패턴은 직무가 연결 직무 요구 사항/대기열 직무 기준을 완전히 충족하는 사용 가능한 상담원을 필터링합니다. 그런 다음 연결 기술 요구 사항/대기열 기술 기준에 언급된 모든 기술의 숙련도 값을 사용하여 각 적격 상담원에 대해 점수를 계산합니다. 각 연결에 대해 기술 점수가 가장 높은 상담원이 "최상" 상담원으로 간주됩니다.

사실상 연결 기술 요구 사항/대기열 기술 기준과 일치하는 상담원의 직무 값의 합계가 점수를 결정합니다.

이해해야 할 몇 가지 핵심 사항은 다음과 같습니다.

  • 일반적으로 실제 기술 값은 점수 계산에 사용됩니다. 기술 점수가 높을수록 더 강한 일치를 나타내기 때문입니다. 단, 직무 요구 사항에서 같지 않음(<=) 조건을 사용하는 경우 상담원의 특정 직무 값은 점수 계산에서 반전됩니다( 예: effective_skill_value = (10) 빼기(actual_skill_value)). 이는 점수가 낮을수록 더 강한 일치를 나타내도록 하기 위해 수행됩니다.
  • 여러 명의 적격 상담원의 점수가 같으면 그 중에서 가장 오래 사용할 수 있는 상담원이 선택됩니다
  • 점수 계산 시에는 숙련도 기술만 고려됩니다. 연결 기술 요구 사항/대기열 기술 기준의 부울, 텍스트 또는 열거형 기술은 점수 계산 시 고려되지 않습니다.

위의 예에는 숙련도 직무 값이 서로 다른 숙련도 및 비숙련도 기술을 가진 4명의 상담원이 있습니다.

어떤 연결이 "가장 유용한" 라우팅 패턴을 가지는 직무 기반 대기열에 대기되어 있다고 가정해 보겠습니다.

  • 흐름을 통해 위의 기술 요구 사항이 할당된 경우, 또는
  • 를 사용하여 위의 기술 기준을 기술 기반 대기열에서 구성합니다.

이 시나리오의 내용은 다음과 같습니다.

  • 연결 기술 요구 사항/대기열 기술 기준을 완전히 충족하는 상담원만 라우팅 대상으로 고려됩니다. 상담원 A1, A2A4 만 연결 기술 요구 사항/대기열 기술 기준을 완전히 충족합니다.

    상담원 A3 은 적합하지 않습니다. 대기열 에 할당된 기술 기준의 경우 A3 은 대기열과 연관되지도 않습니다.

  • A1 , A2 A4 중에서 점수 계산은 숙련도 기술만 고려되는 연결 기술 요구 사항/대기열 기술 기준에 기초하여 시스템에 의해 수행됩니다.

    상담원이 추가/기타 숙련도 기술을 보유하고 있더라도 연결 기술 요구 사항/대기열 기술 기준에 언급된 기술만 점수 계산 시 고려됩니다.

    또한 <=(less-than-equal-to) 조건을 사용하는 경우 점수 계산에서 기술 값이 반전됩니다.

  • 점수에 따라 A2가 가장 가용 가능한 상담원이므로 연결이 A2 라우팅됩니다. A2 를 사용할 수 없거나 통화 중인 경우 연결은 점수가 두 번째로 높은 다음으로 사용 가능한 상담원에게 라우팅됩니다.

    그러나 다음으로 높은 점수를 받은 A1과 A4 의 상담원 2 명이 있습니다. 연결은 A1과 A4 사이에서 가장 오래 사용할 수 있는 상담원에게라우팅됩니다.

이 라우팅 패턴은 다음과 같은 유형의 기술 기반 대기열에서 지원됩니다.

비기술 기반 라우팅

Webex Contact Center는 또한 상담원의 특정 기술이나 전문 지식을 고려하지 않고 들어오는 고객 상호 작용을 분산하는 데 중점을 둔 다양한 비기술 기반 라우팅 패턴을 지원합니다. 기술 기반 라우팅 패턴과 달리, 이러한 패턴은 상담원 기술을 고려하지 않으며 연락처 또는 대기열이 라우팅에 대한 기술 요구 사항/기준을 정의할 것을 요구하지 않습니다. 대신 가용성, 작업 부하 분산 및 사전 정의된 시퀀스와 같은 요소에 우선 순위를 지정하여 개별 상담원 역량이 아닌 운영 로직을 기반으로 연결을 효율적으로 처리할 수 있습니다. 이러한 패턴은 상호 작용이 비교적 균일하거나 특별한 처리가 필요하지 않은 환경에서 특히 유용합니다.

가장 오래 사용할 수 있음

최장 사용 가능 라우팅 패턴은 사용 가능하며 해당 대기열과 연결된 모든 상담사에서 마지막 연결을 처리한 이후 가장 오랫동안 사용 가능한 대기열의 해당 상담사에게 연결을 라우팅합니다.

이 라우팅 패턴은 가장 오랫동안 유휴 상태였던 상담사에게 상호 작용을 할당하여 공정하고 균형 잡힌 워크로드 분산을 보장합니다. 워크로드 불균형을 방지하여 상담원이 과중한 부담을 느끼지 않도록 하고 다른 상담원은 여유 시간을 유지할 수 있습니다. 이 방법은 고객 응대 흐름이 꾸준한 기간에 특히 효과적이며 상담원 풀 전체에서 일관적인 참여를 유지합니다.

상담원은 모든 미디어 유형의 연결을 제공받을 경우 모든 채널에서 "가장 오래 사용할 수 있는" 위치를 잃게 됩니다. 이는 상담원이 연결을 처리한 후 대기열에 있는 미디어 유형의 다음 연결이 해당 대기열에서 다음으로 사용 가능한 최장 상담원에게 할당됨을 의미합니다.

위의 예에서 상담원 A1 은 가장 오래 이용할 수 있는 상담원(위치 1)입니다. 즉, 이 상담원이 먼저 로그인했거나 다른 상담원보다 오래 연결이 할당되지 않았습니다.

상담원 A2 (위치 2) 및 A3 (위치 3)도 사용할 수 있지만 로그인했거나 A1 이후에연결을 처리했습니다. 모든 상담사는 이 라우팅 패턴이 있는 두 대기열에 연결됩니다.

다음과 같은 경우를 생각해볼 수 있습니다.

  • 시간 T0에 음성 연결 C1 이 대기열에 배치되고 사용 가능한 시간이 가장 긴 상담원(예: A1)에게 라우팅됩니다.

    A1 에 C1 이 할당 되었으므로 A1 은 더 이상 모든 미디어 채널을 통틀어 가장 오래 사용할 수 있는 상담원이 아닙니다.

  • 시간 T1에서 채팅 연결 C2 가 대기열에 추가되고 사용 가능한 최장 상담원(현재 A2)에게 라우팅됩니다.
  • 마지막으로, 시간 T2에서 다른 음성 연결 C3 이 대기열에 배치되어 A3 으로 라우팅됩니다.

    A1A2 는 최근에 연락을 취했는데, 이 시점에서 가장 오래 기다린 것은 A3 입니다 .

고도로 분산된 Webex Contact Center 아키텍처로 인해, 사용 가능한 시간이 가장 긴 단일 상담원이 여러 연결을 같은 대기열에 동시에 배치할 가능성이 적습니다.

이 라우팅 패턴은 다음과 같은 유형의 비기술 기반 대기열에서 지원됩니다.

원형

순환 라우팅 패턴은 수신 연결을 사용 가능한 상담원 그룹에 라운드 로빈 순서로 분배합니다. 연결이 대기열에 배치되면 시스템은 미리 결정된 순서에 따라 대기열에서 사용 가능한 다음 상담원에게 해당 연결을 할당합니다.

이 프로세스는 구성된 순서의 상담원으로 시작됩니다. 첫 번째 수신 연결은 이 순서에서 사용 가능한 첫 번째 상담원에게 할당됩니다. 후속 연결의 경우 시스템은 정의된 대기열 순서에서 중단된 부분부터 이어서 사용 가능한 다음 상담원을 선택합니다. 이 패턴은 반복되어 상담원 사이를 순환하지만 항상 마지막으로 선택한 상담원의 위치 이후부터 시작합니다.

이 방법은 상담원 간에 연결을 공정하고 고르게 분산시키는 데 효과적입니다. 이를 통해 상담원이 너무 많은 문의를 받는 일이 없도록 하고, 모든 상담원이 동등하게 기회를 얻어 상호 작용을 일관성 있게 처리할 수 있습니다. 그러나 순환 라우팅 패턴은 현재 워크로드 또는 특정 연결을 처리하는 상담원의 능력에 영향을 줄 수 있는 기타 요인을 고려하지 않습니다.

위의 예에서 상담원은 A3 → A4 → A5 → A6 → A1 → A2 의 순서로 순환 대기열에 구성됩니다.

우선 시작 위치는 구성된 순서의 첫 번째 상담원입니다(A3). 연결이 이 대기열의 상담원에게 라우팅되면 위치는 원 주위로 이동하여 마지막 연결이 라우팅된 상담원에 대해 구성된 순서대로 다음 위치에 있는 상담원에게 배치됩니다.

다음과 같은 경우를 생각해볼 수 있습니다.

  • 첫 번째 연결(C1)이 대기열에 배치되고 상담원 A3으로 라우팅됩니다.

    포인터는 구성된 순서대로 다음 에이전트(예: A4)로 업데이트됩니다.

  • 두 번째 연결(C2)이 대기열에 배치되면 시스템은 A4(예: A4 → A5 → A6 → A1 → A2 → A3 )부터사용 가능한 에이전트를 찾기 시작합니다.

    그러나 A4A5 는 사용할 수 없으므로(로그인조차 하지 않았거나, 유휴 상태이거나, 이 미디어 유형의 다른 연결과 통화 중임) C2 는 사용 가능한 다음 상담원 인 A6으로 라우팅됩니다. 포인터는 구성된 순서대로 다음 에이전트(예: A1)로 업데이트됩니다.

  • 마찬가지로 세 번째 연결(C3)은 A1 으로라우팅되고 네 번째 연락처(C4)는 A2 로 라우팅됩니다. 포인터가 다시 A3 에 있습니다 .

    이러한 논리는 계속되며 연결이 "순환"/"라운드 로빈" 패턴으로 사용 가능한 상담원들에게 분배됩니다.

대기열에 지정보류된 연결이 있는 경우 상담원 잉여 시나리오는 이 미디어 유형에서 사용 가능하게 되는 다음 상담원을 우선 순위가 가장 높고 가장 오래된 연결 상담원과 일치시킵니다.

이는 이 대기열의 기존 위치 값을 고려하거나 영향을 주지 않습니다. 이 위치 값은 고객 응대 초과 라우팅이 상담원과 성공적으로 일치할 때만 업데이트됩니다.

이 라우팅 패턴은 다음과 같은 유형의 비기술 기반 대기열에서 지원됩니다.

하향식

하향식 라우팅 패턴은 수신 연결을 사용 가능한 상담원 그룹과 순서가 지정된 상담원 그룹에 순차적으로 분배합니다. 연결이 대기열에 있으면 시스템은 항상 처음부터 정렬된 상담원 목록을 순회하여 해당 시퀀스에서 사용 가능한 첫 번째 상담원(연결 미디어 유형의 사용 가능한 채널을 가진 상담원)과 연결을 일치시킵니다.

이는 대기열에 있는 모든 연락처에 대해 발생합니다. 연결은 항상 맨 위(첫 번째로 구성된 상담원)부터 시작하여 일치하는 상담원을 찾을 때까지 목록 아래로 진행하여 일치시키려고 시도합니다.

순환 라우팅 패턴과 달리, 마지막으로 선택한 상담원의 위치를 기반으로 시작점을 동적으로 변경하는 "포인터"가 없습니다.

이 접근법은 관리자에 의해 결정된 몇 가지 편향/선호도에 따라 정렬된 상담원들 사이에 연결을 분배하는 데 효과적입니다. 이는 항상 위쪽에 있는 상담원이 아래쪽 상담원보다 연결을 처리하는 데 우선적으로 사용되도록 하는 데 도움이 됩니다. 그러나 하향식 라우팅 패턴은 현재 작업량이나 특정 연결을 처리하는 상담원의 능력에 영향을 줄 수 있는 기타 요소를 고려하지 않습니다.

위의 예에서 상담사는 A3 → A4 → A5 → A6 → A1 → A2 순 으로 하향식 대기열에 구성됩니다.

즉, 관리자는 모든 연결을 첫 번째 상담원(A3)에게 라우팅하고, 그렇지 않은 경우 다음 상담원(A4)에게 라우팅하는 방식으로 구성된 순서대로 라우팅합니다.

다음과 같은 경우를 생각해볼 수 있습니다.

  • 첫 번째 연결(C1)이 대기열에 배치되고 A3이 주문의 맨 위에 있으므로 상담원A3 에게 라우팅됩니다.
  • 두 번째 연결(C2)이 대기열에 배치되면 항상 A3 부터시작하여 순서의 맨 위에서부터 라우팅이 다시 시도됩니다.

    A3에 이 미디어 유형에 대해 더 많은 채널 용량이 있는 경우 C2 도 A3 으로 라우팅됩니다. 그러나 A3 이 이 미디어 유형에서 완전히 사용 중인 경우 라우팅은 목록 아래쪽에서 A4 진행됩니다.

  • 그러나 A4A5 는 사용할 수 없으므로 (로그인조차 하지 않았거나, 유휴 상태이거나, 이 미디어 유형의 다른 연결과 통화 중임) C2 는 하향식 순서 인 A6에서 사용 가능한 다음 상담원에게 라우팅됩니다.
  • 마찬가지로 세 번째 연결(C3)은 A3 에서 시작하여 아래쪽으로 라우팅하려고 시도합니다. 첫 번째로 일치하는 에이전트는 A1 입니다.

    이 논리는 연락처가 주문의 맨 아래까지 사용 가능한 상담원을 찾지 못할 때까지(대기열에 지정보류될 때까지) 계속됩니다.

이 라우팅 패턴은 다음과 같은 유형의 비기술 기반 대기열에서 지원됩니다.

에이전트 기반 라우팅

상담원 기반 라우팅은 지정된("기본 설정") 상담원에게 직접 연결을 라우팅하거나 대기열에 넣는 기능입니다. 상담원의 전자 메일 주소 또는 상담원의 ID를 사용하여 상담원을 조회하면 연결이 기본 상담원으로 라우팅됩니다. 흐름에서 대기열에서 상담원으로의 활동은 상담원 기반 라우팅을 달성하는 데 도움이 됩니다. 자세한 내용은 Queue To Agent 활동을 참조하십시오 .

연결에는 일반적으로 Webex Contact Center 외부의 외부 애플리케이션에서 관리될 수 있는 한 명 이상의 기본 설정 상담원에 대한 매핑이 있을 수 있습니다. 연락처에 대한 기본 에이전트 조회는 외부 애플리케이션에서 매핑을 검색하는 HTTP 요청 활동을 통해 수행됩니다. 연결을 기본 설정 상담원으로 라우팅하거나 지정보류하려면 상담원의 Webex Contact Center ID 또는 전자 메일 주소를 사용하여 대기열에서 상담원으로의 활동을 구성합니다. 기본 상담원이 즉시 통화할 수 없는 경우 해당 기본 상담원에 대해 연결을 지정보류할 수도 있습니다.

에이전트 기반 라우팅은 다음과 같은 시나리오에서 유용합니다.

  • 기본 상담원 라우팅: 고객이 전담 상담원 또는 관계 담당 임원에게 연락처를 할당할 수 있습니다. 그러한 시나리오에서 상담원 기반 라우팅은 연결을 선호하는 상담원에게 직접 라우팅합니다.
  • 마지막 상담원 라우팅: 연락처가 상담원과 상호 작용하기 위해 컨택 센터에 여러 번 콜백하는 경우 상담원 기반 라우팅은 해당 연락처를 처리한 마지막 상담원에게 연락처를 라우팅할 수 있습니다.

두 사용 사례 모두에서 연결 및 상담원 매핑의 세부 정보는 Webex Contact Center 외부에 저장됩니다.

Flow

Flow의 대기열 및 라우팅 기능

Webex Contact Center에서는 흐름을 통해 광범위한 라우팅, 대기 및 통화 제어 기능을 오케스트레이션할 수 있습니다.

흐름 디자이너에서 제공하는 다양한 흐름 작업 및 이벤트 처리기를 흐름에 배치하여 인바운드 및 아웃바운드 연결의 주기를 효과적으로 관리할 수 있습니다.

흐름 설정 및 사용에 대한 자세한 내용은 흐름 디자이너 를 사용하여 흐름 빌드 및 관리를 참조하세요.

대기열 활동

대기열 연락처

대기열 연락처 활동은 연결을 조직의 활성 인바운드 대기열로 대기시켜 해당 대기열의 올바른 상담원과 일치시키고 라우팅할 수 있도록 하는 기능을 제공합니다.

이 활동을 통해 대기열의 다음과 같은 측면을 관리할 수 있습니다.

  • 우선 순위 - 대기열에 있는 연락처에 1(최고)에서 10(최저, 기본값) 범위의 계층적 중요도를 할당합니다.
  • 기술 요구 사항 - 연결을 라우팅할 수 있는 것으로 간주되기 위해 기술 기반 대기열에서 상담원이 충족해야 하는 기술 기준을 설정합니다.
  • 스킬 완화 - 일정 기간 후에 이전에 설정한 스킬 요구 사항을 조정, 수정 또는 제거하여 상담원을 찾을 가능성을 높입니다.
  • 상담원 가용성 확인 - 대기 시간을 방지하기 위해 사용 가능한 상담원을 찾을 수 없는 모든 통화 분배 그룹으로 시스템을 즉시 확장할 수 있습니다.

라우팅 연결에서 우선 순위, 기술 구성 및 상담원 가용성이 어떤 역할을 하는지에 대한 자세한 내용은 라우팅 을 참조하십시오.

대기열 연결 활동이 연결을 성공적으로 대기열에 넣으면

  • 일치하는 상담원이 이미 있는 경우 시스템은 해당 연결을 상담원에게 라우팅하려고 시도합니다.

    이렇게 하면 기본 흐름 실행이 중단되고 추가 이벤트가 해당 이벤트 흐름(구성된 경우)을 트리거할 수 있습니다 .

  • 일치하는 상담원이 없으면 연결이 대기열에서 지정보류되고 일치하는 상담원이 사용할 수 있게 될 때까지 기다립니다.

    그런 다음 대기열 연결 활동 다음에 첨부된 활동으로 흐름 실행이 계속되며 다음과 같은 기능을 제공합니다.

    • PlayMusic 활동을 첨부하여 대기열에서 대기 중인 고객에게 미리 구성된 음악을 재생합니다 .
    • 고객의 요청에 따라 콜백을 등록합니다 - 콜백 활동을 첨부합니다 .
    • 대기열 다시 만들기: 즉, 다른 대기열 연락처 또는 상담원 에 대기열을 연결하여 현재 대기열에서 연락처를 제거하고 새 대기열에 추가 활동입니다.

일치하는 상담원이 사용 가능해지면 시스템은 해당 상담원에게 연결을 라우팅하려고 시도합니다.

성공하면 기본 흐름 실행이 중단되고 추가 이벤트가 각 이벤트 흐름(구성된 경우)을 트리거할 수 있습니다 .

다음과 같은 경우 대기열 연락처 활동을 사용할 수 없습니다.

  • 상담원이 이미 연락처에 할당되어 있습니다.
  • 잘못된 대기열, 기술 또는 기타 구성이 흐름에 제공됩니다.
  • 연결에 대해 허용된 최대 진입점 및 대기열 전환(25)이 모두 사용되었습니다.
  • 연결을 성공적으로 라우팅하기 위해 허용된 최대 시도 횟수(20회)가 모두 사용되었습니다.

이러한 경우 작업으로 인해 오류가 발생하고 흐름 실행이 오류 처리 경로로 이동합니다.

기술 요구 사항, 기술 완화 및 상담원 가용성 확인과 같은 기능은 팀이 할당된 대기열을 선택한 경우에만 대기열 연결 활동에서 사용할 수 있습니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 대기열 연결 > 흐름 작성 및 관리를 참조하십시오.

대기열에서 상담원으로

대기열에서 상담원으로의 활동은 Webex Contact Center에서 고유한 상담원 ID 또는 전자 메일 주소를 검색하여 연결을 기본 상담원에게 직접 대기시킬 수 있는 기능을 제공합니다.

이 활동을 통해 대기열의 다음과 같은 측면을 관리할 수 있습니다.

  • 우선순위 - 동일한 상담원에 대해 대기열에 있는 연결에 중요도를 높이거나 낮게 할당합니다.
  • 보고 대기열 - 녹음 및 기본 대기열 내 음악과 같은 구성에 사용할 대기열과 연결의 보고 목적을 식별합니다.
  • 복구 대기열 - 연결을 지정된 기본 상담원에게 라우팅할 수 없는 경우 대체로 사용할 대기열을 식별합니다.

상담원 대기열 활동에서 연결을 성공적으로 대기열에 넣으면

  • 상담원이 이미 사용 가능한 상태인 경우 연결이 해당 상담원에게 라우팅됩니다.

    이렇게 하면 기본 흐름 실행이 중단되고 추가 이벤트가 해당 이벤트 흐름(구성된 경우)을 트리거할 수 있습니다 .

  • 상담원이 통화를 할 수 있지만 거절하거나, 응답하지 않거나, 연결을 받지 못한 경우 상담원은 제공된 복구 대기열로 이동됩니다.

    복구 대기열에서 해당 연결은 기술 지원 없이 가장 오랫동안 이용할 수 있는 상담원에게 라우팅됩니다.

  • 상담원을 사용할 수 없는 경우 "상담원을 사용할 수 없는 경우 연락처 지정보류" 옵션을 선택하면 연락처가 지정보류되고 상담원이 사용 가능한 상태가 될 때까지 대기합니다.

    그런 다음 대기열에서 상담원으로의 활동 다음에 첨부된 활동으로 흐름 실행이 계속되며 다음과 같은 기능을 제공합니다.

    • PlayMusic 활동을 첨부하여 대기열에서 대기 중인 고객에게 미리 구성된 음악을 재생합니다 .
    • 콜백 활동.
    • 대기열 다시 만들기: 상담원 또는 대기열 연락처 활동에 다른 대기열을 연결하여 현재 대기열에서 연결을 제거하고 새 대기열에 추가합니다.

    상담원이 가용 상태가 되면 시스템에서 해당 상담원에게 연결을 라우팅하려고 시도합니다.

    이렇게 하면 기본 흐름 실행이 중단되고 추가 이벤트가 해당 이벤트 흐름(구성된 경우)을 트리거할 수 있습니다 .

  • 상담원을 사용할 수 없는 경우 "상담원을 사용할 수 없는 경우 연락처 지정보류" 옵션을 선택하지 않으면 대기열에 실패합니다.

다음과 같은 경우 대기열에서 상담원으로 활동을 사용할 수 없습니다.
  • 상담원이 이미 연락처에 할당되어 있습니다.
  • 잘못된 기본 상담원 ID 또는 전자 메일 주소가 입력되었습니다.
  • 올바르지 않은 보고 또는 복구 큐가 제공되었습니다.
  • 기본 설정 상담원이 존재하지만 로그인하지 않았거나, 사용할 수 없거나, 다른 연결을 처리 중입니다.

이러한 경우 작업으로 인해 오류가 발생하고 흐름 실행이 오류 처리 경로로 이동합니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 에이전트 대기열> 흐름 작성 및 관리를 참조하십시오 .

통화 분배 그룹 에스컬레이트

통화 메일 그룹 에스컬레이션 작업은 팀이 할당된 대기열에 대해서만지원되며, 구성된 대기 기간 후 다음 그룹으로 자동 확장 업데이트가 수행될 때까지 기다리지 않고 연락처의 통화 메일 그룹을 즉시 업데이트할 수 있는 기능을 제공합니다. 이렇게 하면 대기열에 있는 모든 적격 상담원에게 연결을 신속하게 라우팅할 수 있습니다.

에스컬레이트 통화 메일 그룹 활동을 사용하여 연락처를 다음으로 에스컬레이션할 수 있습니다.

  • 다음 그룹 - 바로 다음 통화 분배 그룹에 추가된 팀을 포함하도록 팀 집합을 확장합니다.
  • 마지막 그룹 - 팀 집합을 확장하여 대기열에 대해 구성된 모든 통화 분배 그룹에서 매핑된 모든 팀을 포함합니다.

에스컬레이트 통화 메일 그룹 작업은 다음과 같은 경우에 사용할 수 없습니다.
  • 연락처가 이미 대기열에 있지 않습니다.
  • 연락처가 통화 메일 그룹의 개념을 지원하지 않는 큐에 대기 중입니다.

이러한 경우 작업으로 인해 오류가 발생하고 흐름 실행이 오류 처리 경로로 이동합니다.

30초 후에 각각 업데이트되는 세 개의 통화 메일 그룹이 있는 대기열에 연결이 대기하는 시나리오를 예로 들어 보겠습니다.

CDG 1 CDG 2 팀 부분에서 사용할 수 있는 상담원이 없고 마지막 통화 분배 그룹에 속한 TEAM 3 에서 상담원을 사용할 수 있습니다.

에스컬레이트 통화 메일 그룹 활동이 흐름에 사용되지 않으면 아래와 같이 대기 시간이 길어집니다.

다음과 같이 Escalate Call Distribution Group 활동을 사용하여 대기 시간을 줄일 수 있습니다.

아래 그림과 같이 다음 그룹 또는 마지막 그룹 옵션 선택을 기반으로 연락처 대기 시간이 상당히 줄어듭니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 Build and manage flows > Escalate Call Distribution Group 을 참조하십시오.

대기열 정보 활동

대기열 정보 가져오기

대기열 정보 가져오기 활동은 다음과 같이 지정된 연락처에 대한 실시간 대기열 정보를 가져오는 기능을 제공합니다.

  • PIQ(대기열에서 연결의 현재 위치) 또는 아직 대기열에 있지 않은 경우 잠재적 위치입니다.
  • 작업이 응답되기 전에 대기열에서 대기할 것으로 예상되는 EWT(예상 대기 시간) 또는 기간입니다.
  • 연결의 현재 통화 분배 그룹 내에서 로그인되거나 사용 가능한 상담원 수입니다.
  • 선택한 대기열에 대해 모든 통화 분배 그룹에서 로그인되었거나 사용 가능한 상담원 수입니다.
  • 대기열에서 가장 오래된 연결이 대기한 기간입니다.

이러한 세부 정보는 흐름 실행에서 활동 출력 변수로 사용할 수 있습니다.

각 대기열 세부 정보에 대한 활동 사용량, 자세한 정의 및 계산 방법에 대한 자세한 내용은 흐름 빌드 및 관리 > 대기열 정보 가져오기를 참조하세요.

대기열 정보를 사용하는 몇 가지 방법은 다음과 같습니다.

  • 고객이 라우팅을 기다리는 동안 대기열에서의 연결 위치와 예상 대기 시간을 고객에게 알리기 위해.
  • 예상 대기 시간이 너무 긴 경우 고객에 대해 콜백을 등록할 수 있는지 여부를 결정합니다.
  • 현재 CDG에 매핑된 팀에 사용 가능한 상담원이 없는 경우 연결을 다음 CDG(통화 분배 그룹)로 에스컬레이션합니다.

변수 선택을 통해 잘못된 큐가 제공된 경우 대기열 정보 가져오기 작업을 사용할 수 없습니다.

이 경우 작업으로 인해 오류가 발생하고 흐름 실행이 오류 처리 경로로 이동합니다.

다음과 같은 경우에는 현재 통화 분배 그룹에 대한 실시간 대기열 정보가 적용되지 않습니다.
  • 대기열 정보 가져오기 작업이 실행될 때 연락처가 (아직) 대기열에 없습니다.
  • 연락처가 통화 메일 그룹 개념을 지원하지 않는 큐에 대기되어 있습니다.

이러한 경우, 이러한 출력 필드의 값이 -1이면 이 정보가 해당되지 않음을 나타냅니다.

대기열에서 보낸 15초마다 고객에게 대기열의 긴 EWT에 대한 알림을 제공해야 하는 시나리오 예를 생각해 보십시오.

이 작업은 다음과 같이 흐름에서 Get Queue Info 활동을 사용하여 수행할 수 있습니다.

고급 대기열 정보

고급 대기열 정보 활동은 지정된 연락처에 대한 실시간 대기열 정보를 가져오는 기능을 제공하며 다음과 같은 연락처의 기술 기준을 추가로 고려합니다.

  • PIQ(대기열에서 연결의 현재 위치) 또는 아직 대기열에 있지 않은 경우 잠재적 위치입니다.
  • 지정된 기술 기준과 일치하는, 연결의 현재 통화 배포 그룹에 로그인되었거나 사용 가능한 상담원 수입니다.
  • 선택한 대기열에 대해 모든 통화 배포 그룹에서 로그인되었거나 사용 가능하며 지정된 기술 기준과 일치하는 상담원 수입니다.
  • 제공된 대기열에서 연결이 지정보류되는 현재 통화 분배 그룹입니다.
  • 제공된 대기열에 있는 통화 분배 그룹의 총 수입니다.

이러한 세부 정보는 흐름 실행에서 활동 출력 변수로 사용할 수 있습니다.

각 대기열 세부 정보에 대한 활동 사용량, 세부 정의 및 계산 방법에 대한 자세한 내용은 고급 대기열 정보를 > 흐름 작성 및 관리를 참조하십시오.

다음과 같은 고급 대기열 정보를 사용하는 몇 가지 방법이 있습니다.

  • 고객이 라우팅을 기다리는 동안 대기열에서 연락처의 위치를 고객에게 알리기 위해.
  • 현재 통화 배포 그룹에 매핑된 팀에서 기술 기준에 맞는 에이전트를 사용할 수 없는 경우 연결을 다음 통화 배포 그룹으로 에스컬레이션합니다.
  • 직무 기준에 맞는 상담원이 없는 경우 고객에 대해 콜백을 등록할 수 있는지 여부를 결정하기 위해 모든 통화 메일 그룹에서 로그인되어야 합니다.

다음과 같은 경우 고급 대기열 정보 활동을 사용할 수 없습니다.

  • 기술 기준이 대기열에 할당된 대기열에 대해 정보가 요청됩니다.
  • 연락처가 이미 대기열에 있지만 정보가 요청된 대기열이 아닌 다른 대기열에 있습니다.
  • 연결이 기본 상담원에 대해 직접 대기열에 배치된 경우

이러한 경우 작업으로 인해 오류가 발생하고 흐름 실행이 오류 처리 경로로 이동합니다.

기술 기준을 충족하는 사용 가능한 상담원이 없는 경우 고객에게 콜백 수신에 대해 알려야 하는 시나리오 예를 고려해 보십시오.

다음과 같이 흐름에서 고급 대기열 정보 활동을 사용하여 이 작업을 수행할 수 있습니다.

통화 제어 작업

발신자 ID 설정

발신자 ID 설정 활동은 통화 중에 표시되어야 하는 발신자 ID를 정의하는 데 사용됩니다. 발신자 설정 ID 활동은 이벤트 흐름의 끝을 표시하는 터미널 활동으로 사전 다이얼 이벤트 흐름에서만 사용해야 합니다.

발신자 ID 설정 활동을 통해 DNIS(Dialed Number Identification Service), 작업 유형 또는 참가자 유형에 따라 필요한 ANI(자동 번호 식별)를 구성할 수 있습니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 흐름 빌드 및 관리 > 발신자 설정 ID 을 참조하세요.

녹음 제어

녹음 제어 활동은 Menu 활동과 함께 사용되어 발신자의 녹음 동의를 캡처하도록 설계되었습니다. 이렇게 하면 녹음을 시작하기 전에 명시적 동의가 필요한 규정 또는 정책을 준수하여 이 단계를 워크플로에 원활하게 통합할 수 있습니다.

Menu IVR 활동은 녹음 제어 활동에 입력으로 할당될 부울 변수에 사용자의 동의를 캡처해야 합니다. 고객이 동의 보고서에서 사용자 동의를 보고해야 하는 경우 동의 값을 보고 가능한 전역 변수에 저장해야 합니다. 또는 보고가 필요하지 않은 경우 지역 변수를 사용할 수 있습니다. 이 접근 방식은 테넌트와 고객에게 변수를 효과적으로 관리하고 활용할 수 있는 향상된 유연성을 제공합니다.

이 활동이 흐름에 추가되면 사용자의 동의가 테넌트 수준이나 대기열 수준 또는 녹음 일정 수준 구성 설정보다 우선합니다.

우선 순위는 다음과 같습니다.

  • 흐름에서 사용자 동의가 [예]이면 테넌트나 대기열 또는 녹음 일정 수준에서 설정된 녹음 구성과 상관없이 통화가 녹음됩니다.
  • 사용자가 활동에 대한 응답으로 동의하지 않으면 테넌트 또는 대기열 또는 녹음 일정 수준에서 설정된 녹음 구성에 관계없이 통화가 녹음되지 않습니다.
  • 흐름에 녹음 제어 활동이 구성되어 있지 않지만 테넌트, 대기열 또는 녹음 일정과 같은 다른 수준 중 하나에서 구성이 예로 설정된 경우 통화가 녹음됩니다.
  • 흐름에 녹음 제어 활동이 구성되어 있지 않고 테넌트, 대기열 및 녹음 일정과 같은 모든 수준에서 구성이 아니요로 설정되어 있으면 통화가 녹음되지 않습니다.

이 녹음 제어는 아래와 같이 설명할 수 있습니다.

또한 전송 시 계속, 다시 시작 일시 중지 활성화, 일시 중지 기간 등과 같은 녹음 구성은 테넌트, 대기열 또는 녹음 일정 수준 등 기존 계층 구조에 따라 계속 적용할 수 있습니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 기록 컨트롤을 > 흐름 작성 및 관리를 참조하십시오 .

익명 호전환

익명 호전환은 상담원의 개입이 필요 없도록 IVR 시스템을 통해 연락처가 외부 DN(Dial Number)으로 효율적으로 라우팅되는 프로세스입니다.

익명 호전환 활동은 통화를 외부 또는 타사 DN으로 호전환해야 할 때 사용됩니다. 이는 터미널 활동이므로 전송이 실행되면 흐름이 종료됩니다.

흐름이 상담을 위해 실행될 때는 익명 호전환 활동이 지원되지 않습니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 블라인드 전송 > 흐름 빌드 및 관리를 참조하세요 .

브리지된 호전환

Bridged Transfer 활동을 사용하면 흐름이 통화를 제어하는 동안 연락처를 일시적으로 외부 대상으로 전송할 수 있습니다. 외부 대상은 외부 브리지 또는 Interactive Voice Response(IVR) 서비스일 수 있습니다.

외부 대상에서 통화가 종료되면 통화 흐름이 상담원에게 대기하는 것과 같이 필요에 따라 계속 진행됩니다.

Bridge Transfer 활동은 연결을 타사 IVR 또는 자동 통화 분배(ACD) 시스템으로 전송하는 동안 해당 문의를 대기열에서 제거합니다. 타사 시스템에서 처리하지 않는 문의는 원래 대기열로 다시 대기하여 해당 문의가 워크플로에서 적절히 처리되도록 할 수 있습니다.

예를 들어 컨택 센터에 Webex Contact Center 상담원 리소스와 외부 콜 센터 또는 PBX(Private Branch Exchange)의 상담원 리소스가 있다고 가정해 보겠습니다. 고객이 Webex Contact Center 상담원 대기열에 대한 통화를 짧은 기간(예: 60초) 동안 대기시키려고 합니다. 해당 기간 동안 사용할 수 있는 상담원이 없는 경우 해당 연결을 처리하기 위해 통화를 외부 콜 센터로 브리지 호전환(암시적 대기열 제거 사용)할 수 있습니다.

  1. 브리지된 호전환 활동은 발신 전화 흐름 및 이벤트 흐름에서 지원되지 않습니다.
  2. 상담원에게 이미 할당된 연결은 흐름을 통한 브리지 전송이 지원되지 않습니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 브리지 전송을 > 흐름 빌드 및 관리를 참조하세요 .

연락처 연결 끊기

연결 끊기 활동은 흐름에서 직접 활성 연결을 끊거나 종료할 수 있는 기능을 제공합니다.

이는 흐름에 연결된 터미널 활동으로, 상담원 조정 없이 연결을 종료하거나 오류 경로 흐름에 적합하거나 고객에 대한 콜백을 등록한 후에 유용할 수 있습니다.

구성에 따라 이 활동을 통해 연결이 종료되면 POST 통화 설문 조사 또는 피드백이 트리거됩니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 흐름 빌드 및 관리 > 연결 끊기를 참조하십시오 .

연락처 우선 순위 설정

[연결 우선 순위 설정] 활동을 사용하면 연결에 특정 우선 순위 수준을 할당할 수 있으므로 흐름 내에서 연결 우선 순위를 효과적으로 관리할 수 있습니다. 이렇게 하면 특정 연락처에 중요도를 높이거나 낮게 지정할 수 있으므로 상담원이 가용 상태가 되었을 때 대기 중인 다른 연락처와 비교하여 적절하게 라우팅됩니다. 이러한 유연성 덕분에 흐름 전반에 걸쳐 접점 우선 순위를 정밀하게 제어할 수 있습니다.

우선 순위는 1(최고)에서 9(최저)까지 계층적 중요도 수준을 할당하여 설정됩니다. 우선 순위가 가장 높은 문의가 우선 순위가 낮은 문의보다 먼저 라우팅됩니다. 여러 연락처가 동일한 우선 순위 수준을 공유하는 경우 가장 오래 대기한 연결이 다음으로 사용 가능하고 적격한 상담원에게 먼저 라우팅됩니다. 이 시스템은 우선 순위가 높은 연락처가 대기 시간을 기준으로 우선 순위가 동일한 연락처 간에 공정성을 유지하면서 즉각적인 주의를 받을 수 있도록 합니다.

  1. Contact Priority 설정 활동은 주 또는 이벤트 흐름의 어느 지점에나 배치할 수 있습니다.
  2. 연락처 우선 순위 설정 활동이 대기열 활동(예: 대기열 연락처 또는 상담원 대기열)보다 먼저 구성된 경우 해당 우선 순위 설정은 후속 대기 활동에서 명시적으로 구성된 우선 순위에 의해 재정의될 수 있습니다. 그러나 다음 대기열 활동에서 우선 순위를 지정하지 않으면 이전의 연결 우선 순위 설정 활동에서 설정한 연결 우선 순위가 적용됩니다.
  3. 반대로, 연락처 우선 순위 설정 활동이 대기열 활동(예: 연락처 대기열 또는 상담원 대상 대기열) 후에 구성되면 이전 대기열 활동에서 구성한 우선 순위 설정을 무시합니다.
  4. 연락처 우선 순위 설정 활동은 현재 아웃다이얼 및 캠페인 문의에서 지원되지 않습니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 흐름 작성 및 관리 > 연락처 우선 순위 설정을 참조하십시오.

콜백 활동

콜백

콜백 활동을 사용하면 발신자가 보류를 기다리지 않고 콜백을 요청할 수 있으므로 대기 시간을 줄이고 취소율을 최소화하여 고객 만족도를 크게 높일 수 있습니다. 콜백 활동이 활성화되면 대기열에 작업을 만들어 사용 가능한 상담원이 고객의 통화에 응답할 수 있도록 합니다.

흐름 디자이너는 통화가 시작된 원래 대기열에 연결을 유지하거나 기본 설정에 따라 다른 대기열에 할당하도록 활동을 구성할 수 있습니다. 콜백이 원래 대기열에 유지되는 경우 연결은 위치, 기술, 우선순위 및 컨텍스트 데이터를 유지하여 사용 가능한 다음 상담사에게 매끄럽게 할당할 수 있습니다. 그러나 다른 대기열을 선택하면 해당 연결은 기술 없이 기본 우선 순위로 선택한 대기열의 끝으로 푸시됩니다.

또한 이 활동을 통해 고객은 선호하는 상담원에게 콜백을 요청할 수 있으므로 경험에 개인적인 느낌을 더하고 고객 만족도를 높일 수 있습니다. 콜백 활동이 흐름에서 QueueToAgent 활동을 따를 때 수행할 수 있습니다. 또한 콜백 활동은 콜백 프로세스 중에 사용되는 ANI(자동 번호 식별)를 사용자 지정하기 위한 선택적 구성을 제공합니다. 이러한 사용자 지정은 브랜드 일관성에 도움이 되며 ID 발신자를 인식할 수 있도록 하여 통화 거부 가능성을 줄입니다.

흐름 디자이너에는 이벤트 흐름에 CallbackFailed 이벤트를 포함할 수 있는 옵션이 있습니다. 이 이벤트는 콜백 시도가 실패할 때 트리거되어 흐름 디자이너가 특정 간격으로 재시도를 구현할 수 있도록 합니다. 재시도 지연 또는 간격은 Wait 활동을 사용하여 구성할 수 있으며 최소 재시도 간격은 10초에서 최대 72시간입니다. 시스템은 대기 활동을 사용하여 최대 14일 동안 최대 10번의 재시도 시도를 지원합니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 콜백 > 흐름 빌드 및 관리를 참조하세요.

콜백 예약

예약된 콜백 활동은 흐름의 역량을 강화하여 고객이 미래의 특정 날짜 및 시간에 편리하게 콜백을 요청할 수 있도록 하므로 상담원과 즉시 연결할 필요가 없습니다. 이 기능을 사용하면 고객이 편리한 콜백 창을 선택할 수 있으므로 인식된 대기 시간을 최소화하고 통화 취소율을 줄임으로써 고객 경험을 개선합니다.

흐름은 DTMF 프롬프트를 통해 호출자의 입력(예: 기본 설정 날짜 및 시간)을 캡처하고 필요한 입력 유효성 검사를 수행한 후 활동에 전달해야 합니다.

시작하기 전에 콜백 기본 진입점이 Control Hub의 채널 설정 아래에 구성되어 있는지 확인하십시오 . 자세한 내용은 콜백 진입점 설정을 참조하세요.

콜백은 인바운드든 아웃바운드든 모든 텔레포니 대기열을 사용하여 예약할 수 있습니다. 최상의 결과를 얻으려면 콜백이 예약된 후 현재 통화가 제대로 종료되도록 예약된 콜백 활동 바로 뒤에 연결 끊기 활동을 추가하는 것이 좋습니다. IVR 콜백 예약에 대한 자세한 내용은 IVR 콜백 예약을 참조하십시오 .

요청된 미래 날짜 및 시간에 콜백이 트리거되면 새 통화 또는 상호 작용이 생성됩니다. 이 새로운 상호 작용은 콜백 기본 진입점에 연결된 표준 흐름을 따릅니다. 콜백 시도가 실패하면 흐름은 CallbackFailed 이벤트 처리기(해당 흐름에 구성된 경우)를 사용하여 자동으로 호출을 다시 시도할 수 있습니다.

활동에 입력을 전달하기 전에 다음 입력 유효성 검사를 고려해야 합니다.

  1. 날짜 선택 - 오늘부터 최대 31일 후까지의 날짜를 선택할 수 있습니다. 날짜는 YYYY-MM-DD 형식(예: 2025-07-18)이어야 합니다.
  2. 시간 창 시작 및 종료 시간—선택한 시간은 지금부터 최소 30분 후에 시작해야 하며 Anywhere 30분에서 8시간 사이에 지속될 수 있습니다. 24시간 형식(예: 14:30:00)을 사용하세요.
  3. 시간대—IANA 형식(예: America/New_York)으로 유효한 시간대를 입력해야 적시에 전화를 걸 수 있습니다.

참조 구현은 활동과 함께 사용되는 DTMF 프롬프트 및 기본 유효성 검사를 보여주기 위해 하위 흐름 템플릿 형식으로 제공됩니다. 자세한 내용은 예약된 콜백 하위 흐름 템플릿을 참조하십시오.

통화 진행 분석

CPA(통화 진행 분석 작업)를 사용하면 콜백 통화에서 자동 응답 시스템 및 실제 사람의 목소리를 감지할 수 있습니다.

콜백 시도 중 AMD(자동 응답기 감지) 또는 음성 메일이 발생하는 경우 시스템에서 통화를 실패한 것으로 식별합니다. AMD(자동 응답기 검색)의 결과는 CallbackFailed 이벤트 처리기의 reason 출력 변수에 캡처됩니다. 이 출력 변수를 기반으로 흐름 디자이너는 콜백 재시도를 구성할 수 있습니다.

  1. 무료 콜백의 경우 CallProgressAnalysis는 기본 흐름에서 콜백 활동 뒤의 지점에 배치할 수 있습니다. 예약된 콜백 또는 개인 예약된 콜백의 경우 기본 흐름에서 NewPhoneContact 다음에 배치할 수 있습니다.
  2. 이벤트 흐름에서는 CallbackFailed 이벤트 처리기에서만 지원됩니다.
  3. POST 통화 고객 설문 조사(피드백 활동)가 흐름에 구성된 경우 AMD 또는 음성 메일로 통화에 응답하면 시작되지 않습니다. 이렇게 하면 불필요한 설문 조사가 트리거되는 것을 방지할 수 있습니다.

활동 설정, 사용량 및 출력 변수에 대한 자세한 내용은 흐름 빌드 및 관리 > 통화 진행률 분석을 참조하십시오.

이 문서가 도움이 되었습니까?
이 문서가 도움이 되었습니까?