1.1Virtual Media

1.1.1Virtual media 개요

1.1.1.1Virtual Media 란?

콜에 의존한 고객과 상담사 간의 Communication이 진행 되던 예전 Call Center에서는 교환기라는 미디어를 통해 호 분배가 이루어 졌으나, 최근 다양한 미디어를 통한 Communication이루어지면서 Contact Center의 개념으로 확대 되었습니다. 이러한 미디어들에 대해 CTI에서는 가상의 미디어로 등록하여 호분배하는 형태의 구조를 가지게 되었습니다.

1.1.2Virtual Media Queue

1.1.2.1Virtual Media Queue 란?

Virtual Media는 교환기에서 사용하는 큐와 같은 개념이 없기에, 상담사 분배를 위해 가상의 큐를 만들어 사용 하게 됩니다. 즉 CTI에서는 Virtual Media에서 사용 할 Virtual Media Queue를 만들어 주고, 각 미디어에서는 다음 함수들을 호출 하여 큐에 대한 이벤트를 생성해 주어야 합니다.

1.1.2.2Openserver시

Virtual Media에 등록된 Virtual Queue로 Openserver를 요청 합니다. 단, 이때 App Name은 sys_ivr이어야 하기에 엔진에서 사용할 포트 관련 사항을 설정 하여야 합니다

아래는 엔진 Procecc.conf에 9705포트에 sys_ivr로 설정

아래는 3 party 에서 Openserver시 설정방법 입니다.

1.1.2.3큐 호인입

Virtual Queue에 호인입을 하기 위해서는3 party 에서 해당 큐에 nxcapiIVRRegisterCall 함수를 요청 하여 큐에 Queued 이벤트를 발생 시키면서 큐 대기 시키도록 합니다.

nxcapiIVRRegisterCall

Virtual Queue에 호가 인입되면 다음과 같이 해당 큐에 Queued 이벤트가 발생하게 됩니다

1.1.2.4상담사 호 분배 & 큐포기

Virtual Queue에 큐 대기 되었을 경우, 분배 대상이 있으면 다음과 같이 해당 상담사의 정보를 받게 됩니다.

분배 대상이 있을경우 해당 대상을 다음 필드에 입력을 하여 하여 nxcapiIVRReleaseCall 함수를 요청합니다. 만일 큐 포기를 해야 한다면 해당 필드에 0을 입력 하여 함수를 호출 합니다.

nxcapiIVRReleaseCall

CalledDN에 타켓을 입력할 경우 해당 큐에는 Diverted 이벤트가 발생하며 해당 상담사에게 호분배 합니다.
(상담사는 DL 이벤트발생됨)
CalledDN 에 0을 입력할 경우 해당 큐에는 ConnectionCleared 이벤트가 발생하며 해당 호는 큐포기 됩니다.

1.2Universal Queue

1.2.1Universal Queue 개요

1.2.1.1Universal Queue 란?

일반적인 Queue는 인입되는 하나의 Call kind에 대해 호 분배가 가능 한 반면, Universal Queue는 다양한 Call Kind에 대한 호가 인입 되어도 하나의 큐에서 모두 호분배가 가능한 통합형 큐입니다.

1.2.2Universal Queue

1.2.2.1Universal Queue

Universal Queue 사용시 다음 그림과 같이 하나의 큐(3100번)에 다양한 Call Kind에 대한 호 인입을 하여 해당 업무를 받을수 있는 상담사에게 분배를 하게 됩니다.

Universal Queue에 호인입, 상담사 분배, 큐포기 하는 방법은 Virtual Queue에서 하는 방법과 동일 합니다. 해당 내용 참고 하시기 바랍니다.

1.3Omni-Channel Balanced Routing

1.3.1Omni-Channel Balanced Routing 개요

1.3.1.1Omni-Channel이란?

소비자가 온라인, 오프라인, 모바일 등 다양한 경로를 넘나들며 상품을 검색하고 구매할수 있도록 한 서비스, 각 유통 채널의 특성을 결합해 어떤 채널에서든 같은 매장을 이용하는 것처럼 느낄수 있도록 한 쇼핑 환경을 말합니다.

1.3.1.2Omni-Channel Balanced Routing 기능이란?

기존 Contact Center에서는 Voice에 의존한 고객과 상담사간의 Communication이 형성 되었으나, 최근에는 다양한 미디어를 통해 서로간의 Communication을 요구 하고 있습니다. Omni-Channel Balanced Routing이란 이런 트랜드에 맞춰 다양한 채널을 통한 상담사와 고객과의 Communication이 이루어지도록 라우팅을 하는 전략입니다. 즉, 상담사는 Voice 뿐만이 아니라 E-mail, Chat, SNS등을 통해 고객과 상담을 하게 되며, 각 미디어에 대한 상담을 진행중이더라도 다른 미디어의 호를 동시에 받아 처리 할수 있게 됩니다.

1.3.2Omni-Channel Balanced Routing 설정

1.3.2.1Media 등록

Voice(Call)가 아닌 기타 미디어를 통해 상담사와 고객간의 호 연결을 하기 위해서는 해당 미디어를 Virtual Media(10: MEDIA_VIRTUAL)로 등록 하여야 합니다. UI A에서 해당 미디어에 대해 다음과 같이 Virtual Media 로 등록 합니다.

미디어 아이디 1:     Real Media(Avaya PBX)
미디어 아이디 3~8: Virtual Media

1.3.2.2권한등록

Omni-Channel Balanced Routing을 사용시 UI별 다음 메뉴 ID를 추가 해야 합니다

1.3.2.3자원등록

상담사가 다양한 미디어에 대해 상담을 받기 위해서는 해당 미디어에 로그인을 하여야 합니다.
따라서 일반 콜센터의 자원 등록과 마찬가지로 DN, 상담원 ID, 로그인 ID를 등록 하도록 합니다.

단, 자원에 대한 미디어 ID는 해당 Virtual Media의 ID로 등록 해야합니다. 
또한 각 DN들은 미디어 ID가 다르더라도 중복된 번호를 가질수 없으며, 해당 자원에 대해서는 라이선스가 카운팅 됩니다.

1.3.2.4멀티계정 등록

Omni-Channel Balanced Routing시 상담사는 각 미디어에 대해 전담 혹은 병행하여 업무를 처리 할수 있습니다. 전담으로 사용시는 해당 미디어에 등록된 아이디로 로그인 하여 업무를 진행하면 되나, 병행하여 업무 처리를 하기 위해서는 멀티계정에 다음과 같이 아이디를 등록해 주어야 합니다.
마스터 ID는 주 계정을 의미 하며, 이 계정과 함께 같이 사용할 아이디를 등록합니다.

즉, 주계정 2003을 사용하는 상담사는 추가로 3003, 3004, 8004, 8003에 로그인 하여 업무를 병행할수 있습니다.

멀티 계정을 설정 후 엔진에서 prtagent 확인시 다음과 같이 해당 정보가 나타납니다.
해당 정보는 마스터 ID, 상담대 ID, 미디어 ID순입니다.

1.3.2.5상담사 로그인 및 상태 변경

상담사 멀티계정을 등록하여 각 미디어에 대한 병행 업무를 처리시 Softphone에서는 해당 미디어 DN에 대해 Adddevice를 한후 로그인 하여 사용 하면 됩니다.

상담사 ID 2003에 대해 위와 같이 등록 하여 사용 할 경우,
상담사 ID 2003, 상담대 2003으로 Openserver -> Monitorstart 후, 상담대 3003, 3004, 8003, 8004에 대해 Adddevice한 후 각 DN별로 로그인/로그오프/상태 변경을 하여 업무를 진행하면 됩니다.
Softphone에서는 각 DN에 대해 이벤트와 콜ID, 상담원 ID를 별도로 관리하여야 합니다.

1.3.2.6모니터링 및 통계

Omni-Channel Balanced Routing에서 사용하는 권한 등록시 다음과 같이 UI별 해당 정보가 나타납니다.

UI A의 22번 권한 설정시 아래와 같이 A화면에 멀티계정 탭이 추가 됩니다.
해당 탭에서는 상담사의 멀티계정을 등록, 수정, 삭제 할수 있습니다.

UI R의 101번 권한 설정시 R통계 화면에서 상담사가 받은 콜의 종류를 확인 할수 있습니다.

UI I의 22번 권한 설정시 아래와 같이 I화면에 멀티계정 탭이 추가 됩니다.
해당 탭에서는 멀티 계정 설정된 상담사가 나타나면 각 계정별 상태를 실시간으로 확인 가능합니다.

UI P의 22번 권한 설정시 아래와 같이 P화면에 버튼 하나가 추가 됩니다.
해당 버튼을 선택시 소속 멀티 계정의 통계가 나타납니다.

1.3.2.7Dedicate 함수

dedicate 함수를 사용 하면 상담사 병행 업무 처리시 각 미디어에 대한 호 분배 여부를 설정 할 수가 있습니다.

큐에 인입된 시나리오가 다음과 같을 경우:

dedicate["Voice","Facebook,Email"]

상담사가 Facebook 혹은 Email 업무에 대해 통화 중이더라도 Voice 호인입시 분배 하도록 합니다.
만일, 상담사가 Facebook, Email이 아닌 다른 업무에 대해 통화중일 경우 Voice 호는 분배 되지 않습니다.

정의 가능한 Call Kind는 다음과 같이 8가지 입니다.

VOICE
TWITTER
FACEBOOK
RESERVED
CHAT
VIDEO
EMAIL
FAX

1.3.2.8참고사항

1. Virtual Media에 등록되는 자원도 prtlicense에 표현 되는 개수에 포함된다.

2. Omni-Channel Balanced Routing 사용시 각 Virtual Media별로 호에 대한 분배 여부를 dedicat함수를 통해 설정 가능하다.

3. 큐에 시나리오가 없을 경우 또는 dedicate 시나리오가 없을 경우 멀티 계정에 상담사 대기시, 각 Media별로 모두 호가 인입 된다.

4. Media에 종속되는 자원 DN과 Queue는 Media ID가 다르더라도 중복된 번호를 가질수 없다.

5. 멀티계정 등록시 Sub Agent의 통계는 Master Agent 통계에 포함 된다.

6. 멀티계정 설정 삭제시 해당 Sub Agent의 엔진 메모리 통계는 초기화 된다.

7. 미디어에서는 Virtual Media에 Openserver시 App name을 sys_ivr로 해야한다.

8. 미디어에서는 Registercall후 Select Target을 받게 되며 바로 Release Call을 통해 바로 Divert를 해야한다.

   (App에서 늦게 Releasecall 호출시 대기 상태가 아닌 상태에서 호분배 가능성이 있다)

9. Virtual Media에서 라우팅한 호에 대해서는 협의, 전환, 회의, Singlestep Transfer가 불가하다.(요청시 검토)

10. Virtual Media에 로그인시 상담사는 대기 상태가 된다.

11. Virtual Media의 분배 우선 순위는 다음과 같다.

    1. MasterID의 총 Busy카운트가 아닌 해당 채널 모드의 Busy 카운트가 적으면서 가장 오래 대기한 상담원

    2. MasterID의 총Busy 카운트가 아닌 해당 채널 모드의 Busy 카운트가 적으면서 스킬 댑스가 가장 큰 상담원

1.4Score Routing

1.4.1Score Routing 전략 개요

1.4.1.1Score Routing 을 개발배경

• 주 목적은 등급이 높은 상담원이 인바운드 호를 더 많이 받도록 하게 위함 입니다.

• 호 분배 대상중에서 Score값이 가장 높은 상담원에게 호를 분배 합니다.

• 상담원이 호를 받으면 Score값은 1씩 감소합니다.

• Score값이 0이 되면 분배를 하지 않습니다.

1.4.1.2Score Routing 이란?

상담원별로 등급을 주어 등급이 높은 상담사에게 호를 먼저 분배 하여 해당 상담사가 많은 호를 받도록 하는 라우팅을 Score Routing이라고 합니다. 여기서 등급이란 Skill Depth 개념이 아니라, 관리자가 상담사에게 직접 할당하게 되는 등급이며, 이 등급을 Score라고 칭합니다.

Supervisor KELLY는 각 상담사들의 경력사항등을 고려해, 가장 오랜 경력의 JANE에게 140, ERICA에게 130 그리고 신입 MARK에게 120의 Score를 할당합니다. 이 Score는 해당 상담사의 등급을 나타내기도 하지만, 해당 상담사가 금일 받을수 있는 콜의 수를 뜻하기도 합니다. (여기서 콜의 수는 IB큐 응답호수로, 협의, 전환, 회의등의 호수는 제외합니다.)

금일 각 상담사가 받은 IB큐응답호수와 현재 대기시간이 다음과 같은 상황에서, 신규 고객 호 인입시, Score Routing시나리오의 nxrouting에서는 각 상담사의 설정된 score값에서 IB큐 응답호수를 뺀값이 가장 큰 상담원를 Target으로 잡아 분배를 시도합니다. (Score 계산값 = 상담사별 설정된 score값 – IB큐응답호수)

Mark Score 계산값 = 120 – 4 = 116
JANE Score 계산값 = 150 - 12 = 138
ERICA Score 계산값 = 130 – 14 =116

일반 그룹분배의 경우 대기 시간이 가장 긴 ERICA에게 호분배가 되거나, 스킬분배의 경우 스킬 Depth가 가장 높은 MARK에게 호분배가 되어야 하지만, Score Routing의 경우 계산된 Score값이 가장 큰 JANE에게 호를 분배 합니다.

만일, JANE이 통화중인 상태에서 신규 호가 인입이 되다면, MARK와ERICA는 계산된 Score값이 동일하게 되는데, 이 값이 동일한 경우에는스킬 또는 그룹 분배 시나리오에 따라 SKILL LEVEL과 대기시간을 가지고 분배를 하게 됩니다.
즉, 시나리오가 스킬 분배시는 SKILL LEVEL이 높은 MARK에게, 그룹 분배시는 대기시간이 긴 ERICAL에게 호가 인입 됩니다.

주의 사항으로, Score값이 설정되지 않은 상담사의 경우는 Score라우팅시 분배대상에서 제외가 되며, Score 계산된 값(상담사별 설정된 score값 – IB큐응답호수)이 0이하가 될 경우 해당 상담사에게 호분배를 하지 않습니다.(IB 큐응답호수는 00시 00분 00초에 초기화가됩니다.)

1.4.2Score Routing 설정

1.4.2.1NEXUSCUBE A 에서 설정

• Score는 UI A의 상담원 자원의 사용자 옵션에서 limit=’Score’ 형태로 입력을 합니다.

• 해당 옵션 설정은 실시간 적용이 됩니다.

위와 같이, 2005 원빈 상담사의 경우 limit=30, 2003 정우성 상담사의 경우 limit=25를 설정 하였습니다.
UI A의 상담원 자원의 사용자 옵션중 limit=’숫자’의 경우, 상담사별로 인입 제한 호수 설정을 하는 옵션이기에, Score Routing을 하기위해서는 UI S에서 시나리오상 Score[1]을 설정 해야합니다.

만일, IB큐응답호수가 있는 상태에서 UI A를 통해 기존 Score값을 변경하게 되면, 신규호가 인입될 때, 설정된 Score에서 기존 큐 IB응답호수를 뺀값으로 계산이 됩니다. (즉, Score값을 변경하여도 IB큐 응답호수는 초기화 되지 않습니다)

1.4.2.2NEXUSCUBE S 에서 설정

• Score Routing을 하기 위해서는 UI S시나리오 작성시 Score[ ] 구문을 입력 해야 합니다.

• Score[1] : Score Routing 동작, Score[0] : Score Routing 해제, Score [ ] 미설정시는 해제상태

Score Routing을 사용하여 200그룹으로 호를 분배 합니다.

Score Routing을 사용하여 101 스킬로 호를 분배합니다.