에이전시가 고객사를 비슷하게 보이지 않게 하면서 재사용할 수 있는 SaaS 웹사이트 진단

요약

이번 분기에 완전히 다르다고 주장하는 두 고객을 위해 똑같은 디스커버리 콜(제품, 고객, 경쟁사에 대한 같은 질문)을 몇 번이나 진행했습니까? 답이 다를 것이라는 건 이미 알고 있지만, 각 SaaS 사이트가 수행해야 하는 작업(jobs)은 다르지 않습니다. 모든 SaaS 제품 웹사이트는 동일한 작업을 수행하는 작은 기계들의 집합입니다: 제품이 무엇을 하는지 설명하고, 비용이 얼마인지 보여주고, 개발자에게 통합 방법을 알려주고, 구매를 막는 반대 의견에 답하고, 회사의 신뢰성을 입증하는 것입니다. 이러한 다섯 가지 작업을 감사하는 반복 가능한 진단은 작업이 변하지 않으므로 어떤 고객과도 문제없이 적용될 수 있습니다. 그 주변에 구축하는 시스템이 바로 당신이 매번 처음부터 시작하지 않고 한 계약에서 다음 계약으로 이동할 수 있게 해줍니다. 이는 현재의 디스커버리 프로세스보다 시간이 덜 걸리고, 고객에게 당신을 신뢰해야 하는 분명한 이유를 제공하며, 질문은 표준적이지만 답은 구체적이기 때문에 템플릿처럼 보이지 않는 결과물을 만들어냅니다.

이번 분기에 완전히 다르다고 주장하는 두 고객을 위해 똑같은 디스커버리 콜(제품, 고객, 경쟁사에 대한 같은 질문)을 몇 번이나 진행했습니까? 답이 다를 것이라는 건 이미 알고 있지만, 각 SaaS 사이트가 수행해야 하는 작업(jobs)은 다르지 않습니다. 모든 SaaS 제품 웹사이트는 동일한 작업을 수행하는 작은 기계들의 집합입니다: 제품이 무엇을 하는지 설명하고, 비용이 얼마인지 보여주고, 개발자에게 통합 방법을 알려주고, 구매를 막는 반대 의견에 답하고, 회사의 신뢰성을 입증하는 것입니다. 이러한 다섯 가지 작업을 감사하는 반복 가능한 진단은 작업이 변하지 않으므로 어떤 고객과도 문제없이 적용될 수 있습니다. 그 주변에 구축하는 시스템이 바로 당신이 매번 처음부터 시작하지 않고 한 계약에서 다음 계약으로 이동할 수 있게 해줍니다. 이는 현재의 디스커버리 프로세스보다 시간이 덜 걸리고, 고객에게 당신을 신뢰해야 하는 분명한 이유를 제공하며, 질문은 표준적이지만 답은 구체적이기 때문에 템플릿처럼 보이지 않는 결과물을 만들어냅니다.

'내 고객들은 한 시스템에 맞추기엔 너무 달라'

모든 고객에게 카피 한 줄을 쓰거나 디자인 도구를 열기 전에 동일한 5점 진단을 실행하세요. 고객을 특별하게 만드는 차이점(산업, 잠재고객, 가격 모델)은 공통된 기반 위에 있습니다. 급여 SaaS와 소셜 미디어 스케줄링 도구는 모든 페이지가 수행하는 다섯 가지 작업을 제외하고는 공통점이 없습니다. 이러한 작업을 감사하면 같은 장소에서 동일한 패턴을 발견하게 됩니다.

페이지 또는 섹션	고객이 보통 요청하는 것	페이지에서 실제로 일어나는 일
기능 쇼케이스	'우리가 만든 모든 기능을 보여주세요'	기능만이 아니라 사용자가 얻는 결과를 보여줍니다. 스크린샷, GIF, 비디오 같은 시각 자료는 제품이 누군가의 작업 방식을 바꾸는 순간을 보여주어야 합니다.
가격	'가격을 읽기 쉽게 만들어 주세요'	구매자는 어떤 요금제가 자신에게 맞는지 결정해야 합니다. 요금제는 가격의 단순한 목록이 아니라 선택을 안내하는 진행 단계로 읽혀야 합니다.
API 문서	'우리 개발자들이 문서에서 찾을 것입니다'	개발자가 제품을 신뢰할 수 있는지 평가할 때 실행하는 첫 번째 테스트인 경우가 많습니다. 여기서의 명확성은 선택 사항이 아니라 핵심 기능입니다.
FAQ 섹션	'지원 문의를 줄이기 위해 질문에 답해 주세요'	구매자가 버튼을 클릭하기 전에 마지막으로 읽는 것입니다. 단순한 일반적인 회사 질문이 아니라 가격 반대 의견과 예외적인 상황을 처리해야 합니다.
사회적 증명	'로고를 올려 주세요'	앞서 한 주장이 사실임을 보여주는 증거입니다. 로고와 추천사는 장식이 아니라 신뢰 지표입니다.

진단은 템플릿이 아닙니다. 모든 페이지에 묻는 일련의 질문입니다: 이것이 구매자가 제품이 무엇을 하는지 이해하게 하는가, 다음 단계를 분명하게 하는가, 현재 판매를 막고 있는 반대 의견에 답하는가? 고객이 있는 자리에서 이러한 질문을 하면, 고객은 당신을 슬라이드 덱을 보여준 열 번째 에이전시가 아니라 자신들의 시장을 이해하는 사람으로 봅니다. SaaS 웹사이트에 대한 연구는 HubSpot, Slack, Zendesk와 같은 회사들을 잘 정리된 FAQ 섹션의 예로, Stripe, GitHub, Twilio를 문서 명확성의 기준으로 지목합니다. 그 어떤 회사도 FAQ를 지원 티켓 더미로 취급하여 그 자리에 오르지 않았습니다. 그들은 FAQ를 전환 표면(conversion surface)으로 취급했습니다. 그것이 바로 당신의 진단이 모든 고객에게 가져와야 할 태도입니다.

재고 소프트웨어를 판매하는 고객과 급여 소프트웨어를 판매하는 고객을 생각해 보세요. 진단은 종종 동일한 세 가지 격차를 드러냅니다: 기능 페이지가 결과가 아닌 모듈을 언급하고, 가격 페이지가 요금제 간의 차이를 정당화하지 않으며, FAQ가 구매 망설임이 아닌 지원 질문에 답합니다. 두 경우 모두에서 이러한 격차를 보았기 때문에 디자인 단계에서 무엇을 요청해야 할지 정확히 압니다. 고객은 일반적이지 않은 구체적인 프로세스를 보고 있습니다. 진단을 각 작업에 대해 1~5점의 점수와 각각의 메모가 있는 한 페이지 PDF로 작성하세요. 디자인 킥오프 전에 고객과 공유하세요. 이는 공동의 어휘를 제공하고 감사를 청구할 수 있는 결과물로 바꿔줍니다. 이것이 반복 가능한 시스템의 핵심이며, 시스템을 설정하는 방법에 대한 별도의 안내가 여기에 있습니다.

'우리 작업이 다른 에이전시처럼 보일 것입니다'

묻는 질문을 표준화하되, 내놓는 답변을 표준화하지 마세요. 진단은 레이아웃이 아니라 평가 기준표를 제공합니다. SaaS 기능 쇼케이스에 대한 연구에 따르면 스크린샷, GIF, 비디오 같은 시각 자료를 사용하지만, 그러한 시각 자료의 내용은 제품마다 다릅니다. HR 도구의 급여 보고 기능과 재고 소프트웨어의 바코드 스캔 기능은 결코 비슷해 보이지 않습니다. 일정하게 유지되는 것은 전략적 사고에 던지는 질문입니다: “이 페이지가 결과를 보여주는가, 아니면 기능만 보여주는가?”

의사의 접수 양식은 모든 진단을 동일하게 만들지 않습니다. 의사를 신뢰할 수 있게 만듭니다. 당신의 프레임워크가 접수 양식입니다. 고객은 여전히 맞춤형 웹사이트를 받지만, 당신은 반복 가능한 진단을 얻습니다. 실제로 작업이 평범해 보이게 만드는 것은 진단의 부재입니다. 진단이 없으면 빠르게 진행하기 위해 지난 프로젝트에서 사용했던 동일한 히어로 이미지, 동일한 3열 기능 레이아웃, 동일한 홈페이지 구조로 돌아가기 때문입니다. 진단은 증거를 바탕으로 구조를 정당화하도록 강제하므로 각 사이트는 필요한 곳에서 구조적으로 달라집니다.

실제로 이는 진단이 한 고객의 기능 페이지를 가져오기 마법사의 비디오로 시작하고, 다른 고객의 것은 드래그 앤 드롭 리포트 빌더의 GIF로 시작하도록 지시할 수 있음을 의미합니다. 페이지 구조는 동일하지만 에셋, 카피, 템포는 고유합니다. 고객은 맞춤형 작업을 보고, 당신은 반복 가능한 프로세스를 봅니다. 진단을 고객에게 제시할 때 당신은 모든 SaaS 사이트가 무엇을 해야 하는지 알고 있음을 입증하는 것입니다. 이는 “독특한 디자인을 만들어 드리겠습니다”보다 더 강력한 제안입니다. 디자인은 진단의 결과이지 시작점이 아닙니다.

'모든 페이지를 감사할 시간이 없습니다'

전체 감사가 아니라 집중된 90분 버전을 수행하세요. 대부분의 에이전시 디스커버리 프로세스는 이미 감사이지만, 구조화되지 않은 감사입니다. 배경, 경쟁사, “이 프로젝트에서 원하는 것이 무엇인가”를 다루는 디스커버리 콜에 45분을 쓰고, 몇 주 동안 반응하며 보냅니다. 진단은 이를 뒤집습니다: 다섯 가지 작업을 점수화하고, 가장 영향력이 큰 수정 사항을 나열한 다음, 디자인으로 이동합니다. 이는 첫 디자인 리뷰 후에 작업을 다시 하지 않게 해주므로 시간을 절약합니다. 가장 저렴한 수정은 아무도 픽셀을 보기 전에 하는 수정입니다.

구체적인 90분 분할은 다음과 같습니다: 블록 1(30분)은 홈페이지와 기능 페이지를 다섯 가지 작업에 대해 검토합니다. 블록 2(30분)는 가격 페이지와 FAQ를 훑어봅니다. 블록 3(15분)은 API 문서가 “데이터를 내보낼 수 있나”에 답하는지 확인하고, 마지막 15분은 주요 수정 사항과 각 담당자를 나열합니다. 모든 페이지를 처음부터 끝까지 읽을 필요는 없습니다. 작업이 수행되고 있는지 확인하면 됩니다. 가격 페이지에 FAQ가 없다면 네 번째 가격 열을 목업하기 전에 이를 발견하면 디자인 승인이 더 빨라집니다. API 문서가 개발자 기준이 아닌 내부 기준으로 작성되었다면 카피라이터에게 브리핑하기 전에 알게 됩니다.

한 계약에서 진단은 타겟 구매자가 데이터 마이그레이션을 극도로 두려워한다는 것을 밝혀냈습니다. 그 답변을 위해 추가한 FAQ는 작성에 두 시간이 걸렸습니다. 진단이 없었다면 그 두려움은 디자인, 개발, 그리고 출시 후 지원 과부하까지 우리를 따라왔을 것입니다. 90분 버전은 프로젝트에 앞서는 단계가 아니라 프로젝트의 첫 번째 단계입니다. 또한 정직한 견적 방법을 제공합니다: 존재하는 것과 존재하지 않는 것의 목록을 가지고 세션을 떠나므로, 쓰는 제안서는 추측이 아닌 증거를 바탕으로 작성됩니다.

'비기술적 고객에게 API 문서는 필요 없습니다'

체크리스트가 아닌 결정 트리를 사용하세요: 제품에 공개 API나 통합 스토리가 있다면 API 문서는 핵심 페이지입니다. 그렇지 않다면 의식적으로 건너뛰세요. API 문서에 대한 연구는 단호합니다: Stripe, GitHub, Twilio 같은 회사들은 개발자가 사실상 구매자이기 때문에 문서 명확성의 기준을 세웁니다. 고객이 개발자 대상 통합을 가지고 있다면 문서는 개발자의 편의가 아니라 가격 페이지 옆에 위치한 신뢰 장치입니다. 비기술적 고객은 결코 그것을 보지 않을 수도 있지만, 구매를 평가하는 개발자는 반드시 볼 것입니다.

결정 트리는 시스템의 일부입니다. 고객이 “우리에겐 개발자 잠재고객이 없습니다”라고 말하면 한 가지 질문을 하세요: “온보딩 중에 제품을 다른 시스템에 연결하기 위해 개발자가 필요한 부분이 있나요?” 그렇다면 문서는 유지됩니다. 아니라면 건너뛰고 FAQ와 사회적 증명에 노력을 기울이세요. 사회적 증명에도 동일한 논리를 적용하세요: 한 고객에게는 로고 한 줄이 충분하고, 다른 고객에게는 측정 가능한 결과가 포함된 상세한 추천사가 필요합니다. 진단은 수집할 수 있는 모든 로고를 기본으로 사용하는 대신 어느 쪽인지 알려줍니다. 그 선택이 프레임워크를 경직되지 않게 반복 가능하게 만듭니다. ‘명확성’이 실제로 무엇을 의미하는지 파악해야 한다면, 이 API 문서 가이드가 구조를 안내합니다.

'하지만 제 고객은 결과가 아닌 기능 목록을 원합니다'

고객이 기능을 자랑하고 싶다고 말하면, 각 기능이 어떤 사용자 작업을 가능하게 하는지 이름을 대도록 요청하세요. 일반적인 가정은 기능 쇼케이스에서 판매가 이루어진다는 것입니다. 진단은 그 반대를 시사합니다: 일반적인 SaaS 사이트에서는 가격 페이지에서 최종적인 계산이 이루어지고, FAQ에서 마지막 반대 의견이 해결됩니다. 기능 쇼케이스는 필수적이지만 그 역할은 좁습니다. 제품이 가치 있게 되는 순간을 보여주는 것입니다. 각 기능 아래에 단락이 있는 긴 기능 목록은 그러한 역할을 하지 못합니다.

고객들이 이에 저항하는 이유는 목록이 실질적이고 승인하기 쉽게 느껴지기 때문입니다. 그러나 50개의 기능이 있는 페이지는 훑어보는 방문자를 만들고, 기능 페이지를 훑어보는 방문자는 이미 관심을 가격 표로 옮깁니다. 시스템의 역할은 고객이 트레이드오프를 편안하게 받아들이도록 하는 것입니다: 기능을 제거하는 것이 아니라 읽힐 위치로 옮기는 것입니다. “이미 사용하는 도구와 통합됩니다”라고 말하는 잘 배치된 FAQ는 종종 잘못된 제목 아래에서 같은 말을 하는 기능 페이지보다 더 많은 역할을 합니다. 이것은 대부분의 기사가 건너뛰는 미묘한 차이이며, 진단이 명확하게 만들 수 있는 바로 그런 종류의 트레이드오프입니다.

진단은 또한 범위 확대에 반대할 수 있는 방어 가능한 이유를 제공합니다. 고객이 홈페이지에 또 다른 기능 행을 추가해 달라고 요청하면 표를 가리키며 “그 페이지의 역할은 결과를 보여주는 것이지 기능을 목록화하는 것이 아닙니다”라고 말할 수 있습니다. 일반적인 페이지 빌더는 기능 그리드를 생성할 수 있지만, 그리드를 비디오나 FAQ로 대체해야 하는지 결정할 수는 없습니다. 그 결정이 진짜 제품이며, 프레임워크가 당신의 작업을 상품화하지 않는 이유입니다.

'우리에겐 이미 내부 프로세스가 있습니다'

에이전시에 홈페이지 프로세스나 가격 페이지 체크리스트가 있다면, 그 반대는 보통 그것을 대체하고 싶지 않다는 것입니다. 대체할 필요는 없습니다. 5가지 작업 진단은 창의적인 프로세스를 대체하는 것이 아니라 그것을 공급하는 프런트엔드입니다. 대부분의 내부 프로세스의 문제는 보이지 않는다는 것입니다. 그들은 시니어 디자이너의 머릿속에 있습니다. 진단은 프로세스를 외부화하여 주니어 팀원이 첫 번째 패스를 실행할 수 있고, 당신은 몇 분 안에 검토할 수 있습니다. 그것이 다중 고객을 둔 에이전시에서 실제로 필요한 반복성입니다.

보이는 프로세스는 고객과의 대화도 바꿉니다. “독점적인 디자인 프로세스가 있습니다” 대신 “모든 SaaS 사이트가 수행해야 하는 다섯 가지 작업에 대해 진단을 실행하고, 발견 사항을 중심으로 디자인합니다”라고 말할 수 있습니다. 첫 번째 문장은 고객을 긴장하게 만드는 블랙박스입니다. 두 번째는 고객을 초대하는 명확한 방법입니다. 진단은 단순한 생산 도구가 아니라 영업 스토리의 일부가 됩니다.

'고객이 현재 사이트가 괜찮다고 말합니다'

고객이 리프레시만을 원할 때도 진단은 여전히 작동합니다. 그것은 기준점을 제공합니다. 현재 사이트를 점수화하고 특정 페이지가 특정 작업을 수행하지 못하고 있음을 보여줍니다. “FAQ 페이지가 잘 정리되어 있지만 영업팀이 매주 듣는 질문에 답하지 않습니다”라고 말할 수 있으며, 그것은 미적 선호가 아니라 사실에 근거한 변경 이유입니다. 이것은 종종 리디자인을 시작하는 가장 부드러운 방법입니다: 사이트가 못생겼다고 말하는 것이 아니라 한 가지 작업이 수행되지 않고 있다고 말하는 것입니다.

이는 또한 전환에 해를 끼치는 사랑받는 홈페이지 요소를 유지하려는 고객의 흔한 실수로부터 당신을 보호합니다. 진단은 “그 요소는 다섯 가지 작업 중 어떤 것도 수행하지 않습니다”라고 말할 수 있는 어휘를 제공하고, 고객은 증거를 볼 수 있습니다. 반대 의견은 더 이상 취향의 문제가 아닙니다.

진단이 곧 제품입니다

반복성은 모든 고객을 동일한 템플릿에 맞추는 것이 아닙니다. 각 고객의 고유한 특성을 표면화하는 표준 프로세스를 실행하는 것입니다. 5가지 작업 진단은 2시간 미만이 소요되며 팀에 공통 언어를 제공하고 고객에게 명확한 결정 목록을 제공합니다. 일관된 진단을 약속할 수 있는 에이전시는 일주일 안에 고객을 확보하고 한 달 안에 인도할 수 있습니다. 작업이 더 쉬워서가 아니라 디스커버리가 예측 가능하기 때문입니다. 그리고 고객이 왜 그렇게 많은 질문을 해야 하는지 묻는다면 답은 간단합니다: 오디션을 보는 것이 아니라 진단을 하는 것입니다.

기능 쇼케이스와 가격 페이지가 어떻게 함께 작동해야 하는지, 그리고 그 주변의 신화가 왜 지속되는지에 대한 더 깊은 내용은 이 신화를 깨는 가이드를 참조하세요.