CTI와 CRM 연동 구조: 콜시스템의 전화 이벤트와 고객정보는 어떻게 연결될까

1장 전화 시스템과 CRM은 왜 따로 존재할까#

콜센터에서 상담원이 사용하는 화면을 보면 전화와 고객정보가 하나의 시스템처럼 움직이는 것처럼 보입니다.

고객이 전화를 걸면 화면에 고객정보가 나타나고, 상담원이 통화를 종료하면 통화시간과 상담결과가 저장됩니다.

하지만 실제 내부 구조에서는 전화 시스템과 CRM이 서로 다른 역할을 담당합니다.

전화 시스템은:

전화 착신
통화 연결
통화 종료
호 전환
상담원 분배

같은 통신 영역을 담당합니다.

CRM은:

고객정보
상담이력
주문정보
문의내역
업무 처리결과

같은 업무 데이터 영역을 담당합니다.

이 두 영역을 연결하는 중간 계층이 필요합니다.

원본 자료에서는 CRM과 콜시스템이 CTI·API·이벤트 버스를 통해 연결되며 양방향 데이터 동기화가 핵심이라고 설명합니다.

2장 CRM과 콜시스템의 기본 연동 구조#

원본 자료에서 제시하는 가장 기본적인 구조는 다음과 같습니다.

CRM / 상담 화면
       ↕
   CTI 미들웨어
       ↕
콜시스템
PBX / IVR / ACD

이 구조에서 각각의 역할을 구분해야 합니다.

CRM#

고객과 상담 업무 데이터를 관리합니다.

CTI 미들웨어#

전화 시스템의 이벤트와 상담원의 명령을 중간에서 전달합니다.

PBX·IVR·ACD#

실제 전화와 콜 흐름을 처리합니다.

3장 CTI 미들웨어가 왜 필요한가#

CRM이 PBX와 직접 연결되면 안 될까 생각할 수 있습니다.

하지만 실제 콜센터에는 여러 시스템이 동시에 동작합니다.

예를 들어:

PBX
ACD
IVR
CRM
녹취
통계
상담원 프로그램

등이 서로 다른 기술과 데이터 형식을 사용할 수 있습니다.

CTI 미들웨어는 이러한 시스템 사이에서 전화 이벤트를 전달하고 필요한 경우 형식을 맞춰주는 중간 역할을 합니다.

즉 CTI 미들웨어는 단순한 연결선이 아니라 전화 시스템과 업무 시스템 사이의 번역 계층에 가깝습니다.

4장 CRM과 콜시스템은 양방향으로 연결된다#

CRM 연동에서 가장 중요한 개념은 양방향입니다.

전화 시스템에서 CRM으로만 데이터가 흐르는 것이 아닙니다.

반대로 CRM에서 전화 시스템으로도 명령이 전달됩니다.

원본 자료에서는 다음 두 방향을 명확하게 구분합니다.

콜시스템 → CRM#

호 이벤트 전달

착신
종료
통화시간

CRM → 콜시스템#

상담원 명령 전달

발신
전환

이를 구조로 보면:

전화 이벤트
PBX → CTI → CRM

전화 제어
CRM → CTI → PBX

입니다.

5장 콜시스템에서 CRM으로 전달되는 정보#

고객 전화가 들어오면 콜시스템은 다양한 상태 변화를 발생시킵니다.

예를 들어:

전화가 들어옴
상담원에게 연결됨
실제 통화 시작
통화 종료

같은 이벤트입니다.

이 정보가 CTI를 거쳐 CRM으로 전달되면 CRM은 전화 흐름에 맞춰 업무 화면을 변경할 수 있습니다.

예:

전화 착신
 ↓
CTI 이벤트
 ↓
CRM
 ↓
고객정보 조회
 ↓
상담 화면 표시

이것이 Screen Pop의 기반이 됩니다.

6장 CRM에서 콜시스템으로 전달되는 명령#

연동은 반대 방향으로도 작동합니다.

상담원이 CRM 화면에서 전화번호를 클릭하면 전화 발신을 요청할 수 있습니다.

또 상담 중 다른 상담원에게 통화를 넘길 수도 있습니다.

구조는 다음처럼 볼 수 있습니다.

상담원
 ↓
CRM
 ↓
CTI
 ↓
PBX
 ↓
전화 제어

원본 자료에서는 상담원의 발신과 전환 같은 명령이 CTI를 거쳐 PBX로 전달된다고 설명합니다.

7장 고객 DB 조회는 어디에서 이루어질까#

CTI는 전화 이벤트를 전달하지만 일반적으로 고객 상세정보 자체를 모두 가지고 있는 시스템은 아닙니다.

고객정보는 CRM 또는 CRM이 사용하는 DB에 있습니다.

원본에서는 고객 조회 구조를:

CRM → DB 또는 CRM 내부

라고 설명합니다.

즉 다음과 같은 흐름을 생각할 수 있습니다.

CTI
 ↓
고객 식별값 전달
 ↓
CRM
 ↓
고객 DB
 ↓
고객정보

8장 전화번호는 고객을 찾기 위한 키가 될 수 있다#

인바운드 전화에서는 ANI 같은 발신번호를 이용해 고객을 검색할 수 있습니다.

예를 들어 CTI에서:

01012345678

이라는 번호가 넘어왔다고 하겠습니다.

CRM은 이 번호를 기준으로 고객 DB를 검색할 수 있습니다.

검색 결과가 한 명이면 해당 고객의 상세정보를 바로 표시할 수 있습니다.

하지만 실제로는 전화번호 형식이나 중복 고객 문제가 있기 때문에 단순 문자열 검색만으로 끝나지 않을 수 있습니다.

9장 전화번호 정규화가 필요한 이유#

원본 자료에서는 CRM 연동 설계 포인트로 고객 식별자 매핑과 전화번호 정규화를 명시합니다.

같은 전화번호라도 시스템마다 저장 방식이 다를 수 있습니다.

예를 들어:

010-1234-5678
01012345678
+82-10-1234-5678

모두 같은 전화번호를 의미할 수 있습니다.

그런데 형식이 다르면 CRM에서 고객을 찾지 못할 수 있습니다.

따라서 검색 전에 전화번호를 일정한 규칙으로 변환하는 과정이 필요합니다.

10장 고객 식별자 매핑이란 무엇인가#

전화번호만으로 모든 고객을 관리하는 것은 아닙니다.

CRM에는 보통 별도의 고객 ID가 존재합니다.

예를 들어:

전화번호
01012345678

↓

고객 ID
C000123

처럼 연결됩니다.

CTI에서는 전화번호를 전달하고, CRM에서는 해당 번호를 고객 ID로 변환한 뒤 나머지 고객정보를 조회할 수 있습니다.

즉 고객 식별자 매핑은 통신 영역의 식별값과 업무 영역의 식별값을 연결하는 과정입니다.

11장 같은 전화번호에 고객이 여러 명이면 어떻게 될까#

실제 고객 DB에서는 하나의 전화번호가 여러 고객에 연결될 가능성도 있습니다.

예를 들어:

가족 공용번호
회사 대표번호
보호자 연락처

같은 경우입니다.

이 경우:

전화번호 검색
 ↓
고객 A
고객 B
고객 C

처럼 여러 결과가 나올 수 있습니다.

이때 특정 고객을 무조건 자동 선택하면 잘못된 고객정보가 표시될 수 있습니다.

따라서 다중 검색 시에는 고객 선택 화면을 제공하는 등의 업무 정책이 필요할 수 있습니다.

12장 고객을 찾지 못하면 어떻게 해야 할까#

원본 자료에서는 ID 매핑 실패 시 Fallback을 설계 포인트로 제시합니다.

Fallback은 정상적인 매핑이 실패했을 때 사용할 대체 흐름입니다.

예를 들어:

고객 검색 성공
→ 고객 상세화면

고객 검색 실패
→ 고객 검색 화면

미등록 고객
→ 신규 고객 화면

처럼 처리할 수 있습니다.

중요한 것은 고객을 자동으로 찾지 못했다고 상담 업무 자체가 중단되어서는 안 된다는 점입니다.

13장 Screen Pop은 CRM 연동의 대표적인 결과다#

CTI와 CRM 연동을 가장 쉽게 체감할 수 있는 기능이 Screen Pop입니다.

전체 흐름은 다음과 같습니다.

전화 착신
 ↓
PBX
 ↓
CTI
 ↓
CRM
 ↓
고객 DB 조회
 ↓
고객 상세화면

즉 전화 시스템의 이벤트가 CRM 업무 화면을 움직이게 만듭니다.

이 때문에 CTI와 CRM 연동을 이해하면 Screen Pop의 원리도 자연스럽게 이해할 수 있습니다.

14장 상담이력은 어떻게 저장되는가#

원본 자료에서는 상담 이력 저장을:

CRM → DB

구조로 설명합니다.

즉 통화가 이루어졌다는 정보만 저장하는 것이 아니라 상담 업무의 결과도 CRM에서 DB로 저장합니다.

예를 들어 다음과 같은 정보가 포함될 수 있습니다.

고객 ID
상담원 ID
상담 시작 시각
상담 종료 시각
상담 내용
처리 결과

구체적인 필드는 조직과 CRM 설계에 따라 달라질 수 있습니다.

15장 통화시간과 상담이력을 연결하면 무엇이 달라질까#

전화 시스템은 통화 시작과 종료 시점을 알고 있습니다.

CRM은 상담 내용과 처리 결과를 알고 있습니다.

이 둘을 연결하면:

고객
+
상담원
+
통화시간
+
상담내용
+
처리결과

를 하나의 상담 기록으로 만들 수 있습니다.

즉 CTI와 CRM 연동은 단순히 화면을 자동으로 띄우는 것 이상의 의미가 있습니다.

전화 데이터와 업무 데이터를 하나의 상담 데이터로 결합하는 것이 핵심입니다.

16장 상담이력은 다른 시스템과도 연결된다#

원본 자료에서는 상담이력이 CRM 고객 상세화면뿐 아니라 다음 영역과 연결된다고 설명합니다.

통계·리포팅
AI 분석
STT
상담 요약
품질평가
VOC
만족도 데이터

즉 상담이력은 단순 보관 데이터가 아니라 콜센터 분석의 핵심 데이터가 됩니다.

17장 CRM 연동에서 Lock이 필요한 이유#

원본 자료에서는 잠금 Lock 정책을 통한 동시 수정 방지를 설계 포인트로 제시합니다.

예를 들어 동일 고객정보를 두 상담원이 동시에 수정한다고 하겠습니다.

상담원 A가 주소를 변경하고,

상담원 B가 연락처를 변경합니다.

두 작업이 동시에 저장되면 한쪽의 변경 내용이 덮어쓰여질 가능성이 있습니다.

이런 충돌을 방지하기 위해 동시 수정 정책이 필요합니다.

18장 Lock 정책은 무엇을 해결하는가#

Lock의 기본 목적은 동시에 같은 데이터를 수정하면서 발생하는 충돌을 방지하는 것입니다.

개념적으로는:

상담원 A
 ↓
고객정보 수정 중
 ↓
Lock

상담원 B
 ↓
동일 데이터 수정 시도
 ↓
정책에 따라 제한

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

원본에서는 Lock의 구체적인 구현 방식까지 제시하지는 않으므로, 여기서는 동시 수정 방지 정책이 필요하다는 수준이 핵심입니다.

19장 네트워크 단절은 왜 큰 문제인가#

CTI와 CRM은 서로 다른 시스템이기 때문에 네트워크에 문제가 생기면 상태가 어긋날 수 있습니다.

예를 들어:

고객과 통화 시작
CRM 화면 정상
네트워크 순간 단절
통화 종료
종료 이벤트를 CRM이 받지 못함

이라고 하겠습니다.

전화는 이미 끝났지만 CRM에서는 여전히 통화 중으로 표시될 수 있습니다.

이런 문제가 발생하면 시스템의 실제 상태와 화면 상태가 달라집니다.

20장 재동기화란 무엇인가#

원본 자료에서는 오프라인 또는 네트워크 단절 시 재동기화를 중요한 설계 포인트로 제시합니다.

재동기화는 연결이 복구된 뒤 서로 다른 시스템의 상태를 다시 맞추는 것입니다.

예를 들어:

CTI 상태
통화 종료

CRM 상태
통화 중

↓

재동기화

↓

CRM 상태
통화 종료

처럼 실제 상태에 맞게 정리해야 합니다.

21장 CTI 이벤트는 실시간성이 중요하다#

전화 이벤트는 순서가 중요합니다.

예를 들어:

Ringing
 ↓
Established
 ↓
Released

순서로 발생합니다.

이 가운데 하나라도 누락되면 CRM의 상태가 실제 통화와 달라질 수 있습니다.

따라서 CTI와 CRM 연동에서는 단순히 데이터를 전달하는 것뿐 아니라:

이벤트 순서
이벤트 누락
중복 이벤트
재연결

같은 문제를 함께 고려해야 합니다.

22장 CRM 연동에서 실시간과 저장 데이터를 구분해야 한다#

CTI와 CRM에는 서로 성격이 다른 데이터가 있습니다.

실시간 데이터#

착신 이벤트
통화 연결
통화 종료
상담원 상태

저장 데이터#

고객정보
상담이력
처리결과

실시간 이벤트는 즉시 화면에 반영되어야 하고, 상담이력은 DB에 정확하게 저장되어야 합니다.

따라서 실시간 이벤트 처리와 업무 데이터 저장을 분리해서 생각하는 것이 중요합니다.

23장 콜시스템 전체 흐름에서 CRM은 어디에 위치할까#

원본의 콜시스템 아키텍처는 다음 흐름을 제시합니다.

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

전화가 상담원에게 도달하기까지는 여러 시스템을 거칩니다.

CRM은 이 흐름의 마지막 업무 접점에서 고객정보와 상담 데이터를 처리합니다.

CTI는 전화 시스템과 CRM을 연결합니다.

24장 PBX와 CRM의 역할을 혼동하지 말자#

두 시스템의 역할은 완전히 다릅니다.

PBX#

전화 연결

CRM#

고객업무 관리

CTI#

두 시스템 연결

한 줄로 표현하면:

PBX는 전화를 알고, CRM은 고객을 알고, CTI는 둘을 연결한다

라고 정리할 수 있습니다.

25장 IVR과 CRM은 어떻게 연결될 수 있을까#

IVR은 고객의 입력을 받아 업무를 분기합니다.

예를 들어 고객이:

주문조회 1번

을 선택했다고 하겠습니다.

이 정보가 상담원에게 전달될 수 있다면 CRM에서는 단순 고객정보뿐 아니라 고객이 어떤 메뉴를 통해 들어왔는지까지 업무 컨텍스트로 활용할 수 있습니다.

원본 CRM 연동 문서는 구체적인 IVR 데이터 항목까지 제시하지는 않지만, 콜시스템 영역을 PBX·IVR·ACD로 함께 묶어 CTI 미들웨어와 연결하는 구조를 제시합니다.

26장 ACD와 CRM 연동은 왜 중요한가#

ACD는 상담원을 선택합니다.

CRM은 해당 상담원의 업무 화면을 관리합니다.

따라서:

ACD
 ↓
상담원 선택
 ↓
CTI
 ↓
해당 상담원 CRM
 ↓
Screen Pop

같은 연결이 필요합니다.

이 과정에서 상담원 ID와 내선번호 같은 매핑이 중요해집니다.

27장 상담원 명령은 어떻게 전화 시스템까지 갈까#

상담원이 CRM에서 고객 전화번호를 클릭한다고 하겠습니다.

흐름은 다음처럼 볼 수 있습니다.

CRM
 ↓
발신 명령
 ↓
CTI
 ↓
PBX
 ↓
상담원 단말
 ↓
고객

이것이 Click-to-Call과 같은 기능의 기본 구조입니다.

원본 자료에서도 상담원 명령이 CTI를 거쳐 PBX로 전달된다고 설명합니다.

28장 호 전환도 CRM에서 제어할 수 있다#

상담원이 상담 중 다른 상담원에게 통화를 넘기려면 PBX에서 호 전환이 이루어져야 합니다.

하지만 상담원이 전화기 버튼 대신 CRM 화면에서 전환 기능을 사용할 수 있습니다.

이 경우:

CRM 전환 버튼
 ↓
CTI
 ↓
PBX
 ↓
호 전환

구조로 동작할 수 있습니다.

즉 CRM은 고객정보 화면인 동시에 전화 제어 UI 역할도 할 수 있습니다.

29장 API는 CRM 연동에서 어디에 쓰일까#

원본 자료에서는 CRM·업무시스템 연동 범주에 별도로 API Gateway와 REST API를 두고 있습니다.

CTI가 실시간 전화 이벤트에 강점을 가진다면 업무 데이터 교환에는 API를 함께 사용할 수 있습니다.

예를 들어:

고객정보 조회
주문정보 조회
외부 업무시스템 연계

등은 API 기반으로 연결할 수 있습니다.

즉 현대적인 콜시스템에서는 CTI 하나만이 아니라 CTI + API 조합으로 업무 연동을 구성할 수 있습니다.

30장 이벤트 기반 연동과 API 호출은 무엇이 다를까#

개념적으로 보면:

이벤트#

시스템에서 일이 발생하면 알려줌

예:

전화가 들어왔다.

API#

필요한 정보를 요청함

예:

이 고객의 주문정보를 달라.

따라서 상담 화면에서는:

CTI 이벤트
→ 전화 착신 알림

API
→ 고객·주문정보 조회

처럼 서로 다른 역할을 담당할 수 있습니다.

31장 CRM 연동 실패를 어디서부터 확인해야 할까#

CRM 연동 장애는 구간별로 나누어 확인해야 합니다.

1. 전화 자체는 정상인가#

PBX·ACD 확인

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

PBX ↔ CTI 확인

3. CRM으로 이벤트가 전달됐는가#

CTI ↔ CRM 확인

4. 고객 DB 조회는 성공했는가#

CRM ↔ DB 확인

5. 상담이력 저장은 성공했는가#

DB 저장 확인

이렇게 보면 단순히:

CRM 연동이 안 된다.

라고 판단하는 것보다 원인을 빠르게 좁힐 수 있습니다.

32장 전화는 되는데 CRM 화면만 안 뜬다면#

이 증상은 CTI 또는 CRM 연동 구간을 의심할 수 있습니다.

구조를 다시 보면:

PBX
 ↓
CTI
 ↓
CRM

PBX가 정상적으로 통화를 연결했다면 전화 기능 자체는 정상일 수 있습니다.

하지만 CTI 이벤트가 CRM까지 전달되지 않는다면 Screen Pop은 발생하지 않습니다.

따라서 전화와 화면을 별도의 경로로 나누어 보는 것이 중요합니다.

33장 화면은 뜨는데 고객이 틀리다면#

이 경우 CTI 이벤트 전달 자체는 정상일 수 있습니다.

하지만:

전화번호 정규화
고객 식별자 매핑
중복 고객
오래된 전화번호

같은 CRM 데이터 문제를 확인해야 합니다.

즉 이벤트 문제와 데이터 매핑 문제는 다릅니다.

34장 상담이력은 저장됐는데 통화시간이 틀리다면#

이 경우 CRM 저장 기능은 정상일 수 있지만 CTI에서 전달받은 통화 이벤트의 시작·종료 시점이 정확한지 확인해야 합니다.

예를 들어 종료 이벤트가 늦게 들어오거나 누락되면 실제 통화시간과 기록된 통화시간이 다를 수 있습니다.

따라서 전화 관련 시간 데이터는 CTI 이벤트의 정확성과 밀접하게 연결됩니다.

35장 CRM 연동에서 재처리 정책도 중요하다#

원본 자료는 재동기화를 명시적으로 설계 포인트로 제시합니다.

네트워크 오류가 발생했을 때 단순히 실패로 끝내면 상담 데이터가 누락될 수 있습니다.

따라서 연결이 회복된 뒤:

상태를 다시 확인
누락된 정보를 보완
CRM과 CTI 상태를 일치

시키는 정책이 필요합니다.

36장 CRM 연동에서 가장 중요한 것은 일관성이다#

콜센터에서는 같은 상담 한 건에 여러 시스템이 관여합니다.

예를 들어:

PBX
→ 전화

CTI
→ 이벤트

CRM
→ 고객정보

DB
→ 상담이력

녹취
→ 음성 파일

이 데이터가 서로 다른 상담으로 연결되면 문제가 발생합니다.

따라서 동일한 고객, 상담원, 통화, 상담이력을 일관된 식별 기준으로 연결하는 것이 중요합니다.

37장 CRM 연동 데이터가 AI 분석의 기반이 되는 이유#

원본 자료에서는 상담이력이 STT·요약·품질평가 같은 AI 분석과도 연결된다고 설명합니다.

예를 들어 상담 한 건에:

고객정보
통화시간
상담원
상담내용
녹취
STT 텍스트

가 모두 연결되어 있다면 AI 분석의 품질과 활용성이 높아질 수 있습니다.

즉 AICC에서도 기반은 여전히 정확한 CRM·콜시스템 데이터 연동입니다.

38장 CRM과 콜시스템 연동 설계 핵심 체크포인트#

원본에서 직접 제시한 설계 포인트는 네 가지입니다.

고객 식별자 매핑#

전화번호와 CRM 고객 ID를 정확히 연결

전화번호 정규화#

서로 다른 번호 형식을 동일한 기준으로 변환

Lock 정책#

여러 사용자가 동시에 수정할 때 충돌 방지

네트워크 단절 후 재동기화#

끊긴 연결이 복구된 뒤 상태 일치

ID 매핑 실패 Fallback#

고객을 찾지 못했을 때 대체 업무 흐름 제공

이 다섯 가지를 중심으로 보면 CRM 연동에서 발생하는 많은 문제를 이해할 수 있습니다.

39장 CRM과 CTI의 차이를 다시 정리하면#

CRM#

고객 업무를 관리합니다.

CTI#

전화 시스템과 CRM을 연결합니다.

PBX#

전화 자체를 연결합니다.

구조로 보면:

PBX
 ↕
CTI
 ↕
CRM
 ↕
고객 DB

입니다.

각 시스템의 역할이 다르기 때문에 장애도 구간별로 나누어 분석해야 합니다.

40장 CRM과 콜시스템 연동을 한 문장으로 설명하면#

가장 쉽게 설명하면:

전화에서 발생한 이벤트를 CTI가 CRM으로 전달하고, CRM은 고객정보와 상담이력을 처리하며, 상담원의 전화 제어 명령은 다시 CTI를 통해 PBX로 전달되는 구조다.

입니다.

조금 더 짧게 표현하면:

전화와 고객업무를 양방향으로 연결하는 구조

라고 할 수 있습니다.

CRM·콜시스템 연동 FAQ#

CRM과 콜시스템은 어떻게 연결되는가#

원본 자료에서는 CRM과 콜시스템 사이에 CTI 미들웨어를 두고 양방향으로 연결하는 구조를 제시합니다.

CTI에서 CRM으로 어떤 정보가 전달되는가#

원본에서는 착신, 종료, 통화시간 같은 호 이벤트를 예로 제시합니다.

CRM에서 PBX로 어떤 명령을 보낼 수 있는가#

원본에서는 발신과 전환 같은 상담원 명령을 예로 제시합니다.

고객 DB 조회는 어디에서 이루어지는가#

원본에서는 CRM이 DB 또는 CRM 내부 데이터를 조회하는 구조를 설명합니다.

상담이력은 어디에 저장되는가#

CRM을 통해 DB에 저장되는 구조로 설명합니다.

전화번호 정규화가 왜 필요한가#

같은 전화번호가 서로 다른 형식으로 저장될 수 있기 때문에 고객 매칭 오류를 줄이기 위해 필요합니다.

Lock 정책은 왜 필요한가#

여러 상담원이 동일한 고객 데이터를 동시에 수정하면서 발생하는 충돌을 방지하기 위해서입니다.

네트워크가 끊기면 어떻게 해야 하는가#

원본에서는 연결 복구 후 재동기화가 필요한 설계 요소라고 설명합니다.

고객 ID 매핑에 실패하면 어떻게 해야 하는가#

원본에서는 Fallback 정책을 설계 포인트로 제시합니다.

상담이력은 어디에 활용되는가#

원본에서는 통계·리포팅, AI 분석, STT, 요약, 품질평가, VOC, 만족도 데이터와 연결될 수 있다고 설명합니다.

핵심 정리#

CRM과 콜시스템 연동의 기본 구조는 다음과 같습니다.

CRM / 상담 화면
       ↕
   CTI 미들웨어
       ↕
PBX / IVR / ACD

원본 자료에서는 이 구조를 중심으로 다음 데이터 흐름을 제시합니다.

호 이벤트 → CTI → CRM

상담원 명령 → CTI → PBX

고객 DB 조회 → CRM → DB

상담이력 저장 → CRM → DB

입니다.

그리고 설계에서는:

전화번호 정규화

고객 식별자 매핑

Lock을 통한 동시 수정 방지

네트워크 단절 후 재동기화

ID 매핑 실패 시 Fallback

이 중요합니다.

또한 상담이력은 CRM 내부에서 끝나는 데이터가 아니라 통계·리포팅·STT·AI 요약·품질평가·VOC·만족도 분석까지 확장될 수 있습니다.

가장 짧게 정리하면 다음과 같습니다.

CRM은 고객을 관리하고, PBX는 전화를 관리하며, CTI는 두 시스템을 양방향으로 연결한다.

CTI와 CRM 연동 구조: 콜시스템의 전화 이벤트와 고객정보는 어떻게 연결될까

1장 전화 시스템과 CRM은 왜 따로 존재할까#

2장 CRM과 콜시스템의 기본 연동 구조#

CRM#

CTI 미들웨어#

PBX·IVR·ACD#

3장 CTI 미들웨어가 왜 필요한가#

4장 CRM과 콜시스템은 양방향으로 연결된다#

콜시스템 → CRM#

CRM → 콜시스템#

5장 콜시스템에서 CRM으로 전달되는 정보#

6장 CRM에서 콜시스템으로 전달되는 명령#

7장 고객 DB 조회는 어디에서 이루어질까#

8장 전화번호는 고객을 찾기 위한 키가 될 수 있다#

9장 전화번호 정규화가 필요한 이유#

10장 고객 식별자 매핑이란 무엇인가#

11장 같은 전화번호에 고객이 여러 명이면 어떻게 될까#

12장 고객을 찾지 못하면 어떻게 해야 할까#

13장 Screen Pop은 CRM 연동의 대표적인 결과다#

14장 상담이력은 어떻게 저장되는가#

15장 통화시간과 상담이력을 연결하면 무엇이 달라질까#

16장 상담이력은 다른 시스템과도 연결된다#

17장 CRM 연동에서 Lock이 필요한 이유#

18장 Lock 정책은 무엇을 해결하는가#

19장 네트워크 단절은 왜 큰 문제인가#

20장 재동기화란 무엇인가#

21장 CTI 이벤트는 실시간성이 중요하다#

22장 CRM 연동에서 실시간과 저장 데이터를 구분해야 한다#

실시간 데이터#

저장 데이터#

23장 콜시스템 전체 흐름에서 CRM은 어디에 위치할까#

24장 PBX와 CRM의 역할을 혼동하지 말자#

PBX#

CRM#

CTI#

25장 IVR과 CRM은 어떻게 연결될 수 있을까#

26장 ACD와 CRM 연동은 왜 중요한가#

27장 상담원 명령은 어떻게 전화 시스템까지 갈까#

28장 호 전환도 CRM에서 제어할 수 있다#

29장 API는 CRM 연동에서 어디에 쓰일까#

30장 이벤트 기반 연동과 API 호출은 무엇이 다를까#

이벤트#

API#

31장 CRM 연동 실패를 어디서부터 확인해야 할까#

1. 전화 자체는 정상인가#

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

3. CRM으로 이벤트가 전달됐는가#

4. 고객 DB 조회는 성공했는가#

5. 상담이력 저장은 성공했는가#

32장 전화는 되는데 CRM 화면만 안 뜬다면#

33장 화면은 뜨는데 고객이 틀리다면#

34장 상담이력은 저장됐는데 통화시간이 틀리다면#

35장 CRM 연동에서 재처리 정책도 중요하다#

36장 CRM 연동에서 가장 중요한 것은 일관성이다#

37장 CRM 연동 데이터가 AI 분석의 기반이 되는 이유#

38장 CRM과 콜시스템 연동 설계 핵심 체크포인트#

고객 식별자 매핑#

전화번호 정규화#

Lock 정책#

네트워크 단절 후 재동기화#

ID 매핑 실패 Fallback#

39장 CRM과 CTI의 차이를 다시 정리하면#

CRM#

CTI#

PBX#

40장 CRM과 콜시스템 연동을 한 문장으로 설명하면#

CRM·콜시스템 연동 FAQ#

CRM과 콜시스템은 어떻게 연결되는가#

CTI에서 CRM으로 어떤 정보가 전달되는가#

CRM에서 PBX로 어떤 명령을 보낼 수 있는가#

고객 DB 조회는 어디에서 이루어지는가#

상담이력은 어디에 저장되는가#

전화번호 정규화가 왜 필요한가#

Lock 정책은 왜 필요한가#

네트워크가 끊기면 어떻게 해야 하는가#

고객 ID 매핑에 실패하면 어떻게 해야 하는가#

상담이력은 어디에 활용되는가#

핵심 정리#

이 페이지의 목차