あるエージェンシーが買収した40アカウントを移行なしで吸収した方法

取引は金曜に成立しました。翌火曜までに、このエージェンシーは競合の顧客基盤全体を所有し、それとともに、これまで触れたことのない40の顧客広告アカウントを、個別のログインとビジネスマネージャーに散らばった状態で継承しました。誰もが従うと想定した計画は移行プロジェクトでした。すべての認証情報を集め、すべてのアカウントにログインし、いくつかの苦痛な週にわたってすべてを手作業で再入力する、というものです。実際に起きたことが、このagency acquisition consolidate ad accountsの引き継ぎをどう運用するかについてのケーススタディの主題です。エージェンシーは買収した1つのSystem-Userトークンを差し込み、自動検出にすべてのアカウントを表示させ、移行がスケジュールされる前に両方の基盤を1つのワークスペースから運用していたからです。

これは、実際のエージェンシーが買収後の統合をどう扱うかから描いた複合的な物語です。名前と正確な数字は説明用です。引き継ぎの問題と、修正の形はそうではありません。

取引が成立する：今やあなたは競合の顧客ポートフォリオを所有する

より小さなエージェンシーを買収することは、顧客基盤を成長させる普通の方法です。顧客関係、リテイナー、それらにサービスを提供する人々を買うのです。紙の上では、エージェンシーは一夜にして40のアカウントを追加したばかりでした。実際には、もつれを継承していました。買収された店は、ほとんどのエージェンシーがそれを卒業する前にそうするやり方でアカウントを運用していました。ログインの散らばり、いくつかのビジネスマネージャー、そして数人の頭の中に存在するアクセスの知識です。

エージェンシー自身の家は整っていました。すでに既存の顧客を、名前付きシートとスコープされたロールを持つ1つのレイヤーを通じて運用しており、なぜ共有ログインがあなたの広告エージェンシーを殺すのかで説明した共有ログインの混沌の対極でした。問題は、他人の慣習で運用された40のアカウントを、継承した顧客が継ぎ目を決して感じないほど速く吸収することでした。買収は契約を即座に、運用の現実をゆっくりと移転し、「私たちが所有する」と「私たちが運用できる」の間の溝こそ、買収後の引き継ぎが停滞する場所です。

M&Aの隠れたコスト：個別ログインの背後にある数十のアカウント

継承したポートフォリオを歩くと、古い構造のコストが具体的になります。40のアカウントは、40のきれいなエントリを意味しませんでした。異なる時期にセットアップされた2つのビジネスマネージャー、それぞれに付随するアカウントの散らばり、前の所有者が顧客付与のログインで到達したいくつか、そして唯一の入り口が3人の元従業員が知っていた共有パスワードだったひと握り、を意味しました。

それは何も珍しくありません。エージェンシーのアクセスレイヤーが一度に1つの顧客で成長したときの姿です。しかしそれは、すべての買収を考古学プロジェクトに変えます。アカウントを運用する前に、それを見つけ、誰が到達できるかを確認し、自分自身の入り口を確立しなければなりません。40回、いくつかのプラットフォームにわたって。

いつもの計画：週単位で測られる認証情報ごとの移行

エージェンシーのオペレーションリードは、まず明白なアプローチを見積もりました。すべてのアカウントをリスト化し、それぞれについて、アクセス経路を特定し、認証情報を集め、ログインし、元従業員に依存しない持続的な入り口を確認し、エージェンシー自身の構造の下でそれを再確立する。そして次のアカウント、また次へと、2つのビジネスマネージャーといくつかのプラットフォームにわたって。

正直に見積もると、それは数週間の脆い作業です。すべての共有パスワードは単一障害点です。去っていく従業員がそれを変えたり応答をやめたりすれば、アカウントが暗転します。すべての顧客付与のログインは、所有権の変更を関係が生き残るよう再確認しなければなりません。そして移行が実行される間ずっと、継承した顧客は宙ぶらりんです。技術的にはエージェンシーの責任、実際にはまだ古い店のログインを通じて半分管理されています。チームはこれの小さなバージョンを以前に実行したことがありました。彼ら自身のプレイブックの初週に新しい顧客アカウントをオンボーディングするでカバーされた初週の慌てふためきです。そして40のアカウントでは、その慌てふためきはスケールしません。

近道：買収したSystem-Userトークンを差し込む

近道があり、それがプロジェクト全体の形を変えました。買収したエージェンシーは、規模で運用するほとんどのエージェンシーと同様に、プラットフォーム統合のためにビジネスマネージャーレベルでSystem-Userトークンを発行していました。System-Userトークンは、一人の従業員に紐づいた個人ログインではありません。そのビジネスマネージャーが管理するすべての広告アカウントへのアクセスをすでに持つ、持続的なビジネスレベルの認証情報です。エージェンシーは40の認証情報を必要としませんでした。ビジネスとともに買収したトークンを必要としたのです。

そこで移行を始める代わりに、オペレーションリードは1つのことをしました。買収したエージェンシーのSystem-Userトークンを運用レイヤーに差し込んだのです。エージェンシーがすでにMetaログインを一切共有せずに顧客アカウントをオンボーディングするのに使っていた、同じ一度接続の仕組みです。1つのトークン、1回の貼り付けで、ビジネスマネージャー1つ分のアカウント全体です。移行計画はすべてのアカウントに個別に触れたでしょう。トークンは、それらすべてをすでに保持していたレイヤーに触れました。

自動検出が表示したもの：すべてのアカウントとBM、手作業の棚卸しなし

次に起きたことが、移行プロジェクトが決して実行されなかった理由です。運用レイヤーはトークンを読み、その背後のbusiness_idを解決し、アカウントを自動的に列挙しました。そのビジネスマネージャーの下のすべての広告アカウントが、誰もリストを入力することなく表示されました。2つ目のビジネスマネージャーが、それ自身のトークンとともに同じ方法で入り、2つの間で40のアカウントの大半が1つの午後に可視化されました。

トークンがすでに棚卸しを知っていたので、手作業の棚卸しはありませんでした。business_idを介した自動検出は、「どのアカウントが存在するか」の真実の源が、元従業員の記憶から再構築されたスプレッドシートではなく、ビジネスマネージャー自身であることを意味しました。買収したBMではなく顧客付与のアクセスを通じて保持されたひと握りのアカウントは、依然として個別の再確認を必要としましたが、それらはプロジェクト全体ではなく短い尾でした。

継承したチームを内部RBACロールにマッピングする

アカウントを表示することは仕事の半分でした。もう半分は、誰がそれらに触れられるかを決めることでした。買収したエージェンシーは取引の一部として一部のバイヤーを残留させ、他を手放し、エージェンシーは古い店のアクセスの散在を複製するつもりはありませんでした。アカウントが今や運用レイヤーの中にあるので、誰がそれらを働かせるかを管理することは、プラットフォームログインの特性ではなく、内部の決定でした。

オペレーションリードはスコープされたロールを割り当てました。残留したバイヤーは、彼らがサービスを続けるアカウントに合わせた名前付きシートを得たので、顧客関係は顧客がすでに知っている人々を通じて温かいままでした。エージェンシー自身のリードは両方の基盤にわたる監督を得ました。去っていくスタッフは何も得ませんでした。ネイティブのプラットフォームで取り消すべきものは何もありませんでした。継承したバイヤーの誰一人として、根底のログインを通じて操作していなかったからです。彼らは、エージェンシーが個別ログインが運用レイヤーになるのを防ぐのに使うモデルである、1つの接続されたトークン上の内部ロールを通じて働きました。アクセスのガバナンスは、ネイティブの権限画面にわたって40回ではなく、一度行われました。

初週のうちに両方の基盤を1つのワークスペースから運用する

初週の終わりまでに、エージェンシーは元の顧客と40の継承したアカウントを同じワークスペースから運用していました。スケーリングミーティング、ローンチキュー、レポート、そのすべてが両方の基盤を一度にカバーし、エージェンシー自身の構造と買収した店の2つのビジネスマネージャーの間を切り替える代わりに、1つのビューでした。継承した顧客は、移行四半期の後ではなく即座に、エージェンシーの標準的なレポートの頻度を得ました。

顧客は何も感じませんでした。パスワードのリセットも、「あなたのアカウントを移行しています」というメールも、管理の隙間もありません。彼らの古い店を買ったエージェンシーが、単に彼らの広告を運用し続けました。移行が生み出したであろう半分管理された宙ぶらりんの数週間は、決して存在しませんでした。

教訓：トークンが発見を行うとき、買収は接続である

後で、買収に直面する別のエージェンシーに何を伝えるかと尋ねられて、オペレーションリードの答えは具体的でした。移行を見積もる前に、あなたが買っているアクセスがビジネスマネージャーのSystem-Userトークンを含むかどうかを確認しなさい。もし含むなら、あなたは40のアカウントを移行しているのではありません。2つのビジネスマネージャーを接続し、顧客付与の短い尾を再確認しているのであり、あなたの本当の仕事は、その上のガバナンスレイヤーです。

その再構成が教訓の全体です。移行は、仕事がアカウントの数に比例してスケールすると想定します。接続は、それがアクセス経路の数に比例してスケールすると想定し、System-Userトークンはビジネスマネージャー全体を1つの経路に折りたたみます。エージェンシーは40のアカウントを1つの午後に統合しました。business_idを介した自動検出が、すでにアカウントごとの仕事を済ませていたからです。同じパターンが、運用レイヤーがサポートする6つの広告プラットフォームにわたって成り立つので、Meta、Google、TikTok、Taboola、Snapchat、Outbrainにまたがる買収した基盤は、アカウントごとではなくチャネルごとに入ります。

Wevionのプランは、永続的な無料ティア（€0）から始まり、次にStarterが月€99、Proが月€499、Plusが月€1,499（年間€1,199、-20%で年払い）、そしてEnterpriseがカスタムプランで、すべての有料ティアには無料プランと共存する14日間のトライアルが含まれます。System-Userトークンを接続し、アカウントが自動検出されるのを見ることは、その中に収まります。プレイブックの残りはエージェンシーツールクラスターにあります。

この学びは、買収によって成長するあらゆるエージェンシーに一般化します。引き継ぎの規模は、あなたが買ったアカウントの数ではなく、それらに到達しなければならない明確な方法の数です。ビジネスマネージャー全体を運ぶトークンを継承し、発見に棚卸しをさせ、継承したチームを内部ロールを通じて管理しましょう。そうすれば、あなたが恐れていた移行は、接続のステップだったと判明するのです。