알림을 받은 사용자와 작업을 끝내야 하는 사용자는 같은 집합이 아닙니다. 메일 협업 도구를 설계할 때도 이 차이를 데이터와 화면에 남기는 편이 좋습니다.
cc 배열을 assignee로 쓰지 않기
예를 들어 문의 메시지에 세 사람이 참조돼 있다고 합시다. 세 사람의 읽음 상태를 모두 확인해도 누구의 답변을 기다리는지는 알 수 없습니다. 반대로 담당자가 아닌 사람이 먼저 답장을 보냈다고 해서 해당 업무의 검토가 끝난 것도 아닙니다.
수신자 목록은 메시지를 전달하는 범위이고, 담당자는 다음 행동의 책임입니다. 메시지의 수신자를 그대로 업무 담당자로 복사하지 않는 것이 출발점입니다.
작은 모델에 남길 세 항목
- 메시지별 수신자: 그 메시지가 누구에게 전달됐는지 보존합니다.
- 업무별 답변 담당자: 내용을 취합해 외부에 회신할 사람을 별도로 둡니다.
- 검토 요청: 특정 질문에 대한 의견이 필요하면 대상과 요청 내용을 명시합니다. 단순 참조와 구분해야 합니다.
하나의 문의에 메시지가 여러 통 생겨도 담당자가 자동으로 늘어나지는 않도록 생각해 볼 수 있습니다. 담당자를 바꾸는 동작에는 새 담당자의 확인과 현재 진행 상태를 같이 보여 주는 편이 안전합니다.
전체답장 버튼 앞에서 테스트할 것
참조자가 추가됐을 때 이전 내부 메모까지 새 수신자에게 노출되지 않는지, 수신자가 빠졌을 때 업무 담당자까지 조용히 삭제되지 않는지 확인해 보세요. 회신 초안에는 이번 메시지의 수신자와 외부 전달 내용을 미리 보여 주고, 전송 성공과 검토 완료를 서로 다른 상태로 다루는 것이 좋습니다.
다음 세 상황을 테스트 케이스로 삼을 수 있습니다.
- 알림 수신자는 늘었지만 담당자는 그대로인 경우
- 담당자는 바뀌었지만 원본 메시지의 수신 이력은 남아야 하는 경우
- 내부 검토가 진행 중인데 외부 답장만 먼저 발송된 경우
기능보다 먼저 정할 운영 문장
“이번 문의는 A가 취합해 회신하고, B는 일정만 검토한다”는 문장을 화면 없이도 설명할 수 있어야 합니다. 그 기준이 모호하면 알림을 늘리는 구현은 혼란을 빠르게 전달할 뿐일 수 있습니다.
메일 업무 흐름을 점검하고 있다면 오피셜메일 서비스 안내도 살펴보세요. 이 글의 데이터 구분은 설계 제안이며, 특정 제품의 구현 완료 기능을 설명하는 것은 아닙니다.
Top comments (0)