How we solved the "out-of-scope" client request trap
범위 밖 고객 요청이 수정 횟수를 잡아먹지 않게 하는 방법
웹사이트 피드백 도구 tweak.page가 고객 요청을 ‘범위 밖’으로 표시하는 기능을 추가했습니다. 단순 수정과 새 페이지 같은 범위 확장을 구분해 수정 횟수나 유지보수 계약 한도에 반영되지 않도록 합니다.
- 주제
AI 요약
웹 에이전시와 디자이너를 위한 피드백 도구 tweak.page가 고객 수정 요청을 ‘범위 밖’으로 분류하는 기능을 소개했습니다. 수정 횟수를 세는 방식은 오탈자 수정과 새 페이지 레이아웃처럼 규모가 다른 요청을 똑같이 취급한다는 문제가 있습니다.
요청 분류 방식
고객이 스테이징 사이트에 피드백을 남기면 에이전시가 요청을 검토합니다. 가벼운 수정은 기존 수정 횟수에 포함하고, 구조를 바꾸는 큰 요청은 ‘범위 밖’으로 표시해 유지보수 계약이나 수정 횟수 한도에서 분리합니다. 게시물 작성자는 이 기능으로 범위 변경을 이메일에서 어색하게 설명하는 상황을 줄이려 합니다.
Indie Hackers 반응
- @jonasbenso — 에이전시가 고객 요청을 처음으로 범위 밖이라고 표시할 때 긴장감이 생기는지 궁금합니다. 승인 대기 단계를 두면 부담이 줄어드나요? 고객이 별말 없이 승인하는 경우와 반발하는 경우를 가르는 요인이 무엇인지도 궁금합니다.
- @capo689 — 토글은 적절한 기본 기능이지만, 진짜 어려운 부분은 표시한 뒤의 대화입니다. 범위 밖 표시를 고객 화면에도 보여주고, ‘새 범위입니다. 예상 비용은 이렇습니다’라고 한 줄로 알려주세요. 표시를 숨기면 고객은 청구서를 받을 때 처음 알게 되고, 속았다고 느낄 수 있습니다. 제안서에는 시간보다 결과물별 수정 회차를 적으세요. 고객은 수정 회차를 이해하기 쉽습니다. 수정 횟수, 눈에 보이는 표시, 제안서의 범위 문구를 함께 쓰면 요청이 다툼거리가 되지 않습니다.
- @Roman_t — 고객에게 요청 분류를 직접 고르게 하지 않는 점이 좋습니다. 다만 에이전시 직원 둘이 같은 요청을 다르게 표시하면 고객에게 기준이 임의적으로 보일 수 있습니다. 표시와 함께 이유를 한 줄로 보여주면 좋겠습니다. 에이전시가 실제로 토글을 쓸지도 궁금합니다. 익숙한 이메일 방식을 계속 쓰지는 않을까요?
- @OrientLabs — 합의한 작업의 결함과 새 요구사항을 구분하는 사례를 시험해야 합니다. 납품한 페이지가 제안서에 적힌 조건을 충족하지 못했다면, 수정 요청을 범위 밖으로 분류할 때 고객은 당연히 불쾌해할 수 있습니다. 요청마다 원래 요구사항과 승인 조건을 함께 보여주면 판단이 쉬워집니다. 실제 범위 변경이라면 바뀌는 내용, 예상 비용, 납기 영향을 간단히 기록해 고객이 승인하거나 미룰 수 있게 하세요.
- @geeknonerd — 요청을 올릴 때 고객이 먼저 직접 분류하게 하지 않는 편이 낫습니다. 그러면 검토가 협상으로 바뀝니다. 다만 범위 밖 표시가 에이전시 내부에만 보이면 고객은 허용량이 차감되지 않는 이유를 나중에 알게 되고, 불편한 대화가 더 나쁜 시점에 생깁니다. 고객에게 ‘견적 필요’ 같은 중립적인 표시를 보여주는 편이 좋습니다. 범위 밖으로 보는 기준을 계약서에 한 문장으로 적어두면, 토글은 양측이 이미 합의한 규칙을 적용하는 도구가 됩니다. 고객이 표시를 문제 삼으면 어떻게 처리하나요? ‘견적 발송, 승인 대기’ 상태가 있나요, 아니면 결국 이메일로 돌아가나요? 이 기능이 대체하려던 이메일에서 다시 논의한다면 문제를 이름만 바꾼 셈입니다.
- @usetether — 요청을 사전에 분류하게 하는 것보다 사후에 표시하는 편이 고객에게 부담이 적습니다. 여러 고객이 반복해서 요청하는 범위 밖 작업도 추적하나요? 여러 에이전시가 같은 ‘간단한 수정’을 요청받는다면, 실제로는 새 페이지를 만드는 작업을 상품으로 묶어 판매할 수도 있습니다.
원문: Indie Hackers / 번역·요약: Trawling