제품 미팅 뒤에 “좋은 이야기 나눴습니다”로 끝나는 메일을 보내면, 다음 주에 같은 질문이 다시 돌아올 때가 있습니다. 개발 작업의 상태를 공유할 때는 완료, 진행 중, 차단된 항목을 구분하면서 고객과의 대화는 왜 한 문단으로 뭉뚱그릴까요? 아래는 가상의 고객 미팅을 바탕으로 한 예시입니다.
합의와 가설을 분리하기
“관리 화면을 먼저 만든다”는 말이 나왔더라도, 어떤 사용자가 어떤 데이터를 봐야 하는지는 아직 열린 질문일 수 있습니다. 후속 메일에서 확정된 결정과 검증이 필요한 가정을 따로 적으면 아직 약속하지 않은 기능을 범위에 넣는 일을 막을 수 있습니다.
| 구분 | 메일에 남길 문장 |
|---|---|
| 확정 | 첫 화면은 주문 상태 확인에 집중합니다 |
| 미결 | 관리자별 접근 범위는 다음 미팅에서 정합니다 |
| 다음 행동 | 제가 목요일까지 화면 초안을 보냅니다 |
표는 예시일 뿐입니다. 실제 합의 내용은 회의 중 확인한 기록과 다시 맞춰야 합니다.
할 일에는 담당자와 확인 시각을 붙이기
“자료 부탁드립니다”라는 문장은 이슈를 만들고 담당자를 비워 둔 것과 비슷합니다. 무엇을, 누가, 언제까지 주는지 적고, 답을 받지 못했을 때 다시 확인할 시각도 정해 둡니다. 기한이 확정되지 않았다면 임의로 만들어 넣지 않습니다.
메일은 최종 판정이 아니라 수정 가능한 기록
“제가 이해한 범위가 다르면 알려 주세요”라는 한 줄을 마지막에 넣습니다. 고객이 바로 고칠 수 있어야 틀린 가정이 다음 작업으로 전파되지 않습니다. 답장이 없다는 이유만으로 자동 승인을 받았다고 해석하지도 않습니다.
미팅 후 메일은 회의록을 예쁘게 만드는 일이 아니라, 다음 작업의 입력값을 서로 같게 맞추는 일에 가깝습니다. 실제 발송 문안과 체크리스트는 고객 미팅 후 정리 메일 가이드에 정리했습니다.
Top comments (0)