エージェンシーがサプライチェーンを運営しようと決めることはまれです。しかし物理的な商品に触れるあらゆるクライアントのプログラムは、1つを引き込みます。本プレイブックは、複数のクライアントプログラムを単一の供給パートナーを通じて運営するエージェンシーのオペレーター向けです。何を共有し、何が分離されなければならないか、データと承認をどう統治するか、そしてあるクライアントのピークシーズンを別のクライアントの在庫切れにしない方法。
経済性が、モデルが存在する理由です。調達の連絡先リスト、検品のルーティン、フルフィルメントの統合、キャリアのアカウント構造は、それぞれ1度組むのに実際の資金がかかり、プログラムをまたいでの再利用はほぼ無コストです。しかしプログラムの規律のない共有インフラは、レバレッジの正反対を産みます。混ざったカートン、交差した出荷、アカウント間に漏れる機密の価格、そして11月の容量の争奪。以下のプレイブックは、その規律の層です。その拡張する段階の考えはDTCブランドのサプライチェーンプレイブックで扱っており、本記事は同じ問題のマルチクライアント版です。
なぜエージェンシーはサプライチェーンを継承するか
クライアントのストアを管理するエージェンシーは、いずれ、ストアが依存するものを直すよう求められます。立ち上げの途中で消えたサプライヤー、顧客がもう信じない配送レンジ、クライアントのレビューでトレンドになる品質のクレーム。断れば、エージェンシーの評価対象であるマーケティングの結果が、広告アカウントの外の理由で劣化するのを見ることになります。引き受ければ、エージェンシーは今や、サプライチェーンの一部を運営します。ほとんどのエージェンシーは、1クライアントずつ引き受け、チャットのスレッドと好意で繋がれた非公式のインフラを運営していることに気づきます。プレイブックの目的は、そのインフラが荷重を支えるものになる3〜4人目のクライアントの前に、意図的なものにすることです。
例示的な合成
構造を具体的にするため、例示的な合成を考えてください。4つのECのクライアントプログラムを運営するエージェンシー — 2つの初期のドロップシッピングのテスト、安定した日次ボリュームの倉庫在庫のブランド1つ、そして厳格な入庫ルールを持つマーケットプレイス中心のセラー1つ。プログラムは、1つの供給パートナー、1つの倉庫、1つの統合層を共有します。以下のどれも、実在のエージェンシーやクライアントを記述しません。分離のルール、統治、競合の仕組みこそが内容です。
インフラは共有し、プログラムは分離する
モデル全体は1つの区別の上に立ちます。インフラは共有、プログラムは分離。あらゆる運用の決定は、その線のどちらかの側に落ち、分類してしまえば不一致は扱いやすくなります。
| 決定 | プログラム間で共有 | プログラムごとに分離 |
|---|---|---|
| 物理ネットワーク | 倉庫、パックステーション、QCエリア、キャリアのアカウント | クライアントの在庫ゾーン、プログラムごとの入庫ラベリング |
| 商品の同一性 | 統合プラットフォーム、注文フロー、追跡ループ | プログラムの接頭辞付きSKUの命名、承認サンプル、仕様 |
| ブランド資産 | クライアントが共用を承認した場合のパッケージサプライヤー | ブランドパッケージ、同梱物、請求書、開梱コピー |
| 商業データ | 既定では無し | 価格、サプライヤー見積、マージン、ボリューム、予測 |
| サプライヤー関係 | 検証と監査のインフラ | 関係そのもの。書面で別に合意しない限り |
| 報告 | プログラム横断のエージェンシービュー | 自社プログラムのみに範囲づけられたクライアントのダッシュボード |
破られたとき最も損害が大きいのは最後の行です。エージェンシーが自社の商品調査、サプライヤーファイル、価格を、競合に近いブランドのために再利用したと知ったクライアントは、再交渉しません。去ります。そして他の創業者に、理由を語ります。
新しいクライアントプログラムのオンボーディング
反復可能な受入のシーケンスが、4つ目のプログラムを1つ目と同じきれいさに保ちます。
- プログラムの範囲を書面で。チャネル、目標市場、期待されるボリュームの帯、コンプライアンスの要件、そして誰がどの決定を所有するか。ここでの曖昧さは、その後のあらゆる紛争として再浮上します。
- サプライヤーと商品をクライアントごとに検証する。商品が同一に見えても、明示的な書面の許可なしに、あるクライアントのサプライヤーファイルや承認サンプルを別のプログラムへ再利用しない。
- 識別子を分離する。SKUの接頭辞、入庫カートンのラベリング、梱包基準、ブランド資産は、最初の注文の前に設定します。その途中で即興しません。
- プログラムごとのサービス水準を定義する。発送締め切り、同期の頻度、例外処理、再出荷の権限を、各プログラムのボリュームとチャネルの要求に合わせて設計。
- 報告のリズムを設定する。クライアントが見る週次のプログラム別スコアカードと、エージェンシーが内部で回す月次のプログラム横断レビュー。
- エスカレーションマップを合意する。誰が工場と話し、誰が再出荷を承認し、何かが壊れたとき誰がクライアントの会話を所有するか。役割ごとに1つの名前、書面で。
容量の競合とピークシーズン
1つの供給パートナーを共有することは、その有限の容量を共有することです。工場の生産枠、Q4の倉庫労働、キャリアの集荷。失敗形態は、静かな優先の転倒です — うるさいアカウントが労働を取り、静かなクライアントがダッシュボードの中で在庫切れを発見する。機能するプログラムは、季節の途中ではなく前に合意された、3つの書面のルールで競合を処理します。第1に、容量はプログラムごとに、事前予約されたピークのコミットメントで配分されます。11月の労働は、駆け回りではなく予約です。第2に、競合はメッセージの量ではなく、貢献と契約に従います。公平性のルールは書面で、まさに誰も圧力の下で即興しなくていいように。第3に、あるプログラムのサージは、発送が遅れうる他のプログラムへの通知をトリガーします。心地よくないニュースは劣化するのが早いからです。高ボリュームのセラーが自社プログラムのために使う同じ事前予約のロジック — 1日百注文を越える拡大のガイドで扱っています — は、複数の事業が1つのキューを共有するという追加の制約付きで、ここにも当てはまります。
報告、データ、機密性
3つのルールがデータ層をきれいに保ちます。クライアントのダッシュボードは自社のプログラムのみに範囲づけられます — 注文、発送パフォーマンス、在庫、例外 — プログラム横断の合計は見えません。エージェンシーの内部ビューは、容量と資金計画のためにプログラム間で集計します。そして商業データの既定は分離です。あるクライアントのために得たサプライヤーの価格は、書面の同意なしに別のクライアントの見積へ再利用されず、ある仕事の下で行われた商品調査はその仕事に留まります。供給パートナーが報告層を提供する場合、プログラムごとのアクセス制御は、要望ではなく選定基準であるべきです — 要求する価値のあるインフラのコミットメントはフルフィルメントサービスページに要約しています。
オンボーディング前のチェックリスト
共有構造へあらゆる新しいクライアントプログラムを受け入れる前に回してください。未チェックの行はどれも、後の紛争の既知の源です。
- 書面の範囲：チャネル、市場、ボリューム帯、コンプライアンスの義務、決定の所有。
- このプログラムのために特化して検証されたサプライヤー。検証は文書化済み。
- SKUの命名、入庫ラベリング、梱包基準をプログラムごとに設定。
- ブランド資産を受領し、プログラム範囲のフォルダに保管。
- プログラムごとのサービス水準を定義：締め切り、同期の頻度、例外処理、再出荷の権限。
- データ分離のルールをクライアント契約で確認。サプライヤーファイルの再利用を含む。
- ピーク容量の期待を表明し、書面で確保。
- エスカレーションマップに名前：工場の連絡先、再出荷の承認者、顧客向きのオーナー。
よくある質問
各クライアントに専用の供給パートナーを持つべきですか？+
プログラム数が少ないうちは、専用パートナーは単純ですが、実質的に高価で、立ち上げも遅いです。あらゆるパートナーが検証、統合、報告を組み立て直すからです。共有モデルがその複雑さを稼ぐのは、プログラムが増え始めたときです。2〜3未満では、単一の良く運営されたプログラムパートナーの方が、誠実に良い取引かもしれません。
あるクライアントのボリュームが別のクライアントを飢えさせるのをどう止めますか？+
事前に合意された割当でです。プログラムごとに事前予約されたピーク容量、書面の競合ルール、あるプログラムのサージが別の発送を脅かすときの通知の義務。仕組みよりも効くのは、その存在です — 書かれていない公平性のルールこそ、エージェンシーが静かなクライアントを失う方法です。
クライアントプログラム間で法的に共有できるものは何ですか？+
影響を受けるあらゆるクライアントが書面で合意したものだけです。インフラは、当然。既定では、ほぼ他に何も。サプライヤーファイル、価格、商品調査、ボリュームは、それに支払った仕事に属する商業データです。疑わしいなら許可を尋ねてください — それが防ぐ去留より安い。
プログラムが共有モデルを越えて成長するのはいつですか？+
あるプログラムのコンプライアンス要件が隔離を要求するとき、そのボリュームが長期にわたり共有容量を支配するとき、またはクライアントが専用インフラを契約条件として要求するときです。成長がプログラムを自前のインフラへ移すのは、成功の帰結であって、モデルの失敗ではありません。
