AI 어시스턴트와 예측 스코어링은 이제 영업 및 지원 부문 리더들의 표준적인 요구 사항입니다. 대부분의 팀은 이를 단순한 기능 요청으로 간주합니다. 플러그인을 구매하고, 토글을 활성화하면 마법 같은 일이 일어날 것이라 기대합니다. 하지만 실제로 얻게 되는 것은 노이즈입니다. 잘못된 추천, 혼란스러운 결과물, 그리고 아무도 신뢰하지 않는 답변을 내놓는 시스템뿐입니다.
이는 CRM에서의 AI가 기능의 문제가 아니라 아키텍처의 문제이기 때문에 발생합니다. 지능은 그 아래에 있는 운영 계층(operating layer)이 얼마나 훌륭한가에 달려 있습니다. 데이터가 신뢰할 수 없고, 워크플로우가 모호하며, 거버넌스가 존재하지 않는다면 AI는 이러한 격차를 해결하지 못합니다. 오히려 격차를 가속화할 뿐입니다. 통찰력을 빠르게 얻는 것이 아니라, 혼란을 더 빠르게 겪게 될 뿐입니다.
AI 기능을 덧붙이기 전에 운영 계층이 필요합니다. 이는 데이터, 프로세스, 그리고 사람을 잇는 연결 고리입니다. AI 모델이 제안을 할 때, 원시 입력값부터 사용자 작업에 이르기까지 실제로 깨끗한 경로가 확보되도록 보장합니다.
해당 계층을 구축하는 방법은 다음과 같습니다.
알고리즘이 아닌 데이터부터 시작하십시오
AI에는 컨텍스트(맥락)가 필요합니다. AI는 자유 형식의 엉망인 텍스트에서 의도를 해석하거나, 다섯 개의 중복된 레코드 사이에서 신원을 식별할 수 없습니다. AI는 제공된 데이터를 읽을 뿐입니다. 데이터가 나쁘면 결과도 나쁩니다.
핵심 오브젝트를 감사하는 것부터 시작하십시오. 일반적으로 계정(Accounts), 리드(Leads), 기회(Opportunities)가 시작점입니다. 필수 필드를 확인하십시오. 만약 기회(Opportunity)가 종료 날짜(close date)나 단계(stage) 없이 생성될 수 있다면, 예측 모델은 분석할 근거가 없는 셈입니다. 픽리스트(picklists)도 확인하십시오. "Industry" 필드에 "Healthcare"의 변형이 12개나 있다면, 학습시킨 어떤 세분화 모델도 파편화될 것입니다.
중복을 공격적으로 제어하십시오. 만약 "Acme Incorporated"가 서로 다른 이메일 도메인과 활동 이력을 가진 세 개의 별도 연락처(Contacts)로 존재한다면, 참여도나 이탈 위험을 계산하려는 모든 AI는 진실을 여러 조각으로 나누어 처리하게 됩니다. 하나의 마스터 레코드를 선택하고 이를 강제하십시오.
라이프사이클 단계를 명확한 언어로 정의하십시오. 팀의 모든 구성원은 "Prospecting(잠재 고객 발굴)", "Qualification(자격 확인)", "Negotiation(협상)"의 차이를 알고 있어야 합니다. 단계가 모호하면, 승률을 예측하려는 AI는 노이즈를 학습하게 됩니다.
AI 시스템에 읽기 권한을 부여하기 전에 민감한 데이터를 보호하십시오. PII(개인정보), 재무 세부 정보, 계약 조건이 어디에 있는지 파악하십시오. 모델이 보아서는 안 되는 데이터라면, 하위 아키텍처에서 해당 데이터에 대한 접근을 차단해야 합니다.
자동화하기 전에 워크플로우를 매핑하십시오
이해하지 못하는 프로세스는 자동화할 수 없습니다. AI는 명확한 소유자가 없고, 정의된 진입점이 없으며, 상황이 잘못되었을 때 어떻게 해야 하는지에 대한 규칙이 없는 워크플로우를 지원할 수 없습니다.
업무가 CRM에 어떻게 유입되는지 그려보십시오. 웹 양식인가요? 스프레드시트 업로드인가요? 아니면 결제 시스템의 API인가요? 각 진입점에는 게이트(gate)가 필요합니다. 유료 캠페인을 통한 리드는 자동으로 자격이 부여될 수 있지만, 인바운드 지원 티켓은 검토 없이 영업 파이프라인에 유입되어서는 안 됩니다.
상태 전환(status transitions)을 명시적으로 정의하십시오. 누군가 종료하는 것을 잊었다고 해서 리드가 기회로 변해서는 안 됩니다. 규칙을 설정하십시오. 예를 들어, 미팅이 기록되고 예산이 확인된 후에만 리드가 전환되도록 할 수 있습니다. 나중에 AI가 "이 리드는 준비된 것으로 보입니다"라고 제안할 때, 이는 실제 퍼널(funnel)과 일치하는 기준을 바탕으로 측정되어야 합니다.
팀 구조를 반영하는 할당 규칙(assignment rules)을 만드십시오. 소규모 팀에는 라운드 로빈(Round-robin) 방식이 적합합니다. 지역이나 계정 규모별로 세분화했다면 지역 기반 라우팅(Territory-based routing)이 효과적입니다. 어떤 방식이든 AI는 누가 무엇을 소유하고 있는지 알아야 합니다. 뜨거운 잠재 고객을 모니터링되지 않는 대기열에 던져버리는 리드 스코어링 모델은 무용지물입니다.
예외 상황과 에스컬레이션(escalations)에 대비하십시오. AI 라우팅 규칙이 실패하면 어떻게 됩니까? 거래 금액이 특정 수준을 초과하여 관리자의 확인이 필요하다면 어떻게 됩니까? 이러한 분기점을 지금 구축하십시오. 배포 이후로 미루게 되면, 당신은...