주말에 쌓인 VOC, Claude가 먼저 읽으면 월요일 아침이 어떻게 달라질까?

주말 사이 들어온 고객 불만 4건과 지난주에 분류하지 못한 1건을 Claude가 Recoble에서 먼저 읽고 묶을 문제와 근거·회신 초안을 댓글로 남겼습니다. 사람은 노트 한 장에서 받을지 고칠지만 정했습니다(가상 사례).

한눈에 보기 월요일 아침 VOC 분류는 읽기, 비슷한 문제 찾기, 같은 고객의 지난 이력 확인, 회신 초안 쓰기가 대부분입니다. 이 글은 가상의 쇼핑몰 주문·재고 관리 SaaS 팀이 이 네 가지를 Recoble 커넥터로 연결한 Claude에게 맡기고 분류 확정·연결·고객 회신은 사람이 하는 방식을 실제 화면으로 보여 줍니다. 핵심은 "AI는 댓글로만 쓰고, 칸은 사람이 바꾼다"는 규칙 하나입니다.

같은 팀, 출시 3주째 월요일

지난 사례에서 이 팀은 v3.7 출시 뒤 받은 VOC 12건을 문제 5개로 묶고 긴급 패치·정기 개정·로드맵으로 나눴습니다. 그 뒤로도 VOC는 계속 들어옵니다. 주말 사이 4건이 더 왔고 지난주에 받은 「반품 접수 알림 메일이 안 와요」는 아직 분류도 못 했습니다.

새 VOC를 분류하는 일은 매번 같은 질문의 반복입니다. 이미 있는 문제인가? 그렇다면 어느 문제인가? 이 고객은 전에도 연락했나? 뭐라고 답할까? 질문은 단순하지만 답을 찾으려면 접수함과 개정 보드와 지난 회의 노트를 오가야 합니다.

무엇을 Claude에게 넘겼나

위 네 줄은 찾고 읽고 쓰는 일이고 아래 세 줄은 결정하는 일입니다. 이 팀은 이 선을 넘지 않게 요청문에 못 박았습니다.

요청은 한 단락

팀장은 Claude에게 이렇게 보냈습니다. Claude에는 Recoble 커넥터가 연결돼 있어 접수함과 개정 보드를 직접 읽습니다.

VOC 접수함에서 아직 분류 안 된 항목을 읽고, 제품 개정 보드의 문제(REV)와 대조해서 묶을 곳을 제안해 줘. 항목마다 근거와 회신 초안을 댓글로 남기고, 상태나 분류 칸은 바꾸지 마. 마지막에 이 노트로 요약해 줘.

"칸은 바꾸지 마"가 중요합니다. AI가 분류 칸을 직접 채우면 누가 확인했는지 알 수 없는 값이 보드에 섞입니다. 댓글로만 남기면 제안과 확정이 화면에서 갈립니다.

Claude가 남긴 것은 항목마다 댓글 하나

댓글은 다섯 줄로 같은 틀을 씁니다. 묶을 문제, 근거, 다른 점이나 주의, 제안 값, 회신 초안입니다. 눈여겨볼 대목은 세 군데입니다.

• 같은 고객의 반복을 짚었습니다. VOC-15는 생활용품 쇼핑몰 A가 보낸 세 번째 VOC입니다. Claude는 고객 칸이 같은 VOC-1·VOC-7을 찾아, VOC-7과 같은 문제를 다시 겪은 것이라 회신을 v3.8까지 미루면 불만이 커질 수 있다고 적었습니다. 그리고 영업 담당이 먼저 통화할지 정해 달라고 했습니다.

• 이미 내린 결정을 회신에 가져왔습니다. REV-3 설명에는 지난 회의 결정으로 「그 전까지 CS가 '품절 임박 시 수동 판매 중지' 안내를 회신에 넣습니다」가 적혀 있습니다. Claude의 회신 초안에 이 임시 조치가 들어간 이유입니다.

• 억지로 묶지 않았습니다. VOC-16(배송 메모가 잘려 보임)에는 「기존 문제 REV-1~5 중 맞는 것이 없습니다」라고 쓰고, 새 문제로 만들지 주간 회의에서 정해 달라고 넘겼습니다. VOC-13에는 REV-1과 증상이 같지만 이번에는 주문이 사라지지 않고 다음 날 들어왔다는 차이를 적고, 담당 개발자의 확인이 필요하다고 표시했습니다.

사람은 노트 한 장에서 확정

Claude는 마지막에 요약 노트를 만들었습니다. 다섯 건의 제안, 확신 정도, 사람이 볼 것을 한 표에 모으고 「사람 확정」 칸은 비워 뒀습니다. PM은 이 표만 보고 결정했습니다.

다섯 건 가운데 그대로 받은 것은 두 건입니다. VOC-15는 묶을 문제는 받되 심각도를 높음에서 치명으로 올렸습니다. 같은 고객이 판매 점수 하락을 걱정하고 있어 해지로 이어질 수 있다고 봤기 때문입니다. AI의 제안을 사람이 고친 이 한 칸이 이 방식에서 가장 중요한 장면입니다. VOC-16은 보류, VOC-12는 Claude가 쓴 질문을 CS가 초안대로 보냈습니다.

같은 노트에는 처리 흐름을 도식 블록으로 넣어 두었습니다. 새로 온 팀원도 이 그림 하나로 규칙을 압니다.

확정한 뒤 VOC-15를 다시 열면 칸과 연결과 댓글이 한 화면에 쌓여 있습니다. 누가 무엇을 제안했고 누가 무엇을 바꿨는지 따로 묻지 않아도 됩니다.

이렇게 쓰려면 미리 갖춰 둘 것

• 문제 항목에 원인과 결정을 적어 두기. Claude가 근거를 대고 회신 초안에 임시 조치를 넣을 수 있었던 것은 REV 항목에 원인·결정이 글로 남아 있었기 때문입니다. 제목만 있는 보드에서는 AI도 제목끼리 비교하는 수밖에 없습니다.

• 고객 칸을 같은 이름으로 쓰기. 같은 고객을 "A몰", "A 쇼핑몰"로 섞어 쓰면 반복 VOC를 놓칩니다.

• 댓글 머리표를 정하기. Claude가 커넥터로 남긴 댓글은 커넥터를 연결한 사람의 이름으로 표시됩니다. 그래서 이 팀은 [Claude 분류 제안 — 확정 전], [PM 확정]처럼 머리표로 쓴 쪽을 구분합니다.

• 요청문을 노트에 저장해 두기. 매주 같은 문장으로 맡기면 결과의 틀도 매주 같아 비교가 쉽습니다.

자주 묻는 질문

Q1. Claude가 분류 칸을 직접 채우게 하면 더 빠르지 않나요?
빠르긴 합니다. 하지만 확인하지 않은 값이 보드와 대시보드에 그대로 섞입니다. 제안은 댓글로, 확정은 칸으로 나누면 한 번 더 보는 수고가 생기는 대신 보드의 숫자를 믿을 수 있습니다.

Q2. Claude의 제안이 틀리면 어떻게 되나요?
댓글로 남아 있을 뿐이라 보드에는 영향이 없습니다. 사람이 「사람 확정」 칸에 다르게 적고 칸을 고치면 됩니다. 이 사례의 VOC-15처럼 제안의 일부만 받는 일도 흔합니다.

Q3. 어떤 AI를 써야 하나요?
이 사례는 Recoble 커넥터를 연결한 Claude로 진행했습니다. Recoble은 MCP로 노트와 워크보드를 읽고 쓰는 도구를 제공하므로 MCP를 지원하는 다른 AI 도구에서도 같은 흐름을 만들 수 있습니다.

Q4. 고객 개인정보가 AI에 넘어가지 않나요?
VOC 원문에 연락처·주소 같은 개인정보를 넣지 않고 고객 칸에는 회사명만 쓰는 것을 권합니다. 원문에 개인정보가 필요하면 별도 시스템에 두고 링크만 거는 편이 안전합니다.

마무리

월요일 아침 VOC 분류에서 사람이 꼭 해야 하는 일은 결정입니다. 읽고 찾고 초안을 쓰는 일은 Claude에게 넘기고 제안은 댓글로만 받으면 결정할 거리가 노트 한 장에 모입니다. 다음 주 월요일, 요청문 한 단락부터 붙여 보세요.

무료로 시작하기 — recoble.com

Recoble은 VWAY가 만든 AI 협업 워크스페이스로, 노트·워크보드·링크·대시보드를 한 공간에서 쓰고 Claude나 ChatGPT 같은 AI가 노트와 작업을 직접 읽고 씁니다. 본문의 회사, 고객, VOC는 사용 흐름을 보여 주려고 만든 가상 시연 데이터입니다. Claude의 분류 제안과 회신 초안은 실제로 Recoble 커넥터를 통해 생성한 것이며 시연은 한 계정으로 진행해 댓글 작성자 이름이 모두 같게 보입니다.