[데이터넷] 기업의 성공 척도는 소비자의 만족도를 높여 기업 브랜드 충성화를 높이느냐가 관건이다. 고객 접점을 높이는 방법에는 다양한 커뮤니케이션이 있으며, 모든 기업들이 고객 인게이지먼트를 향상시키고자 고민한다. 그렇기에 기업들은 소비자와의 소통의 시발점인 컨택을 어떻게 하는 것이 좋을지를 찾기 위해 노력하고 있으며, 그 최전선에는 컨택센터가 있다. 현재 우리나라의 컨택센터의 현주소는 무엇이고, 어떤 문제가 있는지, 그리고 클라우드 컨택센터가 왜 필요한지에 대해 알아보고자 한다. 클라우드 컨택센터 전환의 필요성과 구축 시 고려사항에 대해 알아본다.

픽사(PIXAR)의 유명한 3D 애니메이션 영화 ‘인사이드 아웃(2015)’은 주인공인 미국 소녀 라일리의 다양한 심리 상태를 그려낸 성장 영화다. 라일리의 마음 속에는 ‘기쁨, 슬픔, 소심, 까칠, 버럭’이라는 다섯 가지 감정에 대응하는 캐릭터가 살고 있다. 디즈니가 배급한 이 영화는 굉장히 탄탄한 정서심리학 기반 위에 그려지고 있는데, 이 이론적 기반을 제공한 사람 중에 폴 에크만(Paul Ekman, 1934~) 박사가 있다.

감성과 비언어적 신체 행동과의 관계에 대한 선구적인 연구자 폴 에크만은 1954년부터 비언어적 행동에 대한 연구를 시작했다. 60년대와 70년대에는 얼굴 표정과 감성 인식에 관한 연구로 거짓말할 때의 얼굴표정 특징, 즉 미동(micro facial expression)을 발견했고, 세계 각지에서의 연구여행을 통해 ‘얼굴 표정의 범 문화성’을 학문적으로 정리했다.

이후 얼굴 표정 움직임을 객관적으로 측정하는 도구인 얼굴표정 부호화 시스템(FACS: Facial Action Coding System)을 개발 적용해 우리나라를 포함해 FBI, CIA 등 전 세계 정부기관 및 연구소에서 현재까지 이용되고 있다.

이런 선행적인 연구 기반 위에 최근의 컴퓨터 사이언스에 의해 발전한 패턴 매칭(pattern matching)이 적용돼 신분증명이나 거짓말 여부, 나이 및 감성을 실시간으로 읽어내는 수준으로 발전할 수 있었다. 이런 감성컴퓨팅, 인지컴퓨팅 기술들이 빅테크 기업의 퍼블릭 클라우드 내부에 API 서비스 형태로 편입돼 있어서 기업이나 개인이 별도의 R&D 투자 없이도 데이터만 있으면 손쉽게 접근해 사용해 볼 수 있다. 클라우드 컨택센터 영역도 고객의 감성지능을 파악해 구매 여정에서 고객이 긍정적인 경험을 하도록 발전하고 있다.

긍정적인 고객경험 제공은 기업성공의 핵심
기업 고객접점을 관리하는 조직, 프로세스 및 인프라를 ‘컨택센터’라 정의할 수 있다. 기업과 고객 사이의 커뮤니케이션 채널은 전화, 웹, 이메일, 게시판, 채팅, 모바일 앱 등 열거하기 어려울 정도로 다양하고, 채널이 증가하면서 이용하는 고객 및 사용자 경험은 채널별로 파편화된다. 이러다 보니 채널 및 담당자를 늘리는 것만이 능사가 될 수 없어 다양한 무인화 기반 셀프서비스 채널을 제공해 효율성을 높이는 것이 기업 CS 담당 임원들의 고민이 된 지 오래다.

고객은 기업을 단일 개체로 바라보기 때문에 의사소통 과정에서 여러 채널을 이용하더라도 그간의 맥락(Context)을 이해해줄 것으로 생각한다. 그러나 오늘날의 기업들은 채널별 또는 담당자별로 분산돼 고객의 의도와 맥락을 종합적으로 이해하지 못해 단순히 반응하는 수준의 응대에 그칠 뿐이다. 이는 곧 고객의 실망으로 연결된다.

활용 가능한 기술 환경의 변화를 고려하면 전통적인 CRM을 넘어 마이크로 세그먼테이션 및 초개인화 맞춤형 서비스를 위한 기업의 노력은 자연스러운 현상이다. 이러한 노력은 다음 세 가지 사항이 고려돼야 한다.

① 기술이 아닌 고객·사용자 경험에서 시작해야
여러 채널을 이용하는 고객의 맥락을 손쉽게 추적, 관리 및 분석할 수 있어야 한다. 개별 운영되고 있는 시스템을 고객 여정 차원에서 서로 연결하고, 마케팅, 세일즈 및 서비스 관점에서 어떤 개입을 할 지 사전에 정의해 두는 것이 우선 필요하다.

다시 말해 고객여정지도는 기업이 고객을 유지·획득하기 위해 가치를 유인, 충족, 추가하는 프로세스의 시각화 차트라고 할 수 있다. 이는 단지 시각화된 흐름도(Flow chart)가 아니라 고객의 의도(Intent), 구체적 상황(Status)에 맞춤화된 구체적인 행동에 대해 서비스, 상태, 업무 레벨로 정의된 부호를 각 서비스 터치 포인트에 매핑하는 것을 포함한다.

고객경험관리 리서치 및 컨설팅으로 유명한 미국의 COPC는 ‘Service Journey Thinking’ 서비스와 같이 고객의 관점뿐 아니라 해당 기업의 인력, 기술 및 프로세스를 포함한 사용자 경험에 관련된 구성요소 전체를 검토하는 활동을 한다.

일례로 몇몇 금융권에서는 다양한 채널에서 발생하는 서비스 및 세일즈 프로세스상의 인터랙션을 고객경험관리 관점에서 활용 가능한 고객 여정 매핑 및 그 수집 인프라를 완비했고, 현재 진행되는 고객접점의 모든 프로젝트는 고객 여정 데이터의 수집 및 처리와 관련된 기능을 RFP 기본 요구 사항으로 제시하고 있다.

다양한 페르소나 또는 업무별 고객 여정 설계가 돼 있다면 어떤 채널이든 유입 고객의 현재 상황과 의도에 기반해 맞춤형 서비스를 제공할 수 있게 될 것이고, 상품 및 서비스 데이터와 고객 데이터를 연계해 개인별 맞춤형이 아니라 개인의 상황에 맞춘 서비스 및 가치 전달이 훨씬 용이해질 것이다.

② 다양한 채널 매시업해 제공할 수 있어야
고객이 여러 채널을 이용하면서도 기업을 하나의 개체로 인식하듯 기업의 접점 서비스 담당자도 이를 통합적인 시각으로 바라보고 측정 및 관리할 수 있어야 한다. 파편화되고 사일로화돼 있는 채널을 통합관리하기 위해 디지털 전담 부서와 고객센터 조직을 통합하거나 협업체계를 강화하는 기업이 늘어나고 있다.

이런 조직통합은 필수적으로 프로세스 및 인프라 시스템 통합이 필요한 상황으로 이어지게 된다. 전통적인 콜센터의 전화 채널을 포함해 다양한 모델로 서비스를 통합 제공할 수 있어야 하고, 각 채널에 어떤 무인화 기반 기술을 연계시킬 것인지 선택해야 한다. 기업의 마케팅 및 CS 담당이 고객 서비스 경로 상에 상담사 및 무인화 기반 서비스를 어떻게 배치할지에 대한 도전 과제는 다음과 같이 정리할 수 있다.

사람이 대응하던 업무를 ARS 또는 웹/앱으로 처리할 수 있는 선택권을 고객에게 제공하는 것을 넘어 보다 능동적으로 상담 업무 처리시 AI 기반의 지식 추천 서비스를 제공해 상담직원의 업무 숙련도를 상향 평준화시키고, 녹음 멘트 및 DTMF 수준의 기존 ARS 서비스에 음성 및 자연어 처리 기술을 접목하고 시각적인 보조 정보를 함께 제공해 서비스 처리 신속성, 편의성 및 기업 측면의 효율성을 동시에 높일 수 있어야 한다. 또한 QA 프로세스, 녹음정보 입력 등 후선 업무에 대한 효율화를 위해 다양한 자동화 및 AI 기술을 활용한 개선이 이뤄져야 한다.

최근의 디지털 ARS, 음성봇 및 챗봇 등의 서비스 도입 시 기존에 제공되던 서비스와 통합해 제공하는 것도 고려해볼 수 있다. 고객에게 제공하는 각각의 서비스 채널 완성도 수준이 높지 않아도 여러 보조채널을 통합 제공할 수 있다면 고객 입장에서는 가치를 느끼고 쓸 만한 서비스로 자리매김할 수 있을 것이다. 기술적인 완성도 추구보다는 고객경험 관점에서 총체적인 서비스 디자인이 필요한 이유가 여기에 있다.

③ 서비스 전달에 필요한 기술·인프라 적시에 적용 가능해야
엔터프라이즈 기업의 레거시 시스템은 대체로 복잡하고 무겁다. 서비스 하나를 추가하는 데에도 보안, 상호운용성 및 운영관리에 필요한 조직 준비 계획 등에 몇 개월의 시간이 소요될 만큼 상호영향도가 큰 아키텍처로 구성돼 있기 때문이다.

이런 레거시의 복잡성을 고려해 신규 서비스 추가 시 중장기 로드맵 기반을 마련하고 추진계획을 단계별로 설정하는 것이 불가피하다. 이는 서비스 기획 및 반영 주기가 길어지는 주요 원인이 되기도 한다. 마찬가지로 신기술 도입을 위해 시험삼아 사용하기에도 그 기회비용의 투자가 적지 않다. 따라서 개념검증(PoC)을 통해 신규 시스템 도입 리스크를 최소화할 뿐 아니라 효용성을 검증하는 방식이 사용되고 있다.

변동성이 클 수밖에 없는 서비스 수요를 예측하고 대응하기 위해 서비스 인프라 및 조직의 구성은 비용과 서비스 레벨을 고려해 그 규모를 한정할 수밖에 없다. 콜센터의 경우 필요회선 및 상담원 수를 결정하는데 100년이 넘는 스웨덴 수학자의 알고리즘(Erlang B, C)과 안톤(Anton) 박사(2000)의 알고리즘을 사용해도 무방한 이유다.

서비스 수요와 공급의 비대칭성은 ‘오토 스케일링(Auto Scaling)’ 기술을 통해 피크 수요에 대응하는 자원을 자동 배치하는 것으로 해결이 가능하지만 전통적인 컨택센터 인프라는 적절한 자원 예비율을 책정해 설계돼 있어 변동성에 대한 대응에 어려움이 있다. 하지만 컨택센터를 구성하는 기반 기술에 클라우드와 인공지능 기술이 점차적으로 진입하면서 기업 입장에서 서비스 수요 및 공급의 비대칭성은 해소될 수 있을 것으로 기대된다.

컨택센터, 클라우드 전환 불가피
클라우드로의 마이그레이션은 ‘시기(When)’의 문제지 ‘여부(Go or Not)’의 문제가 아니라고 한다. 일반적인 IT 환경은 클라우드 마이그레이션을 통해 보안과 데이터 접근, 확장성 및 유연성을 향상시킬 수 있다. 하지만 컨택센터 영역의 경우 클라우드와 관련한 기술 성숙도의 문제로 왜 해야 할 지, 어떻게 해야 할 지에 대한 논의가 분분했다.

컨택센터 관련 솔루션 공급업체들의 클라우드 기술이 성숙해지면서 사용하지 않는 예비 자원의 확보는 이미 불필요해졌다. 컨택센터 서비스를 개발하는 프로젝트들의 추세를 살펴보면 인공지능 기술이 비탄력적 자원인 상담직원을 대체할 수 있는 가능성이 조금씩 높아지고 있다.

보안 측면에서도 ‘제로 트러스트’로 일컬어지는 클라우드 서비스 제공자(CSP)의 보안정책을 반영하는 것 외에도 각각의 솔루션에서 핸들링하는 솔루션의 민감정보 수준과 각사의 컴플라이언스 환경에 따른 별도의 보안 조치를 고려해야 한다.

클라우드에서 활용할 수 있는 비용 편익과 리스크를 종합적으로 고려해 적합한 퍼블릭 클라우드 벤더를 함께 사용해야 하는 멀티 클라우드와 하이브리드 클라우드 전략이 불가피한 경우도 있다. 시장조사기관인 가트너는 전략적 공급업체를 선택하고, 조직의 클라우드 서비스 정책을 정의한 후 혁신과 차별화를 위해 애플리케이션을 끊임없이 통합하고 반복해야 한다고 조언한다. 또한 기존 레거시의 전환방식은 필요한 인력과 비즈니스 가치를 고려한 ‘6R’ 전략을 통해 분류하는 것이 일반적이다.

· Retain/Retire: OS 지원 또는 전환이 불가해 유지 또는 통폐합하는 전략이다.

· Rehost(Lift & Shift)/Replatform(Lift & Shape): VM 이미지 이전 또는 OS나 DB 등의 플랫폼을 클라우드 서비스와 연동하는 것과 같은 중소규모 영향도의 전환 전략이다. 특히 안정성이 필요한 경우 취할 수 있는 전환 전략으로, 클라우드로의 전환에 따른 기대 효과가 크지 않아 컨택센터의 경우 사용자가 내부 직원에 국한되는 WFMS, 통계/보고서 등 스케일 아웃이 필요 없는 응용 솔루션 정도의 전환을 통한 효익을 기대할 수 있다.

· Refactor(Cloud Native)/Repurchase(Drop & Shop): 운영하고 있는 기존 솔루션을 클라우드 네이티브로 완전히 소스 레벨에서 재개발하는 전략이며, 재구매 전략은 기존 운영 제품을 버리고 클라우드의 상품 패키지 혹은 SaaS 서비스를 도입하는 전략이다. 서비스 수요가 일정하지 않은 SBC, ARS, ACD/교환기 및 웹서비스 등의 사용량에 따라 탄력적인 용량 변화가 필요한 경우 취해야할 방법이다.

· 클라우드 네이티브로 개편되거나 SaaS 솔루션이 점점 시장에 진입하고 있어 클라우드 전환 시 각 기업의 상황에 따라 전환전략에 대한 고려가 필요하다.

기업이 당면한 과제는 메타버스, 클라우드, 인공지능 등 기술 환경의 변화를 지속적인 혁신의 자양분으로 삼아 가치사슬 전반에서 지속적인 통합과 개선을 통해 환경 변화에 적응하는 일일 것이다. 컨택센터 영역에서는 고객 여정 전반의 서비스 전달 과정에 인지지능(IQ)과 감성지능(EQ)을 높일 수 있는 방향으로 기술, 조직 및 프로세스를 정렬해 환경 변화에 적응하며 경쟁우위를 유지해야 할 것이다.

蛇足: 종의 기원에서 ‘적자생존’을 주창한 찰스 다윈이 1872년 출간한 ‘인간과 동물의 감정표현’이 잊혀진 걸작으로 오랫동안 남아있었는데 이를 잇는 후속 연구가 폴 에크만(Paul Ekman) 박사에 의해 시작되는데 거의 100년이 소요됐으며, 이 결과물을 소프트웨어 형태로 사용 가능해지는 데에는 약 30년이 걸렸고, 클라우드 위에서 API 서비스로 등록돼 대중적인 사용이 가능하기 까지는 10년이 필요했다. 앞으로의 변화가 가늠이 되지 않을 정도다.