CTI 시스템 구성과 동작 원리: PBX·CTI 서버·CRM은 어떻게 연결되는가?

CTI 시스템 구성과 동작 원리: PBX·CTI 서버·CRM은 어떻게 연결되는가#

1장 CTI 시스템은 어디에 위치하는가#

CTI를 이해할 때 가장 먼저 알아야 할 것은 CTI 서버가 전화 시스템과 업무 시스템 사이에 위치한다는 점입니다.

콜센터에는 서로 성격이 다른 두 종류의 시스템이 존재합니다.

한쪽에는 전화를 처리하는:

  • PBX
  • IP-PBX
  • ACD
  • 상담원 전화기
  • 소프트폰

등이 있습니다.

다른 한쪽에는 업무를 처리하는:

  • CRM
  • 상담 프로그램
  • 고객 데이터베이스
  • 상담이력 시스템
  • 통계 시스템

등이 있습니다.

CTI는 이 두 영역 사이에서 전화 이벤트와 제어 명령을 연결합니다.

기본 구조를 단순화하면 다음과 같습니다.

PBX / IP-PBX
      ↕
   CTI 서버
      ↕
CRM / 상담원 애플리케이션

원본 자료에서도 CTI 서버를 PBX와 CRM 사이에서 이벤트 전달과 명령 제어를 중재하는 시스템으로 설명합니다.

2장 CTI 아키텍처의 핵심 구성요소#

CTI 시스템을 크게 나누면 다음 구성요소를 생각할 수 있습니다.

PBX 또는 IP-PBX#

실제 전화 호를 처리합니다.

CTI 서버#

PBX의 이벤트를 받고 필요한 형태로 변환하여 업무 시스템에 전달합니다.

CRM 또는 상담원 UI#

전화 이벤트를 받아 고객정보를 표시하고 상담원이 전화 기능을 제어할 수 있게 합니다.

상담원 단말#

실제 음성 통화를 처리하는 전화기 또는 소프트폰입니다.

이 네 요소를 구분하면 CTI 구조 대부분을 이해할 수 있습니다.

3장 PBX는 무엇을 담당하는가#

PBX는 전화 호 Call 자체를 연결하고 관리합니다.

예를 들어 고객이 대표번호로 전화를 걸면 PBX는 다음과 같은 일을 처리할 수 있습니다.

  • 전화 수신
  • 내선 연결
  • 상담원 단말 호출
  • 통화 연결
  • 통화 보류
  • 호 전환
  • 통화 종료

즉 전화의 실제 흐름을 담당합니다.

CTI는 PBX를 대신하는 시스템이 아닙니다.

PBX에서 발생한 일을 컴퓨터 시스템이 알 수 있도록 연결하는 것이 CTI의 역할입니다.

4장 CTI 서버는 무엇을 담당하는가#

CTI 서버는 전체 구조의 중앙 중계자 역할을 합니다.

원본 자료에서는 CTI 서버의 주요 역할을 다음과 같이 정리합니다.

  • PBX 이벤트 수신·정규화
  • 상담원 단말 매핑
  • 명령 라우팅
  • 재접속·세션 복구
  • 장애 시 Failover

즉 CTI 서버는 단순히 이벤트를 전달하기만 하는 것이 아닙니다.

전화 시스템과 업무 시스템 사이의 차이를 흡수하고, 어느 상담원에게 어떤 이벤트를 전달해야 하는지 판단하며, 반대로 어느 전화기에 제어 명령을 전달할지도 결정합니다.

5장 CTI 서버가 이벤트를 정규화한다는 의미#

PBX와 CTI 제품은 제조사나 플랫폼에 따라 이벤트 구조가 다를 수 있습니다.

예를 들어 전화가 연결되었다는 상태를 어떤 시스템에서는:

Established

라고 표현할 수 있고 다른 시스템에서는 다른 이벤트 이름이나 코드로 전달할 수 있습니다.

CTI 서버는 이런 차이를 업무 시스템이 일관된 방식으로 사용할 수 있도록 중간에서 정리할 수 있습니다.

원본 자료에서는 이를:

PBX 이벤트 수신·정규화, 벤더별 차이 흡수

라고 설명합니다.

즉 CRM 개발자가 PBX 제조사마다 전혀 다른 로직을 구현하지 않도록 중간 계층이 차이를 줄여주는 것입니다.

6장 상담원 단말 매핑은 왜 필요한가#

CTI 시스템은 단순히 전화가 왔다는 사실만 알아서는 부족합니다.

다음 정보를 알아야 합니다.

이 전화가 어느 상담원에게 전달되는가?

이를 위해 상담원과 단말 사이의 관계를 관리합니다.

예를 들어:

상담원 내선번호
상담원 A 2101
상담원 B 2102
상담원 C 2103

와 같은 매핑이 있을 수 있습니다.

2102번 단말에서 전화 이벤트가 발생했다면 CTI는 이것을 상담원 B와 연결해야 합니다.

그래야 상담원 B의 CRM 화면에 정확한 고객정보를 표시할 수 있습니다.

7장 단말 매핑이 잘못되면 어떤 문제가 생길까#

상담원과 단말의 연결 정보가 잘못되면 매우 이상한 현상이 발생할 수 있습니다.

예를 들어:

고객은 상담원 A에게 연결되었는데

고객정보 화면은 상담원 B에게 표시되는 문제가 생길 수 있습니다.

또는:

  • 전화는 울리는데 Screen Pop이 안 뜸
  • 다른 상담원의 화면에 고객정보가 나타남
  • Click-to-Call이 다른 전화기에서 실행됨
  • 상담원 상태가 실제와 다르게 표시됨

같은 문제가 발생할 수 있습니다.

따라서 CTI 장애를 분석할 때 상담원 ID와 내선·단말 매핑은 매우 중요한 확인 항목입니다.

8장 CTI 명령 라우팅이란 무엇인가#

CTI는 전화 이벤트를 받는 것뿐 아니라 컴퓨터에서 전화 시스템으로 명령을 보낼 수도 있습니다.

예를 들어 상담원이 CRM 화면에서 고객 전화번호를 클릭하면:

CRM
 ↓
CTI 서버
 ↓
PBX
 ↓
상담원 전화기
 ↓
고객에게 발신

과 같은 흐름으로 동작할 수 있습니다.

원본 자료에서는 CTI 서버 역할 중 하나로 어느 상담원이 누구에게 발신할지 명령을 라우팅한다고 설명합니다.

즉 CTI 서버는:

누가 명령을 보냈고

어떤 단말이 그 상담원의 단말이며

어느 번호로 전화를 걸어야 하는지

연결해주는 역할을 합니다.

9장 CTI 시스템의 기본 데이터 흐름#

기본적인 CTI 흐름은 크게 두 방향입니다.

전화 시스템에서 업무 시스템으로#

PBX
 ↓
CTI 이벤트
 ↓
CTI 서버
 ↓
CRM

업무 시스템에서 전화 시스템으로#

CRM
 ↓
전화 제어 명령
 ↓
CTI 서버
 ↓
PBX

이 두 방향을 모두 지원하기 때문에 CTI는 양방향 연동 시스템이라고 볼 수 있습니다.

10장 인바운드 전화가 들어올 때 CTI 동작 흐름#

고객이 콜센터에 전화를 걸었을 때를 단계별로 살펴보겠습니다.

1단계: 고객 발신#

고객이 대표번호 또는 DID 번호로 전화를 겁니다.

2단계: PBX 수신#

PBX 또는 IP-PBX가 전화를 수신합니다.

3단계: IVR·ACD 처리#

필요한 경우 IVR 메뉴와 ACD 분배를 거쳐 상담원이 선택됩니다.

4단계: PBX 이벤트 발생#

상담원에게 전화가 전달되면서 Ringing 등의 이벤트가 발생합니다.

5단계: CTI 서버 이벤트 수신#

CTI 서버가 PBX로부터 이벤트를 전달받습니다.

6단계: 상담원 매핑#

전화가 전달될 단말이 어느 상담원의 것인지 확인합니다.

7단계: CRM 이벤트 전달#

전화 관련 데이터를 상담원 프로그램이나 CRM에 전달합니다.

8단계: Screen Pop#

CRM이 고객정보를 조회해 상담원 화면에 표시합니다.

전체 흐름은 다음처럼 정리할 수 있습니다.

고객
 ↓
PBX
 ↓
IVR / ACD
 ↓
상담원 선택
 ↓
CTI 이벤트
 ↓
CTI 서버
 ↓
CRM
 ↓
Screen Pop

11장 전체 콜시스템에서 CTI가 위치하는 지점#

원본 자료의 전체 콜시스템 흐름은 다음과 같은 구조를 제시합니다.

고객
 ↓
통신사업자 / 회선
 ↓
IP-PBX
 ↓
IVR
 ↓
ACD
 ↓
CTI
 ↓
상담원 / CRM
 ↓
녹취

이 흐름에서 CTI는 ACD 이후 상담원과 CRM 영역을 연결하는 중요한 접점으로 볼 수 있습니다.

즉:

전화 분배는 ACD

전화와 화면의 연결은 CTI

라는 구분이 중요합니다.

12장 CTI와 Screen Pop은 어떻게 연결되는가#

Screen Pop은 CTI 시스템 구조를 이해하기 가장 좋은 사례입니다.

원본 자료에서는 다음과 같은 흐름을 제시합니다.

  1. 전화 착신
  2. PBX에서 CTI 이벤트 발생
  3. CTI가 발신번호 또는 착신번호 전달
  4. CRM이 고객 DB 조회
  5. 상담원 화면을 고객 상세화면으로 전환

이를 구조로 보면 다음과 같습니다.

PBX
 ↓
CTI
 ↓
ANI / DNIS
 ↓
CRM
 ↓
고객 DB
 ↓
고객정보 화면

즉 CTI는 고객정보를 직접 가지고 있는 것이 아니라 고객을 식별할 수 있는 전화 정보를 CRM에 전달하는 역할을 합니다.

13장 CTI 서버와 CRM은 어떤 데이터를 주고받는가#

CTI와 CRM 사이에서는 다양한 정보가 이동할 수 있습니다.

CTI → CRM#

  • 발신번호
  • 착신번호
  • 상담원 ID
  • 내선번호
  • 착신 이벤트
  • 통화 연결 이벤트
  • 통화 종료 이벤트
  • 보류 이벤트
  • 전환 이벤트

CRM → CTI#

  • 발신 요청
  • 응답
  • 보류
  • 재개
  • 전환
  • 3자 통화
  • 종료

이처럼 CTI와 CRM의 관계는 단순 조회가 아니라 이벤트와 명령을 주고받는 양방향 관계입니다.

14장 ANI와 DNIS는 왜 중요한가#

CTI 기반 Screen Pop에서는 전화번호 정보가 고객과 업무를 구분하는 중요한 키가 될 수 있습니다.

원본 자료에서는 ANI와 DNIS를 다음처럼 구분합니다.

ANI#

Automatic Number Identification

발신번호입니다.

주로:

누가 전화를 걸었는지

식별하는 데 사용합니다.

DNIS#

Dialed Number Identification Service

고객이 어느 번호로 전화했는지를 나타냅니다.

주로:

어떤 서비스 또는 캠페인으로 전화가 들어왔는지

구분하는 데 활용할 수 있습니다.

15장 CTI와 ACD의 관계#

ACD는 전화를 적절한 상담원에게 분배합니다.

CTI는 그 결과와 상담원 상태를 업무 시스템과 연결합니다.

예를 들어 상담원이:

Ready

상태라면 ACD의 분배 대상이 될 수 있습니다.

Not Ready라면 분배 대상에서 제외될 수 있습니다.

원본 자료에서도 CTI 이벤트에는:

  • Ready
  • Not Ready
  • After Call Work
  • Login
  • Logout

같은 상담원 상태가 포함됩니다.

따라서 CTI와 ACD는 독립적으로 존재할 수 있지만 실제 콜센터 운영에서는 매우 밀접하게 연결됩니다.

16장 CTI 이벤트와 상담원 상태는 왜 분리해서 봐야 할까#

CTI에는 크게 두 종류의 상태 변화가 있습니다.

전화 Call 상태#

  • Ringing
  • Established
  • Held
  • Released
  • Transferred

상담원 Agent 상태#

  • Login
  • Logout
  • Ready
  • Not Ready
  • After Call Work

전화 상태와 상담원 상태는 서로 관련 있지만 같은 것은 아닙니다.

예를 들어 통화가 종료되었다고 해서 상담원이 즉시 Ready 상태가 되는 것은 아닐 수 있습니다.

상담 후 기록 작업을 위해 After Call Work 상태에 들어갈 수 있기 때문입니다.

17장 CTI 세션은 무엇을 관리하는가#

CTI 환경에서는 상담원이 로그인하면 단순히 사용자 ID 하나만 관리하는 것이 아닙니다.

다음과 같은 요소들이 서로 연결될 수 있습니다.

  • 상담원 ID
  • 로그인 세션
  • 내선번호
  • 전화기
  • 소프트폰
  • CRM 세션
  • ACD 상태

이 중 하나라도 연결이 어긋나면 실제 전화와 화면의 상태가 일치하지 않을 수 있습니다.

따라서 안정적인 CTI 시스템에서는 세션 관리와 상태 동기화가 중요합니다.

18장 CTI 서버가 재접속 기능을 가져야 하는 이유#

실제 시스템에서는 네트워크가 항상 완벽하게 유지되지 않습니다.

순간적인 네트워크 단절이나 PBX 연결 끊김이 발생할 수 있습니다.

이때 CTI가 한번 연결을 잃었다고 계속 장애 상태로 남아 있다면 운영에 큰 문제가 됩니다.

그래서 원본 자료에서는 CTI 서버의 역할 중 하나로:

재접속·세션 복구

를 제시합니다.

즉 연결이 끊어진 뒤 자동으로 다시 연결하고 기존 상태를 최대한 복구하는 기능이 중요합니다.

19장 CTI 서버 장애 시 어떤 일이 생기는가#

원본 자료에는 매우 중요한 운영 포인트가 있습니다.

CTI 서버 장애 시 전화는 되지만 화면 연동이 끊길 수 있다고 설명합니다.

이 현상은 CTI의 역할을 정확하게 보여줍니다.

PBX가 정상이라면 전화 자체는 연결될 수 있습니다.

하지만 CTI가 중단되면:

  • Screen Pop 중단
  • Click-to-Call 실패
  • 상담원 상태 동기화 실패
  • 통화 이벤트 누락
  • CRM 자동 화면전환 실패

등이 발생할 수 있습니다.

20장 "전화는 되는데 화면이 안 떠요"의 의미#

콜센터 운영에서 자주 접할 수 있는 유형의 장애입니다.

이 경우 전체 전화망 장애라고 단정하면 안 됩니다.

다음 구조로 나누어 볼 수 있습니다.

전화도 안 된다#

PBX, SIP, 회선, SBC, ACD 등 확인

전화는 된다#

전화 시스템 자체는 정상일 가능성이 있음

화면만 안 뜬다#

CTI 또는 CRM 연동 구간 확인

즉 장애 범위를 좁힐 때:

전화 흐름과 CTI 데이터 흐름을 따로 보는 것

이 중요합니다.

21장 CTI 서버는 왜 SPOF가 될 수 있는가#

CTI 서버 하나에 모든 상담원의 전화 이벤트와 제어 명령이 집중된다면 해당 서버는 매우 중요한 시스템이 됩니다.

이 서버 하나가 장애를 일으켰을 때 전체 CTI 기능이 중단된다면 SPOF Single Point of Failure가 됩니다.

원본 자료에서도 CTI 단일 장애점을 피하기 위해 이중화 구성을 권장하고 있습니다.

22장 CTI 이중화 구조란 무엇인가#

CTI 서버 장애에 대비하려면 한 대의 서버만 사용하는 것이 아니라 복수의 서버를 구성할 수 있습니다.

개념적으로는 다음과 같은 형태를 생각할 수 있습니다.

        PBX
       ↙   ↘
CTI Server A   CTI Server B
       ↘   ↙
        CRM

정상 상태에서는 한 서버가 주 역할을 수행하고 장애 시 다른 서버가 역할을 이어받는 형태를 구성할 수 있습니다.

원본 자료에서는 이를 Failover와 연결합니다.

23장 Failover란 무엇인가#

Failover는 현재 서비스를 제공하던 시스템에 장애가 발생했을 때 대기 시스템이 자동 또는 수동으로 역할을 넘겨받는 구조입니다.

CTI에서는 특히 다음 상태가 중요할 수 있습니다.

  • PBX 연결 상태
  • 상담원 세션
  • 단말 매핑
  • 진행 중인 통화 상태
  • 이벤트 전달 상태

단순히 서버만 하나 더 준비했다고 안정적인 이중화가 완성되는 것은 아닙니다.

장애 발생 후 상태를 얼마나 정확하게 복구할 수 있는가도 중요합니다.

24장 CTI 장애에서 이벤트 유실이 중요한 이유#

CTI는 이벤트 기반으로 동작합니다.

따라서 특정 이벤트를 놓치면 CRM의 상태가 실제 전화 상태와 달라질 수 있습니다.

예를 들어:

통화가 실제로 종료되었지만

Released 이벤트를 CRM이 받지 못했다고 생각해보겠습니다.

CRM에서는 여전히 통화 중이라고 표시될 수 있습니다.

또는 상담원이 실제로 Ready 상태가 되었지만 상태 이벤트를 받지 못하면 ACD나 업무 시스템에서 여전히 Not Ready로 표시될 수도 있습니다.

따라서 CTI 시스템에서는 이벤트의 정확성과 순서, 누락 여부가 중요합니다.

25장 CTI 장애를 추적할 때 무엇을 봐야 하는가#

CTI 문제를 분석할 때는 흐름을 단계별로 확인하면 좋습니다.

1. PBX에서 이벤트가 발생했는가#

전화 시스템 자체 확인

2. CTI 서버가 이벤트를 받았는가#

PBX ↔ CTI 구간 확인

3. CTI 서버가 상담원을 정확히 찾았는가#

단말·상담원 매핑 확인

4. CRM으로 이벤트를 보냈는가#

CTI ↔ CRM 구간 확인

5. CRM이 이벤트를 처리했는가#

애플리케이션 로직 확인

이렇게 보면 장애 범위를 빠르게 좁힐 수 있습니다.

26장 CTI 로그가 중요한 이유#

CTI는 여러 시스템 사이에서 동작하기 때문에 장애 원인이 명확하지 않을 수 있습니다.

따라서 로그에는 다음과 같은 정보가 중요할 수 있습니다.

  • 이벤트 발생 시각
  • Call ID
  • 상담원 ID
  • 내선번호
  • 이벤트 종류
  • 이전 상태
  • 변경 상태
  • 제어 명령
  • 명령 처리 결과
  • 오류 코드

특히 같은 통화를 처음부터 끝까지 추적하려면 Call ID 같은 고유 식별자가 중요합니다.

27장 CTI 시스템에서 시간 순서가 중요한 이유#

콜센터 전화는 짧은 시간 안에 여러 이벤트가 발생합니다.

예를 들어:

Ringing
 ↓
Established
 ↓
Held
 ↓
Retrieved
 ↓
Transferred
 ↓
Released

이런 이벤트 순서를 정확히 기록해야 통화 흐름을 복원할 수 있습니다.

순서가 뒤바뀌거나 일부 이벤트가 누락되면 상담 시스템의 상태가 실제 전화와 달라질 수 있습니다.

따라서 CTI 개발과 운영에서는 단순 데이터 전달뿐 아니라 이벤트 순서와 상태 전이도 중요한 문제입니다.

28장 CTI와 통계 시스템의 관계#

CTI 이벤트는 실시간 화면 연동뿐 아니라 통계에도 활용될 수 있습니다.

예를 들어 이벤트를 기반으로 다음과 같은 정보를 계산할 수 있습니다.

  • 통화 시작 시각
  • 통화 종료 시각
  • 통화 시간
  • 보류 여부
  • 호 전환 여부
  • 상담원 상태 시간
  • 후처리 시간

이러한 데이터는 상담원 운영 분석이나 콜센터 성능 분석에 활용될 수 있습니다.

즉 CTI는 실시간 기능뿐 아니라 운영 데이터의 원천 역할도 할 수 있습니다.

29장 CTI와 녹취 시스템의 관계#

전체 콜시스템에서는 CTI와 녹취 시스템도 연계될 수 있습니다.

전화가 시작되었을 때 녹취가 시작되고 통화가 종료되면 녹취가 종료되는 구조를 생각할 수 있습니다.

이때 통화 ID나 상담원 ID, 고객정보 등을 함께 연결하면 나중에 CRM에서 해당 상담의 녹취를 찾을 수 있습니다.

원본 전체 콜 흐름에서도 상담 응대 단계에서 상담이력 작성과 녹취 시작·종료가 함께 처리되는 구조를 제시합니다.

30장 CTI와 CRM 데이터 연계#

콜 종료 후에는 전화 이벤트만 남는 것이 아니라 상담 기록도 함께 남습니다.

예를 들어:

  • 고객 ID
  • 상담원 ID
  • 통화 시작 시각
  • 종료 시각
  • 상담 유형
  • 상담 결과
  • 녹취 파일 ID

등을 연계할 수 있습니다.

이렇게 전화 데이터와 고객 데이터를 결합하면 단순 통화 기록이 아니라 상담 업무 데이터가 됩니다.

31장 CTI 시스템을 개발할 때 중요한 관점#

CTI 개발은 단순 API 연동이라고 생각하면 놓치는 부분이 많습니다.

실제로는 다음 세 가지를 동시에 봐야 합니다.

통신 관점#

전화 호가 어떻게 움직이는가

이벤트 관점#

어떤 상태 변화가 언제 발생하는가

업무 관점#

그 이벤트에 따라 상담 화면이 어떻게 변해야 하는가

CTI는 이 세 영역의 경계에 있기 때문에 전체 흐름을 이해하는 것이 중요합니다.

32장 CTI 서버가 필요한 이유를 한 문장으로 정리하면#

CTI 서버는:

PBX에서 발생하는 전화 이벤트를 업무 시스템이 사용할 수 있는 형태로 전달하고, 업무 시스템에서 발생한 전화 제어 명령을 올바른 상담원 단말로 전달하는 중간 시스템

이라고 정리할 수 있습니다.

33장 CTI 구조를 가장 단순하게 암기하면#

다음 세 단계를 기억하면 됩니다.

전화 시스템
    ↓
   CTI
    ↓
업무 시스템

조금 더 구체적으로는:

PBX
 ↓
CTI Server
 ↓
CRM

입니다.

그리고 CTI의 역할은 두 가지입니다.

이벤트 전달

명령 제어

입니다.

CTI 시스템 구성 FAQ#

CTI 서버는 어디에 위치하는가?#

일반적으로 PBX와 CRM 또는 상담원 애플리케이션 사이에서 동작합니다.

CTI 서버의 가장 중요한 역할은 무엇인가?#

PBX 이벤트를 업무 시스템으로 전달하고 반대로 업무 시스템의 전화 제어 명령을 PBX로 전달하는 것입니다.

CTI 서버가 직접 전화를 연결하는가?#

기본적인 전화 연결은 PBX가 담당합니다. CTI는 전화 시스템과 컴퓨터 시스템 사이의 연동을 담당합니다.

상담원 단말 매핑이란 무엇인가?#

어느 상담원이 어느 전화기나 내선번호를 사용하는지를 연결하는 정보입니다.

CTI 서버가 장애 나면 전화도 반드시 안 되는가?#

구성에 따라 다르지만 원본 자료에서는 전화는 가능하면서 화면 연동이 끊길 수 있다고 설명합니다.

CTI 서버를 왜 이중화하는가?#

CTI 서버 하나가 전체 화면 연동의 단일 장애점이 되는 것을 줄이기 위해서입니다.

Failover란 무엇인가?#

주 서버가 장애를 일으켰을 때 다른 서버가 역할을 이어받도록 하는 장애 대응 방식입니다.

Screen Pop은 어떤 흐름으로 동작하는가?#

전화 착신 → CTI 이벤트 → ANI/DNIS 전달 → CRM 조회 → 고객정보 화면 표시의 흐름으로 이해할 수 있습니다.

CTI와 ACD의 차이는 무엇인가?#

ACD는 전화를 상담원에게 분배하고 CTI는 전화 이벤트와 업무 시스템을 연결합니다.

CTI 로그에서 무엇을 확인해야 하는가?#

Call ID, 상담원 ID, 내선번호, 이벤트 종류, 발생 시각, 명령 처리 결과 등이 중요할 수 있습니다.

핵심 정리#

CTI 시스템은 PBX와 CRM 사이에서 전화 이벤트와 제어 명령을 중계하는 구조입니다.

가장 기본적인 구조는:

PBX
 ↕
CTI 서버
 ↕
CRM / 상담원 UI

입니다.

CTI 서버의 핵심 역할은:

PBX 이벤트 수신·정규화

상담원과 단말 매핑

전화 제어 명령 라우팅

세션 재접속·복구

장애 시 Failover

입니다.

또한 실제 콜 흐름에서는:

PBX → IVR → ACD → CTI → 상담원·CRM

순서로 연결될 수 있습니다.

CTI 서버 장애 시 PBX가 정상이라면 전화 자체는 가능할 수 있지만 Screen Pop과 CRM 연동 등 컴퓨터 연계 기능이 중단될 수 있습니다.

가장 짧게 정리하면 다음 한 문장으로 기억하면 됩니다.

CTI 서버는 전화 시스템의 상태와 업무 시스템의 화면을 연결하는 중간 허브다.

이 페이지의 목차