CS 자동화 시스템 구축하는 방법 (답변·조회·상담 이관 범위 정리)

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

- 공통 안내와 고객별 조회는 필요한 데이터와 개발 범위가 다릅니다.

- 상담원에게 넘길 때는 대화 내용과 미해결 요청도 함께 전달합니다.

- 초기 구축과 운영 중 수정 범위를 나눠 견적을 비교합니다.

반복되는 고객 문의를 줄이려고 AI를 알아보다 보면, 어디까지 개발해야 실제 상담 업무가 줄어들지 고민됩니다. 질문에 답하는 시연은 자연스러워도 주문 상태를 확인하거나 담당자에게 연결하는 일까지 가능한지는 별도로 살펴봐야 합니다. 고객이 상담원에게 같은 이야기를 다시 설명한다면 자동 응답이 늘어난 만큼 일이 줄었다고 보기도 어렵습니다.

CS 업무 자동화를 의뢰할 때는 고객의 요청이 접수된 뒤 누가 어떤 상태로 마무리하는지까지 범위를 잡는 편이 좋은데요. 오늘은 CS 자동화 구축 견적에 담을 답변·조회·상담 이관 범위를 정리해보겠습니다!

1. 안내와 조회를 구분합니다.

공통 규정을 설명하는 답변과 특정 고객의 주문을 확인하는 답변은 준비물이 다릅니다.

배송 정책 안내에는 승인된 도움말이 필요하고, 배송 상태 조회에는 고객을 확인하는 절차와 주문 시스템 연결이 필요합니다. 두 기능을 모두 챗봇이라는 이름으로 묶으면 연동 작업이 견적에 포함됐는지 놓치기 쉽습니다.

온라인 쇼핑몰을 가상의 예로 들어보겠습니다.

반품 접수 방법은 안내 문서로 설명할 수 있지만, 특정 주문이 반품 가능한 상태인지는 주문 정보와 접수 조건을 확인해야 합니다. 여기에 실제 접수까지 맡긴다면 조회만 하는 경우보다 처리 결과와 실패 상황을 더 세밀하게 정해야 합니다. 첫 구축에서는 정책 안내와 주문 조회까지만 포함하고 접수는 기존 화면으로 연결하는 선택도 가능합니다.

똑똑한개발자팀은 자동화할 질문 수보다 답변 뒤에 필요한 작업을 먼저 구분하는 편이 좋다고 생각합니다. 질문 표현이 달라도 같은 데이터로 해결된다면 함께 묶을 수 있고, 같은 반품 문의라도 안내·조회·접수는 개발 범위가 달라지기 때문입니다.

견적 요청서에는 문의 유형, 사용할 원본 자료, 연결할 시스템, 완료 상태를 나란히 적어보세요. 담당자가 화면에서 정보를 확인할 수 있어도 외부 프로그램이 같은 정보를 읽을 수 있는지는 별도로 확인해야 합니다. 주문 시스템의 API 제공 여부와 접근 조건을 개발사와 확인하고, 연동을 아직 확인하지 못한 항목은 가정으로 구분해 두면 추가 비용을 논의할 때도 근거가 남습니다.

2. 상담 이관을 끝까지 연결합니다.

상담원 연결 버튼이 있다고 이관 설계가 끝나는 것은 아닙니다. 고객의 요청이 어느 상담 대기열에 들어가고, 담당자는 어떤 내용을 보고 응대를 시작하며, 그동안 AI는 답변을 계속해도 되는지까지 정해야 합니다. 상담원이 이미 처리 중인데 AI가 다른 안내를 이어가면 고객은 어느 답변을 따라야 할지 혼란스러워집니다.

[참고] Zendesk의 메시징은 상담원에게 이관된 뒤 AI 에이전트가 해당 대화에 응답하지 않도록 처리하고 있는데요,

이처럼 응답 담당자가 바뀌는 시점과 다시 AI가 응답할 조건을 구체적으로 살펴보고 싶다면 Zendesk의 대화 이관·반환 안내를 참고해 보세요.

상담원에게는 고객이 원하는 일, 이미 확인한 정보, 아직 해결하지 못한 요청을 함께 전달하는 방식을 권합니다.

AI가 만든 요약만 전달하기보다 원래 대화도 열 수 있게 하면 잘못 요약한 내용을 다시 확인하기 수월합니다. 주문 조회가 실패했다면 단순히 이관이라고만 표시하지 말고 무엇을 확인하지 못했는지 남깁니다.

상담 시간이 끝난 뒤의 흐름도 빠뜨리지 마세요. 즉시 연결할 사람이 없다면 문의를 접수하고 다음 안내를 언제 받을 수 있는지 보여주는 방식으로 설계할 수 있습니다. 실제 운영 가능한 응대 시간과 알림 채널을 CS팀이 정해야 고객에게 지키지 못할 약속을 하지 않게 됩니다. 이관 후 고객이 채팅창을 닫아도 담당자가 요청을 찾을 수 있는지, 같은 문의로 다시 들어오면 기존 대화로 이어지는지도 시연에서 확인해 보세요.

3. 구축비와 운영 범위를 나눕니다.

견적을 비교할 때는 초기 개발에 포함된 작업과 운영 중 별도로 맡길 작업을 나눠 읽어야 합니다.

도움말 정리, 주문 시스템 연동, 상담 도구 연결, 담당자용 검토 화면이 각각 어디에 포함되는지 묻고, 특정 도구의 구독료나 사용량 비용은 개발비와 구분합니다. 도입 비용을 낮추려고 필수 연동을 뒤로 미루면 출시 후 CS팀이 수작업으로 이어 붙이는 일이 남을 수 있습니다.

검수에는 정상 답변 외에 주문을 찾지 못한 경우, 고객 확인에 실패한 경우, 상담원이 없는 경우를 포함해 보세요. 각 상황에서 고객에게 보이는 안내와 직원이 받는 정보를 함께 확인하면 됩니다. 답변 문장만 비교하면 문의를 처리할 담당자가 없는 상황을 발견하기 어렵습니다.

똑똑한개발자팀은 CS 자동화의 완료 조건에 직원이 이어받는 업무도 포함하는 것이 중요하다고 봅니다. 사람이 맡을 일을 남겨두더라도 필요한 기록이 도착하고 후속 처리가 가능해야 도입한 시스템을 일상 업무에 사용할 수 있기 때문입니다.

정책 변경 후 누가 도움말을 수정하고, 연동 오류는 누가 확인하며, 새로운 문의 유형을 추가할 때는 어떤 비용이 드는지도 합의해 두세요.

운영 담당자가 직접 바꿀 수 있는 설정과 개발사 수정이 필요한 기능을 구분하면 관리 범위를 판단하기 쉽습니다. 자동 응답 건수와 함께 상담원이 다시 확인한 이유를 살펴보면 다음에 개선할 부분도 구체적으로 찾을 수 있습니다.

CS 자동화는 고객 접점의 답변 기능과 내부 시스템의 처리 업무가 만나는 작업입니다.

똑똑한개발자는 업무 분석부터 시스템 개발과 운영 개선까지 연결하고, 현재 시스템 상태에 맞춰 API 연동 등 구현 방식을 선택합니다. 답변을 만드는 부분과 실제 데이터를 조회·처리하는 부분을 함께 설계하는 접근입니다.

우리 서비스에 맞는 CS 자동화 범위와 기존 시스템 연결 방식을 정하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요! 감사합니다. :)