메일 발송 이벤트를 미팅 확정 이벤트로 취급하면, 아직 회신하지 않은 고객이 내부 일정표에서는 참석자로 바뀔 수 있습니다. 이 글은 특정 제품의 구현 사례가 아니라, 작은 팀의 일정 조율을 설계할 때 써볼 수 있는 개념 모델입니다.
상태보다 먼저 전이 조건을 정하기
- draft: 목적·참석자·후보를 준비 중입니다.
- proposed: 날짜, 시작·종료 시각, 시간대를 적은 후보를 상대에게 보냈습니다.
- selected: 상대가 어떤 후보를 선택했는지 확인했습니다.
- confirmed: 필요한 참석자의 동의와 장소 또는 접속 정보를 확인하고 확정 안내를 보냈습니다.
메일이 전송됐다는 사실만으로는 proposed에서 confirmed로 넘어가지 않습니다. 상대의 회신이라는 별도 근거가 필요합니다. 회신 기한이 지났다는 이유로 자동 확정해서도 안 됩니다.
저장해둘 데이터는 문장과 다릅니다
자연어 본문 외에 후보의 날짜, 시작·종료 시각, 기준 시간대, 선택한 후보, 회신 근거를 분리해두면 어떤 합의를 했는지 다시 보기 쉽습니다. 이때 메일 본문에 적힌 현지 시각을 확인 없이 변환한 값으로 덮어쓰지 않는 편이 안전합니다.
일정 변경은 기존 확정 시간의 단순 수정이 아니라 새 제안으로 취급할 수 있습니다. 기존 약속과 새 후보를 구분하고, 새 선택이 확인되기 전까지 무엇이 유효한지 명시해야 합니다.
테스트에서 놓치기 쉬운 네 가지
- 같은 회신을 두 번 읽어도 확정 안내를 두 번 보내지 않는가?
- 다른 후보를 고른 새 회신이 도착하면 이전 선택과 구분되는가?
- 필수 참석자 중 한 명만 답했을 때 전체 확정으로 표시하지 않는가?
- 시간대가 빠진 후보를 바로 확정하지 않고 확인이 필요한 상태로 남기는가?
이 질문은 특정 라이브러리의 기능 설명이 아니라 운영 규칙 점검표입니다. 실제 자동화에서는 메일 발송 성공과 업무 합의 성립을 서로 다른 결과로 검증해야 합니다.
다음에 만들 최소 화면
거대한 캘린더부터 만들기보다 ‘보낸 후보 / 기다리는 회신 / 현재 확정 시간’을 분리해 보여주는 화면을 먼저 그려보세요. 사용자가 상태를 읽는 방식이 명확해지면 자동화할 경계도 선명해집니다.
업무 메일을 정리하는 관점이 필요하다면 오피셜메일 살펴보기에서 시작해보세요.
