Click-to-Call이란? CRM에서 클릭 한 번으로 전화를 거는 CTI 발신 원리

1장 전화번호를 직접 누르지 않아도 전화가 걸리는 이유#

전통적인 전화 업무에서는 상담원이 고객 전화번호를 확인한 뒤 전화기에 직접 번호를 입력해야 했습니다.

예를 들어 CRM에:

고객명: 김고객
전화번호: 010-1234-5678

이 표시되어 있다면 상담원은 번호를 확인하고 전화기에서 하나씩 입력해야 했습니다.

하지만 CTI가 연결된 콜센터에서는 전화번호 옆의 버튼을 클릭하는 것만으로 바로 전화를 걸 수 있습니다.

010-1234-5678  [통화]

상담원이 [통화] 버튼을 누르면 CRM이 CTI에 발신을 요청하고, CTI는 올바른 상담원 단말과 PBX를 찾아 실제 발신을 실행합니다.

이 기능이 Click-to-Call입니다.

원본 자료에서도 Click-to-Call을 CRM의 고객 번호 클릭 → 발신으로 정의하고 있습니다.

2장 Click-to-Call이란 무엇인가#

Click-to-Call은 화면에 표시된 전화번호를 클릭해 전화를 거는 CTI 기능입니다.

쉽게 말하면:

전화번호를 전화기에 다시 입력하지 않고 CRM에서 바로 발신하는 기능

입니다.

원본 CTI 자료에서는 CTI가 전화기에서 발생한 이벤트를 컴퓨터로 전달하는 것뿐 아니라 컴퓨터에서 전화기를 제어할 수 있다고 설명합니다. 그 대표적인 예로 Click-to-Call과 Hold 등을 제시합니다.

즉 Click-to-Call은:

컴퓨터 → 전화

방향의 대표적인 CTI 기능입니다.

3장 Screen Pop과 Click-to-Call의 차이#

두 기능 모두 CTI의 대표 기능이지만 방향이 반대입니다.

Screen Pop#

전화
 ↓
CTI
 ↓
CRM 화면

전화 이벤트가 컴퓨터 화면을 움직입니다.

Click-to-Call#

CRM 화면
 ↓
CTI
 ↓
전화

컴퓨터 화면에서 전화 시스템을 움직입니다.

따라서 가장 쉽게 기억하면:

Screen Pop = 전화가 화면을 움직인다

Click-to-Call = 화면이 전화를 움직인다

입니다.

4장 Click-to-Call의 기본 구조#

원본 CRM 연동 자료에서는 상담원 명령이 다음 경로로 전달된다고 설명합니다.

상담원 명령
 ↓
CTI
 ↓
PBX

Click-to-Call을 조금 더 구체적으로 표현하면 다음과 같습니다.

상담원
 ↓
CRM 고객번호 클릭
 ↓
CTI 서버
 ↓
PBX
 ↓
상담원 단말
 ↓
고객에게 발신

이 구조가 Click-to-Call의 핵심입니다.

5장 상담원이 번호를 클릭하면 실제로 무슨 일이 일어날까#

예를 들어 상담원이 CRM에서 다음 번호를 클릭했다고 하겠습니다.

01012345678

전체 흐름을 단계별로 보면 다음과 같습니다.

1단계: 고객 선택#

상담원이 CRM에서 고객정보를 조회합니다.

2단계: 전화번호 클릭#

전화번호 또는 발신 버튼을 클릭합니다.

3단계: 발신 명령 생성#

CRM이 CTI 서버에 발신 명령을 전달합니다.

4단계: 상담원 확인#

CTI가 어떤 상담원이 요청했는지 확인합니다.

5단계: 단말 확인#

해당 상담원이 사용하는 전화기나 소프트폰을 찾습니다.

6단계: PBX에 명령 전달#

CTI가 PBX로 발신 명령을 전달합니다.

7단계: 실제 발신#

상담원 단말을 통해 고객에게 전화가 연결됩니다.

6장 CTI 서버가 중간에 필요한 이유#

CRM이 고객 전화번호를 알고 있다고 해서 전화 시스템이 자동으로 움직이는 것은 아닙니다.

CRM은 업무 시스템입니다.

PBX는 전화 시스템입니다.

둘은 서로 다른 역할을 합니다.

CTI가 가운데서 다음 정보를 연결합니다.

누가 발신했는가
+
어느 단말을 사용하는가
+
누구에게 전화할 것인가

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

7장 상담원 단말 매핑이 중요한 이유#

Click-to-Call에서 매우 중요한 정보가 상담원과 전화 단말의 연결 관계입니다.

예를 들어:

상담원 A → 내선 2101
상담원 B → 내선 2102
상담원 C → 내선 2103

라고 하겠습니다.

상담원 B가 CRM에서 전화번호를 클릭했다면 CTI는:

이 명령은 상담원 B가 보냈다.

그리고:

상담원 B의 전화기는 2102다.

라는 사실을 알아야 합니다.

그래야 올바른 전화기에서 발신이 시작됩니다.

원본 자료에서도 CTI 서버가 상담원 단말 매핑을 담당한다고 설명합니다.

8장 단말 매핑이 잘못되면 어떤 일이 생길까#

상담원과 단말 매핑이 잘못되어 있다고 하겠습니다.

상담원 A → 실제 2101
CTI 설정 → 2102

이 상태에서 상담원 A가 Click-to-Call을 실행하면 예상하지 않은 단말에서 발신이 시작될 수 있습니다.

따라서 다음과 같은 장애가 발생할 수 있습니다.

클릭했는데 전화가 안 걸림
다른 상담원 전화기에서 발신됨
발신 명령 오류
CRM에서는 발신 처리됐지만 실제 단말은 반응 없음

Click-to-Call 장애에서는 상담원 ID와 내선·단말 매핑을 확인하는 것이 중요합니다.

9장 Click-to-Call은 전화번호를 PBX에 바로 보내는 기능일까#

단순히 고객 전화번호만 PBX에 보내는 것으로 끝나는 것은 아닙니다.

CTI는 일반적으로:

요청한 상담원
상담원 단말
고객 전화번호
현재 세션

같은 정보를 함께 고려해야 합니다.

즉 다음 구조입니다.

상담원
+
상담원 단말
+
대상 번호
+
CTI 세션
 ↓
발신

이 때문에 Click-to-Call은 단순 링크 기능이 아니라 상담원 세션과 전화 시스템이 연결된 CTI 기능입니다.

10장 발신 명령과 전화 이벤트는 다른 것이다#

상담원이 Click-to-Call을 실행하면 먼저 명령 Command이 발생합니다.

예:

Make Call

또는 시스템에서 사용하는 발신 명령입니다.

그 이후 실제 전화 상태가 바뀌면 다시 이벤트 Event가 발생할 수 있습니다.

개념적으로는:

CRM
 ↓
발신 명령
 ↓
CTI
 ↓
PBX
 ↓
실제 발신
 ↓
전화 상태 이벤트
 ↓
CTI
 ↓
CRM

입니다.

즉:

명령 = 전화를 걸어라

이벤트 = 전화 상태가 이렇게 바뀌었다

로 구분할 수 있습니다.

11장 발신 결과도 CRM에 반영할 수 있다#

Click-to-Call을 실행했다고 해서 무조건 고객과 통화가 연결되는 것은 아닙니다.

고객이:

전화를 받지 않을 수 있고
통화 중일 수 있고
연결이 실패할 수도 있습니다.

따라서 CRM에서는 발신 요청만 기록하는 것이 아니라 실제 전화 이벤트를 다시 받아 상태를 갱신할 수 있습니다.

예:

발신 요청
 ↓
호 생성
 ↓
고객 연결
 ↓
Established
 ↓
통화
 ↓
Released

처럼 전화 이벤트와 결합할 수 있습니다.

12장 Click-to-Call과 CRM 상담이력#

Click-to-Call을 사용하는 가장 큰 장점 중 하나는 발신 대상 고객과 상담 업무 컨텍스트가 이미 연결되어 있다는 점입니다.

상담원이 CRM에서 고객 A를 선택하고 발신하면 시스템은:

고객 A
+
전화 발신
+
상담원

을 연결할 수 있습니다.

원본 CTI 자료에서도 상담 이력과 통화시간이 CRM에 자동 연동되는 것을 CTI의 가치로 제시합니다.

따라서 발신 이후 상담이력 작성과 연결하기 쉬운 구조가 됩니다.

13장 Click-to-Call은 아웃바운드 업무에서 특히 편리하다#

아웃바운드 상담에서는 상담원이 고객에게 먼저 전화를 겁니다.

예를 들어:

고객 안내
후속 상담
만족도 확인
예약 확인

등의 업무가 있을 수 있습니다.

상담원이 CRM에서 고객을 찾고 다시 전화번호를 전화기에 입력한다면 반복 작업이 많아집니다.

Click-to-Call을 사용하면:

고객 선택
 ↓
전화 클릭
 ↓
발신

으로 줄일 수 있습니다.

원본은 Click-to-Call의 세부 업무 사례까지는 제시하지 않으므로 구체적인 적용 업무는 조직마다 달라질 수 있습니다.

14장 Click-to-Call의 핵심 가치는 재입력 제거다#

상담원 입장에서 가장 직접적인 변화는 전화번호를 다시 입력할 필요가 없다는 것입니다.

기존 방식:

CRM 고객 조회
 ↓
전화번호 확인
 ↓
번호 기억 또는 복사
 ↓
전화기 입력
 ↓
발신

Click-to-Call:

CRM 고객 조회
 ↓
전화번호 클릭
 ↓
발신

처럼 단순화됩니다.

원본은 CTI가 전화기 버튼을 화면 클릭으로 대체하여 상담원 UX를 향상시킨다고 설명합니다.

15장 Click-to-Call과 Answer의 차이#

원본의 CTI 통화 제어에는 Click-to-Call뿐 아니라 Answer도 있습니다.

Click-to-Call#

상담원이 새로운 전화를 겁니다.

Answer#

상담원에게 들어온 전화를 받습니다.

즉:

Click-to-Call = 발신
Answer = 응대

입니다.

16장 Hold와 Retrieve란 무엇인가#

원본에서는 CTI의 주요 통화 제어 기능으로 Hold / Retrieve를 제시합니다.

Hold#

현재 통화를 보류합니다.

Retrieve#

보류된 통화를 다시 이어갑니다.

개념적으로:

통화 중
 ↓
Hold
 ↓
보류
 ↓
Retrieve
 ↓
통화 재개

입니다.

17장 Transfer란 무엇인가#

Transfer는 현재 고객 전화를 다른 상담원이나 내선으로 넘기는 기능입니다.

원본에서는 CTI 통화 제어 기능 중 하나로 Transfer를 제시합니다.

예:

고객
 ↓
상담원 A
 ↓
Transfer
 ↓
상담원 B

입니다.

18장 Transfer에는 어떤 방식이 있을까#

원본의 PBX 호 전환 문서에서는 Transfer를 두 방식으로 구분합니다.

Blind Transfer#

상대방에게 바로 연결한 뒤 기존 상담원은 통화에서 빠집니다.

Attended Transfer#

먼저 상대 상담원에게 내용을 설명한 뒤 고객을 연결합니다.

즉 CTI의 Transfer 버튼 뒤에는 실제 PBX의 호 전환 기능이 동작합니다.

19장 Conference란 무엇인가#

원본 CTI 제어 문서에서는 Conference를 3자 통화 기능으로 설명합니다.

예:

고객
+
상담원 A
+
상담원 B

가 동시에 통화할 수 있는 구조입니다.

복잡한 문의에서 다른 담당자가 함께 참여해야 하는 상황 등에 사용할 수 있습니다.

원본은 구체적인 업무 사례까지는 제시하지 않습니다.

20장 Hangup이란 무엇인가#

Hangup은 통화를 종료하는 기능입니다.

원본에서는 CTI의 주요 제어 기능으로:

Hangup = 종료

를 제시합니다.

즉 전화기의 종료 버튼을 상담원 화면의 버튼으로 대체할 수 있습니다.

21장 CTI 통화 제어 기능을 정리하면#

원본 자료에 제시된 주요 제어 기능은 다음과 같습니다.

기능	의미
Click-to-Call	CRM 고객번호 클릭 후 발신
Answer	호 응대
Hold	통화 보류
Retrieve	보류된 통화 재개
Transfer	호 전환
Conference	3자 통화
Hangup	통화 종료

이 기능들이 상담 화면 안으로 들어오면 별도 전화기 버튼을 조작하는 업무가 줄어듭니다.

22장 CTI 통화 제어는 양방향 구조다#

CTI는 단순히 전화를 제어하는 기능만 제공하지 않습니다.

전화 상태도 다시 CRM으로 전달합니다.

전체 구조는 다음과 같습니다.

CRM
 ↓
전화 명령
 ↓
CTI
 ↓
PBX

PBX
 ↓
전화 이벤트
 ↓
CTI
 ↓
CRM

원본 CRM 연동 자료도 이 구조를 다음처럼 설명합니다.

호 이벤트 → CTI → CRM

상담원 명령 → CTI → PBX

즉 CTI는 명령과 이벤트를 모두 중재합니다.

23장 Click-to-Call 장애가 발생하면 어디를 확인할까#

상담원이 CRM의 전화번호를 클릭했는데 아무 반응이 없다고 하겠습니다.

전체 경로를 나누면 다음과 같습니다.

CRM
 ↓
CTI
 ↓
상담원 매핑
 ↓
PBX
 ↓
상담원 단말
 ↓
고객

따라서 장애도 단계별로 볼 수 있습니다.

1. CRM에서 발신 명령이 생성됐는가#

2. CTI가 명령을 받았는가#

3. 상담원 세션이 정상인가#

4. 상담원 단말 매핑이 정상인가#

5. PBX가 발신 명령을 처리했는가#

6. 실제 단말에서 발신됐는가#

이처럼 경로를 나누어 확인하는 것이 중요합니다.

24장 CRM에서는 클릭했는데 다른 전화기에서 발신된다면#

이 경우 CTI 명령 자체는 전달됐을 가능성이 있습니다.

하지만 상담원과 단말의 매핑을 확인해야 합니다.

원본 CTI 서버 자료에서는 어느 단말이 어느 상담원인지 매핑하는 것을 핵심 역할로 제시합니다.

즉:

사용자 ID
↔
상담원 ID
↔
내선번호
↔
전화 단말

관계가 정확해야 합니다.

25장 전화기는 반응하는데 고객에게 연결되지 않는다면#

이 경우 Click-to-Call 명령이 CTI와 PBX까지 전달됐을 수 있습니다.

하지만 실제 전화 연결 과정에서는 추가적인 전화망 문제가 존재할 수 있습니다.

원본은 Click-to-Call 이후 세부 통신 장애까지는 설명하지 않습니다.

따라서 이 글에서는:

CRM·CTI 명령 전달 성공 여부와 실제 전화 연결 성공 여부를 별도로 봐야 한다

는 정도가 핵심입니다.

26장 Click-to-Call과 상담원 세션#

원본 CTI 제어 문서에서는 CTI 명령은 인증된 세션에서만 허용되어야 한다고 설명합니다.

이는 매우 중요합니다.

단순히:

누군가 API를 호출하면 전화가 걸리는 구조

여서는 안 됩니다.

시스템은 최소한:

누가 로그인했는지
어떤 상담원인지
어떤 전화 단말을 제어할 권한이 있는지

를 확인해야 합니다.

27장 왜 인증된 세션이 필요한가#

CTI는 실제 전화기를 움직일 수 있습니다.

따라서 권한 없는 사용자가 CTI 명령을 실행할 수 있다면 문제가 됩니다.

원본은 특히 임의 단말에 대해:

발신
녹음
전환

등을 수행할 수 없도록 권한과 세션 관리가 필요하다고 설명합니다.

즉 CTI 명령은 일반적인 화면 버튼보다 보안 중요도가 높습니다.

28장 Click-to-Call API가 외부에 노출되면 왜 위험할까#

원본에는 명확한 경고가 있습니다.

CTI API가 외부에 노출될 경우:

통화 도청
임의 발신

같은 위험이 있을 수 있으므로 인증·암호화·권한 통제가 필수라고 설명합니다.

특히 Click-to-Call API가 적절하게 보호되지 않는다면 공격자가 임의 번호로 발신을 시도할 수 있는 구조가 될 수 있습니다.

29장 CTI API 보안의 핵심 요소#

원본 내용을 기준으로 핵심은 다음 세 가지입니다.

인증#

누가 요청했는지 확인

암호화#

CTI 명령과 세션 정보를 안전하게 전달

권한 통제#

해당 상담원이 실제로 그 전화 기능을 사용할 수 있는지 확인

여기에 원본에서는 세션 관리의 필요성도 함께 강조합니다.

30장 모든 상담원이 모든 단말을 제어하면 안 되는 이유#

예를 들어 상담원 A가 상담원 B의 전화기를 제어할 수 있다면 정상적인 구조라고 보기 어렵습니다.

따라서 CTI에서는:

상담원 A
 ↓
자신에게 허용된 단말

관계를 명확히 관리해야 합니다.

원본에서도 임의 단말에 대한 발신·전환 등이 가능하지 않도록 권한과 세션 관리가 필요하다고 설명합니다.

31장 브라우저 기반 상담 화면에서도 Click-to-Call을 사용할 수 있다#

원본 CTI 개요에서는 WebRTC·WebSocket을 브라우저 기반 소프트폰의 연동 방식으로 제시합니다.

따라서 브라우저 기반 상담 시스템에서도:

웹 CRM
 ↓
전화번호 클릭
 ↓
CTI 또는 웹 기반 전화 제어
 ↓
소프트폰
 ↓
발신

과 같은 구조를 생각할 수 있습니다.

실제 구현 방식은 사용하는 컨택센터 플랫폼에 따라 달라질 수 있습니다.

32장 하드폰 기반과 소프트폰 기반의 차이#

Click-to-Call의 사용자 경험은 비슷하지만 실제 단말은 다를 수 있습니다.

하드웨어 전화기#

CRM
 ↓
CTI
 ↓
PBX
 ↓
책상 전화기

소프트폰#

CRM
 ↓
CTI
 ↓
PBX 또는 컨택센터
 ↓
PC 소프트폰

브라우저 기반#

웹 CRM
 ↓
CTI / 웹 이벤트
 ↓
WebRTC 소프트폰

어떤 구조이든 핵심은 화면에서 발신 명령을 실행한다는 점입니다.

33장 First-Party 방식에서의 Click-to-Call#

First-Party CTI에서는 사용자 PC가 자신의 전화 단말을 직접 제어하는 구조로 이해할 수 있습니다.

개념적으로:

CRM
 ↓
상담원 PC
 ↓
자신의 전화기
 ↓
발신

입니다.

34장 Third-Party 방식에서의 Click-to-Call#

Third-Party CTI에서는 중앙 CTI 서버가 PBX를 통해 단말을 제어합니다.

CRM
 ↓
CTI 서버
 ↓
PBX
 ↓
상담원 전화기
 ↓
발신

대규모 콜센터에서는 상담원과 단말의 중앙 매핑과 명령 라우팅이 중요해집니다.

원본 CTI 서버 자료에서도 명령 라우팅을 핵심 역할로 제시합니다.

35장 Click-to-Call 성공 여부를 로그로 남기는 이유#

원본은 Click-to-Call 로그 항목을 세부적으로 제시하지 않습니다.

다만 CTI 명령이 실제 전화 시스템을 제어하므로 운영 관점에서는 요청과 처리 결과를 추적할 수 있어야 장애 분석이 쉬워집니다.

예를 들어 개념적으로 다음 흐름을 추적할 수 있습니다.

상담원
 ↓
발신 요청
 ↓
CTI 처리
 ↓
PBX 처리
 ↓
전화 상태

즉 단순히 버튼 클릭 여부만 볼 것이 아니라 명령이 어느 단계까지 처리되었는지를 확인해야 합니다.

36장 Click-to-Call에서 고객번호와 상담원번호를 혼동하면 안 된다#

하나의 발신에는 두 번호가 존재합니다.

상담원 측 번호#

전화가 시작되는 단말 또는 내선

고객 측 번호#

실제로 연락할 대상 번호

CTI는 어느 상담원이 발신했는지 확인해 올바른 단말에서 고객번호로 전화를 걸도록 명령을 라우팅합니다.

즉:

상담원 단말
→ 고객 번호

관계를 정확하게 구성해야 합니다.

37장 Click-to-Call과 전화번호 정규화#

원본 CRM 연동 자료에서는 전화번호 정규화를 중요한 설계 포인트로 제시합니다.

CRM의 고객번호가:

010-1234-5678

형태로 저장되어 있고 전화 시스템에는 다른 형식이 필요한 경우 시스템 내부에서 적절한 형식으로 처리할 필요가 있을 수 있습니다.

원본은 Click-to-Call용 번호 변환 규칙을 구체적으로 제시하지 않으므로 실제 규칙은 PBX와 통신 환경에 따라 달라질 수 있습니다.

38장 발신 버튼을 여러 번 누르면 어떻게 해야 할까#

원본에는 중복 클릭 처리 정책까지는 포함되어 있지 않습니다.

하지만 Click-to-Call이 실제 전화 명령이라는 점을 고려하면 UI에서 동일 명령이 반복 실행되지 않도록 처리하는 문제도 설계 시 고려할 수 있습니다.

다만 이는 원본에 없는 확장적인 설계 관점이며 구체적인 구현은 시스템에 따라 달라집니다.

39장 네트워크가 끊기면 Click-to-Call은 어떻게 될까#

CTI와 CRM은 네트워크를 통해 연결됩니다.

원본 CTI 서버 자료에서는 CTI의 역할로:

재접속
세션 복구
Failover

를 제시합니다.

따라서 연결이 끊어지면 발신 명령이 전달되지 않거나 세션이 정상적으로 유지되지 않을 수 있습니다.

연결 복구 후에는 상담원 세션과 단말 상태가 다시 정상인지 확인할 필요가 있습니다.

40장 CTI 서버 장애 시 Click-to-Call은 어떻게 될까#

원본 자료에서는 CTI 서버 장애 시 전화 자체는 가능할 수 있지만 화면 연동은 끊길 수 있다고 설명합니다.

Click-to-Call은 CRM에서 CTI를 통해 전화 명령을 전달하는 기능이므로 CTI 서버에 문제가 있다면 영향을 받을 수 있습니다.

즉 상담원이 전화기에서 직접 번호를 눌러 통화할 수 있더라도 CRM의 Click-to-Call은 작동하지 않는 상황이 가능할 수 있습니다.

41장 Click-to-Call은 단순 편의 기능만은 아니다#

겉으로 보면 번호 입력을 줄여주는 작은 기능처럼 보입니다.

하지만 시스템 구조에서는:

고객정보
+
상담원
+
전화번호
+
상담원 단말
+
전화 이벤트

를 연결합니다.

즉 CRM에 존재하는 고객 컨텍스트와 실제 전화 발신을 하나의 업무 흐름으로 만드는 기능입니다.

이 때문에 Click-to-Call은 CTI의 양방향 연동을 가장 쉽게 이해할 수 있는 대표 사례입니다.

42장 Screen Pop과 함께 사용하면 업무 흐름이 완성된다#

인바운드에서는:

고객 전화
 ↓
CTI
 ↓
CRM Screen Pop

아웃바운드에서는:

CRM 고객정보
 ↓
Click-to-Call
 ↓
CTI
 ↓
고객 전화

가 됩니다.

즉 CTI는:

전화 → CRM

과

CRM → 전화

를 모두 연결합니다.

이것이 Computer Telephony Integration의 핵심입니다.

43장 Click-to-Call을 한 문장으로 설명하면#

가장 쉽게 설명하면:

CRM의 고객 전화번호를 클릭하면 CTI가 해당 상담원의 전화 단말을 찾아 고객에게 발신하도록 PBX에 명령하는 기능이다.

조금 더 짧게 표현하면:

CRM의 전화번호를 실제 전화 발신으로 연결하는 CTI 기능

이라고 할 수 있습니다.

Click-to-Call FAQ#

Click-to-Call이란 무엇인가#

CRM에 표시된 고객 전화번호를 클릭하면 실제 전화 발신이 이루어지는 CTI 기능입니다. 원본에서는 CRM의 고객 번호 클릭 → 발신으로 정의합니다.

Click-to-Call은 CRM 기능인가 CTI 기능인가#

사용자 버튼은 CRM에 있을 수 있지만 실제 전화 제어는 CTI와 PBX 연동을 통해 이루어집니다.

Click-to-Call의 기본 흐름은 무엇인가#

CRM → CTI → PBX → 상담원 단말 → 고객으로 이해할 수 있습니다. 원본 CRM 자료에서도 상담원 명령이 CTI를 거쳐 PBX로 전달된다고 설명합니다.

CTI 서버는 Click-to-Call에서 어떤 역할을 하는가#

상담원과 단말을 매핑하고 올바른 발신 명령을 PBX로 라우팅합니다.

Click-to-Call과 Screen Pop의 차이는 무엇인가#

Screen Pop은 전화 이벤트가 CRM 화면을 움직이는 기능이고 Click-to-Call은 CRM 화면에서 전화 시스템을 제어하는 기능입니다.

CTI에서는 발신 외에 어떤 통화 제어가 가능한가#

원본에서는 Answer, Hold/Retrieve, Transfer, Conference, Hangup을 주요 기능으로 제시합니다.

Hold와 Retrieve의 차이는 무엇인가#

Hold는 통화를 보류하고 Retrieve는 보류된 통화를 다시 이어가는 기능입니다.

Conference는 무엇인가#

원본에서는 3자 통화 기능으로 설명합니다.

CTI 명령은 누구나 실행할 수 있는가#

아닙니다. 원본은 CTI 명령을 인증된 세션에서만 허용해야 한다고 설명합니다.

CTI API 보안이 중요한 이유는 무엇인가#

실제 발신·전환 등 전화 기능을 제어하기 때문입니다. 원본은 외부 노출 시 임의 발신이나 통화 도청 위험이 있으므로 인증·암호화·권한 통제가 필수라고 경고합니다.

클릭했는데 다른 상담원 전화기에서 발신된다면 무엇을 확인해야 하는가#

상담원 ID와 내선·단말 매핑을 우선 확인할 필요가 있습니다.

핵심 정리#

Click-to-Call은 CRM의 고객 전화번호를 실제 전화 발신으로 연결하는 대표적인 CTI 기능입니다.

원본에서는 다음과 같이 정의합니다.

CRM 고객 번호 클릭
 ↓
발신

실제 시스템 구조로 확장하면 다음처럼 이해할 수 있습니다.

상담원
 ↓
CRM
 ↓
Click-to-Call
 ↓
CTI 서버
 ↓
PBX
 ↓
상담원 전화기 / 소프트폰
 ↓
고객

CTI 서버는 원본 자료 기준으로:

상담원 단말 매핑

명령 라우팅

재접속·세션 복구

등을 담당합니다.

또한 CTI에서는 Click-to-Call뿐 아니라 다음 기능을 화면에서 제어할 수 있습니다.

Answer = 전화 받기

Hold = 보류

Retrieve = 보류 해제·재개

Transfer = 호 전환

Conference = 3자 통화

Hangup = 통화 종료

그리고 이러한 명령은 실제 전화 시스템을 제어하므로 반드시 인증된 세션과 권한 관리가 필요합니다. 원본에서도 CTI API가 외부에 노출될 경우 임의 발신·통화 도청 위험이 있을 수 있으므로 인증·암호화·권한 통제가 필수라고 설명합니다.

가장 짧게 기억하면 다음과 같습니다.

Click-to-Call은 CRM의 전화번호 클릭을 실제 발신 명령으로 바꾸는 CTI 기능이다.