Zum Inhalt springen
Agentur-Betrieb

Wie eine Agentur 40 übernommene Konten ohne Migration absorbierte

8 Min. Lesezeit
DF

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

Newsletter

The Ad Signal

Wöchentliche Einblicke für Media Buyer, die nicht raten. Eine E-Mail. Nur Signal.

Verwandte Artikel

Bereit, Ihre Werbeoperationen zu automatisieren?

Starten Sie Kampagnen massenhaft über alle Konten. Starte kostenlos, für immer. Keine Kreditkarte. Jederzeit kündbar.