혼자 제품을 만들 때는 마지막 배포 버튼을 누르면 프로젝트가 끝난 것처럼 느껴집니다. 고객 입장에서는 그때부터 시작입니다. 다음 날 로그인하려는데 권한이 막히거나, 공지 문구 하나를 바꾸려는데 어느 화면을 열어야 할지 모르면 완성된 결과물도 잠시 멈춥니다.
납품 파일보다 먼저 정할 것은 담당자
파일 목록만 전달하면 고객은 문제를 발견한 뒤 다시 물어봐야 합니다. 그래서 인계 문서의 첫 줄에는 “누가 무엇을 할 수 있는가”를 적는 편이 좋습니다. 관리자 로그인 담당자, 결제와 도메인 관리 담당자, 일상적인 콘텐츠 수정 담당자를 구분합니다. 한 사람이 세 역할을 맡아도 괜찮습니다. 다만 그 사실이 적혀 있어야 합니다.
예를 들어 홈페이지를 납품했다면 “관리자 계정은 고객 대표가 보관하고, 배너 문구는 마케팅 담당자가 편집하며, 서버 설정은 별도 요청으로 처리한다” 정도면 충분합니다. 추상적인 ‘운영 가능’보다 훨씬 쓸모가 있습니다.
마지막 화면은 고객 계정으로 열어 본다
제작자 계정에서는 멀쩡한 기능이 고객 계정에서는 안 보일 수 있습니다. 검수할 때는 고객이 실제로 사용할 계정으로 접속해 다음 세 가지를 따라 해 봅니다.
- 첫 로그인과 비밀번호 재설정이 되는가
- 자주 바꿀 정보 한 가지를 직접 수정할 수 있는가
- 문제가 생기면 어디에 문의해야 하는지 찾을 수 있는가
이 검사는 기술적인 완성도를 자랑하기 위한 절차가 아닙니다. 고객이 월요일 아침에 혼자 일을 시작할 수 있는지를 보는 절차입니다.
수정 범위를 남겨야 관계가 편해진다
납품 뒤 가장 애매한 말은 “간단한 것만 한 번 봐 주세요”입니다. 고객도 어디까지 요청해도 되는지 모르고, 제작자도 어디서부터 새 일인지 설명하기 어렵습니다. 종료 메일에 무상 수정 기간, 오류와 새 기능의 구분, 이후 요청 채널을 짧게 적어 두면 불필요한 눈치를 줄일 수 있습니다.
예를 들어 “14일 동안 기존 기능의 오류는 확인하고, 새 페이지나 새로운 자동화는 별도 범위로 논의한다”처럼 기준을 보이는 문장이 좋습니다. 기간과 범위는 실제 계약에 맞게 조정해야 합니다.
종료 메일은 짧아도 빠짐없게
고객에게 보내는 마지막 메일은 네 가지를 한 화면에 담으면 됩니다. 최종 파일 위치, 접근 권한 확인, 운영 방법 한 장, 이후 문의 방법입니다. 필요한 경우 다음 점검 날짜도 덧붙입니다. 이렇게 보내면 납품의 끝이 “파일 전달”이 아니라 “고객이 스스로 이어 갈 수 있는 상태”가 됩니다.
실제로 보낼 때 확인할 항목과 종료 메일 예시는 1인기업 프로젝트 종료 체크리스트와 인계 예시에 정리했습니다.

Top comments (0)