고객 문의를 시스템에서 ‘완료’로 옮기는 시점은 단순히 답장을 보냈을 때가 아닙니다. 요청을 실제로 처리했더라도 고객에게 확인 대상과 재문의 경로를 알리지 않았다면, 상태는 닫혔지만 대화는 닫히지 않은 셈입니다.
이 글은 작은 팀에서 문의 상태를 설계할 때 쓸 수 있는 종료 조건을 정리합니다. 특정 제품 구현이 아니라 운영 규칙의 예시입니다.
먼저 상태와 이벤트를 분리하기
- 처리 중: 담당자가 조사·수정·발송을 진행하는 상태
- 고객 확인 대기: 처리 결과와 확인할 항목을 고객에게 전달한 상태
- 완료: 합의한 완료 기준을 충족하고 기록한 상태
‘메일을 보냈다’는 이벤트이지, 자동으로 ‘완료’가 되는 조건이 아닙니다. 보내기 버튼의 성공 여부와 수신자가 다음 행동을 이해했는지는 서로 다른 사실입니다.
종료 메일에 필요한 네 필드
| 필드 | 팀이 남길 기록 | 고객이 보는 문장 |
|---|---|---|
| 처리 결과 | 실제 변경·전달 내용 | 무엇이 바뀌었는지 |
| 확인 대상 | 파일·화면·항목 하나 | 무엇을 확인하면 되는지 |
| 남은 일 | 담당자와 예정 시점, 또는 없음 | 언제 다음 안내가 오는지 |
| 재문의 경로 | 답장 주소 또는 지원 채널 | 문제가 있으면 어디로 돌아오는지 |
네 칸을 채웠다고 모든 문의가 즉시 닫히는 것은 아닙니다. 고객의 확인이 필요하면 ‘고객 확인 대기’로 두고, 프로젝트별 합의 기준을 충족했을 때만 완료로 옮깁니다. 답장이 없다는 사실만으로 만족을 추정하지 않습니다.
상태 전이를 코드로 표현한다면
‘종료’ 버튼 앞에 검증 함수를 하나 둡니다. 아래는 방향을 보여주는 간단한 예시입니다.
type Closeout = { workDone: string; customerCheck: string; remainingOwnerAndTime: string; replyPath: string; completionAgreed: boolean; }; function nextStatus(c: Closeout) { const hasHandoff = [ c.workDone, c.customerCheck, c.remainingOwnerAndTime, c.replyPath, ].every(value => value.trim().length > 0); if (!hasHandoff) return "working"; return c.completionAgreed ? "closed" : "awaiting_customer"; } 실제로는 ‘누가 기준을 합의했는지’와 ‘언제 상태가 바뀌었는지’도 로그에 남기는 편이 좋습니다. 고객 답장이 새로 오면 이전 완료 상태를 고집하지 말고, 같은 대화에 연결해 다시 처리할 수 있어야 합니다. 중복 알림을 피하려면 메일의 메시지 ID와 문의 ID를 연결하는 것도 도움이 됩니다.
오늘 점검할 한 가지
최근 닫힌 문의 하나를 열어 마지막 메일만 읽어 보세요. 고객이 확인할 대상과 재문의 경로가 분명한가요? 없다면 상태명보다 종료 문장을 먼저 고치는 편이 빠릅니다.
업무 메일을 정리하는 관점은 오피셜메일에서 업무 메일 관리 방식 살펴보기에서도 볼 수 있습니다.
