WAITING을 SENT와 분리하기: 고객 회신 대기 큐의 작은 설계

메일 전송 작업이 성공했다는 이벤트와 고객의 결정이 도착했다는 이벤트는 다릅니다. 작은 고객 응대 도구에서도 두 사건을 같은 DONE 값으로 묶으면, 답을 기다리는 업무가 완료 목록으로 사라질 수 있습니다.

아래는 특정 제품의 구현을 설명하는 글이 아니라, 회신 대기 큐를 설계할 때 검토할 수 있는 예시입니다.

전송 상태와 업무 상태를 나눕니다

전송 상태는 메일을 보낼 수 있었는지 확인하는 축입니다. 업무 상태는 지금 누구의 어떤 판단을 기다리는지 보여주는 축입니다. 전송 요청이 성공했어도 실제 수신·열람·회신까지 확인됐다고 표시하지 않습니다.

업무 상태의 최소 예시는 다음과 같습니다.

• WAITING_FOR_CUSTOMER: 고객에게 필요한 질문을 보냈고 답을 기다리는 상태
• NEEDS_REVIEW: 고객 회신이나 새 자료가 들어와 담당자가 읽어야 하는 상태
• READY_TO_CONTINUE: 필요한 결정을 확인해 다음 작업을 검토할 수 있는 상태

기한이 지났다는 이유만으로 마지막 상태로 옮기지는 않습니다.

다음 확인 시점은 고객 마감과 다른 필드입니다

대기 건에는 요청 식별자, 원문 메시지 식별자, 필요한 답, 다음 확인 담당자, 다시 살펴볼 시점을 둡니다. 고객과 합의한 기한이 있다면 별도 값으로 보관합니다.

next_check_at은 내부 담당자가 다시 볼 시점이고, customer_due_at은 실제로 합의한 회신 기한입니다. 두 값을 한 칸에 넣으면 내부 알림이 고객에게 약속한 마감처럼 보일 수 있습니다. 합의한 기한이 없다면 후자는 비워두는 편이 낫습니다.

시각에는 시간대를 명시하고, 담당자 화면에서는 어느 시간대로 표시하는지도 드러내도록 설계합니다.

재확인 작업은 자동 발송보다 검토 대상을 만듭니다

정해둔 시점이 오면 곧바로 메일을 보내는 대신, 아직 답이 필요한 건인지 확인할 작업을 만들 수 있습니다. 담당자는 다음 내용을 함께 봅니다.

• 가장 최근에 도착한 고객 회신
• 이미 해결한 질문과 아직 남은 질문
• 첨부·링크가 유효한지와 전송 오류 여부
• 다른 담당자가 같은 후속 안내를 준비하고 있는지

후속 메일 초안에는 필요한 행동 하나와 실제 가능한 선택지를 남깁니다. 고객의 답이 늦었다고 새로운 승인 조건을 만들어 넣지는 않습니다.

검토 뒤에 새 회신이 들어오는 경우도 다룹니다

발송 직전에는 담당자가 검토한 이후 새 회신이 들어왔는지 다시 확인하는 경계가 필요합니다. 예를 들어 다음처럼 검토 결과를 무효화할 조건을 명시할 수 있습니다.

새 고객 회신이 검토 기준 이후에 도착함 → 초안을 다시 검토
발송 담당자의 승인이 없음 → 발송 보류
같은 후속 안내가 이미 처리 중임 → 상태 확인

여러 작업자가 동시에 실행될 수 있다면 처리 권한 확보와 중복 실행의 결과도 따로 설계해야 합니다. 위 조건 몇 줄만으로 동시성이나 중복 발송 문제가 모두 해결되는 것은 아닙니다.

작은 테스트 목록

처음에는 실제 고객 데이터 대신 가상 대화로 확인해보세요.

• 답장이 없는 경우: 정해진 확인 대상만 생성되는가
• 일부 질문에만 답한 경우: 해결한 질문을 다시 묻지 않는가
• 초안 검토 후 회신이 도착한 경우: 기존 초안이 그대로 발송되지 않는가
• 내부 확인 시점을 넘긴 경우: 고객 동의로 처리되지 않는가
• 발송 결과가 불확실한 경우: 성공으로 집계하거나 무작정 재전송하지 않는가

핵심은 알림을 많이 보내는 것이 아니라, 무엇을 기다리는지와 누가 다음으로 확인할지를 상태에 남기는 일입니다. 여러분의 대기 큐에서는 어떤 사건이 업무 상태를 바꾸나요?

오피셜메일에서 업무 메일 안내 살펴보기