Jak agencja wchłonęła 40 przejętych kont bez migracji

Deal zamknął się w piątek. Do kolejnego wtorku ta agencja posiadała cały portfel klientów konkurenta — a wraz z nim czterdzieści kont reklamowych klientów, których nigdy nie tknęła, rozsianych po osobnych loginach i Business Managerach. Plan, który wszyscy zakładali, że będą realizować, to projekt migracji: zebrać każde poświadczenie, zalogować się do każdego konta, ręcznie przenieść wszystko przez kilka bolesnych tygodni. To, co faktycznie się stało, jest tematem tego studium przypadku o tym, jak przeprowadzić przekazanie agency acquisition consolidate ad accounts — bo agencja wpięła jeden przejęty token System-User, pozwoliła auto-wykrywaniu ujawnić każde konto i operowała oba portfele z jednego workspace, zanim migracja w ogóle została zaplanowana.

To historia złożona, oparta na tym, jak prawdziwe agencje radzą sobie z konsolidacją po przejęciu. Nazwy i dokładne liczby są poglądowe; problem przekazania i kształt naprawy — nie.

Deal się zamyka: teraz posiadasz portfel klientów konkurenta

Przejęcie mniejszej agencji to normalny sposób na powiększenie portfela klientów: kupujesz relacje z klientami, abonamenty i ludzi, którzy je obsługują. Na papierze agencja właśnie dodała czterdzieści kont z dnia na dzień. W praktyce odziedziczyła plątaninę — przejęty sklep prowadził swoje konta tak, jak robi to większość agencji, zanim z tego wyrosną: z rozrzutem loginów, paroma Business Managerami i wiedzą o dostępie żyjącą w głowach kilku osób.

Własny dom agencji był w porządku. Operowała już swoich istniejących klientów przez jedną warstwę z imiennymi miejscami i ograniczonymi rolami, przeciwieństwo chaosu współdzielonych loginów opisanego w dlaczego współdzielone loginy zabijają Twoją agencję reklamową. Problemem było wchłonięcie czterdziestu kont prowadzonych według cudzych konwencji, na tyle szybko, by odziedziczeni klienci nigdy nie poczuli szwu. Przejęcie przenosi kontrakty natychmiast, a rzeczywistość operacyjną powoli, a przepaść między "posiadamy to" a "potrafimy to operować" to miejsce, gdzie grzęzną przekazania po przejęciu.

Ukryty koszt M&A: dziesiątki kont za osobnymi loginami

Przejdź odziedziczony portfel, a koszt starej struktury staje się konkretny. Czterdzieści kont nie oznaczało czterdziestu schludnych wpisów. Oznaczało dwa Business Managery założone w różnym czasie, rozrzut kont przypisanych do każdego, kilka, do których poprzedni właściciele sięgali przez loginy nadane przez klientów, i garstkę, gdzie jedyną drogą do środka było współdzielone hasło, które znało trzech byłych pracowników.

Nic z tego nie jest nietypowe; tak wygląda warstwa dostępu agencji, gdy rośnie klient po kliencie. Ale zamienia to każde przejęcie w projekt archeologiczny: zanim będziesz mógł prowadzić konto, musisz je znaleźć, potwierdzić, kto może do niego dotrzeć, i ustanowić własną drogę do środka — czterdzieści razy, na kilku platformach.

Zwykły plan: migracja poświadczenie po poświadczeniu mierzona w tygodniach

Operations lead agencji najpierw oszacował oczywiste podejście. Wypisz każde konto; dla każdego zidentyfikuj ścieżkę dostępu, zbierz poświadczenie, zaloguj się, potwierdź trwałą drogę do środka, która nie zależy od byłego pracownika, i ustanów ją na nowo pod własną strukturą agencji. Potem następne konto, i następne, na dwóch Business Managerach i kilku platformach.

Oszacowane szczerze, to tygodnie kruchej pracy. Każde współdzielone hasło to pojedynczy punkt awarii — jeśli odchodzący pracownik je zmieni albo przestanie odpowiadać, konto gaśnie. Każdy login nadany przez klienta trzeba potwierdzić na nowo, by relacja przetrwała zmianę właściciela. A przez cały czas trwania migracji odziedziczeni klienci są w zawieszeniu: technicznie odpowiedzialność agencji, praktycznie wciąż na wpół zarządzani przez loginy starego sklepu. Zespół przeprowadzał mniejsze wersje tego wcześniej — szarpaninę pierwszego tygodnia opisaną we własnym playbooku do onboardowania nowego konta klienta w pierwszym tygodniu — a przy czterdziestu kontach ta szarpanina się nie skaluje.

Skrót: wpięcie przejętego tokena System-User

Był skrót i zmienił kształt całego projektu. Przejęta agencja, jak większość agencji działających na skalę, wydała token System-User na poziomie Business Managera dla swoich integracji platformowych. Token System-User to nie osobisty login powiązany z jednym pracownikiem; to trwałe poświadczenie na poziomie biznesu, które już niesie dostęp do każdego konta reklamowego zarządzanego przez jego Business Managera. Agencja nie potrzebowała czterdziestu poświadczeń — potrzebowała tokena, przejętego wraz z biznesem.

Więc zamiast zaczynać migrację, operations lead zrobił jedno: wpiął token System-User przejętej agencji w warstwę operacyjną, ten sam mechanizm podłącz-raz, którego agencja już używała, by onboardować konto klienta bez nigdy współdzielenia loginu Meta. Jeden token, jedno wklejenie, dla całego Business Managera kont. Plan migracji dotknąłby każdego konta z osobna; token dotknął warstwy, która już trzymała je wszystkie.

Co ujawniło auto-wykrywanie: każde konto i BM, bez ręcznej inwentaryzacji

To, co stało się dalej, jest powodem, dla którego projekt migracji nigdy nie wystartował. Warstwa operacyjna odczytała token, rozwiązała stojące za nim business_id i wyliczyła konta automatycznie — każde konto reklamowe pod tym Business Managerem, ujawnione bez wpisywania listy przez kogokolwiek. Drugi Business Manager przyszedł w ten sam sposób z własnym tokenem, a między tymi dwoma większość czterdziestu kont była widoczna w jedno popołudnie.

Nie było ręcznej inwentaryzacji, bo token już znał inwentarz. Auto-wykrywanie przez business_id oznaczało, że źródłem prawdy dla "które konta istnieją" był sam Business Manager, a nie arkusz odtworzony ze wspomnień byłych pracowników. Garstka kont trzymanych przez dostęp nadany przez klientów, a nie przez przejęty BM, wciąż wymagała indywidualnego potwierdzenia na nowo, ale były krótkim ogonem, a nie całym projektem.

Mapowanie odziedziczonego zespołu w wewnętrzne role RBAC

Ujawnienie kont było połową roboty; drugą połową było zdecydowanie, kto może ich dotykać. Przejęta agencja zatrzymała część buyerów w ramach deala i puściła innych, a agencja nie zamierzała replikować rozrostu dostępu starego sklepu. Z kontami teraz wewnątrz warstwy operacyjnej zarządzanie tym, kto na nich pracował, było decyzją wewnętrzną, a nie właściwością loginów platformowych.

Operations lead przypisał ograniczone role. Zatrzymani buyerzy dostali imienne miejsca dopasowane do kont, które mieli dalej obsługiwać, więc relacje z klientami pozostały ciepłe przez ludzi, których klienci już znali; własne leady agencji dostały nadzór nad oboma portfelami; odchodzący personel nie dostał nic. Niczego nie trzeba było cofać na natywnych platformach, bo żaden z odziedziczonych buyerów nigdy nie operował przez podstawowe loginy. Pracowali przez wewnętrzne role na jednym podłączonym tokenie, model, którego agencja używa, by nie zamieniać osobnych loginów w warstwę operacyjną. Zarządzanie dostępem odbyło się raz, zamiast czterdzieści razy na natywnych ekranach uprawnień.

Operowanie oboma portfelami z jednego workspace w pierwszym tygodniu

Do końca pierwszego tygodnia agencja prowadziła swoich oryginalnych klientów i czterdzieści odziedziczonych kont z tego samego workspace. Spotkanie skalowania, kolejka uruchomień, raportowanie — wszystko to obejmowało oba portfele naraz, w jednym widoku zamiast przełączania między własną strukturą agencji a dwoma Business Managerami przejętego sklepu. Odziedziczeni klienci dostali standardowy rytm raportowania agencji natychmiast, a nie po kwartale przejściowym.

Klienci nie poczuli nic. Żadnych resetów haseł, żadnych maili "migrujemy wasze konto", żadnej luki w zarządzaniu — agencja, która kupiła ich stary sklep, po prostu dalej prowadziła ich reklamy. Tygodnie na wpół zarządzanego zawieszenia, które stworzyłaby migracja, nigdy nie istniały.

Lekcja: gdy token robi wykrywanie, przejęcie jest podłączeniem

Zapytany później, co powiedziałby innej agencji stojącej przed przejęciem, operations lead odpowiedział konkretnie: zanim oszacujesz migrację, sprawdź, czy dostęp, który kupujesz, zawiera token System-User Business Managera. Jeśli tak, nie migrujesz czterdziestu kont — podłączasz dwa Business Managery i potwierdzasz na nowo krótki ogon tych nadanych przez klientów, a Twoją prawdziwą robotą jest warstwa zarządzania na wierzchu.

To przeformułowanie to cała lekcja. Migracja zakłada, że praca skaluje się z liczbą kont; podłączenie zakłada, że skaluje się z liczbą ścieżek dostępu — a token System-User zwija cały Business Manager w jedną ścieżkę. Agencja skonsolidowała czterdzieści kont w jedno popołudnie, bo auto-wykrywanie przez business_id już wykonało robotę per konto. Ten sam wzorzec trzyma się na sześciu platformach reklamowych, które wspiera warstwa operacyjna, więc przejęty portfel obejmujący Meta, Google, TikTok, Taboola, Snapchat i Outbrain przychodzi kanał po kanale, a nie konto po koncie.

Plany Wevion zaczynają się od permanentnego darmowego planu (€0), potem Starter za €99/mc, Pro za €499/mc i Plus za €1,499/mc (€1,199 rocznie, rozliczane co roku przy -20%), z Enterprise jako planem custom, a każdy płatny plan zawiera 14-dniowy trial, który współistnieje z planem darmowym. Podłączenie tokena System-User i patrzenie, jak konta same się wykrywają, mieści się w tym. Reszta playbooka żyje w klastrze narzędzi agencyjnych.

Wniosek uogólnia się na każdą agencję, która rośnie przez przejęcia: rozmiar przekazania to nie liczba kont, które kupiłeś, to liczba odrębnych sposobów, na jakie musisz do nich dotrzeć. Odziedzicz token, który niesie cały Business Manager, pozwól wykrywaniu zrobić inwentaryzację, zarządzaj odziedziczonym zespołem przez wewnętrzne role — a migracja, której się obawiałeś, okazuje się krokiem podłączenia.