Що відбувається із сайтом після купівлі компанії?

Угода не об'єднує два сайти. Вона зіштовхує два бізнеси.

ПИТАННЯ

Коли угоду закрито

Коли одна компанія купує іншу, очевидні активи зазвичай легко перелічити: виторг, клієнти, контракти, співробітники, інтелектуальна власність, обладнання, склад, грошовий потік.

Сайт, як правило, десь наприкінці цього списку. У чек-листі due diligence він може значитися як домен, маркетинговий канал або просто «цифрові активи». Хтось підтверджує, що домен належить компанії, сайт працює і явних проблем немає.

Потім угоду закривають, і комусь доводиться відповідати на значно довший список питань. Хто насправді керує доменом? Де розміщено сайт і в кого є доступ до коду? Який сайт стане основним? Що буде з тисячами проіндексованих адрес, з позиціями в пошуку, з формою заявки та CRM, у яку вона пише, з особистими кабінетами клієнтів та історією замовлень, з аналітикою та поштою?

І, мабуть, найнезручніше питання: наскільки куплений бізнес залежить від сайту, який ніхто не вважав критичною інфраструктурою?

Відповідь часто дивує. Після угоди саме сайт нерідко стає місцем, де покупець уперше бачить, як компанія працює насправді: куди в дійсності йдуть заявки, які системи залежать одна від одної і які процеси ніхто ніколи не описував.

Тут сайт змінює свою природу. До угоди це був «наш сайт». Після неї він стає частиною задачі з інтеграції.

Коротко

• Після купівлі компанії сайт перестає бути лише маркетинговим активом і стає частиною інтеграції: домени, хостинг, код, аналітику, CRM, особисті кабінети клієнтів і видимість у пошуку треба врахувати.
• Юридичне володіння і технічне керування - різні речі. Договір може передати сайт, а паролі, акаунти та API-ключі залишаться в людей, які більше не працюють у компанії.
• Видима частина сайту рідко буває найціннішою. Частіше цінні історія в пошуку, контент, інтеграції та дані клієнтів, і застарілий сайт може нести більше цінності, ніж гарний.
• Не робіть редизайн у перші місяці. Спершу інвентаризація і контроль, потім розуміння того, що створює цінність, і лише тоді проєктування спільної цифрової архітектури: приблизно 90 днів.
• Якщо ви продавець, наведіть лад із доступами і правами до угоди. Це значно дешевше, ніж пояснювати прогалини, знайдені на due diligence.

РЕАЛЬНИЙ АКТИВ

Не просто сайт

Сайт легко сприймати як візуальний об'єкт. Його можна відкрити, подивитися на головну, оцінити дизайн і порахувати сторінки. Він здається відчутним.

Але видима частина сайту - це лише інтерфейс. За ним можуть стояти роки накопичених бізнес-рішень. Сайт може бути пов'язаний із CRM, платіжною системою, складом, ERP, клієнтською базою, поштою, аналітикою, рекламними кабінетами, внутрішніми API та десятками дрібних сервісів, про які вже ніхто не пам'ятає, як їх підключали.

Картка товару може брати залишки з ERP. Форма заявки може створювати лід у CRM. Одна онлайн-покупка може запускати оплату, списання зі складу, сповіщення про доставку, бухгалтерські проведення і листи клієнту. Стаття в блозі може приносити органічний трафік, що накопичувався десять років, а одна посадкова сторінка може давати помітну частку вхідних заявок.

На головній сторінці нічого цього не видно. Тому оцінювати сайт під час купівлі компанії як дизайнерський актив буває оманливо: дизайн може коштувати дуже мало, а система за ним бути незамінною. Про цей ширший зсув ми писали у статті «Софт має пасувати бізнесу».

Ви купуєте не сайт. Ви купуєте його залежності.

Покупець платить не за HTML, CSS і дизайн. Він отримує мережу зв'язків, яка робить сайт частиною бізнесу, і кожен із них після угоди має й далі працювати або бути свідомо замінений.

ВОЛОДІННЯ

Володіння і контроль

Перш ніж хтось почне щось перемальовувати, постає простіше питання: що ви насправді купили? Не компанію, а цифрову інфраструктуру, на якій вона працює. Нормальна інвентаризація після угоди охоплює щонайменше ось що:

Звучить як адміністративна рутина. Це не так. Компанія може юридично купити іншу компанію і потім виявити, що ключові частини її цифрової інфраструктури контролюють люди, які більше не мають до бізнесу стосунку. Домен може бути оформлено особисто на засновника. Акаунт хостингу може належати сторонньому розробнику. Аналітика може жити в особистому акаунті Google співробітника, який пішов три роки тому. Код може лежати в репозиторії агенції, а інтеграція з CRM триматися на API-ключі, який ніхто не задокументував.

Формально в компанії є сайт. Фактично повного контролю над ним немає ні в кого.

На папері і на практиці

Володіння може бути очевидним у договорі й зовсім неясним на практиці. Договір купівлі-продажу може вказувати, що інтелектуальна власність, домени і програмне забезпечення переходять до покупця. Але передача права на папері не передає кожен пароль, акаунт, API-ключ, хостинг, підписку й адміністративне право, без яких систему неможливо експлуатувати.

Тому цифровий due diligence не має закінчуватися питанням «чи володіє компанія своїм сайтом?». Правильне питання інше: чи може компанія справді керувати всім, що потрібно, щоб її цифровий бізнес і далі працював? Як перевірити це до підписання, ми розповіли у статті «Як перевірити сайт або цифровий продукт перед купівлею», а про ширшу картину - у матеріалі «Аудит цифрового володіння».

Ми самі опинилися на цьому боці

Ми самі опинилися по той бік цієї проблеми, причому без жодної угоди. Частина наших власних сайтів досі розміщувалася на акаунтах, що належали колишній компанії-партнеру. Юридично сайти були нашими, і ніхто з цим не сперечався. Технічно будь-яка зміна на сервері залежала від акаунта, яким ми не керували.

Переїзд вимагав саме тієї послідовності, про яку ця стаття: інвентаризації того, що де лежить, резервних копій, самої міграції, редиректів зі старих адрес і видалення копій, яких більше не має існувати. І вже в процесі ми знайшли ту саму картину в іншому місці: повний адміністративний доступ до одного з наших рекламних кабінетів залишається в людей поза компанією.

На папері все було гаразд. На практиці контроль був неповним. Якщо таке може статися з digital-агенцією, яка займається цим щодня, це може статися майже з будь-яким бізнесом, і угода зазвичай стає моментом, коли це спливає.

ЯКИЙ ЗАЛИШИТЬСЯ

Який сайт залишиться

Коли з володінням і доступами зрозуміло, постає стратегічне питання. Тепер є два бізнеси і, можливо, дві цифрові екосистеми. Загалом шляхів чотири:

• Залишити обидва сайти, якщо компанії й далі працюють як окремі бренди, обслуговують різні аудиторії або займають різні позиції на ринку.
• Вбудувати куплену компанію в сайт покупця, якщо вона стає підрозділом, продуктовою лінійкою або послугою материнської компанії.
• Зберегти куплений бренд, але перебудувати його цифрову присутність на новій архітектурі.
• Побудувати цілком нову платформу для об'єднаного бізнесу.

А іноді правильна відповідь менш очевидна: взяти найкраще з обох систем і побудувати те, чого не було в жодної з компаній. Угода не обов'язково означає вибір, чий сайт переміг. Вона означає рішення, які частини обох бізнесів заслуговують на те, щоб залишитися.

Негарний сайт може виявитися цінним

Тут зовнішній вигляд починає небезпечно вводити в оману. Уявіть дві компанії. У компанії А гарний, швидкий, сучасний сайт. Сайт компанії Б має вигляд років на десять старший: застаріла типографіка, незручна навігація, дизайн, якому явно потрібна робота.

Але в компанії Б п'ятнадцять років історії домену, тисячі зворотних посилань, сотні сторінок у видачі, велика бібліотека корисного контенту, сильний брендовий попит, особисті кабінети клієнтів, інтеграції з внутрішніми системами і роки даних про конверсію.

Який сайт цінніший? Не той, що має кращий вигляд. Десятирічний сайт може бути ціннішим активом в угоді, ніж гарний новий, бо візуально застарілий не означає економічно застарілий. В M&A зовнішній вигляд часто виявляється найменш надійним мірилом цифрової цінності. Саме тому надто швидкий редизайн сайту купленої компанії може бути небезпечним.

Можна покращити дизайн і випадково знищити сам актив.

ПОШУКОВИЙ КАПІТАЛ

Невидимий актив

Видимість у пошуку - один із найбільш недооцінених активів, бо більша частина її цінності невидима. Домен роками накопичує авторитет. Сторінки ранжуються за сотнями і тисячами запитів, на них посилаються інші сайти, клієнти шукають компанію за назвою, а стаття, написана вісім років тому, досі щомісяця приводить цільових відвідувачів. Нічого з цього не відображено у фінансовій звітності, але це частина цифрової вартості компанії.

Під час купівлі компанії пошуковий капітал може працювати як невидимий канал дистрибуції. Якщо компанія отримує, скажімо, третину цільових заявок з органічного пошуку, це вже не «SEO». Це частина її інфраструктури залучення клієнтів, і втрата цього каналу після угоди змінює економіку, за яку заплатив покупець.

Тому рішення «сайт старий, зробимо новий» цілком розумне. Нерозумно вважати, що старий сайт нічого не вартий, бо в нього застарілий інтерфейс. Редизайн може зберегти цю цінність. Недбала міграція може її знищити.

«Просто поставимо редиректи на все»

Ця фраза створила чимало проблем. Уявіть, що в купленої компанії 2 000 проіндексованих адрес: товари, послуги, статті, категорії, старі кампанії. Одні мають зворотні посилання, інші приносять трафік, треті вже нічого не варті. Тепер уявіть, що всі 2 000 перенаправлено на головну сторінку нової компанії. Технічно міграція спрацювала. Стратегічно це може бути катастрофою.

Серйозна міграція ставить кожній сторінці питання: чим вона була, яку цінність мала, звідки йшов трафік, хто на неї посилався, що їй відповідає в новій архітектурі і що з нею робити: зберегти, об'єднати, перенаправити чи закрити? Завдання не в тому, щоб перенаправити адреси. Завдання в тому, щоб перенести корисні частини старої інформаційної архітектури в новий бізнес. Технічний бік цього ми розбираємо у статті «Оновлення старого сайту на Laravel або PHP».

Сайт як літопис бізнесу

Структура адрес часто показує, як розвивалася компанія: продукти, рішення, галузі, матеріали, філії, підтримка. Під нею можуть лежати роки організаційної історії. Якихось категорій уже немає, якісь продукти знято з виробництва, якісь ринки втратили значення, а інші несподівано виявляються дуже цінними.

Те саме з контентом. Статті, кейси, посібники, документація, відповіді на питання, відео: щось застаріло, щось дублюється, щось ніяково показувати, а щось тихо приводить цільових клієнтів щомісяця. Відповідь не в тому, щоб зберегти все. Відповідь у тому, щоб зрозуміти, що у вас є, перш ніж вирішувати, що видаляти, бо видалити сторінку завжди простіше, ніж зрозуміти, навіщо вона існує.

СИСТЕМИ

CRM, кабінети і дані

Тепер питання виходить за межі пошуку. Сайт може не лише приводити трафік. Він може живити всю воронку продажів компанії: форма, CRM, менеджер, комерційна пропозиція, договір.

Уявіть, що покупець працює в Salesforce, а куплена компанія в HubSpot, і сайт досі надсилає заявки в стару систему. Міграція перестає бути проєктом сайту. Це проєкт відділу продажів, і наслідки серйозніші, ніж зламана сторінка. Перестала працювати форма - втрачено заявки. Зламалася інтеграція - дані не доходять до продажників. Дублі записів створюють операційні проблеми, зникле поле ламає автоматизацію, а змінене джерело ліда позбавляє маркетингову атрибуцію сенсу. Як ці системи співвідносяться між собою, ми описали у статті «CRM і ERP: у чому різниця».

В e-commerce це видно ще чіткіше. Припустімо, у купленої компанії 40 000 клієнтських акаунтів з адресами, історією замовлень, підписками, бонусними балами, рахунками та історією звернень. У покупця своя клієнтська база. Як дві бази стають однією? Це не редизайн. Це архітектура даних, а сайт часто і є інтерфейсом, через який клієнти до цих даних звертаються. Зробіть це погано, і клієнти втратять доступ до своїх кабінетів, замовлень чи підписок. Новий дизайн може бути чудовим, а працювати з компанією стане гірше.

Зламану головну видно одразу. Зламану інтеграцію з CRM можна не помітити. Після угоди компанія може тижнями працювати з гарним новим сайтом, поки заявки тихо зникають, атрибуція ламається, з'являються дублі клієнтів, відділ продажів більше не розуміє, звідки надходять звернення, підписки перестають синхронізуватися, а постійні клієнти не бачать своїх замовлень. Найдорожчі помилки часто зовсім не схожі на помилки сайту.

ТЕХНІЧНИЙ БОРГ

Борг, який ви успадковуєте

Угода може звести разом дві цілком різні технічні філософії. Одна компанія працює на власному застосунку на Laravel із сучасним фронтендом і внутрішніми API. Інша на WordPress з WooCommerce і набором плагінів, накопичених за роки. В однієї структурована база даних, в іншої таблиці, які виконують роботу, що давно потребує автоматизації. Одна викладає зміни через нормальний конвеєр, інша заходить на робочий сервер і заливає файли. В однієї є документація. В іншої є «спитайте в Алекса», а Алекс, можливо, уже звільнився.

Ось чому технічний due diligence такий важливий. Угода не усуває технічний борг. Вона передає його покупцю: непідтримуване ПЗ, застарілі фреймворки, незадокументовані інтеграції, небезпечні плагіни, код, у якому ніхто не розбирається, системи, прив'язані до одного співробітника, бази даних, що дублюються, і покинута інфраструктура.

Технічний борг рідко заявляє про себе в презентації для покупця. Він проявляється, коли хтось намагається щось змінити. На головну потрібна нова форма. Форма залежить від старого API. API працює на сервері, до якого ніхто не знає, як під'єднатися, і на ПЗ, яке ніхто не хоче оновлювати. І «невелика правка на сайті» перетворюється на проєкт міграції.

Іноді найдешевший сайт в угоді обходиться найдорожче.

Те, що робить його дорогим, рідко видно в дизайні. Це все, що ніхто не перевірив під ним до угоди.

Що показує сайт

Можливо, це одна з найцінніших функцій аудиту сайту під час купівлі компанії, бо сайт часто виявляється картою того, як компанія працює насправді. Бізнес може описувати себе як високоавтоматизований, а сайт розповідає іншу історію: кожна заявка падає в спільну поштову скриньку, ціни вручну переносяться з таблиць, замовлення заново вбиваються в іншу систему, і ніхто не знає, який канал приводить клієнтів, бо аналітику багато років тому налаштували неправильно.

Сайт показує не лише те, що компанія продає. Він показує, як вона працює, і на due diligence це може коштувати більше, ніж ще одна відполірована презентація.

БРЕНД

Що буде з брендом

Рано чи пізно питання про сайт стає питанням про бренд. Куплений бренд може зникнути, залишитися незалежним, стати суббрендом, злитися з брендом покупця або поступитися місцем новому. Жодне з цих рішень не має ухвалюватися через те, що один сайт має кращий вигляд, ніж інший.

Архітектура бренду має йти за бізнес-стратегією. Якщо куплену компанію добре знають на її ринку, негайне видалення бренду може знищити цінність. Якщо бренд слабкий або надлишковий, дві цифрові екосистеми створюють зайву складність. Якщо угоду задумано, щоб зайняти нову позицію на ринку, може не підійти жоден з наявних сайтів. Як вирішити, що зберегти, розвинути, замінити чи перевірити, ми описуємо у статті «Коли не потрібен ребрендинг».

Сайт - це втілення такого рішення. Ухвалювати його має не він.

ТЕРМІНИ

Не поспішайте з редизайном

Це, мабуть, найпоширеніша помилка. Угоду закрито, нове керівництво хоче показати результат, і хтось каже: «Давайте переробимо сайт». За кілька тижнів усі обговорюють кольори, шрифти й макет головної.

Але перше питання після купівлі компанії має звучати не «яким має бути новий сайт?», а «яким має бути новий бізнес у цифровому вигляді?». Перш ніж щось проєктувати, треба знати, що зберегти, що інтегрувати, чого позбутися і що перебудувати. Правильна послідовність ближча до зрозуміти, перевірити, зберегти, інтегрувати, спростити, перебудувати, ніж до «купити, перемалювати».

Не кожна угода потребує негайної міграції. Іноді безпечніше залишити обидва сайти працювати, поки триває інтеграція організації, і використати цей час, щоб розібратися в трафіку, клієнтах, конверсії, системах, контенті, пошуку та впізнаваності бренду. Негарний, але робочий сайт часто кращий за гарний, який ламає бізнес. Іноді стриманість і є зрілішим рішенням.

90 ДНІВ

Перші 90 днів

Практичний цифровий план після угоди можна поділити на чотири етапи.

До закриття угоди: знати, чим ви володієте. Задокументуйте все: домени, хостинг, код, CMS, аналітику, рекламу, CRM, пошту, API, бази даних, зовнішні сервіси, користувачів, права, ліцензії, резервні копії, договори та стосунки з агенціями. Мета поки не в тому, щоб щось змінювати. Мета в тому, щоб зрозуміти, що існує.

Дні 1-30: узяти під контроль те, що купили. Переконайтеся, що нова організація справді керує інфраструктурою. Передайте адміністративні права, змініть паролі та ключі, перевірте користувачів і права, відновіть покинуті акаунти, задокументуйте критичні залежності, перевірте резервні копії і підтвердьте доступ до доменів, DNS, хостингу, репозиторіїв та аналітики. Цей етап нудний. Але саме на ньому з невеликими витратами знімаються одні з найбільших ризиків.

Дні 30-60: зрозуміти, що створює цінність. Подивіться на системи з погляду бізнесу. Які сторінки приносять трафік, заявки й виторг? На який контент є зворотні посилання? Які інтеграції критичні, а від яких систем можна відмовитися? Які дані клієнтів треба перенести і який технічний борг небезпечний? Завдання в тому, щоб відрізнити спадщину від цінної історії. Це не одне й те саме.

Дні 60-90: вирішити, що залишиться. Лише тепер нова цифрова архітектура має ставати конкретною: окремі бренди чи один, які домени залишаються, що буде з пошуком, клієнтськими кабінетами, CRM, контентом та аналітикою, що перебудовується, що закривається і що інтегрується. На цьому етапі проєкт сайту вже не редизайн. Це цифрове втілення стратегії угоди.

ЗБЕРЕГТИ ЧИ ПРИБРАТИ

Що зберегти, від чого відмовитися

Тут важить судження. Можна зберегти сторінку, бо вона ранжується, систему, бо від неї залежать клієнти, бренд, бо його впізнають, контент, бо він показує експертизу, адресу, бо на неї посилаються інші сайти. Але збереження не має ставати приводом тримати все вічно. Мета не в тому, щоб побудувати музей купленої компанії. Мета в тому, щоб перенести цінні активи в наступну версію бізнесу.

Дещо має просто зникнути: старі кампанії, дублі сторінок, мертві інтеграції, покинуті плагіни, невикористовувані функції, застарілий контент, надлишкові системи, старе відстеження, діри в безпеці та процеси, які існують лише тому, що «так завжди робили». Угода дає рідкісну можливість поставити краще питання: якби ми будували цей бізнес сьогодні, чи побудували б ми його так?

Два сайти або один, але надто швидко

Іноді проблема не в тому, що один сайт поганий. Проблема в тому, що їх два: дві CMS, два хостинги, дві системи аналітики, дві дизайн-системи, два набори інтеграцій, дві поверхні для атак і дві версії історії компанії. Зберегти обидва бренди може бути стратегічно правильно. Тримати дві цифрові екосистеми, бо ніхто не хоче ухвалювати рішення, - це не стратегія. Це накопичена складність.

Протилежна ситуація не менш небезпечна. Материнська компанія одним махом переводить усе на свою платформу: домен купленої компанії зникає, її контент пропадає, клієнтський портал замінюють, старі адреси більше не відкриваються, а її команда працює в обхід системи, створеної для іншого бізнесу. За пів року всі дивуються, чому впав трафік і чому клієнти заплуталися. Мета не максимальна консолідація. Мета в правильній її мірі.

ДЛЯ ПРОДАВЦІВ

Підготовка до угоди

Усе написане вище - погляд покупця. Для продавця той самий список стає планом підготовки.

Покупці дедалі уважніше дивляться на цифровий бік бізнесу під час due diligence, і кожна знайдена прогалина перетворюється на питання, затримку чи суперечку про ціну. Домен, оформлений особисто на засновника, аналітика в акаунті колишнього співробітника, код у репозиторії агенції, інтеграція, яку ніхто не задокументував: кожне з цього дешево виправити за рік до продажу і дорого виявити посеред нього. Такі прогалини ще й посилюють враження, що бізнес залежить від конкретних людей, а покупці закладають це в ціну. Про це ми розповідаємо у статті «Залежність від засновника: прихований дисконт».

Якщо на горизонті продаж, передача бізнесу чи нові інвестиції, кроки з інвентаризації і контролю з плану на 90 днів варто зробити вже зараз, на своїх умовах. Сесія готовності до продажу і передачі бізнесу - один зі структурованих способів почати, хоча уважна внутрішня перевірка охоплює багато з того самого. Ширшу підготовку ми описуємо у статті «Перш ніж продати, піти на спочинок або передати бізнес».

ВИСНОВОК

Дві історії, один бізнес

Купуючи компанію, ви купуєте не головну сторінку. Ви купуєте систему зв'язків: клієнтів, процеси, дані, технології, контент, бренд, канали продажів, видимість у пошуку та операційні знання. Сайт - одне з місць, де багато з цих зв'язків стають видимими. Іноді це просто маркетинговий шар. Іноді це вхідні двері до всього бізнесу. А іноді це єдине місце, де ще видно роки накопиченої цифрової цінності.

Угода не об'єднує два сайти. Вона об'єднує дві історії, дві клієнтські бази, два технологічні стеки, два бренди і два набори уявлень про те, як має працювати бізнес. Сайт - просто те місце, де ці відмінності стає неможливо ігнорувати.

Тому правильне питання після угоди не «який сайт залишити?». Правильне питання: «які частини цих двох бізнесів варто взяти із собою?» Коли на нього є відповідь, сайт будувати значно простіше.

Сайт не має зберігати минуле заради самого минулого. Він має зберегти те, що робило це минуле цінним.

Найкращий сайт після угоди робить новий бізнес неминучим.

Найкращий сайт після угоди - не той, що має вигляд злиття. Це той, після якого здається, що новий бізнес завжди мав існувати.

FAQ