방어할 수 있는 스토어 플랫폼을 선택하세요

요약

대부분의 플랫폼 추천은 확신으로 포장된 추측입니다. 개인적인 선호가 아니라 모든 고객에게 적용되는 의사 결정 프로세스가 필요합니다. 이 가이드는 클라이언트가 플랫폼을 선택하게 두는 것부터 결제를 부차적인 문제로 취급하는 것까지, 스토어 구축을 실패로 이끄는 흔한 신화들을 분석합니다. 플랫폼 티어를 정의하고, 짧은 디스커버리를 실행하고, 결제 수수료와 입금 속도를 포함한 비용 모델을 구축하는 방법을 배우게 됩니다. 또한 표준화는 제품이 아닌 프로세스에 적용해야 한다는 경고도 얻을 수 있습니다. 목표는 다음 추천을 정당화할 수 있는 반복 가능한 프레임워크를 만드는 것입니다.

방금 새 스토어 프로젝트를 맡았다고 가정해 보세요. 클라이언트가 “어떤 플랫폼을 추천하시나요?”라고 묻습니다. 실제로 뭐라고 대답하시겠어요?

좋아하는 플랫폼을 대답했다면, 그것은 직감에 의존한 비즈니스 결정입니다. 그날 아침 찾은 비교 차트를 대답했다면, 다른 회사의 사업을 위해 쓰인 블로그에 결정을 위임한 것입니다. 클라이언트에게는 그들의 제품, 결제 현실, 현금 흐름에 맞는 플랫폼이 필요합니다. 당신에게는 다음 달, 그 다음 달에 문을 두드리는 모든 사람에게 적용되는 프로세스가 필요합니다.

대부분의 전자상거래 플랫폼 조언은 스토어 소유자를 위해 쓰여 있습니다. 이 글은 스토어를 구축해야 하고, 아키텍처에 관심 없는 클라이언트에게 선택을 정당화해야 하며, 원래 회의에 참석하지 않은 개발자에게 인수인계해야 하는 사람을 위해 쓰였습니다. 당신의 임무는 결정을 게을리 만들지 않으면서도 반복 가능하게 만드는 것입니다.

가장 빠른 방법은 대부분의 팀이 가지고 있는 가정을 공격하는 것입니다. 여기 그 신화들과 현실이 있습니다.

신화	현실
최고의 플랫폼이 하나 존재한다.	최선은 제품 복잡성, 결제 요구 사항, 스토어 운영자에 따라 달라진다.
클라이언트가 플랫폼을 선택한다.	당신이 디스커버리를 실행하고 방어 가능한 추천을 한다.
월 사용료가 가장 낮은 것이 이긴다.	총비용에는 결제 수수료, 앱, 유지보수, 그리고 당신의 시간이 포함된다.
아무 결제 게이트웨이나 작동한다.	게이트웨이 선택은 현금 흐름, 국제 판매, 지원 부하를 결정한다.
출시가 결승선이다.	출시는 측정과 반복의 시작이다.
모든 클라이언트를 위한 하나의 플랫폼.	제품이 아닌 프로세스를 표준화하라.

'최고의 플랫폼이 있다'는 위안이 되는 거짓말

원칙: 보편적으로 최고의 플랫폼은 존재하지 않습니다. 적합한 카테고리가 있을 뿐입니다. 대부분의 플랫폼 가이드는 인기도에 따라 옵션을 순위 매기고, 맨 위에 있는 것을 선택하라고 말합니다. 그 순위는 평균적인 독자에 맞춰져 있지만, 당신은 평균적인 클라이언트와 일하지 않습니다.

대신 이렇게 하세요. 클라이언트를 만나기 전에 스토어의 세 가지 티어를 정의하세요.

티어 1: 단순 스토어. 수십 개의 제품, 지역 배송, 구독 없음, 소규모 팀. 이 클라이언트들은 낮은 비용, 빠른 설정, 그리고 즉시 작동하는 결제 처리가 필요합니다. 이 카테고리에는 기술 경험이 없는 창업자에게 훌륭한 출발점으로 자주 언급되는 Square Online과 Ecwid 같은 초보자 친화적인 호스팅 옵션이 포함됩니다.

티어 2: 성장하는 판매자. 더 큰 카탈로그, 실질적인 마케팅 예산, 디자인 통제와 앱에 대한 욕구. 사용 용이성과 유연성의 균형을 잡아주는 플랫폼이 필요합니다. 이것은 경쟁이 치열한 중간 지점이며, 대부분의 클라이언트가 여기에 속할 것입니다.

티어 3: 복잡한 운영. 대규모 카탈로그, 구독, B2B 가격, 해외 확장, 또는 이미 WordPress에 익숙한 팀. 이 클라이언트들은 설정에 더 오래 걸리더라도 확장성과 커스터마이징이 필요합니다.

당신의 규칙: 클라이언트를 이해하기 전에 티어를 선택하지 마세요. 수십 개의 제품을 만드는 캔들 메이커에게 엔터프라이즈 카탈로그 시스템은 필요 없습니다. 구독 박스 회사에 지역 픽업용 플랫폼은 맞지 않습니다.

모든 후보를 무료 평가판으로 사용해 보세요. 마케팅 비디오가 아니라 제품 업로드 흐름을 테스트하세요. 실제 사진과 함께 실제 제품을 업로드하세요. 가격을 변경해 보세요. 주문을 환불해 보세요. 그 평가판에서 살아남는 플랫폼이 고려할 가치가 있습니다.

실제 사례: 지역 비누 제조사를 만났다고 가정해 보세요. 수십 개의 제품, 구독 없음, 농산물 직거래 장터에서 주문을 받고, 온라인 판매와 고객 픽업을 원합니다. 그것은 티어 1입니다. 통합 결제가 포함된 간단한 호스팅 플랫폼을 추천하세요. 앱은 건너뛰고, 지역 픽업을 활성화하고, 일주일 안에 출시하세요. 플랫폼을 판매한 것이 아니라 적합한 솔루션을 판매한 것입니다.

'클라이언트가 선택하게 두는 것'은 나중에 비용이 드는 지름길

원칙: 당신이 전문가입니다. 클라이언트는 이 결정을 내리고 싶지 않기 때문에 당신을 고용합니다. 클라이언트가 선택하게 두면, 그들의 선택을 이끈 동기(친구의 추천, 블로그 게시물, 마음에 드는 로고)를 물려받게 됩니다. 그것들은 비즈니스 요구 사항이 아닙니다.

플랫폼 이름을 말하기 전에 디스커버리를 실행하세요. 짧게 유지하되 필수로 만드세요. 카탈로그 규모, 제품 유형, 구독, 국제 배송, 현재 주문 관리, 콘텐츠를 업데이트하는 사람, 월 사용료 예산, 일정에 대해 물어보세요. 또한 일회성 구매, 정기 결제, 또는 둘 다를 어떻게 받을 계획인지도 물어보세요.

답변을 한 페이지 분량의 추천서로 만드세요. 한 페이지, 세 가지 옵션. 첫 번째는 당신의 선택입니다. 두 번째는 백업입니다. 세 번째는 현재 단계에서 피하라고 권하는 것입니다. 각각에 대해 한 문장씩 쓰세요: '이것이 맞는 이유는...' 그리고 '이것이 맞지 않는 이유는...'. 그런 다음 클라이언트가 승인하게 하세요. 이렇게 하면 결정을 도랑에 몰아넣지 않으면서도 클라이언트에게 결정의 주인 의식을 줄 수 있습니다.

방어할 수 있는 플랫폼 결정은 특정한 형태를 가집니다. 그것은 당신의 선호가 아니라 클라이언트의 제약을 언급합니다. 제품만이 아니라 티어를 언급합니다. 그리고 당신이 수용한 트레이드오프를 언급합니다. 예를 들어, 나중에 구독을 지원할 수 없는 더 단순한 플랫폼을 선택함으로써 클라이언트가 무엇을 포기하는지 알 수 있게 하는 것입니다. 방어 가능한 추천을 구성하는 데 도움이 필요하다면 방어 가능한 전자상거래 플랫폼 결정을 내리는 방법을 참조하세요.

'월 사용료가 가장 낮은 것'이 가장 저렴한 스토어는 아니다

원칙: 월 사용료는 인보이스에서 가장 흥미롭지 않은 숫자입니다. 총비용에는 결제 처리, 앱 구독, 유지보수, 그리고 당신의 설정 시간이 포함됩니다. 월 사용료가 저렴하지만 앱이 비싼 플랫폼은 기본 가격이 높아도 앱이 필요 없는 플랫폼보다 더 비쌀 수 있습니다.

결제 처리는 숨은 변수입니다. 결제 게이트웨이에 대한 연구는 일관되게 네 가지 요소를 지적합니다: 거래 수수료, 입금 속도, 국제 지원, 그리고 지원 품질. 입금 속도는 대부분의 사람들이 생각하는 것보다 더 중요합니다. 매주 공급업체에 비용을 지불하는 클라이언트는 빠른 지급이 필요합니다. 며칠이 걸리는 게이트웨이는 약간 더 높은 수수료보다 더 큰 고통을 안겨줍니다. 클라이언트가 모든 판매가 며칠 동안 보류되는 것을 지켜볼 때, 그들은 당신에게 전화합니다. 지급이 빠르게 도착하면 그러지 않습니다.

수수료 페이지를 계약서처럼 읽으세요. 환불 시 어떻게 되는지 물어보세요. 차지백에 대해 물어보세요. 클라이언트가 다른 국가의 고객을 받을 수 있는지, 환율 변환이 어떻게 되는지 물어보세요. 국내 판매에 저렴한 게이트웨이는 국제 판매에 치명적일 수 있습니다.

바로 이 지점에서 반복 가능한 프로세스가 빛을 발합니다. 각 플랫폼 티어에 대한 비용 템플릿을 만드세요. 기본 요금제, 일반적인 앱 비용, 평균 거래 수수료, 예상 설정 시간을 기록하세요. 템플릿을 분기마다 업데이트하세요. 그러면 다음 견적은 추측이 아닌 계산이 됩니다. 이런 종류의 표준화는 바로 에이전시 온보딩 시스템을 반복 가능하게 만드는 것이며, 비용 모델에도 동일한 규율을 적용하세요.

'결제는 부차적인 문제'는 스토어를 질식시킨다

원칙: 결제 게이트웨이는 기술적 세부 사항이 아니라 비즈니스 결정입니다. 그것은 클라이언트가 언제 돈을 받는지, 어떤 고객을 받을 수 있는지, 모든 판매에서 얼마를 유지하는지를 결정합니다.

결정을 플랫폼과 클라이언트의 현실에 연결하세요. 게이트웨이를 비즈니스에 맞추세요:

• 클라이언트가 오프라인과 온라인에서 모두 판매한다면, 재고와 결제를 한 곳에서 관리할 수 있는 통합 시스템을 찾으세요. 연구는 전자상거래 기능과 결제 처리를 결합한 초보자 친화적인 옵션으로 Square를 강조합니다.
• 클라이언트가 해외로 확장하거나 구독을 시작할 계획이라면, 강력한 API를 갖춘 개발자 친화적인 프로세서가 더 잘 맞습니다. Stripe는 글로벌 결제와 구독 지원으로 널리 인정받고 있습니다.
• 클라이언트의 구매자 중 카드가 덜 보편적인 지역에 있는 경우, 신뢰와 도달 범위를 위해 PayPal과 같이 널리 인정받는 전자지갑을 추가하세요.

이 결정을 개발자의 개인적 선호에 맡기지 마세요. 개발자는 최고의 API를 가진 프로세서를 선호할 수 있지만, 클라이언트는 가장 빠른 입금 속도를 필요로 할 수 있습니다. 두 옵션을 모두 테이블에 올리고 트레이드오프를 명시하세요.

비싼 실수는 마지막에 게이트웨이를 선택하는 것입니다. 체크아웃을 설계하고, 모든 것을 테스트한 다음, 게이트웨이가 클라이언트의 목표 국가를 지원하지 않는다는 것을 발견하게 됩니다. 재작업은 비쌉니다. 게이트웨이를 마지막 순간의 통합이 아니라 플랫폼 디스커버리의 일부로 만드세요.

'출시가 결승선'이라는 것은 스토어가 죽는 방식

원칙: 측정 계획 없이 출시하는 것은 스토어를 어둠 속에 던지는 것과 같습니다. 스토어의 일은 출시 후에 시작됩니다.

출시 전에 기본 사항을 갖추세요. 플랫폼과 호환되는 분석 도구를 설치하세요. 모바일 보기가 사용 가능한지 확인하세요. 구매자가 묻는 질문에 답하는 제품 설명을 작성하세요. 지침을 위해 제품 목록 팁을 키를 넘겨주기 전에 검토할 가치가 있습니다.

출시 후 처음 90일을 주기로 운영하세요. 첫 주: 체크아웃 마찰을 수정하세요. 사람들이 어디서 이탈하는지 관찰하세요. 모든 초기 고객에게 무엇이 혼란스러웠는지 물어보세요. 둘째 주: 트래픽이 어디서 오는지 파악하세요. 트래픽이 없다면 그게 문제입니다. 제품 페이지가 아니라요. 셋째 주: 어떤 제품이 잘 팔리는지 검토하세요. 그것을 카탈로그에 반영하세요.

온라인 비즈니스 시작에 대한 연구는 계속해서 같은 조언으로 귀결됩니다: 작게 시작하고, 테스트하고, 측정하고, 개선하세요. 첫 달에 대규모 재설계된 스토어를 계획하지 마세요. 매주 하나의 작은 개선을 계획하세요. 그 주기가 스토어가 살아남기 위해 필요한 피드백 루프를 만듭니다.

'모든 것을 표준화하라'는 함정

원칙: 표준화는 플랫폼이 아니라 프로세스에 관한 것입니다. 모든 클라이언트를 하나의 플랫폼에 강제로 넣으면, 작업 흐름을 편하게 하기 위해 맞지 않는 선택을 하게 될 것입니다. 그러면 플랫폼이 클라이언트의 요구를 충족하도록 만드는 데 추가 시간을 쓰게 되고, 클라이언트는 당신의 경직된 태도에 비용을 지불하게 됩니다.

현실은 다양합니다. 당신이 통제하는 레이어를 표준화하세요: 디스커버리 설문지, 플랫폼 추천 템플릿, 설정 체크리스트, QA 체크리스트, 출시 후 검토 일정. 두세 개의 플랫폼 티어를 유지하고, 클라이언트가 실제로 그 밖의 것을 필요로 할 때 문서화된 예외 경로를 허용하세요. 예외 경로는 짧은 문단입니다: 이 클라이언트가 왜 다른지, 추가 비용은 얼마인지, 누가 승인하는지.

이것이 역설적인 부분입니다. 많은 에이전시 팀은 '효율적으로'라는 말을 듣고 단일 워크플로우를 구축하는 것으로 대응합니다. 하나의 플랫폼이 모든 카탈로그 규모, 모든 결제 모델, 모든 팀의 기술 수준을 처리할 수 있다고 스스로 믿게 됩니다. 그 믿음은 클라이언트가 반증하기 전까지는 편리합니다. 좁은 프로세스를 반복 가능한 것과 혼동하지 마세요. 분기 규칙이 있는 유연한 플레이북은 첫 번째 예외에서 실패하는 스크립트보다 더 반복 가능합니다.

하나의 플랫폼이 모든 클라이언트에게 맞지는 않습니다. 이를 받아들이고 일률적인 규칙 대신 계층화된 프로세스를 구축하는 팀은 현실과 싸우지 않기 때문에 반복 가능성에서 승리합니다.

이번 주에 프레임워크를 구축하세요

이제 각 신화에 대한 수정 사항이 있습니다. 그것을 실행으로 옮기세요.

디스커버리 설문지를 작성하세요. 인쇄하세요. 다음 클라이언트 통화에서 사용하세요.

플랫폼 티어를 정의하세요. 각 티어에 대해 한 문단씩 작성하고, 어떤 종류의 클라이언트에 맞는지와 수용하는 트레이드오프를 명시하세요.

한 페이지 분량의 추천 템플릿을 만드세요. 다음 플랫폼 제안에 사용하세요.

결제 게이트웨이에 대한 규칙을 설정하세요. API 선호도가 아니라 클라이언트의 결제 현실에 게이트웨이를 맞추세요.

출시 후 일정을 선택하세요. 90일 동안 매주 하나의 개선을 약속하세요.

그런 다음 새 클라이언트 세 명에게 프로세스를 실행하세요. 각각 후에 조정하세요. 프레임워크는 최종 답변이 아니라 개선하는 대상입니다. 그것이 잘 추측하는 팀과 모든 전달에서 더 나아지는 팀의 차이입니다.