받은 메일을 읽고 담당자에게 넘기는 반복 업무
연구소의 두 공식 받은편지함을 Slack으로 연결하고, 문의 내용에 맞는 답변 초안과 담당자 안내를 구성했습니다. 메일 확인, 첨부파일 전달, 답변 자료 찾기와 담당자 연결을 한 스레드에서 이어가는 흐름입니다.
행사·과정 문의에는 기수와 일정, 신청 상태와 정책이 얽혀 있습니다. 메일을 요약하는 것만으로 끝내지 않고, 누가 무엇을 확인해 답할지까지 연결했습니다.
메일 수집과 답변 작성을 나눴습니다
두 메일함은 각각의 인증과 수집 상태를 사용합니다. 매분 새 받은편지함 메시지를 확인하고, 대기열에서 순서대로 처리합니다. 한 실행에서 메일 하나를 전달해 서로 다른 문의의 본문과 첨부가 뒤섞이지 않도록 했습니다.
- 01새 메일 확인
- 02Slack 원문·첨부
- 03정책 확인·초안
- 04담당자 검토
Slack에는 원문과 첨부 자료, 처리 의견과 답변 초안을 함께 둡니다. 담당자는 초안만 보는 것이 아니라 원래 질문을 함께 확인할 수 있습니다.
담당자는 어떻게 연결하나요?
과정·신청·결제 등 CS 업무와 협업·계약·행사 등 운영 업무를 구분해 담당자를 연결하는 규칙을 두었습니다. 최종 판단이 필요한 사안은 해당 역할에 확인하도록 합니다.
알림이나 뉴스레터처럼 회신이 필요 없는 메일도 문의와 구분합니다. 담당자 연결은 곧 처리 완료가 아니라, 사람이 다음 행동을 할 수 있게 넘기는 단계입니다.
답변 초안은 최신 과정과 정책에 맞춥니다
승인된 답변 문구와 과정·기수·행사별 사실을 별도로 관리합니다. 예전 답변에 있던 날짜나 환불 기준을 다른 기수에 그대로 가져오지 않도록 범위와 유효 기간을 확인합니다.
개별 신청·결제 상태나 예외 판단이 필요한 질문은 조회 또는 담당자 확인으로 넘깁니다. 답변을 자연스럽게 쓰는 것보다 맞는 사실로 초안을 구성하는 것이 먼저입니다.
답변 초안에는 어떤 정보가 필요하나요?
좋은 메일 초안은 문의를 짧게 요약하는 데서 끝나지 않습니다. 질문한 대상, 답변의 근거, 추가로 확인할 내용과 다음 담당자가 드러나야 합니다.
예를 들어 과정 일정 문의와 개인 환불 문의는 같은 “CS”여도 필요한 정보가 다릅니다. 일정 문의는 해당 기수의 최신 공지를 확인하면 되지만, 개인 환불 문의는 신청·결제 상태와 적용 정책을 확인해야 합니다. 아래는 실제 고객 메일을 옮긴 것이 아닌 처리 방식의 예시입니다.
- 공개 일정 질문: 해당 과정·기수의 공지를 찾아 답변 초안을 만듭니다.
- 개인 신청·결제 질문: 기록 조회나 담당자 확인이 필요한 항목을 남깁니다.
- 협업·행사 제안: 내용과 첨부를 보존하고 운영 담당자에게 연결합니다.
- 자동 알림: 회신 필요 여부를 구분해 직원이 빠르게 판단하도록 돕습니다.
사람이 초안을 읽었을 때 다시 메일과 자료를 처음부터 찾아야 한다면 자동화의 효과가 작습니다. 원문·관련 자료·확인할 항목이 같은 스레드에 있어야 검토 시간이 줄어들 여지가 생깁니다.
담당자 연결과 실제 해결을 구분합니다
담당자를 태그했다는 것은 전달 단계입니다. 검토했는지, 수정했는지, 최종 회신을 보냈는지는 별도로 봐야 합니다. 현재 확인한 구현은 문의 분류와 Slack 담당자 연결이며, 직원의 최종 업무 완료까지 자동 확정하는 티켓 시스템이라고 설명하지 않습니다.
장기기억은 담당 역할과 반복 절차를 이해하는 데 도움이 됩니다. 다만 현재 담당자와 최신 정책은 운영 기준에서 확인하도록 합니다. 소담의 기억과 업무 맥락에서 이 구분을 설명합니다.
메일 CS 자동화 효과는 어떻게 측정하나요?
현재 두 받은편지함을 매분 확인하는 구조를 운영하고 있습니다. 처리량은 신규 수신, 중복 제거, Slack 전달, 초안 작성과 최종 회신을 나눠 집계해야 합니다.
수집 코드의 처리 표식은 최근 일부만 보존하며, 특정 자동 알림을 제외한 기록도 포함할 수 있습니다. 따라서 표식 수를 누적 상담 해결 건수로 사용하지 않았습니다. 기간별 실적을 제시할 때는 실제 전달과 회신 기록을 연결해 확인할 계획입니다.
자동 발송보다 검토 가능한 초안을 선택했습니다
소담은 Slack에 답변 초안을 만들고 담당자를 연결합니다. 현재 메일 연동은 읽기 전용이며 답장을 자동으로 보내지 않습니다. 담당자가 최종 표현과 개별 상황을 확인할 수 있는 지점을 남겼습니다.
이메일 도착, Slack 전달과 최종 회신은 다른 단계입니다. 전달 오류가 났을 때 확인하고 다시 처리할 수 있도록 운영 절차도 함께 둡니다.
자주 묻는 질문
여러 메일함을 함께 처리할 수 있나요?
현재 두 메일함을 각각의 인증·수집 상태로 연결했습니다. 메일함별 중복 처리와 진행 상태를 구분합니다.
담당자가 바뀌면 어떻게 하나요?
담당 역할과 연결 규칙을 갱신해야 합니다. 개인 이름을 모든 답변에 복사하는 것보다 운영 기준을 한곳에서 관리하는 편이 낫습니다.
AI 답변을 고객에게 바로 보내나요?
이 사례에서는 보내지 않습니다. Gmail에서 읽은 문의를 Slack으로 옮기고 초안을 작성한 뒤 담당자가 확인합니다. 자동 초안 작성과 자동 회신 발송은 서로 다른 범위입니다.
처음 도입할 때 어떤 자료를 준비하나요?
기존 답변 예시, 현재 공지·정책, 문의 유형별 담당 역할과 예외 처리 기준이 필요합니다. “이 답변을 그대로 써도 되는 경우”와 “사람이 확인해야 하는 경우”를 함께 정리하는 것이 중요합니다.
무엇을 성과 지표로 보면 좋나요?
첫 검토까지 걸린 시간, 초안 수정 비율, 잘못 전달된 문의, 최종 회신 시간과 재문의 비율을 비교할 수 있습니다. 집계 기간과 대상 문의를 고정해야 전후 변화를 판단할 수 있습니다. 이는 권장 측정 항목이며 이번 사례의 측정 완료 수치는 아닙니다.