고객이 메일과 채팅으로 같은 요청을 보냈다고 가정해 봅시다. 메시지 두 개를 곧바로 업무 두 건으로 만들면 두 담당자가 같은 내용을 조사할 수 있습니다. 반대로 비슷한 문장을 자동으로 합쳐 버리면 새 질문이 사라질 수 있습니다.
이 글은 특정 제품의 제공 기능이 아니라, 고객 응대 도구를 만들 때 검토할 수 있는 설계 예시입니다.
메시지와 업무 건의 책임을 나누기
메시지는 누가 어느 채널에서 무엇을 보냈는지 보존합니다. 업무 건은 무엇을 해결해야 하는지와 현재 담당자를 관리합니다. 따라서 메시지 수와 업무 건 수가 항상 같을 필요는 없습니다.
- 원본 메시지: 채널, 수신 시각, 원문, 첨부 자료
- 업무 건: 요청 범위, 담당자, 다음 안내 시점
- 연결 판단: 같은 요청으로 본 이유와 확인한 사람
원문을 삭제하는 대신 관련 메시지를 대표 업무 건에 연결하면 판단을 다시 검토하기 쉽습니다. 연결했다는 사실만으로 해결 완료 상태를 주어서는 안 됩니다.
문자열 유사도보다 먼저 볼 세 가지
같은 고객인지, 같은 대상에 관한 요청인지, 원하는 결과가 같은지 확인합니다. 비슷한 문장이라도 주문이나 계약이 다르면 별개일 수 있습니다. 반대로 다른 표현을 썼어도 같은 요청일 수 있습니다.
불확실하면 ‘같은 문의인지 확인 중’으로 남기고 담당자가 확인하도록 합니다. 새로운 첨부 자료나 추가 질문이 들어왔다면 대표 건의 검토 범위를 갱신하거나 별도 업무로 분리합니다.
답변 경로도 명시적인 결정으로
대표 건에 담당자가 있어도 두 채널에서 각각 답하면 내용이 엇갈릴 수 있습니다. 답변할 담당자와 주 회신 채널을 함께 정하고, 다른 채널에는 어디에서 이어 안내할지 짧게 알립니다. 고객 동의 없이 다른 사람에게 원문을 공유하는 방식은 피합니다.
병합 동작의 테스트 조건
- 연결 전후 원문과 첨부 자료에 접근할 수 있는가?
- 서로 다른 요청을 연결했을 때 다시 분리할 수 있는가?
- 추가 질문이 와도 기존 완료 상태에 가려지지 않는가?
- 동시에 두 담당자가 연결할 때 중복 업무가 생기지 않는가?
- 연결·안내·해결을 각각 다른 상태로 확인할 수 있는가?
먼저 수동으로 검증 가능한 흐름을 만들고, 자동화는 모호한 경우를 사람이 확인할 수 있도록 제한하는 편이 낫습니다. ‘중복을 발견했다’와 ‘고객의 요청을 해결했다’는 다른 사건입니다.
업무 메일 관리의 출발점을 점검하고 싶다면 오피셜메일 서비스 안내를 살펴보세요. 위 설계 예시가 해당 서비스의 자동 병합 기능을 의미하지는 않습니다.
