매장 요구사항에서 시작하세요
커스텀 스토어프런트는 전달 방식의 선택이지, 그 자체가 목표는 아닙니다. 비즈니스가 현재 달성할 수 없는 동작을 적어 보세요: 제품 구성기, 에디토리얼 구매 여정, 고객 포털 또는 백오피스 시스템과의 통합. 그런 다음 테마 변경이나 집중된 앱으로 이를 충족할 수 있는지 확인하세요.
헤드리스 Shopify는 고객 대면 스토어프런트를 커머스 백엔드와 분리합니다. Shopify는 이 접근 방식을 위해 Storefront API와 Hydrogen 도구를 제공합니다. 이러한 유연성은 또한 팀이 스토어프런트 애플리케이션을 유지보수해야 함을 의미합니다. 이것이 결제나 플랜 제한을 자동으로 제거하지는 않습니다. 검토하세요 Shopify의 헤드리스 문서 를 대상 범위의 기능 및 플랜과 비교하여.
세 가지 범위를 비교하세요
- 테마 작업: 기존 매장에 맞는 머천다이징, 콘텐츠, 내비게이션, 레이아웃 변경. 또 다른 런타임을 도입하기 전에 기존 앱과 테마 성능을 평가하세요.
- 통합 작업: Shopify와 다른 비즈니스 시스템 사이를 오가는 재고, 주문, 고객 기록 또는 주문 처리. 이러한 많은 워크플로는 현재 스토어프런트를 유지할 수 있습니다.
- 커스텀 스토어프런트: 별도의 애플리케이션 개발, 미리보기, 호스팅, 지속적인 유지보수를 정당화할 만큼 충분히 차별화된 고객 여정.
예시: 재고 및 주문 인계
어떤 도매업체가 주문을 자사 주문 처리 시스템으로 복사하고 재고 수준을 매장으로 반환해야 한다고 가정해 보세요. 첫 번째 산출물은 제품 식별자, 재고 소유권, 주문 상태의 매핑이어야 합니다. 주문이 편집, 취소 또는 두 번 처리될 때 어떤 일이 일어나는지, 그리고 직원이 실패한 전송을 어떻게 조정하는지 정의하세요. 스토어프런트를 교체하는 것만으로는 이러한 문제가 해결되지 않습니다.
준비할 사항
매장 URL, 현재 테마 및 앱 목록, 대상 시장, 카탈로그 예시, 관련된 시스템을 가져오세요. 가능한 경우 샌드박스 접근 권한과 재고 및 주문이 어떻게 동작해야 하는지 결정할 수 있는 비즈니스 담당자를 제공하세요. 최초 문의 시 실제 운영 자격 증명을 공유하지 마세요.
유용한 제안서는 고객 경험을 데이터 마이그레이션, 플랫폼 통합, 분석, 인수 테스트, 유지보수와 분리합니다. 제안서는 결제 제한 사항, 플랜 확인이 필요한 구독 또는 B2B 요구사항, 그리고 전달에 영향을 줄 수 있는 모든 서드파티 종속성을 식별해야 합니다.
WooCommerce의 경우, WordPress 호스팅, 플러그인 스택, 업그레이드 프로세스를 각각 따로 평가하세요. 이는 Shopify 구현과 서로 교체할 수 있는 것이 아닙니다. 참조하세요 Shopify 및 WooCommerce 개발 을 매장 기능에 대해, 그리고 API 통합 서비스 를 비즈니스 시스템 연결에 대해.
