문의 유형만으로는 문제가 어디서 생겼고 누가 바꿔야 하는지 알기 어렵습니다. 이 글은 문의에서 출발해 고객이 하려던 일, 막힌 조건, 실제 조치와 그 뒤의 결과를 연결하는 순서를 정리한 것입니다.
아래 내용은 실제 콜 데이터로 빈도나 효과를 검증한 결과가 아닙니다. 일을 시작할 때 무엇부터 확인할지 정해 두려고 만든 기준입니다.
1. 무엇을 문제로 볼 것인가
오류와 불만만 문제로 보지 않습니다. 정상적인 절차로 받아들여져 온 고객의 수고도 포함합니다. 제품이 설계대로 작동해도 고객이 하려던 일은 끝나지 않을 수 있습니다. 반대로 모든 상담을 없애야 할 문제로 보지도 않습니다.
네 가지를 구분합니다.
- 문의와 원인: 무엇을 물었는가와 왜 문의해야 했는가는 다릅니다.
- 발견과 조치: 문제를 발견한 조직과 실제로 바꿔야 할 조직은 다를 수 있습니다.
- 사실과 가설: 고객이 한 말, 시스템 기록, 분석하는 사람의 추정을 구분합니다.
- 완료와 해결: 상담 종료, 기능 성공, 개선 배포를 고객이 하려던 일이 끝난 것과 같게 보지 않습니다.
2. 세 가지 단위로 기록한다
- 콜: 한 번의 접촉 기록입니다.
- 고객 문제: 한 고객이 특정한 일을 하려는 과정입니다. 한 콜에 여러 문제가 있을 수 있고, 한 문제가 여러 콜로 이어질 수 있습니다.
- 문제 패턴: 여러 고객에게 반복되는 공통 조건입니다.
문제마다 다음을 남깁니다.
| 항목 | 남길 내용 |
|---|---|
| 상황 | 상품, 채널, 고객 상태, 적용 조건 |
| 고객이 하려던 일 | 원래 하려던 일과 그 일이 끝났다고 볼 기준 |
| 직전 행동 | 시도한 작업, 받은 안내, 거쳐 온 경로 |
| 요청 | 상담사에게 요구한 것 |
| 막힌 지점 | 관측된 조건과 원인에 대한 가설 |
| 조치 | 상담사가 확인하고 처리한 내용 |
| 결과 | 해결 확인, 일부 해결, 미해결, 확인 못 함 |
| 근거 | 원문 위치, 시스템 기록, 추정인지 여부 |
문제 패턴은 문의 이름이 아니라 발생 조건과 완료 조건으로 묶습니다. 같은 “한도 문의”라도 조회, 추가 신청, 서류 접수 확인, 심사 진행 확인은 서로 다른 개선 과제가 될 수 있습니다.
3. 왜 문의하게 됐는지 나눈다
| 문의하게 된 계기 | 확인할 것 | 조치 대상 |
|---|---|---|
| 기능이 실패했다 | 발생 시각, 실패 단계, 재시도 기록 | 오류 개선, 복구 경로, 실패 안내 |
| 기능을 찾지 못했다 | 찾던 기능, 검색어, 진입 경로 | 메뉴, 명칭, 검색 |
| 고객 조건을 지원하지 않는다 | 필요한 기간·형식·대상과 지원 범위의 차이 | 지원 범위, 제공 기준 |
| 처리는 됐지만 다음 일에 쓸 수 없다 | 원래 목적, 필요한 형식과 정보 | 결과물, 완료 조건 |
| 기능과 기능 사이가 끊겼다 | 단계별 상태, 빠진 인계 | 상태·데이터 연계 |
| 채널마다 되는 일이 다르다 | 채널 이동 순서, 다시 입력했는지 | 기능 차이, 맥락 인계 |
| 안내가 문의를 만들었다 | 실제 문구, 발송 시점, 다음 경로 | 안내 내용, 발송 조건 |
| 진행 상태를 알 수 없다 | 실제 지연인지, 상태가 안 보이는 것인지 | 접수 확인, 진행 조회, 알림 |
| 정책이나 절차 때문에 할 수 없다 | 제약의 이유, 지금도 유효한지 | 정책 재검토, 절차 단순화 |
| 앞선 조치가 충분하지 않았다 | 이전 상담과 조치, 남은 요구 | 조치 적합성, 후속 확인 |
| 여러 제품이나 외부 기관이 얽혔다 | 기관 간 상태, 볼 수 없는 정보 | 공동 확인, 책임과 안내 경로 |
| 실패는 없지만 상담이 필요하다 | 사람의 판단이 필요한 이유 | 사람 상담 유지, 사전 정보 |
한 문의에 여러 항목이 함께 해당될 수 있습니다.
4. 누가 조치할지 나눈다
고객센터가 문제를 관측했다고 해서 조치 책임까지 고객센터에 두지 않습니다. 원인에 따라 조치할 곳이 달라집니다.
- 답을 몰라서 생긴 문의는 셀프채널이나 자동 안내로 대응합니다.
- 제품 설계 때문에 생긴 문의는 제품과 화면을 개선합니다.
- 정책이나 안내 문구 때문에 생긴 문의는 정책과 문구를 개선합니다.
- 판단이 필요한 문의는 사람이 맡습니다.
한 문제에 근본 개선, 임시 안내, 사람의 예외 처리를 함께 둘 수 있습니다. 근본 개선에 시간이 걸리면 그동안 안내나 알림으로 먼저 대응합니다.
제품 조직도 기능이 없다는 사실은 이미 알고 있는 경우가 많습니다. 상담 기록은 그 부재가 어떤 고객에게, 어느 단계에서, 얼마나 반복해서 문의를 만드는지를 더해 줍니다. 이 정보가 있어야 우선순위를 논의할 수 있습니다.
5. 순서를 정한다
문의량만으로 순서를 정하지 않습니다. 다음을 함께 확인합니다.
- 고객에게 미치는 영향과 반복되는 정도
- 원인에 대한 근거가 얼마나 확실한지
- 바꾸는 데 드는 비용과 다른 일과의 의존 관계
- 되돌릴 수 있는 변경인지
근거가 부족한 과제는 바로 개발하지 않고 추가 확인부터 합니다.
6. 조치를 기록하고 결과를 확인한다
| 기록 | 내용 |
|---|---|
| 무엇을 왜 바꾸는가 | 대상 문제, 원인 가설, 근거, 해당 고객군 |
| 누가 어떻게 실행하는가 | 실행 책임자, 협업자, 변경 범위, 다시 검토할 시점 |
| 무엇이 달라져야 하는가 | 기대하는 고객 행동과 결과, 비교 기준, 중단 조건 |
결과는 배포가 끝났는지로 판단하지 않습니다. 바뀐 조건에서 고객이 하려던 일이 실제로 끝났는지를 확인합니다. 해당 문제는 줄었는데 전체 문의가 그대로라면 다른 패턴이 늘었는지 확인합니다. 재문의가 없다는 것만으로 해결됐다고 보지 않습니다.
7. LLM을 운영 시스템에 넣을 때 확인할 것
고객센터가 잃지 않아야 하는 가치와 특성을 먼저 정하고, LLM을 쓸 때 그것을 지키려면 무엇이 필요한지 확인합니다.
- 고객에게는 일관된 안내를 해야 합니다. 그런데 LLM은 같은 질문에도 다른 판단을 할 수 있습니다.
- 실시간으로 대응할 수 있어야 합니다. AI 호출이 많으면 지연이 생기므로 호출하는 횟수를 제한해야 합니다.
- 운영 시스템은 같은 기준으로 판단해야 합니다. 그러려면 AI가 기준으로 삼을 데이터를 만들어야 하고, 이것은 새로 생기는 업무입니다.
- 할루시네이션이 없어야 합니다. 그러려면 입력 데이터의 품질에 빈틈이 없어야 하고, 기존 데이터를 정비해야 합니다.
- 고객의 질문은 대부분 반복되는 질문입니다. 매번 답을 새로 생성할 필요가 없습니다.
이런 부분이 갖춰지지 않으면 구조와 모델이 좋아도 결과를 보장할 수 없다고 생각합니다.
8. 사람이 정해야 하는 것
LLM은 원문에서 상황·요청·조치를 추출하고, 표현을 정리하고, 묶음 후보를 만드는 일을 돕습니다. 원문에 없는 사실을 채워 원인을 확정하지는 않습니다. 다음 네 가지는 사람이 정합니다.
- 무엇을 볼지: 어떤 축으로 나눌지와 각 축의 정의
- 추출 기준: LLM의 결과가 틀렸다고 판단하는 기준
- 분류 체계: 묶음의 경계가 업무 기준과 맞는지, 이름이 현장에서 쓰는 말인지, “기타”에 쌓이는 것 중 무엇을 새 유형으로 올릴지
- 결과 해석: 드러난 패턴을 보고 다음에 무엇을 할지
분류 체계는 한 번 만들고 끝내지 않습니다. 어느 유형에도 맞지 않는 문의와, 같은 유형 안에서 갈라지는 문의를 주기적으로 확인해 체계를 갱신합니다.
아직 모르는 것
- 이 기준으로 실제 데이터를 나눴을 때 일관되게 분류되는지
- 여러 콜을 한 고객 문제로 연결하는 기준을 얼마나 믿을 수 있는지
- 조치 책임자를 정하는 과정이 조직 안에서 실제로 어떻게 진행되는지
세 번째는 기준만으로 정해지지 않습니다. 과거 기업들이 이 일을 누구에게 맡겼고 그 방식이 유지됐는지는 Research에서 읽고 있습니다.