Agenturen beschließen selten, Lieferketten zu führen – und doch zieht jedes Kundenprogramm, das ein physisches Produkt berührt, eine hinein. Dieses Playbook richtet sich an Agentur-Operatoren, die mehrere Kundenprogramme über einen einzigen Versorgungspartner führen: was geteilt wird, was getrennt bleiben muss, wie Daten und Freigaben geregelt werden – und wie man verhindert, dass die Peak-Season eines Kunden zum Out-of-Stock des anderen wird.
Die Ökonomie ist der Grund, warum das Modell existiert. Eine Sourcing-Kontaktliste, eine Inspektionsroutine, eine Fulfillment-Integration und eine Carrier-Kontostruktur kosten je echtes Geld, einmal aufzubauen – und fast nichts, über Programme hinweg wiederzuverwenden. Aber geteilte Infrastruktur ohne Programmdisziplin erzeugt das Gegenteil von Hebel: gemischte Kartons, gekreuzte Sendungen, vertrauliche Preise, die zwischen Konten sickern, und Kapazitätskämpfe im November. Das Playbook unten ist die Disziplinschicht. Das gestufte Denken, das sie erweitert, behandelt das DTC-Marken-Lieferketten-Playbook; dieser Artikel ist die Multi-Client-Version desselben Problems.
Warum Agenturen Lieferketten erben
Eine Agentur, die den Store eines Kunden managt, wird irgendwann gebeten, das zu reparieren, wovon der Store abhängt: ein Lieferant, der mittendrin im Launch verschwand; eine Lieferzeit, an die die Kunden nicht mehr glauben; eine Qualitätsbeschwerde, die in den Bewertungen des Kunden Trend wird. Nein sagen bedeutet zuzusehen, wie die Marketingresultate, an denen die Agentur gemessen wird, aus Gründen außerhalb des Werbekontos degradieren. Ja sagen bedeutet, dass die Agentur nun einen Teil einer Lieferkette betreibt. Die meisten Agenturen sagen ein Kunde nach dem anderen ja – und wachen über eine informelle Infrastruktur auf, zusammengehalten von Chat-Fäden und Gefälligkeiten. Der Zweck des Playbooks ist, diese Infrastruktur bewusst zu machen, bevor der dritte oder vierte Kunde sie tragend macht.
Ein illustrierendes Komposit
Um die Strukturen konkret zu machen, betrachten Sie ein illustrierendes Komposit: eine Agentur, die vier E-Commerce-Kundenprogramme betreibt — zwei frühe Dropshipping-Tests, eine Marke mit Lagerbestand und stetigem Tagesvolumen, und ein marktplatzlastiger Verkäufer mit strengen Eingangsregeln. Die Programme teilen einen Versorgungspartner, ein Lager und eine Integrationsschicht. Nichts Untenstehendes beschreibt eine echte Agentur oder einen echten Kunden; die Trennungsregeln, die Governance und die Konkurrenzmechanik sind der Inhalt.
Infrastruktur teilen, Programme trennen
Das gesamte Modell ruht auf einer Unterscheidung: Infrastruktur wird geteilt, Programme werden getrennt. Jede operationale Entscheidung fällt auf eine Seite dieser Linie – und Meinungsverschiedenheiten werden einfacher, sobald man sie klassifiziert:
| Entscheidung | Über Programme geteilt | Je Programm getrennt |
|---|---|---|
| Physisches Netz | Lager, Packstationen, QC-Bereich, Carrier-Konten | Kundenbestandszonen, Eingangsetikettierung je Programm |
| Produktidentität | Integrationsplattform, Bestellflüsse, Tracking-Schleifen | SKU-Benennung mit Programmpräfixen, Referenzmuster, Spezifikationen |
| Markenassets | Verpackungslieferanten, wo Kunden die Mitnutzung freigeben | Gebrandete Verpackung, Beilagen, Rechnungen, Unboxing-Texte |
| Kommerzielle Daten | Nichts per Default | Preise, Lieferantenangebote, Margen, Volumen, Prognosen |
| Lieferantenbeziehungen | Verifizierungs- und Audit-Infrastruktur | Die Beziehungen selbst – es sei denn, ein Kunde stimmt schriftlich anders zu |
| Berichterstattung | Überprogramm-Sicht der Agentur | Kunden-Dashboards, beschränkt auf ihr eigenes Programm |
Die letzte Zeile richtet bei Verletzung den meisten Schaden an. Ein Kunde, der erfährt, dass seine Agentur seine Produkterecherche, seine Lieferantenakten oder seine Preise für eine markennah konkurrierende Marke wiederverwendet hat, verhandelt nicht neu – er geht, und er erzählt anderen Gründern, warum.
Ein neues Kundenprogramm onboarden
Eine wiederholbare Intake-Sequenz hält das vierte Programm so sauber wie das erste:
- Umfang schriftlich festlegen. Kanäle, Zielmärkte, erwartete Volumenbänder, Compliance-Anforderungen – und wer welche Entscheidung besitzt. Mehrdeutigkeit hier kehrt als jede spätere Streitfrage zurück.
- Lieferanten und Produkte je Kunden verifizieren. Die Lieferantenakte oder das Referenzmuster eines Kunden niemals für ein anderes Programm wiederverwenden ohne ausdrückliche schriftliche Erlaubnis – selbst wenn die Produkte identisch aussehen.
- Die Identifikatoren trennen. SKU-Präfixe, Eingangskartons-Etikettierung, Packstandards und Markenassets werden vor der ersten Bestellung konfiguriert – nicht währenddessen improvisiert.
- Servicelevels je Programm definieren. Versandcutoffs, Sync-Rhythmus, Ausnahmebehandlung und Neuversand-Autorität – dimensioniert nach Volumen und Kanalanforderungen jedes Programms.
- Den Berichtsrhythmus setzen. Eine wöchentliche Scorecard je Programm, die der Kunde sieht – und ein monatlicher Überprogramm-Review, den die Agentur intern fährt.
- Die Eskalationskarte vereinbaren. Wer mit der Fabrik spricht, wer einen Neuversand freigibt, wer die Kundenkommunikation besitzt, wenn etwas bricht. Ein Name je Rolle, schriftlich.
Kapazitätskonkurrenz und Peak-Season
Einen Versorgungspartner zu teilen bedeutet, seine endliche Kapazität zu teilen: Fabrikproduktionsslots, Lagerpersonal im Q4, Carrier-Abholungen. Der Störfall ist die stille Prioritätenumkehr – das lauteste Konto bekommt die Arbeitskraft, der stille Kunde entdeckt einen Out-of-Stock in seinem Dashboard. Funktionierende Programme handhaben Konkurrenz mit drei schriftlichen Regeln, vereinbart vor der Saison statt während ihr. Erstens: Kapazität wird je Programm allokiert, mit vorbuchten Peak-Zusagen – November-Arbeitskraft ist dann eine Reservierung, kein Gerangel. Zweitens: Konkurrenz folgt Beitrag und Vertrag, nicht der Anzahl der Nachrichten; die Fairnessregel steht schriftlich, gerade damit niemand sie unter Druck improvisieren muss. Drittens: Ein Schub in einem Programm löst eine Benachrichtigung an die anderen aus, deren Versand ins Rutschen geraten könnte – denn unangenehme Nachrichten altern schlecht. Dieselbe Vorbuchungslogik, die hochvolumige Verkäufer für ihre eigenen Programme nutzen – behandelt im Guide zu Skalierung jenseits von hundert Bestellungen am Tag – gilt hier mit dem Zusatz, dass mehrere Unternehmen sich eine Warteschlange teilen.
Berichte, Daten und Vertraulichkeit
Drei Regeln halten die Datenebene sauber. Kunden-Dashboards sind auf ihr eigenes Programm beschränkt – Bestellungen, Versandperformance, Bestand, Ausnahmen – ohne sichtbare Überprogramm-Totale. Die interne Sicht der Agentur aggregiert über Programme hinweg für Kapazitäts- und Kapitalplanung. Und der Default für kommerzielle Daten ist Trennung: Lieferantenpreise, die für einen Kunden beschafft wurden, werden ohne schriftliche Zustimmung nicht in einem Angebot für einen anderen wiederverwendet, und unter einem Mandat betriebene Produkterecherche bleibt bei diesem Mandat. Wo der Versorgungspartner die Berichtsschicht stellt, sollte je-Programm-Zugriffskontrolle ein Auswahlkriterium sein, keine Bitte – die Infrastrukturzusagen, die es wert sind, eingefordert zu werden, fasst unsere Fulfillment-Service-Seite zusammen.
Pre-Onboarding-Checkliste
Führen Sie diese aus, bevor Sie irgendein neues Kundenprogramm in die geteilte Struktur aufnehmen. Jede ungeprüfte Zeile ist eine bekannte Quelle späterer Konflikte:
- Schriftlicher Umfang: Kanäle, Märkte, Volumenbänder, Compliance-Pflichten, Entscheidungsbesitz.
- Lieferanten speziell für dieses Programm verifiziert, mit dokumentierter Verifizierung.
- SKU-Benennung, Eingangsetikettierung und Packstandards je Programm konfiguriert.
- Markenassets empfangen und in programmspezifischen Ordnern abgelegt.
- Servicelevels je Programm definiert: Cutoffs, Sync-Rhythmus, Ausnahmebehandlung, Neuversand-Autorität.
- Datentrennungsregeln im Kundenvertrag bestätigt, einschließlich Wiederverwendung von Lieferantenakten.
- Peak-Kapazitätserwartungen benannt und reserviert – schriftlich.
- Eskalationskarte benannt: Fabrikkontakt, Neuversand-Freigeber, kundengerichteter Besitzer.
Häufige Fragen
Sollte jeder Kunde stattdessen einen eigenen Versorgungspartner haben?+
Bei niedriger Programmzahl sind dedizierte Partner einfacher, aber spürbar teurer und langsamer einzurichten – denn jeder Partner baut Verifizierung, Integration und Berichterstattung neu. Das geteilte Modell verdient seine Komplexität, sobald sich Programme vervielfachen; unter zwei oder drei kann ein einziger gut geführter Programmpartner ehrlich der bessere Tausch sein.
Wie verhindert man, dass das Volumen eines Kunden das eines anderen aushungert?+
Mit im Voraus vereinbarter Allokation: vorbuchte Peak-Kapazität je Programm, eine schriftliche Konkurrenzregel und Benachrichtigungspflichten, wenn der Schub eines Programms den Versand eines anderen bedroht. Der Mechanismus zählt weniger als seine Existenz – ungeschriebene Fairnessregeln sind der Weg, auf dem Agenturen stille Kunden verlieren.
Was darf legal über Kundenprogramme hinweg geteilt werden?+
Nur das, dem jeder betroffene Kunde schriftlich zugestimmt hat. Infrastruktur, offensichtlich. Fast nichts sonst per Default: Lieferantenakten, Preise, Produkterecherche und Volumen sind kommerzielle Daten, die dem Mandat gehören, das dafür bezahlt hat. Im Zweifel: um Erlaubnis fragen – das kostet weniger als der Abgang, den es verhindert.
Wann wächst ein Programm aus dem geteilten Modell heraus?+
Wenn die Compliance-Anforderungen eines Programms Isolation verlangen, wenn sein Volumen die geteilte Kapazität über längere Perioden dominiert, oder wenn der Kunde dedizierte Infrastruktur als vertragliche Bedingung verlangt. Wachstum, das ein Programm auf eigene Infrastruktur hebt, ist ein Erfolgsergebnis – kein Versagen des Modells.
