マルチベンダーマーケットプレイスのSKU管理：実践ガイド

数ヶ月以上eコマースで働いている誰もがSKUの問題に直面したことがあるでしょう。同じコードを持つ2つの商品。6ヶ月後には意味がないコード。実際に出荷されたSKUがどれか誰も分からないため、解決に20分かかるサポートチケット。

単一ブランドの店舗では、これは迷惑です。数十または数百のベンダーがそれぞれ独自の製品データを作成しているマルチベンダー市場では、新しいベンダーが参加するごとに累積する構造的リスクとなります。

SKUとUPC：実際の問題を引き起こす混乱

これら二つの用語は互換的に使われることがあり、それは単なる技術的なことではなく、実際の誤りです。

SKU（ストックキーピングユニット）は、特定の製品バリアントを追跡するためにあなたのビジネスが作成する内部コードであり、あなたやあなたのベンダーにとって意味のある独自のシステムです。他のマーケットプレイスの外部の人には意味がありません。一方、UPC（ユニバーサルプロダクトコード）は、製品に割り当てられた外部の標準化されたバーコードであり、スキャンする任意の小売業者やシステムで認識できるようになっています。

ここで重要なのは、実際的な違いです：マーケットプレイスはその内部のSKU構造を完全に制御できるし、制御すべきです。UPCはあなたが考案するものではなく、発行されるものであり、実際の製品に印刷されているものと一貫性を保たなければなりません。これらを同じものとして扱うと、重複リスティング、在庫の同期の問題、そして元の注文に戻せない返品が直接的に発生します。

マーケットプレイスでのSKU管理が異なる問題である理由

単一ブランドの店舗は、自社のSKUシステムのみを適用する必要があります。製品データに入力するすべての人は、書かれているかどうかに関わらず、同じルールの下で同じビジネスのために働いています。

マーケットプレイスはこれをひっくり返します。すべてのベンダーは独自の習慣やスプレッドシート、時には他の店舗で既に運営しているSKUシステムを持って到着します。オンボーディング時に共通の構造が課せられないと、ベンダーの数だけ異なるSKUロジックが存在することになり、それらを横断的に検索、報告、調整する信頼性のある方法がなくなります。

これがまさに、SKU管理がマーケットプレイスにおいて意図的な計画を必要とする理由です。単にベンダーが自分で何とかするだろうと想定するべき詳細ではありません。

良いSKU構造はどのようなものか？

すべてのベンダーに適用される一貫した命名規則。

実用的な構造は、通常、ベンダー、カテゴリー、バリアントをコード自体にエンコードします。具体的には、以下のような形式です。VEND-CAT-COLOR-SIZE形式の正確さよりも、すべてのベンダーが同じ形式に従うことが重要です。

プラットフォームレベルでのユニーク性が強制され、信頼に任されていません。

マーケットプレイス自体が、すでに使用されているSKUを拒否すべきであり、ベンダーが製品をリストする前に自分で競合を確認することに依存すべきではありません。

やり直すことなくスケールする余地がある。

10のベンダーと200の製品のために構築された命名規則は、途中でフルリネーミングプロジェクトを必要とせず、100のベンダーと20,000の製品でも意味を持ち続けるべきです。

SKUと外部コードの間に明確な区別を設ける。

UPCやバーコード、メーカー品番はすべてSKUと一緒に保存できますが、それらをSKU自体として使用すべきではありません。なぜなら、それらは常に利用可能とは限らず、文脈によって一意でないこともあり、市場が管理できるものではないからです。

実際にこれを修理し、維持する方法：ステップバイステップ

1. 最初のベンダーをオンボーディングする前に、SKUフォーマットを定義してください。

• SKUにエンコードする内容を決定します: ベンダー識別子、カテゴリ、バリアントが最も一般的です。
• ベンダーが推測せずに従えるように、フォーマットを短くシンプルなルールとして書き留めてください。
• これは各_vendor が独自の解釈をすることのできる提案ではなく、プラットフォーム全体の方針として扱ってください。

2. オンボーディングとリスティングフローにユニークネスチェックを組み込む

• Shipturtleの製品設定リストが公開される前に、重複SKUをキャッチするために必要な構造化フィールドとバリデーションをサポートしています。
• プラットフォームの他の場所に既に存在するSKUを単にフラグ付けするのではなく、却下してください。
• これを自動化し、誰かが実行することを覚えておく必要がない手動レビューのステップにしないでください。

3. 既存のベンダーを新しい構造に慎重に移行する

• 独自のSKUシステムを持っているベンダーは、明確な理由と簡単な移行方法がない限り、自発的には切り替えないでしょう。
• バルクリマッピングツールを提供するか、各製品を手動で再入力することを期待するのではなく、短い移行ウィンドウを設けてください。
• 施行する前に変更を通知し、ベンダーが古いSKUがもはや機能しないことを発見してからではなく、前もって知らせてください。

4. SKUフィールドをUPCおよびバーコードフィールドから明示的に分離する

• ベンダーにSKUフィールドとは別にUPCまたは製造者コード用の明確なフィールドを提供してください。
• バーコードスキャンと商品の認識にはUPCを使用し、内部追跡と報告にはSKUを使用してください。
• これらの2つのフィールドを相互に置き換え可能と見なすリストの流れを避けてください。そこがまさに混乱の始まりです。

5. 定期的に重複や不整合を監査する

• 一度きりのクリーンアップでは綺麗さが保たれず、新しいベンダーや新しい製品が継続的に追加されていきます。
• 定期的なチェックを設定してください。月次はほとんどのマーケットプレイスにとって合理的です。ドリフトが実際のサポートの負担になる前にキャッチします。
• SKU関連のサポートチケットの増加は、単に個別のチケットを解決するのではなく、現在の構造を再検討する必要があるという早期のシグナルと捉えるべきです。

6. SKUの品質をベンダーオンボーディングトレーニングに関連付ける

• 新しいベンダーはオンボーディング中にSKU形式の要件を確認すべきであり、最初のリストが拒否された後にそれを発見するべきではありません。
• 短く具体的な例は、書面のポリシーだけよりも効果的です。
• 理由を理解しているベンダーは、より迅速な検索、より少ない争い、よりクリーンなレポートを提供する傾向があり、単にルールに従うように言われたベンダーよりも、より喜んで従うことが多いです。

この誤りを犯すことで発生するコストの要因は何ですか？

事後にSKUの混乱を整理することは、予防するよりもはるかに多くのコストがかかります。何千もの不一致や重複、無意味なSKUを抱えるマーケットプレイスは、遡って修正するための本格的なデータ移行プロジェクトに直面し、製品の再マッピング、過去の注文の更新、既に壊れたシステムに対して習慣を築いてしまったベンダーの再訓練を行わなければなりません。

ノーコードのマーケットプレイスアプリは、構造化されたSKUフィールドやユニークネスバリデーションが問題が既に明らかになった後にゼロから構築されるのではなく、組み込み機能として既に存在するため、出発点を大幅に変更します。Shipturtleの機能セットに含まれているものを確認してください。と現在の価格を確認してください。正確な数値について。

移行プロジェクトになる前にこれを修正してください。

クリーンなSKU構造は、数百のベンダーがそれぞれ独自の習慣を持つようになってから後付けするよりも、初日から実施する方がはるかに簡単です。これを早期に正しくするためのコストは、政策的な決定です。遅れて修正するコストは、データプロジェクトになります。

デモを予約するShipturtleがSKU構造をどのように強制し、リスティングの時点で重複を防ぐかを見るためです。あるいは全機能セットを探る始める前に、どんなものが組み込まれているのかを確認してください。