작은 요청이 가장 위험
한 건당 10분이라도 20번 쌓이면 몇 시간이 됩니다. 범위 밖 요청을 ‘서비스’로 넘기면 원가가 계속 올라갑니다.
변경요청 로그
요청 날짜, 내용, 예상 시간, 비용 영향을 짧게 기록하면 감정이 아니라 데이터로 협의할 수 있습니다.
추가 견적 전환 기준
기존 기능의 수정인지, 새 기능 추가인지, 이미 승인된 산출물을 다시 바꾸는지 세 기준으로 나누면 좋습니다.
금액보다 승인 흐름
추가 비용이 발생하는 요청은 작업 전에 고객 승인부터 받아야 합니다. 먼저 만들고 나중에 청구하면 분쟁 가능성이 커집니다.
운영 문장
‘계약 범위 외 요청은 별도 견적 후 진행됩니다’라는 한 줄을 견적서와 계약서에 모두 넣어두는 편이 좋습니다.
‘작은 부탁’이 원가를 무너뜨리는 방식
버튼 하나, 문구 하나, 보고서 항목 하나는 각각 작아 보이지만 이런 요청이 프로젝트 전체에 반복되면 투입 시간이 크게 늘어납니다. 그래서 요청의 크기보다 ‘기존 합의 범위 안인가’를 기준으로 판단하는 편이 좋습니다. 기존 기능의 오류 수정은 기본 범위, 새 기능이나 승인 후 방향 변경은 추가 견적으로 구분하면 설명이 쉬워집니다.
핵심 실무 포인트를 한 장으로 정리했습니다.
SOME SENSE
추가 견적은 작업 전에 승인받습니다
범위 밖 요청을 먼저 처리한 뒤 나중에 돈을 청구하면 고객 입장에서는 갑작스러운 비용처럼 느낄 수 있습니다. 요청이 들어오면 예상 시간과 추가 비용을 짧게 안내하고, 고객이 승인한 뒤 작업하는 흐름을 고정하세요. 변경 요청 로그를 남기면 ‘언제 무엇이 추가됐는지’도 쉽게 설명할 수 있습니다.
실제 운영 화면을 설계할 때는 정보와 다음 행동이 한눈에 보여야 합니다.
SOME SENSE
