AI · BUSINESS AUTOMATION · 2026.09.28
AS·클레임 접수, 아직 담당자가 하나씩 읽고 배정하고 계신가요?
"지난주에 접수한 AS, 지금 어디까지 됐어요?"라는 고객 전화를 받고 나서야 담당자 메일함에 묻혀 있던 접수를 찾아낸 경험이 있으실 겁니다. 접수는 이메일로도, 전화로도, 홈페이지 문의 폼으로도, 영업 담당자 메신저로도 들어옵니다. 문제는 접수가 들어오는 것이 아니라, 들어온 접수를 누가 읽고, 어디로 보내고, 지금 어떤 상태인지가 사람 머릿속에만 있다는 것입니다. 이 글은 여러 채널로 들어오는 AS·클레임 접수를 한곳에 모아 AI로 유형과 긴급도를 분류하고, 규칙으로 담당자에게 자동 배정한 뒤, 처리 현황과 반복 원인까지 추적하는 구조를 정리했습니다.
접수는 들어오는데, 어디까지 처리됐는지는 아무도 모른다
AS나 클레임은 회사 입장에서 가장 민감한 접점입니다. 제품에 문제가 생긴 고객은 이미 불편한 상태이고, 이때 응답이 늦거나 "담당자가 누구인지 확인해 보겠다"는 답을 들으면 불만은 제품이 아니라 회사로 향합니다. 그런데 실제 현장에서는 접수 자체보다 접수 이후가 더 자주 무너집니다. 고객센터가 받은 접수를 기술팀에 메일로 넘기고, 기술팀은 그 메일을 읽은 사람이 처리하며, 처리 결과는 전화로 고객에게 알리고 어디에도 남지 않습니다. 같은 고객이 다른 채널로 다시 문의하면 처음부터 다시 접수됩니다.
이 구조에서는 "이번 달 접수가 몇 건이고, 그중 며칠 이상 지연된 건이 몇 건이며, 어떤 제품에서 같은 문제가 반복되는가"라는 기본적인 질문에 답하려면 담당자 여러 명의 메일함을 뒤져야 합니다. 개별 접수는 대부분 성실하게 처리되고 있는데도, 관리 관점에서는 아무것도 보이지 않는 상태가 됩니다.
담당자가 하나씩 읽고 배정하면 생기는 일
- 읽는 사람에 따라 분류가 달라집니다. 같은 내용의 접수가 어떤 날은 "단순 사용 문의"로, 어떤 날은 "불량 클레임"으로 잡힙니다. 기준이 사람 머릿속에 있기 때문입니다.
- 급한 건이 순서대로 처리됩니다. 접수 순서대로 읽다 보면 생산 라인이 멈춘 거래처의 접수와 설명서 재발송 요청이 같은 줄에 섭니다.
- 배정이 끝나면 추적이 끊깁니다. 메일을 넘기는 순간 보낸 사람의 책임은 끝나고, 받은 사람이 휴가 중이면 접수는 며칠간 아무도 모르게 멈춥니다.
- 반복되는 원인이 집계되지 않습니다. 같은 부품, 같은 로트, 같은 사용 환경에서 문제가 반복되어도 개별 건으로만 처리되어 품질 개선으로 이어지지 않습니다.
이 문제들은 담당자가 게을러서가 아니라, 여러 채널의 자유 형식 접수를 사람이 매번 읽고 판단해 옮기는 방식이 규모가 조금만 커져도 유지되지 않기 때문에 생깁니다.
자동화 구조는 네 단계로 나뉜다
접수 자동화는 챗봇을 만드는 일이 아닙니다. 아래 네 단계를 순서대로 연결하는 일이며, 각 단계는 독립적으로 시작할 수 있습니다.
- 접수 채널 통합. 이메일, 홈페이지 문의 폼, 전화 메모, 메신저로 들어오는 접수를 한 저장소에 같은 형식으로 모읍니다. 고객, 제품, 접수 일시, 원문, 첨부 파일이 접수 한 건마다 붙습니다. 전화 접수는 상담원이 정해진 양식에 입력하거나 통화 메모를 붙이는 것으로 시작합니다.
- 유형·긴급도 분류. AI가 접수 원문과 첨부 사진을 읽고 접수 유형(불량, 파손, 오배송, 사용법 문의, 부품 요청 등), 대상 제품, 증상 요약, 긴급도 제안을 구조화된 형태로 뽑습니다. 안전이나 생산 중단 같은 조건은 AI 판단과 별개로 규칙이 무조건 상위로 올립니다.
- 담당자 배정. 분류 결과와 규칙에 따라 담당 팀이나 담당자를 자동으로 정합니다. 제품군별 담당, 지역별 출장 기사, 거래처별 전담 담당자 같은 기준은 규칙표로 관리하고, 담당자 부재 시 대체 배정도 규칙에 넣습니다.
- 처리 현황 추적. 접수마다 접수됨, 확인 중, 처리 중, 고객 회신 대기, 완료 같은 상태를 기록하고, 정해진 시간 안에 상태가 바뀌지 않으면 담당자와 관리자에게 알립니다. 완료된 접수는 원인과 조치 내용이 함께 남아 나중에 집계할 수 있게 합니다.
핵심은 AI가 자유 형식 접수를 구조화하고, 규칙이 배정과 알림을 처리하고, 사람이 실제 판단과 고객 응대를 담당하는 역할 분담입니다. 처리 자체를 AI에게 맡기는 것이 아니라, 처리까지 가는 길에서 사람이 하던 읽기·옮기기·챙기기를 덜어 내는 것입니다.
어떤 기준으로 분류할 것인가
분류 기준은 처음부터 세밀할 필요가 없습니다. 담당자가 실제로 다르게 처리하는 만큼만 나누는 것이 원칙입니다. 아래는 제조·유통 업종에서 흔히 쓰는 구분의 예시이며, 회사의 제품과 조직에 맞게 조정합니다.
| 분류 항목 | 구분 예시 | 이렇게 쓰입니다 |
|---|---|---|
| 접수 유형 | 제품 불량, 배송 중 파손, 오배송·수량 차이, 사용법 문의, 부품·소모품 요청, 반품·교환 | 담당 팀 결정과 처리 절차 선택 |
| 대상 제품 | 제품군, 모델명, 시리얼 번호나 로트 번호 | 담당 기술자 배정, 반복 원인 집계 |
| 긴급도 | 안전 관련, 생산·영업 중단, 일반, 단순 문의 | 처리 순서와 알림 기준 |
| 고객 구분 | 주요 거래처, 일반 거래처, 개인 고객 | 전담 담당자 배정, 응답 기한 |
| 필요 조치 | 원격 안내, 부품 발송, 출장 방문, 회수 검사 | 일정 조율과 비용 예측 |
AI에게는 이 항목들을 정해진 선택지 안에서 고르게 하고, 원문에서 근거가 된 문장을 함께 남기게 합니다. 그래야 담당자가 분류 결과를 빠르게 확인할 수 있고, 틀렸을 때 왜 틀렸는지 보고 기준을 고칠 수 있습니다. 선택지에 맞지 않는 접수는 "기타"로 두고 담당자가 직접 분류하게 하며, 기타가 자주 쌓이는 유형은 새 선택지로 추가합니다.
규칙과 AI의 역할 나누기
흔한 실수는 접수 처리 전체를 AI에게 맡기려 하거나, 반대로 모든 것을 규칙으로 짜려는 것입니다. 단계별로 맞는 방식이 다릅니다.
| 단계 | 처리 방식 | 이유 |
|---|---|---|
| 채널별 접수 수집과 형식 통일 | 규칙(연동·파이프라인) | 매번 같은 방식으로 정확히 반복해야 함 |
| 원문·첨부에서 유형, 제품, 증상 추출 | AI | 자유 형식 문장과 사진을 읽는 일은 규칙으로 어려움 |
| 안전·생산 중단·주요 거래처 우선 처리 | 규칙 | 놓치면 안 되는 조건은 확률이 아니라 확정 규칙이어야 함 |
| 담당 팀·담당자 배정과 대체 배정 | 규칙(배정표) | 조직 기준이라 명확하게 정의되고 설명 가능해야 함 |
| 고객 회신 초안, 유사 사례 검색 | AI | 과거 처리 기록에서 비슷한 사례와 조치를 빠르게 찾아 초안 작성 |
| 실제 원인 판단, 보상·교환 결정, 고객 응대 | 사람 | 책임과 비용, 고객 관계가 걸린 판단 |
| 지연 알림, 상태 변경 추적, 월별 집계 | 규칙 | 시간과 상태 기준이라 자동 처리가 정확함 |
AI의 분류 결과에 확신 수준을 붙이고, 확신이 낮거나 규칙과 충돌하는 접수는 배정 전에 담당자가 먼저 보는 검토 큐로 보냅니다. 초기에는 검토 비율을 높게 두고, 분류가 안정되면 자동 배정 범위를 넓히는 방식이 안전합니다.
배정 이후가 더 중요하다: 추적과 반복 원인
분류와 배정까지 만들어 놓고 상태 추적을 빼먹으면, 접수가 담당자에게 도착하는 속도만 빨라질 뿐 예전과 같은 문제가 반복됩니다. 접수 한 건이 완료될 때까지 최소한 다음 세 가지가 남아야 합니다.
- 현재 상태와 마지막 변경 시각. 정해진 시간 안에 상태가 바뀌지 않으면 담당자에게 먼저, 그다음 관리자에게 알립니다. 알림 기준은 긴급도별로 다르게 둡니다.
- 원인과 조치 내용. "부품 교체"만이 아니라 어떤 부품을 왜 교체했는지, 고객 사용 환경에 특이점이 있었는지를 정해진 항목으로 남깁니다. 자유 서술은 AI가 나중에 항목으로 정리할 수 있습니다.
- 고객 회신 기록. 언제 무엇을 안내했는지가 남아야 같은 고객이 다른 채널로 다시 문의했을 때 처음부터 다시 시작하지 않습니다.
시작할 때 흔한 실수
- 모든 채널을 한 번에 연결하려는 것 — 가장 접수가 많은 채널 하나(대개 이메일이나 문의 폼)부터 시작하고, 전화 접수는 상담원이 양식에 입력하는 것으로 두었다가 나중에 붙입니다.
- 분류 체계를 너무 세밀하게 잡는 것 — 유형이 서른 개면 AI도 사람도 헷갈립니다. 실제로 처리 절차가 다른 만큼만 나누고, 나머지는 증상 요약에 맡깁니다.
- 긴급도를 AI에게 전부 맡기는 것 — 놓치면 안 되는 조건은 규칙으로 고정하고, AI는 그 외의 우선순위를 제안하는 역할로 둡니다.
- 배정만 하고 상태 추적을 만들지 않는 것 — 담당자에게 빨리 도착하는 것과 빨리 처리되는 것은 다릅니다. 지연 알림이 없으면 예전 문제가 그대로 남습니다.
- 완료 기록을 자유 서술로만 남기는 것 — 원인과 조치가 항목으로 남지 않으면 반복 원인 집계가 불가능합니다.
FAQ
접수 건수가 하루 몇 건 안 되는데도 자동화할 가치가 있나요?
건수보다 한 건을 놓쳤을 때의 영향과 접수가 들어오는 채널 수가 기준입니다. 하루 몇 건이라도 이메일·전화·메신저·홈페이지로 흩어져 들어오고 담당자가 여러 명이면 누락과 이중 처리가 생깁니다. 이 경우 분류까지 AI로 하지 않더라도 접수를 한곳에 모아 상태를 기록하는 단계만으로도 효과가 있습니다. 반대로 채널이 하나이고 담당자도 한 명이며 지금 방식에 문제가 없다면 무리해서 만들 필요는 없습니다.
AI가 긴급도를 잘못 판단해서 급한 건이 뒤로 밀리면 어떻게 하나요?
그래서 긴급도는 AI 판단만으로 확정하지 않습니다. 안전 관련 표현, 생산 중단, 특정 거래처 같은 조건은 규칙으로 무조건 상위에 올리고, AI는 그 규칙에 걸리지 않은 나머지 접수의 긴급도를 제안하는 역할로 둡니다. 또 AI가 판단 근거를 함께 남기게 하고, 확신이 낮은 접수는 담당자가 먼저 확인하는 검토 큐로 보냅니다. 초기에는 담당자가 AI 분류를 검수하면서 자주 틀리는 유형을 규칙이나 분류 기준에 반영합니다.
기존에 쓰는 고객센터 솔루션이나 ERP가 있는데 새로 만들어야 하나요?
아닙니다. 이미 접수 관리 기능이 있는 시스템이 있다면 그 시스템을 접수 저장소로 쓰고, 채널 통합·AI 분류·배정 규칙만 앞단에 붙이는 방식이 일반적입니다. API가 있으면 직접 연결하고, 없으면 이메일 전달이나 파일 내보내기 같은 우회 경로로 시작할 수 있습니다. 중요한 것은 접수가 최종적으로 한 곳에 모여 상태가 기록되는 것이지, 어떤 도구를 쓰느냐가 아닙니다.
Voxen은 이렇게 접근합니다
Voxen은 AI를 억지로 모든 단계에 넣기보다 현재 업무와 데이터를 먼저 살펴보고 가장 단순하고 안정적인 자동화 구조를 찾습니다. 데이터 수집·엔지니어링, AI 판단, API·대시보드, 맞춤 시스템 구축을 실제 비즈니스 프로세스에 맞게 연결합니다.
이 글도 읽어보세요
- 고객 문의, AI에게 어디까지 맡겨도 될까? — 반복 문의 응대에서 AI에게 맡길 부분과 사람이 확인할 부분을 나누는 기준입니다.
- 메일·메신저가 쌓여 중요한 일을 놓치고 있나요? — 접수 채널 통합의 출발점이 되는 이메일·메신저 분류 자동화입니다.
- AI가 하면 안 되는 일도 있습니다: 사람 확인이 꼭 필요한 업무는? — 보상·교환 결정처럼 사람이 최종 판단해야 하는 업무를 구분하는 기준입니다.
Voxen Cloud에서 데이터 수집·자동화·맞춤 시스템 구축 방향을 살펴보세요.
cloud.voxen.io →