다중 공급업체 마켓플레이스를 위한 SKU 관리: 실용 가이드

몇 달 이상 전자상거래에서 일한 사람이라면 누구나 SKU 문제를 겪어본 적이 있습니다. 같은 코드의 두 제품. 6개월 후에는 아무 의미가 없는 코드. 실제로 어떤 SKU가 발송되었는지 아무도 모를 때, 해결하는 데 20분이 걸리는 지원 티켓.

단일 브랜드 매장에서는 이것이 짜증스럽습니다. 수십 또는 수백 개의 공급업체가 각자 자신의 제품 데이터를 생성하는 다중 공급업체 마켓플레이스에서는 새로운 공급업체가 합류할 때마다 커지는 구조적 위험입니다.

SKU와 UPC: 실제 문제를 초래하는 혼란

이 두 용어는 서로 바꿔 사용되며, 이는 단순한 기술적인 문제가 아닌 진정한 실수입니다.

SKU(재고 관리 단위)는 특정 제품 변형을 추적하기 위해 귀사가 생성한 내부 코드로, 귀사와 귀사의 공급업체에게만 의미가 있는 시스템입니다. 이는 귀하의 시장 외부 사람들에게는 의미가 없습니다. UPC(범용 제품 코드)는 제품에 할당된 외부 표준 바코드로, 이를 스캔하는 어떤 소매업체나 시스템에서도 인식될 수 있도록 합니다.

여기서 실질적인 차이가 중요합니다: 마켓플레이스는 자신의 SKU 구조를 완전히 제어할 수 있으며 그렇게 해야 합니다. SKU는 내부적인 것이기 때문입니다. UPC는 당신이 고안하는 것이 아니라 발급되는 것이며, 실제 제품에 인쇄된 것과 일관성을 유지해야 합니다. 이를 같은 것으로 취급하면 중복 목록, 재고 동기화 문제, 원래 주문에 다시 맞출 수 없는 반품으로 이어집니다.

마켓플레이스에서 SKU 관리가 다른 문제인 이유는 다음과 같습니다.

단일 브랜드 매장은 오직 하나의 SKU 시스템, 즉 자기 시스템만을 시행하면 됩니다. 제품 데이터를 입력하는 모든 직원들은 동일한 비즈니스를 위해 일하며, 그들이 따르는 규칙이 문서화되었든 아니든 동일한 규칙 아래에 있습니다.

마켓플레이스는 이를 뒤집습니다. 각 공급업체는 자신의 습관, 자신의 스프레드시트를 가지고 오며, 때로는 다른 곳에서 운영 중인 상점에서의 기존 SKU 시스템을 가지고 오기도 합니다. 온보딩 과정에서 공유된 구조가 정해지지 않으면, 공급업체 수만큼 다양한 SKU 논리가 생겨나고, 이를 통해 검색, 보고 또는 조정할 신뢰할 수 있는 방법이 없어지게 됩니다.

이것이 바로 SKU 관리가 시장에서 별도의 신중한 계획을 필요로 하는 이유입니다. 단순히 공급업체들이 알아서 해결할 것이라고 가정해서는 안 됩니다.

우수한 SKU 구조는 실제로 어떻게 생겼는가?

모든 공급업체에 적용되는 일관된 명명 규칙.

작동 가능한 구조는 일반적으로 공급업체, 카테고리, 변형을 코드 자체에 인코딩합니다. 예를 들어:VEND-CAT-색상-사이즈형태는 그리 중요하지 않지만 모든 공급업체가 동일한 형식을 따르는 것이 중요합니다.

플랫폼 수준에서 고유성이 보장되며, 신뢰에 맡겨지지 않습니다.

마켓플레이스 자체가 이미 사용 중인 SKU를 거부해야 하며, 판매자가 제품을 나열하기 전에 충돌 여부를 스스로 확인하도록 의존해서는 안 됩니다.

시작하지 않고도 확장할 수 있는 공간.

10개의 공급업체와 200개의 제품을 위한 명명 규칙은 100개의 공급업체와 20,000개의 제품에서도 여전히 의미가 있어야 하며, 중간에 전체 명명 프로젝트를 필요로 하지 않아야 합니다.

SKU와 모든 외부 코드 간의 명확한 구분.

UPC, 바코드 및 제조업체 부품 번호는 SKU와 함께 저장할 수 있지만, 항상 사용 가능한 것이 아니고, 항상 컨텍스트에 따라 고유하지 않으며, 시장의 통제 하에 있지 않기 때문에 SKU 자체로 사용해서는 안 됩니다.

이것을 실제로 수정하고 유지하는 방법: 단계별로

1. 첫 번째 공급업체를 온보딩하기 전에 SKU 형식을 정의하세요.

• SKU에 입력할 항목을 결정하세요: 공급업체 식별자, 카테고리 및 변형이 가장 일반적입니다.
• 판매자가 추측하지 않고 따를 수 있는 간단한 규칙으로 형식을 작성하세요.
• 이것은 각 공급업체가 자신만의 방식으로 해석할 수 있는 제안이 아니라, 플랫폼 전반에 적용되는 정책으로 간주하십시오.

2. 온보딩 및 리스트 흐름에 고유성 확인 기능 추가하기

• Shipturtle의 제품 구성구조화된 필드와 유효성 검사를 지원하여 목록이 공개되기 전에 중복 SKU를 감지할 수 있도록 합니다.
• 플랫폼의 다른 곳에 이미 존재하는 SKU는 단순히 플래그를 설정하는 것이 아니라 거부해야 합니다.
• 이를 자동화하여 수동 검토 단계가 필요 없도록 하십시오.

3. 기존 공급업체를 새로운 구조로 신중하게 이전하기

• 자신만의 SKU 시스템을 이미 갖춘 판매자들은 명확한 이유와 간단한 방법이 없이는 자발적으로 전환하지 않을 것입니다.
• 제품별로 수동으로 재입력하기를 기대하기보다는 대량 리매핑 도구를 제공하거나 짧은 마이그레이션 기간을 제공하세요.
• 변경 사항을 시행하기 전에 전달해야 하며, 공급업체가 이전 SKU가 더 이상 작동하지 않는 것을 발견한 후에가 아닌.

4. SKU 필드를 UPC 및 바코드 필드와 명확하게 분리하십시오.

• 판매자에게 SKU 필드와 별도로 UPC 또는 제조사 코드를 위한 고유 필드를 제공하세요.
• 바코드 스캔 및 제품 인식을 위해 UPC를 사용하고, 내부 추적 및 보고를 위해 SKU를 사용하세요.
• 이 두 필드를 교환 가능하다고 취급하는 어떤 나열 흐름도 피하세요. 그곳이 바로 혼란이 시작되는 부분입니다.

5. 정기적인 일정에 따라 중복 및 불일치 감사 수행

• 일회성 청소는 새로운 공급업체와 제품이 지속적으로 추가되기 때문에 깨끗하게 유지되지 않습니다.
• 대부분의 마켓플레이스에서는 매월 정기 점검을 설정하는 것이 합리적이며, 이를 통해 문제가 실제 지원 부담이 되기 전에 조기 발견할 수 있습니다.
• 증가하는 SKU 관련 지원 티켓을 개별 티켓을 닫는 것뿐만 아니라 현재 구조를 재검토해야 하는 조기 신호로 간주하세요.

6. SKU 품질을 공급업체 온보딩 교육에 연결하기

• 새 공급업체는 온보딩 과정에서 SKU 형식 요건을 확인해야 하며, 첫 번째 목록이 거부된 후에 이를 알게 되어서는 안 됩니다.
• 짧고 구체적인 예시가 단순한 서면 정책보다 더 효과적이다.
• 이유를 이해하는 판매자들은 더 빠른 검색, 더 적은 분쟁, 더 깔끔한 보고를 가지고 있기 때문에 단순히 규칙을 따르라고 지시받은 판매자들보다 더 기꺼이 준수하는 경향이 있습니다.

이런 실수를 저질렀을 때 드는 비용을 무엇이 좌우합니까?

사후에 SKU 혼란을 정리하는 것은 이를 예방하는 것보다 훨씬 더 많은 비용이 듭니다. 수천 개의 일관성이 없거나 중복되거나 의미 없는 SKU가 있는 마켓플레이스는 제품 재매핑, 과거 주문 업데이트, 이미 손상된 시스템에 대한 습관을 형성한 공급업체 재교육을 포함하는 실제 데이터 마이그레이션 프로젝트에 직면합니다.

코드 없이 시장에 내놓는 앱은 시작점을 상당히 변화시킵니다. 왜냐하면 구조화된 SKU 필드와 유일성 검증이 문제를 인식한 후에 처음부터 만들어지는 것이 아니라 기본 기능으로 이미 존재하기 때문입니다.Shipturtle의 기능 세트에 포함된 내용을 확인하세요.그리고현재 가격 확인하세요.정확한 숫자에 대해.

프로젝트가 마이그레이션으로 발전하기 전에 이 문제를 해결하세요.

청결한 SKU 구조는 수백 개의 공급업체가 이미 자신의 습관을 만들어놓은 후에 수정하는 것보다 처음부터 시행하는 것이 훨씬 쉽습니다. 이를 초기에 올바르게 설정하는 비용은 정책 결정입니다. 늦게 수정하는 비용은 데이터 프로젝트입니다.

데모 예약하기Shipturtle이 SKU 구조를 어떻게 적용하고 나열 지점에서 중복을 방지하는지 확인하기 위해. 또는전체 기능 세트를 탐색하다시작하기 전에 내장된 기능을 확인하세요.