- Startseite
- Blog
- Agentur-Betrieb
- Wie eine Agentur 40 übernommene Konten ohne Migration absorbierte
Wie eine Agentur 40 übernommene Konten ohne Migration absorbierte
Davide Ferraro
Agency Operations Lead
Der Deal wurde an einem Freitag abgeschlossen. Bis zum folgenden Dienstag besaß diese Agentur den gesamten Kundenstamm eines Konkurrenten — und damit vierzig Kundenkonten, die sie nie angefasst hatte, verstreut über separate Logins und Business Manager. Der Plan, von dem alle annahmen, sie würden ihn befolgen, war ein Migrationsprojekt: jedes Zugangsdaten-Paar sammeln, sich in jedes Konto einloggen, über ein paar schmerzhafte Wochen alles von Hand neu eingeben. Was tatsächlich geschah, ist Gegenstand dieser Fallstudie darüber, wie man eine Agentur-Übernahme zur Konsolidierung von Werbekonten durchführt — denn die Agentur setzte einen übernommenen System-User-Token ein, ließ Auto-Discovery jedes Konto zum Vorschein bringen und betrieb beide Stämme aus einem einzigen Workspace, bevor die Migration je geplant war.
Kurze Antwort: Wenn eine Agentur eine andere übernimmt, kommen die Konten als ein Haufen separater Logins und Business Manager an, und der Standardplan ist eine Migration Zugangsdaten für Zugangsdaten, gemessen in Wochen. Den System-User-Token der übernommenen Agentur stattdessen zu verbinden, lässt die Betriebsebene ihre business_id lesen und jedes Konto und jeden BM automatisch aufzählen — vierzig Konten kommen in Stunden zum Vorschein, das geerbte Team wird in interne Rollen abgebildet, und die Übernahme wird ein Verbindungs-Schritt statt einer Migration.
Dies ist eine zusammengesetzte Geschichte, gezeichnet daraus, wie echte Agenturen die Konsolidierung nach Übernahmen handhaben. Die Namen und genauen Zahlen sind illustrativ; das Übergabe-Problem und die Form des Fixes sind es nicht.
Der Deal schließt: Jetzt besitzt du das Kundenportfolio eines Konkurrenten
Eine kleinere Agentur zu übernehmen ist ein normaler Weg, einen Kundenstamm zu vergrößern: Du kaufst die Kundenbeziehungen, die Retainer und die Leute, die sie betreuen. Auf dem Papier hatte die Agentur gerade über Nacht vierzig Konten hinzugefügt. In der Praxis hatte sie ein Gewirr geerbt — der übernommene Laden hatte seine Konten so geführt, wie es die meisten Agenturen tun, bevor sie darüber hinauswachsen, mit einer Streuung von Logins, ein paar Business Managern und Zugangswissen, das in den Köpfen einiger weniger Leute lebte.
Das eigene Haus der Agentur war in Ordnung. Sie betrieb ihre bestehenden Kunden bereits über eine einzige Ebene mit benannten Plätzen und eingegrenzten Rollen, das Gegenteil des Shared-Login-Chaos, das in warum geteilte Logins deine Werbeagentur töten beschrieben wird. Das Problem war, vierzig nach den Konventionen eines anderen geführte Konten zu absorbieren, schnell genug, dass die geerbten Kunden die Naht nie spürten. Eine Übernahme überträgt die Verträge sofort und die Betriebsrealität langsam, und die Lücke zwischen „wir besitzen es" und „wir können es betreiben" ist die Stelle, an der Übergaben nach Übernahmen stocken.
Die versteckten Kosten von M&A: Dutzende Konten hinter separaten Logins
Geh durch das geerbte Portfolio, und die Kosten der alten Struktur werden konkret. Vierzig Konten bedeuteten nicht vierzig ordentliche Einträge. Sie bedeuteten zwei zu unterschiedlichen Zeiten aufgesetzte Business Manager, eine Streuung von an jeden angehängten Konten, mehrere, die die vorherigen Eigentümer über kunden-gewährte Logins erreichten, und eine Handvoll, bei denen der einzige Weg hinein ein geteiltes Passwort war, das drei ehemalige Mitarbeiter kannten.
Nichts davon ist ungewöhnlich; so sieht die Zugangs-Ebene einer Agentur aus, wenn sie Kunde für Kunde wächst. Aber es macht jede Übernahme zu einem Archäologieprojekt: Bevor du ein Konto betreiben kannst, musst du es finden, bestätigen, wer es erreichen kann, und deinen eigenen Weg hinein etablieren — vierzigmal, über mehrere Plattformen.
Die eigentliche Haftung in einer Übernahme ist nicht die Anzahl der Konten; es ist die Anzahl der unterschiedlichen Zugangswege. Vierzig Konten hinter einer sauberen Struktur sind ein Verbinden. Dieselben vierzig hinter einem Dutzend Logins, zwei Business Managern und ein paar geteilten Passwörtern sind eine Migration — und der Unterschied liegt darin, wie der Zugang gehalten wurde.
Der übliche Plan: eine Migration Zugangsdaten für Zugangsdaten, gemessen in Wochen
Der Operations-Leiter der Agentur skizzierte zuerst den offensichtlichen Ansatz. Jedes Konto auflisten; für jedes den Zugangsweg identifizieren, das Zugangsdaten-Paar sammeln, einloggen, einen dauerhaften Weg hinein bestätigen, der nicht von einem ehemaligen Mitarbeiter abhing, und ihn unter der eigenen Struktur der Agentur neu etablieren. Dann das nächste Konto, und das nächste, über zwei Business Manager und mehrere Plattformen.
Ehrlich geschätzt sind das Wochen fragiler Arbeit. Jedes geteilte Passwort ist ein Single Point of Failure — wenn ein scheidender Mitarbeiter es ändert oder nicht mehr antwortet, geht ein Konto dunkel. Jedes kunden-gewährte Login muss neu bestätigt werden, damit die Beziehung den Eigentümerwechsel überlebt. Und die ganze Zeit, während die Migration läuft, sind die geerbten Kunden in der Schwebe: technisch die Verantwortung der Agentur, praktisch noch halb über die Logins des alten Ladens verwaltet. Das Team hatte kleinere Versionen davon schon zuvor durchgeführt — das Erste-Woche-Gerangel, das in ihrem eigenen Playbook für das Onboarding eines neuen Kundenkontos in Woche eins behandelt wird — und bei vierzig Konten skaliert dieses Gerangel nicht.
Ein Migrationsprojekt ist nur dann der richtige Plan, wenn es keine Abkürzung gibt — und es ist immer der langsame Plan, der sich im Tempo des schlechtesten Zugangsdaten-Paars im Haufen bewegt. Die Frage, die es zuerst zu stellen lohnt, ist, ob der Zugang en bloc geerbt werden kann, statt Konto für Konto gesammelt zu werden.
Die Abkürzung: das Einsetzen des übernommenen System-User-Tokens
Es gab eine Abkürzung, und sie änderte die Form des ganzen Projekts. Die übernommene Agentur hatte, wie die meisten in großem Maßstab operierenden Agenturen, einen System-User-Token auf Business-Manager-Ebene für ihre Plattform-Integrationen ausgestellt. Ein System-User-Token ist kein persönliches Login, das an einen Mitarbeiter gebunden ist; er ist ein dauerhaftes Zugangsdaten-Paar auf Geschäftsebene, das bereits Zugang zu jedem Werbekonto trägt, das sein Business Manager verwaltet. Die Agentur brauchte keine vierzig Zugangsdaten — sie brauchte den Token, mit dem Geschäft übernommen.
Statt also eine Migration zu starten, tat der Operations-Leiter eine Sache: Er setzte den System-User-Token der übernommenen Agentur in die Betriebsebene ein, denselben Einmal-verbinden-Mechanismus, den die Agentur bereits nutzte, um ein Kundenkonto zu onboarden, ohne je ein Meta-Login zu teilen. Ein Token, ein Einfügen, für einen ganzen Business Manager voller Konten. Der Migrationsplan hätte jedes Konto einzeln angefasst; der Token fasste die Ebene an, die sie bereits alle hielt.
Die Entschlüsselung in einer Übernahme ist die Erkenntnis, dass der Zugang Großhandel ist, nicht Einzelhandel. Der System-User-Token eines Business Managers spricht für alle Konten darunter — erbe den Token, und du erbst das Portfolio in einem einzigen Schritt, kein Login pro Konto, kein Ernten von Passwörtern von Leuten, die dort nicht mehr arbeiten.
Was Auto-Discovery zum Vorschein brachte: jedes Konto und jeden BM, kein manuelles Inventar
Was als Nächstes geschah, ist der Grund, warum das Migrationsprojekt nie lief. Die Betriebsebene las den Token, löste die dahinterstehende business_id auf und zählte die Konten automatisch auf — jedes Werbekonto unter diesem Business Manager, zum Vorschein gebracht, ohne dass jemand eine Liste tippte. Der zweite Business Manager kam auf dieselbe Weise mit seinem eigenen Token herein, und zwischen beiden war der Großteil der vierzig Konten an einem Nachmittag sichtbar.
Es gab kein manuelles Inventar, weil der Token das Inventar bereits kannte. Auto-Discovery über business_id bedeutete, dass die Quelle der Wahrheit für „welche Konten existieren" der Business Manager selbst war, keine aus dem Gedächtnis ehemaliger Mitarbeiter rekonstruierte Tabelle. Die Handvoll Konten, die über kunden-gewährten Zugang statt über den übernommenen BM gehalten wurden, brauchten noch eine individuelle Neubestätigung, aber sie waren ein kurzer Schweif, nicht das ganze Projekt.
Wenn das Zugangsdaten-Paar das Verzeichnis trägt, hört Discovery auf, deine Aufgabe zu sein: Nicht du zählst die Konten auf, der Token tut es. Das ist der strukturelle Unterschied zwischen einem Verbinden und einer Migration — das eine setzt voraus, dass du jedes Konto finden und neu eingeben musst, das andere setzt voraus, dass der Zugang, den du geerbt hast, die Antwort bereits enthält.
Das geerbte Team in interne RBAC-Rollen abbilden
Die Konten zum Vorschein zu bringen, war die halbe Arbeit; die andere Hälfte war, zu entscheiden, wer sie anfassen konnte. Die übernommene Agentur hatte einige Buyer als Teil des Deals gehalten und andere gehen lassen, und die Agentur war nicht im Begriff, den Zugangs-Wildwuchs des alten Ladens zu replizieren. Mit den Konten nun in der Betriebsebene war die Steuerung, wer sie bearbeitete, eine interne Entscheidung, keine Eigenschaft der Plattform-Logins.
Der Operations-Leiter wies eingegrenzte Rollen zu. Gehaltene Buyer bekamen benannte Plätze, abgestimmt auf die Konten, die sie weiter betreuen würden, sodass die Kundenbeziehungen über Leute warm blieben, die die Kunden bereits kannten; die eigenen Leiter der Agentur bekamen Aufsicht über beide Stämme; scheidendes Personal bekam nichts. Auf den nativen Plattformen musste nichts entzogen werden, weil keiner der geerbten Buyer je über die zugrunde liegenden Logins arbeitete. Sie arbeiteten über interne Rollen auf einem einzigen verbundenen Token, das Modell, das die Agentur nutzt, um separate Logins davon abzuhalten, die Betriebsebene zu werden. Zugangs-Governance geschah einmal, statt vierzigmal über native Berechtigungsbildschirme.
Ein Team zu erben ist sicherer, wenn Zugang oberhalb des Plattform-Logins lebt: Du gewährst und entfernst Rollen in der Ebene, das zugrunde liegende Token bewegt sich nie, und ein Buyer, der geht, verliert eine Rolle, kein Passwort, das drei andere Leute noch kennen.
Beide Stämme aus einem Workspace innerhalb der ersten Woche betreiben
Bis zum Ende der ersten Woche betrieb die Agentur ihre ursprünglichen Kunden und die vierzig geerbten Konten aus demselben Workspace. Das Scaling-Meeting, die Launch-Queue, das Reporting — all das deckte beide Stämme auf einmal ab, in einer Ansicht, statt zwischen der eigenen Struktur der Agentur und den zwei Business Managern des übernommenen Ladens hin- und herzuschalten. Die geerbten Kunden bekamen sofort den Standard-Reporting-Takt der Agentur, statt nach einem Übergangsquartal.
Die Kunden spürten nichts. Keine Passwort-Resets, keine „wir migrieren Ihr Konto"-E-Mails, keine Lücke in der Verwaltung — die Agentur, die ihren alten Laden gekauft hatte, betrieb einfach weiter ihre Anzeigen. Die Wochen halb-verwalteter Schwebe, die eine Migration geschaffen hätte, existierten nie.
Lektion: Wenn der Token die Discovery macht, ist eine Übernahme ein Verbinden
Hinterher gefragt, was sie einer anderen Agentur vor einer Übernahme sagen würden, war die Antwort des Operations-Leiters spezifisch: Bevor du eine Migration skizzierst, prüfe, ob der Zugang, den du kaufst, einen Business-Manager-System-User-Token enthält. Wenn ja, migrierst du keine vierzig Konten — du verbindest zwei Business Manager und bestätigst einen kurzen Schweif kunden-gewährter neu, und deine eigentliche Arbeit ist die Governance-Ebene darauf.
Diese Neurahmung ist die ganze Lektion. Eine Migration setzt voraus, dass die Arbeit mit der Anzahl der Konten skaliert; ein Verbinden setzt voraus, dass sie mit der Anzahl der Zugangswege skaliert — und ein System-User-Token kollabiert einen ganzen Business Manager zu einem Weg. Die Agentur konsolidierte vierzig Konten an einem Nachmittag, weil Auto-Discovery über business_id die Arbeit pro Konto bereits erledigt hatte. Dasselbe Muster gilt über die sechs Werbeplattformen, die die Betriebsebene unterstützt, sodass ein übernommener Stamm, der Meta, Google, TikTok, Taboola, Snapchat und Outbrain umfasst, Kanal für Kanal hereinkommt statt Konto für Konto.
Wevions Tarife beginnen bei einem dauerhaften kostenlosen Tarif (€0), dann Starter mit €99/Mon., Pro mit €499/Mon. und Plus mit €1.499/Mon. (€1.199 jährlich, jährlich abgerechnet mit −20 %), mit Enterprise als individuellem Tarif, und jeder kostenpflichtige Tarif enthält eine 14-Tage-Testphase, die mit dem kostenlosen Tarif koexistiert. Einen System-User-Token zu verbinden und zuzusehen, wie die Konten automatisch entdeckt werden, sitzt darin. Der Rest des Playbooks lebt im Agentur-Tools-Cluster.
Die Erkenntnis verallgemeinert sich auf jede Agentur, die durch Übernahme wächst: Die Größe der Übergabe ist nicht die Anzahl der Konten, die du gekauft hast, sondern die Anzahl der unterschiedlichen Wege, sie zu erreichen. Erbe den Token, der den ganzen Business Manager trägt, lass Discovery das Inventar machen, steuere das geerbte Team über interne Rollen — und die Migration, die du fürchtetest, erweist sich als ein Verbindungs-Schritt.
Häufig gestellte Fragen
The Ad Signal
Wöchentliche Einblicke für Media Buyer, die nicht raten. Eine E-Mail. Nur Signal.
Verwandte Artikel
Wie eine Agentur 80 Kundenkonten ohne einen einzigen geteilten Login onboardete
Eine wachsende Agentur ertrank in Kunden-Business-Managern, jeder ein neuer Login zum Speichern und Rotieren. So lernten sie, ein Kunden-Werbekonto ganz ohne geteilten Login zu onboarden — ein System-User-Token, Auto-Discovery und interne Rollen statt Passwörter.
Wie eine Agentur ein neues Kundenkonto in der ersten Woche mit Wevion onboardet
Montag unterschreibt ein neuer Retainer. Die meisten Agenturen verbringen die erste Woche im Chaos — verstreute Zugangsanfragen, improvisiertes Tagging, ein Wettlauf um den ersten Report. So führt eine Agentur das gesamte Onboarding als eine einzige Sequenz und schließt Freitag mit Rollen, UTMs und einem geplanten Report ab, der bereits live ist.
Separate Logins pro Shop vs. eine Multi-Brand-Betriebsebene
Es gibt zwei Wege, ein Portfolio aus Shops zu betreiben: zwischen separaten Logins pro Brand hin- und herspringen oder alle aus einer Ebene steuern. Dies ist ein ehrlicher Direktvergleich der beiden Modelle — Aufwand, Fehlerrisiko, Wiederverwendung, Reporting und die eine Frage, die sie trennt: Kann es tatsächlich Kampagnen launchen oder nur zusehen?