견적 변경 메일을 자동화할 때 알림 성공을 업무 적용 완료로 기록하면 상태가 어긋납니다. 메일 발송 처리, 고객 의견, 조직의 승인 절차, 실제 적용은 서로 다른 사건이기 때문입니다.
아래는 특정 제품의 구현 설명이 아닌, 작은 업무 도구를 설계할 때 사용할 수 있는 예시입니다.
문서 버전과 전달 상태를 분리하기
같은 변경안이 재전송되더라도 업무상 변경이 하나 더 생긴 것은 아닙니다. 변경 제안에는 고유 식별자를 두고 문서 버전, 비교 기준, 전달 시도를 따로 연결합니다.
{ "change_id": "example-change-001", "baseline_version": "example-v1", "proposal_version": "example-v2", "workflow_status": "awaiting_review", "delivery_status": "sent", "review_evidence_ref": null, "applied_version": null } 값은 모두 설명용입니다. 실제 도구에서는 조직의 데이터 분류·보관 기준에 맞춰 식별자를 사용하고 고객 정보나 견적 내용을 불필요한 로그에 복사하지 않습니다.
적용 전환에는 실제 근거가 필요하기
delivery_status=sent는 적용 조건이 아닙니다. 고객 확인과 내부 승인 방식에 맞는 근거가 확보돼야 다음 업무 단계로 전환할 수 있습니다. 열람 신호나 일정 시간의 경과만으로 applied_version을 채우지 않습니다.
또한 답변이 변경 범위에만 해당하고 일정에는 해당하지 않을 수 있습니다. 어떤 항목이 확인됐는지와 남은 질문을 분리해 기록해야 합니다.
메시지에는 같은 비교 항목을 유지하기
변경 알림 템플릿에는 다음 세 부분을 둡니다.
- 기존 기준: 문서 버전과 실제 확인 상태
- 변경 제안: 작업 범위·비용·일정의 차이
- 다음 행동: 확인받을 항목과 적용 전후의 작업
요약을 생성하는 도구를 붙이더라도 미확정 금액이나 날짜를 채워 넣게 해서는 안 됩니다. 확인하지 못한 값은 명시적으로 비워 두고 검토 대상으로 보냅니다.
확인할 실패 사례
- 같은 알림을 재시도해도 변경안이 중복 생성되지 않는가?
- 발송 실패가 고객 거절로 저장되지 않는가?
- 범위만 확인한 답변을 전체 조건 확인으로 확대하지 않는가?
- 이전 변경안에 온 답변이 새 변경안을 적용하지 않는가?
- 적용 근거와 문서 버전이 어긋나면 사람이 확인할 수 있는가?
알림의 성공과 업무의 완료를 나누면 재시도와 사람 검토의 위치가 선명해집니다. 오피셜메일의 사업용 메일 안내도 함께 살펴보세요. 여러분의 도구에서는 고객 확인 근거와 적용 버전을 어떻게 연결하고 있나요?
