고객 문의를 받았지만 바로 결론을 낼 수 없을 때, 개발팀의 티켓 상태와 고객에게 보이는 상태가 달라지기 쉽습니다. 내부에는 investigating이라고 적혀 있어도 고객의 받은편지함에는 아무 변화가 없으니까요.

내부 상태와 외부 약속을 분리하기 

inquiry: status: investigating owner: 담당자 1명 confirmed: 지금까지 확인한 사실 open_question: 아직 확인할 항목 next_update_at: 고객에게 다시 알릴 시각

이 예시는 특정 제품의 데이터 구조가 아니라 운영 기록의 최소 단위입니다. next_update_at은 해결 예상 시각과 다릅니다. 해결을 장담할 근거가 없더라도, 다음 경과 안내 시각은 정할 수 있습니다.

회신을 트리거하는 세 가지 사건

  1. 접수: 문의 요지를 다시 적고 담당자가 확인할 항목을 명시합니다.
  2. 약속한 시각 도착: 결론이 없으면 확인된 것, 남은 것, 새 안내 시각을 보냅니다. 자동으로 “해결 중”만 반복하지 않습니다.
  3. 상태 변화: 해결, 추가 정보 요청, 다른 담당자 이관 중 무엇이 바뀌었는지 적습니다.

예시 문장도 짧게 만들 수 있습니다.

요청하신 파일 접근 문제를 접수했습니다. 공유 링크와 권한을 확인 중입니다. 오늘 오후 4시까지 해결 여부 또는 다음 조치를 다시 안내드리겠습니다.

next_update_at을 지나도 아무 기록이 없다면, 시스템 알림보다 먼저 고객에게 실제로 안내가 나갔는지 확인해야 합니다. 내부 상태값만 바뀌고 고객은 여전히 기다리는 상황을 막기 위해서입니다.

구현 전에 확인할 질문

  • 약속한 회신 시각은 누가 정하고 변경하나요?
  • 담당자가 부재할 때 누가 원문과 마지막 안내를 이어받나요?
  • 자동 알림에는 확인되지 않은 원인이나 복구 시각이 들어가지 않나요?
  • 고객에게 보낸 답장이 같은 스레드에 남나요?

오피셜메일처럼 회사 주소로 대화를 이어가는 도구를 쓰더라도, 고객에게 무엇을 언제 알릴지는 팀의 운영 규칙이 정해야 합니다. 오피셜메일에서 업무 메일 관리하기를 참고하고, 팀의 문의 흐름에 맞는 상태와 약속을 먼저 정의해 보세요.