디지털 제품 전달을 위한 반복 가능한 플레이북

Summary

대부분의 디지털 제품 조언은 일회성 출시를 가정하는데, 여러 고객을 위해 동일한 작업을 반복해야 할 때는 쓸모가 없습니다. 이 글은 제품이 전략이 아니라 전달이 전략이라고 주장합니다. 전달 사양을 표준화하고, 결제 시점을 자동화하고, 지원과 환불을 인간적으로 유지하는 방법을 배우게 됩니다. 또한 고객이 맞춤 포털을 요청할 때 어떻게 반대할지, 제품 유형에 따라 가격을 책정하는 방법, 그리고 프로세스가 실제로 작동하는지 증명하는 세 가지 숫자가 무엇인지도 다룹니다. 목표는 고객과의 접촉에서 살아남는 반복 가능한 시스템이지, 교묘한 마케팅 퍼널이 아닙니다. 끝까지 읽으면 내일 무엇을 해야 할지 정확히 알게 될 것입니다: 사양을 작성하세요.

디지털 제품 판매에 대한 대부분의 조언은 정확히 한 번만 할 사람을 위해 쓰여졌습니다. 플랫폼을 선택하고, 파일을 업로드하고, 이메일을 추가하고, 출시라고 부르세요. 두 번째 고객, 세 번째 고객을 위해 동일한 작업을 실행해야 하는 순간 그 조언은 무너집니다. 모든 사람을 위해 맞춤 설정을 할 여유가 없습니다. 반복 가능한 무언가를 구축해야 할 의무가 있습니다. 제품 자체는 거의 어려운 부분이 아닙니다. 전달이 어렵습니다. 그리고 전달은 창의적인 문제가 아니라 시스템 문제입니다.

MVST의 디지털 제품 비즈니스 모델 개요에 따르면 디지털 제품 시장은 2027년까지 8485억 달러에 달할 것으로 예상됩니다. 그 숫자가 얼마나 정확한지 저는 모릅니다. 여러분도 모를 것입니다. 그 숫자는 여러분이 파티에 늦었다고 느끼게 하기 위해 존재합니다. 무시하세요. 중요한 것은 파티가 충분히 커서 고객들이 계속 도움을 요청한다는 것이고, 모든 작업을 눈송이처럼 대한다면 일을 즐기기에는 너무 지칠 것입니다.

디지털 제품 조언에서 가장 큰 거짓말은 무엇인가요?

가장 큰 거짓말은 제품이 전략이라는 것입니다. 수익성 있는 틈새 시장을 찾고, 완벽한 강좌 개요를 설계하고, 일회성 구매와 구독 사이에서 선택하는 것에 대해 많이 듣게 될 것입니다. 그것들은 실제 결정이지만, 여러 고객에게 전달해야 하는 사람에게는 실제 병목 지점의 상류에 있습니다. 병목 지점은 인수인계입니다: 누군가 돈을 지불하고 실제로 구매한 것을 사용하는 사이에 일어나는 일입니다. 자동화된 시스템은 그 창을 몇 시간에서 몇 초로 줄일 수 있으며, 더 중요하게는 거래를 처리해야 하는 사람의 수를 줄일 수 있습니다.

따라서 실제 플레이는 한 고객의 제품에 빠지는 것이 아닙니다. 재설계 없이 재구성할 수 있는 전달 아키텍처를 구축하는 것입니다. 그것은 대부분의 디지털 제품 조언이 훈련하는 것과 다른 근육입니다. 제품이 아닌 제품 유형으로, 기능이 아닌 흐름으로 생각한다는 뜻입니다. 그렇게 프레임을 잡으면 다음 질문은 명확해집니다.

모든 고객이 다르지 않나요?

부분적으로는 그렇지만, 그들이 믿게 하려는 것보다는 덜 다릅니다. 강좌, 템플릿 팩, 소프트웨어 라이선스, 전자책은 파일, 가격, 고객이 다릅니다. 그러나 그들은 골격을 공유합니다: 구매, 수령, 접근, 지원. 이 골격에서 시작하면 뼈를 다시 만들지 않고도 세부 사항을 조정할 수 있습니다.

아래 표는 의도적으로 대략적입니다. 전략이 아니라 설계를 시작하기 전에 고객 요청을 분류하는 방법입니다.

고객 상황	실제로 중요한 것	노력을 투자할 곳
단일 파일(전자책, PDF, 템플릿 팩)	즉시 복구 가능한 다운로드	파일 저장소, 다운로드 페이지, 간단한 라이선스 안내
모듈 또는 드립 콘텐츠가 있는 강좌	접근 제어, 진행 상황 추적	로그인, 전달 일정, 이메일 알림
소프트웨어 또는 라이선스 키	키 생성 및 검증	자동화된 키 전달, 명확한 지원 경로
멤버십 또는 구독	반복 접근 및 결제	결제 통합, 취소 처리

고객이 자신이 어느 행에 해당하는지 말할 수 없다면 더 나은 플랫폼이 필요하지 않습니다. 더 나은 대화가 필요합니다.

고객마다 다른 플랫폼을 선택해야 하나요?

아니요. 그리고 그 말에 고개를 끄덕이고 있다면, 1년의 고통을 덜어드리겠습니다. 잘 알고 있는 기본 플랫폼이 매번 다시 배워야 하는 더 유연한 플랫폼보다 낫습니다. 고객은 어떤 플랫폼을 사용하는지 신경 쓰지 않습니다. 그들은 다운로드가 작동하는지 신경 씁니다. 기본 판매 환경을 하나 선택하고, 그 한계를 파악하고, 그 한계에 맞춰 전달 아키텍처를 설계하세요. 고객이 기본값으로 할 수 없는 것을 요청하면 그때가 맞춤 구축에 대해 이야기할 때입니다. 그 전에는 안 됩니다.

이것이 고객의 기존 설정을 무시해야 한다는 뜻은 아닙니다. 의견을 가져야 한다는 뜻입니다. 고객이 어떤 플랫폼을 "이미 사용 중"이고 다르게 작동한다고 말하면, 당신의 일은 그들의 상황을 기본값과 비교하는 것이지 그들을 위해 바퀴를 재발명하는 것이 아닙니다. 반복 가능한 프로세스는 기본값이 있는 프로세스입니다.

고객이 이미 스토어를 가지고 있다면?

그러면 사양이 바뀝니다. 처음부터 설계하는 것이 아니라 기존 흐름을 감사하는 것입니다. 네 가지 질문을 함께 살펴보세요: 고객이 무엇을 받는지, 언제, 어떻게, 그리고 실패 시 어떻게 되는지. 대부분의 기존 설정은 마지막 질문에서 실패합니다. "다운로드 링크가 만료되었습니다"에 대한 대비책이 없는 곳은 없습니다. 그것은 전체 스토어를 뜯어내지 않고도 가치를 더할 수 있는 기회입니다.

기존 설정을 신성하게 여기고 싶은 유혹이 있습니다. 저항하세요. 기존 스토어는 시작점일 뿐입니다. 전달 경로가 수동이라면 고객은 하루에 한 시간씩 파일을 손으로 보내고 있고, 당신은 해결책을 위해 돈을 지불받고 있습니다. 단계를 추가해도 해결되지 않습니다. 인수인계를 결제 시점으로 옮기면 해결됩니다.

프로세스가 실제로 반복 가능한지 어떻게 알 수 있나요?

적어 보세요. 10분 안에 계약자에게 프로세스를 설명할 수 없다면, 프로세스가 아니라 습관입니다. 반복 가능한 프로세스는 중간에 마음을 바꾸는 고객과의 접촉에서도 살아남고, 당신이 안 좋은 날에도 살아남습니다.

테스트는 간단합니다: 사양을 다른 사람에게 건네주고 같은 결과를 얻을 수 있습니까? 에이전시 맥락에서 그것은 일시적인 일과 서비스의 차이입니다. 서비스에는 명확한 경계가 있고, 그 경계가 스트레스를 더하지 않고 확장할 수 있게 해줍니다. 프로세스가 당신이 그 자리에 있어야만 한다면 반복 가능한 것이 아니라 그냥 신뢰할 수 있는 것입니다.

무엇을 먼저 표준화해야 하나요?

실제로 복사할 수 있는 것, 즉 전달 사양부터 시작하세요. 판매하는 각 제품 유형에 대해 고객이 무엇을 받는지, 언제 받는지, 어떻게 접근하는지, 어떻게 도움을 받는지 정의하는 한 페이지 문서입니다. 지루해 보입니다. 지루합니다. 바로 그 때문에 작동합니다.

플랫폼을 선택하기 전에 사양을 작성하세요. 그러면 모든 고객은 동일한 템플릿의 변형이 됩니다. "고객이 무엇을 받나요? PDF와 다운로드 링크. 언제? 즉시. 어떻게 접근하나요? 본인만 접근할 수 있는 페이지를 통해. 고장 나면? 티켓 양식." 이제 무엇을 구축할지 알게 되었고, 사양을 개발자, 계약자, 또는 미래의 자신에게 건네줄 수 있습니다. 이것을 재사용 가능한 산출물로 만드는 방법에 대해 모든 고객을 위한 전달 사양에서 더 자세히 썼지만, 오늘 필요한 버전은 위의 네 가지 질문일 뿐입니다.

실제로 무엇을 자동화해야 하나요?

결제 시점을 자동화하세요. 거래가 승인되는 즉시 고객은 파일, 링크, 라이선스 키 또는 잠금 해제 이메일을 받아야 합니다. 그 경로에 사람이 개입해서는 안 됩니다. 자동화 가이드는 이것이 "전달 시간을 몇 시간에서 몇 초로 줄인다"고 약속하기 좋아하는데, 이는 기술 브로셔처럼 들리지만, 이 경우 기술이 실제로 그렇게 합니다. 고객은 감동받고 싶어하지 않습니다. 그들은 구매를 원합니다.

그러나 고객 관계 전체를 자동화하지는 마세요. 인수인계는 자동화하고 대화는 인간적으로 유지할 수 있습니다. 그 구분은 구식이 되는 것에 관한 것이 아닙니다. 모든 지원 요청이 질문에 답하지 않는 자동 응답을 받는 상황을 피하는 것입니다. 고객이 인간에게 비용을 지불하고 싶지 않았기 때문입니다. 올바른 순서는 인수인계를 보이지 않게 만든 다음, 인간을 이용 가능하게 만드는 것입니다.

무엇을 수동으로 유지해야 하나요?

지원, 환불, 판단. 이것들은 자동화할 수 있을 것처럼 보이지만 절대 자동화해서는 안 되는 작업입니다. 적어도 실제 거래를 수십 건 보기 전에는요. 자동화된 흐름에 묻힌 환불 정책은 그것을 악용하는 방법을 아는 고객에게 선물입니다. 자동 응답기를 받는 불만은 벽처럼 느껴집니다.

이것이 주장의 반대론적 부분입니다: 모든 것을 자동화하라고 말하는 세상에서 당신의 경쟁 우위는 연락이 닿는 것입니다. 구매 후 1시간은 신뢰가 구축되거나 파괴되는 시간이며, 인간은 그 시간에 어떤 이메일 시퀀스보다 더 많은 일을 할 수 있습니다. 소프트웨어에 넘기고 싶다면 구매 후 1시간을 읽어보세요.

고객이 "그냥 팔게 해줘"라고 말하면 어디서 시작해야 하나요?

고객이 그런 말을 하면 설계에 뛰어들고 싶은 충동을 참으세요. 세 가지 질문을 하세요: 무엇을 판매하는지, 어떻게 전달하고 싶은지, 구매 후에 무슨 일이 일어나야 하는지. 그들이 대답할 수 없다면, 그들이 대답할 수 있을 때까지 플랫폼을 선택하지 마세요.

전형적인 예를 들어보겠습니다: 고객이 공예가를 위한 SVG 파일 세트를 가지고 있습니다. 그들은 그것을 팔고 싶지만 전달에 대해 전혀 모릅니다. 멤버십 포털, 모바일 앱, 드립 캠페인이 필요하지 않습니다. 체크아웃 페이지, 다운로드 링크, 구매자가 파일로 무엇을 할 수 있는지 명시하는 작은 페이지가 필요합니다. 그것을 구축한 다음 실제 구매로 테스트하세요. 그게 전부입니다.

모든 고객의 순서는 동일합니다: 제품 유형을 정의하고, 가장 간단한 이행 경로를 선택하고, 구매 후 경험을 매핑하고, 경로가 작동하는지 알려주는 지표 하나를 추가하세요. 간단한 제품의 경우 하루 안에 모두 할 수 있습니다. 플랫폼은 세부 사항입니다.

고객이 맞춤 포털, 멤버십 사이트, 모바일 앱을 원한다면?

여기서는 판매를 잃을 수도 있지만 정직해야 합니다. 맞춤 포털은 구축 비용이 많이 들고 유지 관리가 힘듭니다. 그것을 요청하는 고객은 종종 그것이 필요하지 않습니다. 전문가처럼 느껴질 변명이 필요한 것입니다. 당신의 일은 "원한다"를 "필요하다"로 번역하는 것입니다.

반복 가능한 아키텍처는 작동하다가 작동하지 않을 때가 있습니다. 제품이 실제로 진행 상황 추적이 있는 멤버십 시스템을 요구한다면, 자체 전달 사양이 있는 별도의 제품 유형으로 구축하세요. 그러나 고객이 PDF를 파는 것을 부끄러워해서 모바일 앱을 요청한다면, 다운로드가 즉시 이루어지고 콘텐츠가 좋을 때 PDF에 대해 불평한 고객은 없다는 것을 상기시키세요. 바퀴를 재발명하기 전에 반대하세요.

가격 책정은 어떻게 하나요?

가격 책정은 그 자체의 프로세스가 필요하며, 한 고객의 이상한 할인 습관이 당신의 전달 아키텍처를 오염시키게 두지 마세요. 그러나 전달 사양은 실제로 가격 논의를 형성합니다. 고객이 무엇을 받는지, 언제 받는지, 대비책이 무엇인지 알면 자신 있게 가격을 책정할 수 있고, "브랜드 자산"에 대한 이야기를 지어내지 않고도 고객에게 가격을 설명할 수 있습니다.

여러 고객에게 합리적인 가격을 유지하는 가장 쉬운 방법은 가격을 고객의 열정이 아닌 제품 유형에 연결하는 것입니다. 단일 파일 템플릿 팩은 전체 강좌와 다른 가격대를 가지며, 사양이 그 비교를 자연스럽게 만듭니다. 더 자세한 내용은 최대 이익을 위한 디지털 제품 가격 책정을 참조하세요.

트래픽과 마케팅은 어떻게 하나요?

여기서 대부분의 조언은 "소셜 미디어에 올리고 기도하세요"로 변질됩니다. 마케팅을 또 다른 반복 가능한 시스템으로 취급하면 더 잘할 수 있습니다: 결과를 설명하는 제품 설명, 샘플이나 티저, 출시 전에 이메일 주소를 수집하는 간단한 방법. 바이럴 퍼널이 필요하지 않습니다. 예측 가능한 퍼널이 필요합니다.

함정은 각 고객의 "브랜드 목소리"가 완전히 새로운 마케팅 프로세스를 정당화하도록 두는 것입니다. 단계를 바꾸지 않고 톤을 조정할 수 있습니다. 단계는 다음과 같습니다: 문제를 보여주고, 해결책을 보여주고, 증거를 보여주고, 판매를 요청하세요. 전자책, 강좌, SVG 파일 세트에 모두 작동합니다. 극적이지 않으며, 브랜드가 어떻게 들려야 할지 모르는 고객과의 접촉에서도 살아남습니다.

컨설턴트처럼 들리지 않고 이것을 고객에게 어떻게 제시하나요?

프로세스를 프로세스로 제시하지 마세요. 그들이 받는 것으로 제시하세요: 제품을 고객에게 자동으로 전달하는 스토어프론트, 고객의 주말을 잡아먹지 않는 지원 경로, 개발자가 필요 없는 출시. "전달 사양"으로 시작하면 그들을 잃을 것입니다. "고객이 지불한 것을 즉시 받을 것입니다"로 시작하면 잃지 않을 것입니다.

보너스는 반복 가능한 프로세스가 방어 가능한 범위를 제공한다는 것입니다. 고객이 사양 밖의 것을 요청하면 "그것은 별도의 제품 유형입니다"라고 말할 수 있습니다. "그것은 많은 추가 작업입니다" 대신에요. 후자는 변명처럼 들립니다. 전자는 전문적인 경계처럼 들립니다. 둘 다 아니오라고 말하지만, 하나는 관계를 유지합니다.

고객에게 아직 제품이 없다면?

그러면 전달 프로젝트가 아니라 제품 개발 프로젝트를 하는 것입니다. 시작하기 전에 차이점을 분명히 하세요. "강좌를 만들어 드리겠습니다"라고 말하고 싶지만, 구매자가 얻는 결과를 고객이 말할 수 없다면 존재하지 않는 콘텐츠를 위한 플랫폼을 구축하게 될 것입니다.

그 경우에도 첫 번째 단계는 여전히 사양입니다. 그러나 사양은 전달만이 아니라 제품을 설명합니다. 구매자는 누구인가요? 어떤 문제가 있나요? 구매 후 무엇을 할 수 있게 되나요? 그 답이 존재하면 전달 아키텍처는 다른 제품 유형과 동일합니다. 제품이 없다는 것이 전달을 과도하게 복잡하게 만드는 변명이 되지 않도록 하세요.

무엇을 측정해야 하나요?

인수인계를 측정하세요. 구체적으로, 결제와 고객이 유용한 것을 갖는 사이의 시간, 구매 대비 성공적인 다운로드 비율, 환불 요청의 비율을 측정하세요. 이 세 가지 숫자는 전달 시스템이 건강한지 알려줍니다. 페이지 조회수, 노출수 또는 "참여도"에 주의를 빼앗기지 마세요. 아무도 읽지 않는 보고서를 만들기 위해 돈을 받는 경우가 아니라면요.

인수인계 시간이 지속적으로 짧으면 환불이 줄어들고 지원 티켓이 덜 이상해집니다. 그것은 통계 더미가 아니라 사람들이 지불한 것을 얻을 때 일어나는 일입니다. 대시보드가 필요하지 않습니다. 인수인계를 주시하면 됩니다.

내일 꼭 해야 할 한 가지는 무엇인가요?

전달 사양을 작성하세요. 내일이 아니라 오늘 오후에요. 다음에 팔 가능성이 가장 높은 제품 유형을 선택하고, 빈 문서를 열고, 네 가지 질문에 답하세요: 무엇을, 언제, 어떻게, 그리고 고장 나면 어떻게. 그 하나의 산출물은 어떤 새로운 플랫폼 기능보다 가치가 있습니다.

디지털 제품 조언의 다른 모든 것은 대부분 소음입니다. 시장은 크고, 과대광고는 시끄럽고, 도구는 분기마다 이름이 바뀝니다. 살아남는 것은 "클라이언트 X가 물건을 팔고 싶어 한다"를 이미 생각해 둔 반복 가능한 답으로 바꾸는 프로세스입니다. 그것을 한 번 구축하면 시간을 파는 것을 멈추고 시스템을 팔기 시작합니다.