생각이 바뀌어 온 기록

금융사에서 B2C 챗봇을 구축하고 운영할 때였습니다.
제 목표 중 하나는 챗봇 이용을 늘리는 것이었습니다.

고객센터에 많이 들어오는 문의부터 살폈습니다.
이용내역 조회, 한도 문의, 분실신고처럼 상담유형 상위에 있는 일을 챗봇에서도 처리할 수 있게 하려고 했습니다.
시나리오가 늘면 챗봇에서 끝나는 일이 많아지고, 상담사 연결도 줄 거라고 생각했습니다.

그래서 해당 업무를 담당하는 부서에 협조를 요청했지만 순조롭지만은 않았습니다.

이유를 들어보니 납득이 됐습니다.
그 업무는 이미 앱과 홈페이지, ARS에서도 할 수 있는 일이었습니다.
챗봇에 추가하면 담당 부서는 관리하고 검수할 채널이 하나 더 생깁니다.
저에게는 필요한 기능이었지만 그 부서에는 새로 생기는 관리 업무였습니다.

제가 목표로 삼던 지표가 다르게 보였습니다.
앱에 있는 기능을 챗봇에도 넣고 고객이 앱 대신 챗봇을 쓰게 하면 챗봇 MAU는 오릅니다.
그런데 고객이 새로 얻는 것은 없습니다.
회사 전체로 보면 같은 일을 하는 채널이 하나 더 늘어날 뿐입니다.

한 가지가 더 걸렸습니다.
제가 추가하려던 업무 대부분은 이미 앱이나 ARS에서 할 수 있는 일이었습니다.
이미 자동화된 일인데도 고객은 상담센터로 전화하고 있었습니다.
같은 기능을 챗봇에 한 번 더 만든다고 달라질 것 같지 않았습니다.
고객이 앱과 ARS를 두고 챗봇을 써야 하는 이유는 무엇인지, 챗봇이 다른 채널과 무엇이 다른지를 묻게 됐습니다.

바뀐 생각. 시나리오 수를 늘리는 것보다, 이미 할 수 있는 방법이 있는데도 고객이 왜 문의하는지를 먼저 알아야 한다고 생각하게 됐습니다.

처음에는 어떤 상담유형이 많은지, 어떤 시나리오의 답변이 부족한지를 매일 확인했습니다.
그것만으로는 고객이 왜 문의하는지 알 수 없었습니다.

그래서 챗봇의 앞과 뒤를 봤습니다.
고객이 하나의 문제를 해결하려고 거친 과정 전체를 추적했습니다.
어디에서 문제가 생겼는지, 어떤 안내 메시지를 받았는지, 어떤 경로와 채널을 이용했는지, 챗봇에서 답을 받은 뒤 상담사를 다시 찾았는지를 확인했습니다.
챗봇에 물은 것과 상담사에게 물은 것이 어떻게 다른지, 받은 답은 어떻게 달랐는지도 봤습니다.

그 과정을 따라가니 같은 유형 안에 다른 문제가 섞여 있었습니다.
‘이용내역 조회’로 분류된 문의에는 방금 결제한 내역이 보이지 않아서 묻는 고객도 있었고, 필요한 형식의 내역을 받을 방법이 없어서 묻는 고객도 있었습니다.
‘한도 문의’도 현재 한도를 확인하려는 고객과, 상향 대상이 아니어서 다른 방법을 찾는 고객에게 필요한 조치가 달랐습니다.

같은 질문이어도 고객마다 필요한 조치가 다를 수 있었습니다.
문의만으로는 문제를 알 수 없었습니다.
채널에 따라 고객이 문의를 남기는 방식도 달랐습니다.
챗봇에는 “한도 올리고 싶어”라고 남기던 고객이, 상담사에게는 “앱에서 한도를 올렸는데 더 올리고 싶어요. 그런데 상향할 수 있는 한도가 없다고 나와요. 어떻게 해야 하나요?”라고 물었습니다.

분류 방식 때문에 문제가 가려지는 경우도 있었습니다.
고객이 전문용어를 챗봇에 물으면 그 문의는 용어를 설명하면 되는 질문으로 분류됩니다.
챗봇은 설명을 잘했지만 문의는 줄지 않았습니다.
고객이 왜 그 용어를 찾는지 따라가 보니, 밤늦게 받은 안내 문자를 보고 불안해서 묻는 것이었습니다.
이 경우에 필요한 조치는 문자 문구를 개선하는 것이었습니다.

바뀐 생각. 문의와 문제는 다르다고 생각하게 됐습니다.
상담유형과 건수만으로는 고객에게 어떤 조치가 필요한지 알 수 없었습니다.

이렇게 보니 챗봇이 맡을 일도 달라졌습니다.
챗봇이 모든 업무를 직접 처리할 필요는 없었습니다.
앱에는 이미 기능이 많지만 고객은 회사가 정한 메뉴 이름으로 그 기능을 찾아야 합니다.
챗봇은 고객이 평소 쓰는 말로 물어도 필요한 기능으로 연결할 수 있습니다.

개명한 뒤 카드를 다시 발급받는 고객이 한 예입니다.
기존에는 상담사에게 필요한 서류를 안내받고, 서류를 준비한 뒤 다시 상담사에게 연락해야 했습니다.
챗봇에서 필요한 서류를 먼저 안내하고 앱에서 그 서류를 발급받을 수 있게 연결했습니다.
고객이 상담사와 통화하기 전에 준비를 마칠 수 있게 한 것입니다.

채널을 개선해도 해결되지 않는 문제도 있었습니다.
세금 신고에 쓸 서류를 신청하는 셀프채널은 여러 개 있었습니다.
그런데 고객이 원하는 기간이나 파일 형식을 선택할 수 없었고, 신청한 서류가 발송됐는지 확인할 방법도 없었습니다.
그러면 고객은 결국 상담사에게 전화합니다.
이 경우에는 챗봇 안내를 다듬는 것으로는 부족했고, 기간 선택과 파일 제공, 발송 상태 조회 같은 서비스 기능을 개선해야 했습니다.
저는 이 문제를 끝까지 맡아, 고객이 문의할 필요가 없도록 정기발송 서비스까지 제공했습니다.

여기서 제 목표와 어긋나는 일이 생겼습니다.
제 목표는 챗봇 MAU를 늘리는 것이었고, 상위 리더에게도 이 수치를 보고했습니다.
챗봇에서 더 많은 대화가 일어나게 해야 했습니다.
그런데 정기발송을 제공하면 고객은 챗봇을 찾을 필요가 없어집니다.

고객이 고객센터를 찾는 것은 스스로 해결할 수 없는 일이 생겼을 때입니다.
앱과 ARS, 챗봇에서도 할 수 없는 일입니다.
그런 일은 복잡하고, 많이 묻는 질문도 아닙니다.
고객마다 상황에 맞춰 대응해야 해서 문의 건수로 묶을 수 없습니다.

그렇다면 제가 해야 했던 일은 무엇이었을까요.
고객의 문의를 문제로 번역하는 일입니다.
그리고 하나의 문제를 조직의 경계에 따라 책임과 업무로 나누고, 담당 부서와 협업해 고객이 그 채널 안에서 문제를 해결할 수 있게 하는 일입니다.

제가 다뤄야 했던 문의는 세 가지였습니다.
제품을 개선하면 애초에 문의할 일이 없는 것, 제품 개선으로 없앨 수 없어 채널에서 대응해야 하는 것, 건수는 적지만 고객 상황에 맞춰 상담사가 해야 하는 것입니다.

바뀐 생각. 제 일은 챗봇 이용을 늘리는 것이 아니라, 고객의 문의를 문제로 번역하고 그 문제를 해결할 수 있는 곳으로 연결하는 것이라고 생각하게 됐습니다.
그중 일부는 채널이 아니라 제품과 서비스에서 해결해야 하는 문제였습니다.

무엇을 바꿔야 하는지는 알게 됐습니다.
그런데 바꿔야 할 대상이 제가 담당하는 채널 밖에 있는 경우가 많았습니다.

제품이나 서비스 기능을 개선하려면 담당 부서와 협의해야 했습니다.
문의 데이터를 근거로 문제를 설명하면 필요성에는 대체로 공감해 주었습니다.
하지만 부서마다 목표와 인력 계획이 이미 정해져 있었고, 제가 요청한 개선은 그 계획에 없던 일이었습니다.

기존 고객이 서비스를 이용하며 겪는 불편을 개선하자고 요청한 적이 있습니다.
담당 조직은 신규 고객 유치에 집중하고 있었고, 요청은 받아들여지지 않았습니다.
그 조직이 고객의 불편을 가볍게 여긴 것은 아니었습니다.
맡은 목표가 달랐습니다.

주어진 제약 안에서 문제를 풀 방법을 찾다 보니, 기술과 시스템을 더 깊이 이해해야 한다고 생각했습니다.
업무와 데이터, 시스템을 더 깊이 알면 상대 부서가 받아들일 수 있는 해결책을 설계하고 실행까지 이끌 수 있다고 생각했습니다.
여러 문제를 조금씩 다루는 것보다 문제 하나를 끝까지 해결하는 역량을 갖추고 싶어서 B2B AI 솔루션 회사로 옮겼습니다.

바뀐 생각. 문제를 찾는 것과 해결하는 것은 다른 일이었습니다.
다만 이때는 제가 기술과 시스템을 더 알면 풀 수 있는 문제라고 생각했습니다.
이 생각은 뒤에서 한 번 더 바뀝니다.

2024년 5월에 회사를 옮긴 뒤 그해에는 새 회사에 적응했습니다.
그 뒤로는 상담사를 지원하는 AI 제품을 기획했습니다.
상담사 지원 시스템도 고객센터 효율화를 위해 투자하는 영역 중 하나입니다.
이 시기에 저는 고객센터라는 큰 주제 안에서 이 축에 집중했습니다.

고객이 스스로 해결하지 못한 문제는 상담사의 일이 됩니다.
상담사는 문의 한 건을 처리하려고 여러 시스템을 조회하고, 지식을 검색하고, 필요하면 리더에게 확인을 받습니다.
통화가 끝나면 요약과 후처리, 상담유형 분류가 남습니다.
제가 기획한 제품은 이 과정을 지원합니다.

LLM이 등장했을 때 저는 경계했습니다.
챗봇과 콜봇을 구축하고 그 투자 효과를 증명해야 했던 경험이 있어서, 새 기능을 도입하고 적용하는 것만으로는 원하는 결과를 얻을 수 없다고 생각했습니다.
그래서 저희 팀은 일관된 안내, 실시간 대응, 같은 기준의 판단, 입력 데이터의 품질, 비용처럼 운영 시스템이 지켜야 하는 조건을 처음부터 고려했습니다.

하지만 제품을 만드는 동안 고객사는 정확도를 물었고, 저도 정확도를 높이는 데 집중했습니다.
상담유형 추천은 정확도가 올랐고, 신입 상담사의 후처리 시간은 줄었습니다.
그런데 경력 상담사는 이 기능을 잘 쓰지 않았습니다.

상담사는 더 많은 문의를 더 빨리 처리하는 것이 일이고, 그것으로 평가받습니다.
경력 상담사는 통화 중에 이미 유형을 판단합니다.
추천이 정확해도 상담사가 판단하는 시점에 들어오지 않으면 쓸모가 없었습니다.
STT 품질을 높이려면 상담사가 정확하게 안내하고 기록해야 하는데, 그럴 여유도 없었습니다.
인센티브를 조정해 보기도 했지만 오래 해 온 방식은 쉽게 바뀌지 않았습니다.
운영을 고려해서 만들었지만, 제가 고려한 것은 시스템의 조건이었습니다.
상담사가 일하는 방식과 평가는 제품으로 바꿀 수 있는 범위 밖에 있었습니다.

챗봇에서 답을 받고도 상담사를 찾던 고객과 같은 일이었습니다.
문의에 답을 잘해도 고객의 문제가 해결되지 않으면 고객은 상담사를 찾습니다.
기술이 정확하게 작동하는 것과 사용자가 하려는 일에 도움이 되는 것은 달랐습니다.
금융사에서 챗봇을 운영할 때 했던 질문으로 다시 돌아온 것입니다.

그런데 시장은 여전히 LLM으로 무엇을 할지, 얼마나 정확한지, 답을 얼마나 잘 맞히는지, 얼마나 더 많이 처리하는지, 생산성이 얼마나 오르는지를 이야기하고 있었습니다.
ARS, 챗봇, 콜봇, LLM으로 기술이 바뀔 때마다 투자의 이유는 같았습니다.
콜이 많으니 더 적은 비용으로 더 빨리 처리하자는 것입니다.
새 기술이 나오면 기존에 하던 일을 자동화하는 데 도입합니다.
챗봇을 AI로 바꿔 더 잘 응대하게 하는 것이 한 예입니다.
문의에 더 잘 대응할 수는 있습니다.
다만 콜이 많다는 것은 제품과 서비스에서 해결되지 않은 일이 고객센터로 모인 결과이고, 처리 방법만 바꿔서는 들어오는 문의가 줄지 않습니다.
LLM이 등장했을 때부터 경계했던 일인데, 저도 정확도를 높이는 일에 집중하면서 같은 흐름에 휩쓸리고 있었습니다.

바뀐 생각. 질문이 처음으로 다시 돌아왔습니다.
고객은 왜 문의하는가입니다.
고객센터의 처리 성과와 고객의 문제 해결은 따로 확인해야 하고, 새 기술을 적용하기 전에 그 기술로 고객의 어떤 문제를 해결하려는지부터 정해야 한다고 생각하게 됐습니다.

AI 제품을 기획하면서 새로운 가능성도 봤습니다.
LLM을 쓰면 상담 대화를 고객의 상황, 요청, 상담사의 조치로 나눠 볼 수 있습니다.
‘이용내역 문의’ 한 줄로 남던 기록에서, 고객이 어떤 상황에서 무엇을 하지 못했는지를 읽어낼 수 있습니다.
직접 상담 대화 30건을 이 방식으로 구조화해 보기도 했습니다.

대화만으로 원인을 확정할 수는 없습니다.
고객의 실제 상태와 시스템 기록을 함께 확인해야 합니다.
그래도 사람이 다 읽을 수 없던 양의 대화에서 반복되는 문제와 그 규모를 볼 수 있게 됩니다.

저는 여기에 기대를 걸었습니다.
예전에 협력을 얻지 못한 것은 근거가 부족해서였고, 문제의 규모를 데이터로 보여주면 다른 조직도 우선순위를 다시 볼 거라고 생각했습니다.

협력을 얻기 어려웠던 것이 제가 일한 회사와 국내 AICC 시장의 특성일 수 있다고도 생각했습니다.
그래서 해외 사례를 찾아봤습니다.
Cresta가 소개한 United Airlines와 CVS Health 사례, NiCE의 Value Realization 같은 자료입니다.
솔루션을 공급하는 데서 끝나지 않고 고객사와 함께 어떤 문제가 중요한지 판단하고 운영 방식을 바꾸는 사례가 있었습니다.

더 찾아보니 해외에서도 사정은 비슷했습니다.
분석 도구를 갖추고도 인사이트가 실제 변경으로 이어지지 않는다는 이야기가 계속 나왔습니다.
실행까지 간 사례에는 도구 외에 다른 것이 있었습니다.
소개된 내용으로는 United에는 인사이트를 맡아 다른 부서와 함께 해결하는 전담팀이 있었고, 개선 효과를 ROI로 확인하는 절차가 있었습니다.

바뀐 생각. 문제를 정확하게 보여주는 것과 조직이 실제로 바꾸는 것은 다른 일이었습니다.
1부 04에서 저는 제가 기술과 시스템을 더 알면 협력을 얻을 수 있다고 생각했습니다.
이때부터는 책임과 우선순위, 자원이 조직 사이에 나뉘는 방식에서 찾게 됐습니다.
대화 분석에 대한 기대를 접은 것은 아닙니다.
그 기술로 할 수 있는 일과, 다른 조건이 있어야 가능한 일을 구분하게 됐습니다.

국내와 해외에서 같은 어려움이 보인다면 특정 시장의 문제는 아닙니다.
회사가 커지면 조직은 기능별로 나뉩니다.
제품, 정책, 운영, 고객센터가 각자 목표와 책임을 갖습니다.
그런데 고객은 조직도를 따라 서비스를 이용하지 않습니다.
고객에게는 하나의 서비스이고, 그 서비스로 하려던 일을 마칠 수 있는지가 중요합니다.

조직이 나뉘면서 생기는 문제라면 AI 이전에도 같은 고민이 있었을 거라고 생각했습니다.
그래서 옛 자료를 찾아 읽기 시작했습니다.

1999년 글은 기업이 고객의 소리를 수집하면서도 그것이 부서별로 흩어져 실행과 추적으로 이어지지 않는다고 지적했습니다.
1980년 Fornell의 워킹페이퍼는 소비자 대응 부서가 경영 의사결정에 영향력을 가지려면 무엇이 필요한지를 다뤘습니다.
1964년 논문은 불만 기록에서 구체적인 원인을 찾는 통계 방법을 제안했습니다.
제가 하던 질문을 수십 년 전 사람들도 하고 있었습니다.

실제로 해낸 기업도 있었습니다.
Amazon은 문의를 원인별로 나누고 유형마다 책임질 부서를 정했다고 합니다.
처음 이 사례를 봤을 때는 제가 다루는 채널 문제와 다른 차원의 이야기라고 생각하고 넘겼습니다.
다시 보니 제가 찾던 것과 같은 문제를 다루고 있었습니다.
DBS는 고객여정 단위로 여러 부서 사람을 묶고 공통 지표를 둔 사례로 소개돼 있습니다.

그런데 방법이 이렇게 오래 알려져 있었다면, 왜 많은 기업이 그렇게 하지 못했을까요.
한 번 해낸 기업도 리더와 담당자가 바뀐 뒤에 그 방식을 유지했을까요.
자료만으로는 아직 답할 수 없었습니다.

바뀐 생각. 오래전부터 알려져 있었고 아직 풀리지 않은 문제였습니다.
관심이 좋은 사례를 찾는 것에서, 그 방식이 다른 조직에서도 실행되고 유지되는 조건을 찾는 것으로 옮겨갔습니다.

실행까지 간 사례를 보면 경제적 효과가 근거로 쓰였습니다.
다른 조직이 움직이려면 고객 문제 해결이 회사에 얼마의 이익이 되는지 보여줘야 한다고 생각했습니다.
한동안은 고객의 문제에서 새 기능이나 사업 기회를 찾을 수 있는지도 고민했습니다.

그러다 씁쓸한 생각이 들었습니다.
회사가 만든 제품과 서비스 때문에 고객이 불편을 겪고 있는데, 그것을 개선하려면 이익이 된다는 것을 따로 증명해야 합니다.

회사의 사정은 이해합니다.
자원은 한정돼 있고, 한 조직의 일을 바꾸려면 다른 조직의 시간과 비용이 듭니다.
무엇을 먼저 할지 정해야 하고, ROI는 그 순서를 정하는 기준입니다.
기업이라면 당연히 갖는 특성입니다.

1부 04에서 적은 일을 다시 생각했습니다.
신규 고객 유치에 밀려 기존 고객의 불편 개선이 받아들여지지 않았던 일입니다.
그때 그 개선의 가치를 검토한 뒤에 순위가 낮다고 판단한 것이었을까요.
아니면 다른 부서의 일로 분류돼서 검토 대상에도 오르지 못한 것이었을까요.
어느 쪽이었는지는 지금도 확실히 알지 못합니다.
다만 검토할 기회도 없이 밀리는 개선이 있을 수 있다는 것을 알게 됐습니다.

ROI는 무엇을 먼저 할지 정하는 기준입니다.
기업이 고객에게 무엇을 해야 하는지를 정하는 기준은 아닙니다.
고객은 돈을 내고 서비스를 이용합니다.
그 고객이 불편 없이 서비스를 이용하는 것이 기업이 고객에게 한 약속이고, 기업이 지향해야 할 가치라고 생각합니다.
고객 문제 해결은 이익이 날 때만 하는 추가 과제가 아니라 원래 해야 하는 일입니다.

바뀐 생각. ROI는 우선순위를 정하는 기준이고, 고객에게 약속한 가치는 그와 별개로 원래 지켜야 하는 것이라고 생각하게 됐습니다.
제가 하려는 일도 새로운 사업 기회를 만드는 것이 아니라, 기업이 원래 해야 할 일이 제대로 되도록 하는 것으로 정리됐습니다.

원인을 없앨 수 없는 문의는 남고, 그 문의에는 대응해야 합니다.
처음에는 고객의 흩어진 데이터를 연결해 그 고객의 상황에 맞는 답을 주는 것이 잘 대응하는 것이라고 생각했습니다.
AI가 고객과 통화하면서 업무 시스템을 조회하고 필요한 조치까지 하는 사례도 봤습니다.

그런데 이것도 고객이 먼저 문의해야 시작됩니다.
문제가 생기면 고객이 문의하고 그 뒤에 처리하는 순서는 그대로입니다.
고객의 상태나 오류가 이미 회사 시스템에 기록돼 있고 필요한 조치도 알고 있다면, 고객이 연락할 때까지 기다릴 이유가 없습니다.

그래서 대응은 예측이어야 한다고 생각합니다.
고객센터에는 접수되고 처리된 케이스가 쌓여 있습니다.
어떤 조건에서 어떤 문제가 생겼고 어떤 조치로 해결됐는지가 남아 있습니다.
지금 같은 조건에 놓인 고객이 있다면 문의가 오기 전에 먼저 조치를 제안할 수 있습니다.
충전 오류가 확인된 고객에게 재시작을 제안하고, 해결되지 않으면 점검을 접수할지 묻는 식입니다.

상담사를 지원하는 시스템도 같습니다.
상담은 몇 분 안에 끝납니다.
고객이 문의한 뒤에 분석하고 찾아서 답을 정리해 주면 시간은 줄지 않습니다.
이 고객이 무엇을 문의할지, 그 문의는 어떻게 대응하고 처리해야 하는지를 미리 예측해 안내해야 상담사가 수월하게 일할 수 있습니다.

이 내용은 아직 구상입니다.
실제 업무 시스템에 연결해 검증한 적은 없습니다.

바뀐 생각. 잘 대응한다는 것은 문의가 온 뒤에 더 정확한 답을 주는 것이 아니라, 문제를 먼저 파악하고 대처할 수 있게 하는 것이라고 생각하게 됐습니다.

한동안은 이런 문제를 솔루션으로 풀 수 있다고 생각했습니다.
상담 대화와 고객의 이용 경로, 상담사의 처리 과정을 하나로 연결해 문의의 원인을 보여주는 솔루션입니다.
여러 회사가 함께 쓰는 SaaS라면 데이터가 쌓일수록 더 정확해질 거라고 생각했습니다.
합성 데이터로 상담 대화를 상황·요청·조치로 구조화하는 실험도 했습니다.

실험에서 확인한 것이 있습니다.
분류 기준은 사람이 정해야 했습니다.
표현이 비슷해도 업무상 다르게 처리해야 하는 문의가 한 묶음으로 묶였고, 그 차이는 그 회사의 업무를 아는 사람만 구분할 수 있었습니다.

문의가 오기 전에 대응하려면 더 그렇습니다.
어떤 문제 케이스가 있는지 분석하고 그 조건을 정의해야 예측할 수 있는데, 그러려면 그 조직 안의 상황과 데이터, 기능을 알아야 합니다.
예상할 수 있는 기본 데이터로 할 수 있는 일도 있습니다.
하지만 그 조직의 직원처럼 안에서 일을 분석하지 않으면 좁힐 수 없는 간극이 있습니다.
공통 요건을 우선해야 하는 SaaS도 조직마다 다른 특성까지 메우기는 어렵다고 생각합니다.

바뀐 생각. 외부 솔루션만으로는 풀기 어렵고, 그 조직 안에서 분석하고 기준을 정하는 일이 먼저라고 생각하게 됐습니다.

여기까지 오면서 풀려는 문제가 여러 번 바뀌었습니다.
챗봇 이용률에서 고객이 문의하는 이유로, 채널에서 제품과 서비스로, 기술의 정확도에서 사용자가 하던 일로, 문제를 보여주는 것에서 조직이 실행하는 것으로 옮겨왔습니다.

지금은 이렇게 생각합니다.
고객에게는 하나의 문제인데 기업 안에서는 여러 조직의 일이 됩니다.
분업 자체가 잘못이라고 생각하지 않습니다.
다만 각 조직이 맡은 일을 잘해도 고객이 기대한 결과까지 이어지지 않는 경우가 생깁니다.
고객의 문제는 한 조직의 지표만으로 끝나는 일이 아니기 때문입니다.

지금 어떤 문의가 들어오는지 보는 것은 AI로 할 수 있습니다.
문의를 문제로 번역하는 것, 그 문제를 조직의 경계에 따라 나누는 것은 여전히 남은 과제입니다.
작은 조직에서는 수월할 수 있지만, 큰 기업일수록 그 문제가 누구의 일인지 정하기 어렵습니다.
한 사람이 밑에서 시작하기는 어렵고, 의사결정자의 문제의식이 있어야 시작할 수 있는 일이라고 생각합니다.

제가 하고 싶은 일은 두 가지입니다.
하나는 고객센터에 쌓이는 데이터에서 문제를 찾아 원인을 없애거나 먼저 대응하는 실행 방식을 설계하는 것입니다.
다른 하나는 그 방식이 특정 담당자의 노력이나 한 번의 프로젝트로 끝나지 않고, 조직이 바뀌어도 유지되는 조건을 찾는 것입니다.

아직 모르는 것도 분명합니다.
문의를 원인별로 나누는 기준을 얼마나 믿을 수 있는지, 먼저 대응하는 것이 고객에게 실제로 도움이 되는지, 무엇이 조직을 움직이고 그 실행을 유지시키는지는 검증해야 합니다.
그래서 과거 기록과 기업 사례를 읽고 있고, 그 내용은 Research에 정리하고 있습니다.

기업이 고객에게 약속한 가치가, 조직이 나뉘어도 끝까지 전달되도록 하는 것.
지금까지 질문을 따라오며 정한 방향입니다.