고객 메일 하나가 티켓 하나가 되는 건 자연스럽습니다. 하지만 티켓 하나가 질문 하나라는 가정은 위험할 수 있습니다. 자료 제공 여부, 원본 파일 형식, 일정 확인을 한꺼번에 물었는데 자료 링크만 보낸 뒤 resolved로 바꾸면 나머지 질문이 상태 밖으로 사라지기 때문입니다.
아래는 특정 서비스에 구현됐다는 설명이 아니라, 작은 문의 시스템을 설계할 때 검토해 볼 모델입니다.
발송 이벤트와 질문 해결은 다른 축입니다
‘회신 발송’ 이벤트는 전송 사실을 알려줍니다. 고객이 원한 판단 재료가 모두 전달됐다는 뜻은 아닙니다. 티켓의 표시 상태를 먼저 늘리기보다 질문을 식별할 단위를 두면, 부분 답변을 다루는 기준이 선명해집니다.
예시 데이터는 다음처럼 잡을 수 있습니다.
{
"ticketId": "example-42",
"questions": [
{ "id": "q1", "topic": "자료 제공", "state": "answered" },
{ "id": "q2", "topic": "전달 형식", "state": "awaiting_internal" },
{ "id": "q3", "topic": "일정 범위", "state": "awaiting_customer" }
]
}
질문의 ID는 순번 자체와 분리합니다. 답장에 새 질문이 추가되거나 두 항목을 합쳐도, 과거 답변이 엉뚱한 질문에 연결되지 않도록 하기 위해서입니다.
완료는 질문 상태를 모아서 판단합니다
-
answered: 확인된 답과 근거가 고객에게 전달됐습니다. -
awaiting_internal: 내부 확인 주체와 다음 안내가 남아 있습니다. -
awaiting_customer: 고객에게 어떤 정보가 필요한지 질문해 둔 상태입니다.
이름은 구현에 맞게 바꿔도 됩니다. 중요한 건 내부 담당자에게 전달한 것과 고객에게 답한 것을 같은 완료로 취급하지 않는 것입니다. 모든 유효 질문이 답변 완료일 때만 종료 후보로 올리고, 실제 종결 조건은 제품의 운영 정책에 따르게 합니다.
테스트는 메일 발송 성공 밖까지 넓혀봅니다
- 첫 질문만 답했을 때 다른 두 질문이 유지되는가?
- 내부 확인 답변이 늦게 도착해도 더 최신의 정정을 덮어쓰지 않는가?
- 고객이 새 질문을 보태면 기존 답변의 연결은 유지되는가?
- 중복 질문을 합쳤을 때 무엇을 왜 합쳤는지 사람이 이해할 수 있는가?
- ‘정보 요청 메일 전송 성공’만으로 질문을 완료 처리하지 않는가?
숫자로 보이는 완료율을 높이기 위한 분류가 아니라, 아직 답하지 않은 항목을 숨기지 않기 위한 모델이어야 합니다. 운영자가 원문과 항목을 함께 읽고 분류를 고칠 수 있는 경로도 남겨두는 편이 좋겠습니다.
먼저 해볼 가장 작은 점검
데이터 모델을 바로 바꾸기 어렵다면 오늘 나가는 회신 한 통에서 질문 목록과 답변 문단을 나란히 놓아보세요. 각 질문에 답변·확인 중·추가 정보 요청 중 무엇이 연결되는지 확인하는 것만으로도, 시스템이 어디에서 정보를 잃는지 찾는 출발점이 됩니다.
메일 한 통을 처리하는 것과 질문을 끝까지 따라가는 것은 다른 일입니다. 여러분의 문의 시스템은 어떤 단위를 완료의 기준으로 삼고 있나요?
오피셜메일의 업무 메일 운영 안내에서 메일을 운영 관점으로 정리하는 내용을 살펴볼 수 있습니다.
Top comments (0)