Компания не прирастает к чужому сервису целиком — она прирастает в трёх местах. Первое: канал связи с клиентом, когда номера и переписка существуют только внутри мессенджера. Второе: данные, когда единственная полная копия клиентской базы, сделок и документов лежит в чужом облаке. Третье: сценарии автоматизации, когда рабочая логика существует в виде схемы внутри конструктора и больше нигде. Развязать эти три узла — и смена любого сервиса становится задачей на дни; не развязать — и каждая смена стоит как половина первоначального внедрения.
За последние полтора года такие переезды перестали быть теоретическим упражнением. WhatsApp, включая Business API, заблокирован в России с февраля 2026 года. Notion, Miro, HubSpot, Salesforce, ClickUp, Coda, Slack, Zapier, Make, Power BI и Tableau ушли с рынка. Telegram по состоянию на сентябрь 2026 года работает, но с ограничениями: звонки ограничены с августа 2025 года, в 2026-м добавилась деградация медиа. Ни одно из этих событий нельзя было предсказать за год, и следующее предсказать тоже нельзя — поэтому проектировать надо не под конкретный сервис, а под его замену.
Ниже — как выглядит развязка каждого из трёх узлов, сколько она добавляет к проекту и в каких случаях эта запасливость не окупается. Расчёты модельные и построены на одном проекте: клиентский контур на 900 000 ₽ — связка мессенджера с CRM, 22 живых сценария автоматизации, поток около тысячи обращений в месяц.
Три места, где возникает жёсткая привязка
Признак привязки один и тот же во всех трёх случаях: если сервис исчезнет сегодня ночью, часть вашей работы исчезнет вместе с ним, и восстановить её будет не откуда. Проверять надо не намерения вендора, а собственную способность продолжить работу без него.
| Узел | Признак привязки | Что теряется при отключении | Развязка |
|---|---|---|---|
| Канал связи с клиентом | Номера и история переписки существуют только внутри мессенджера, интеграция написана под его формат | Возможность написать своим клиентам и контекст прошлых разговоров | Слой абстракции: адаптер на канал, единый формат сообщения выше |
| Данные | Единственная полная копия базы, сделок и документов лежит в чужом облаке | Клиентская база, суммы и договорённости; выгрузка «по требованию» перестаёт работать вместе с доступом | Мастер-копия в своём контуре, сервис — витрина поверх неё |
| Сценарии автоматизации | Логика существует только как схема внутри конструктора и нигде не описана словами | Сами правила работы: кто кому что отправляет, при каком условии и с какой задержкой | Экспорт схем в хранилище версий плюс текстовое описание каждого сценария |
Важно, чего в таблице нет. В ней нет строк «интерфейс», «дизайн», «отчёты», «шаблоны писем» — всё это тоже придётся пересобирать, но это работа с понятной ценой и без риска потерять что-то безвозвратно. Три перечисленных узла отличаются тем, что при потере доступа восстановление либо невозможно, либо стоит несопоставимо дороже, чем предусмотрительность.
Карта связей. В центре прямоугольник «свой контур», внутри три блока: «список клиентов и идентификаторы», «мастер-копия данных», «описания и версии сценариев». Слева и справа — пунктирные силуэты внешних сервисов: «мессенджер», «CRM или облачный сервис», «интеграционная платформа», каждый подписан «сменяемый». Между контуром и каждым сервисом нарисован быстросъёмный разъём с ценником: «адаптер канала — 35 000 ₽», «выгрузка мастер-копии — 70 000 ₽ разово», «экспорт сценариев — 45 000 ₽ разово». Внизу подпись: «замена сервиса = один разъём». Чертёжный стиль, подписи по-русски.
Узел первый: канал связи
Самая частая ошибка в интеграциях — писать связку под конкретный мессенджер. Тогда его формат сообщения, его способ отдавать вложения и его идентификатор пользователя расползаются по всему коду: по правилам создания сделок, по маршрутизации на менеджера, по текстам автоответов. Смена канала после этого — не подключение нового, а разбор того, что успело врасти.
Развязка состоит из четырёх правил. Единый внутренний формат сообщения, к которому приводятся все каналы на входе. Свой идентификатор клиента — телефон и внутренний номер в базе, а идентификатор мессенджера хранится рядом как одно из полей, а не вместо ключа. История переписки пишется в ваш архив в момент прохождения через прослойку, а не выгружается потом, когда доступа уже нет. И один изолированный адаптер на канал: получить сообщение, отправить ответ, отдать вложение — всё остальное живёт выше и переживает смену канала.
В деньгах это выглядит так. Слой абстракции при первичной связке — 20 000–25 000 ₽ и примерно неделя работы, около 15 % к стоимости связки с CRM. Новый адаптер при смене канала — 35 000 ₽ и 3–5 дней. Та же смена без абстракции — переписывание связки заново, 180 000 ₽ и 4–6 недель, причём в условиях, когда канал уже не работает. Подробный разбор трёх стратегий готовности и регламент первых 48 часов после ограничения канала мы вынесли в отдельный материал раздела; здесь важен только принцип.
В новых внедрениях основным каналом мы берём MAX: он работает, у него есть бизнес-профиль с верификацией через Госуслуги и Bot API. Прямых официальных интеграций MAX с amoCRM и Битрикс24 на сентябрь 2026 года нет, связка идёт через собственную прослойку. Но выбор канала — это решение на сегодня, а не навсегда: архитектура закладывается на смену канала независимо от того, какой из них сейчас основной. Статус каналов волатилен, и за полтора года он менялся трижды.
Узел второй: мастер-копия у нас, сервис — витрина
Второй узел ломается тише всего и обнаруживается последним. Пока сервис работает, разница между «данные в облаке» и «данные у нас» незаметна: выгрузка доступна, экспорт есть в меню, вендор обещает отдать всё по запросу. Проблема в том, что все эти способы получить данные работают ровно до того момента, когда они понадобятся по-настоящему. Односторонне закрытый доступ забирает с собой и кнопку экспорта.
Полная копия данных в вашем контуре, которая пополняется по расписанию и не зависит от доступа к сервису. Внешняя система при этом остаётся витриной: в ней удобно работать, но она не является единственным местом, где эти данные существуют.
Правило формулируется в одну строку: мастер-копия у нас, сервис — витрина. Практически это означает ежесуточную выгрузку в своё хранилище, а не «экспорт при необходимости», и разное наполнение для разных систем.
| Система | Что уходит в мастер-копию | Периодичность | Что это даёт при потере доступа |
|---|---|---|---|
| CRM | Контакты, сделки, суммы, ответственные, история статусов, файлы вложений | Ежесуточно, инкрементально | Компания продолжает продавать: список клиентов и договорённости на руках |
| Переписка с клиентами | Сообщения с привязкой к клиенту и сделке, вложения | В момент прохождения через прослойку | Контекст разговора не теряется, менеджер видит его в карточке |
| Аналитика и отчётность | Не дашборды, а слой данных под ними: витрины, справочники, меры | Ежесуточно | Отчёты пересобираются на любой платформе за дни, а не восстанавливаются по памяти |
| Документы и договоры | Файлы плюс реквизиты и связи с контрагентом | При изменении | Юридически значимые документы остаются доступны независимо от сервиса |
| Учёт и склад | Обычно уже в своём контуре — проверяется только резервное копирование | По регламенту резервных копий | Здесь риск не в доступе, а в отсутствии проверенного восстановления |
Настройка такой выгрузки на типовом контуре стоит 40 000–90 000 ₽ разово, в нашем модельном проекте — 70 000 ₽, и 3 000 ₽ в месяц на хранение. Дальше начинается неприятная часть, о которой обычно молчат: копия, которую ни разу не восстанавливали, копией не является. Раз в квартал из мастер-копии надо поднимать тестовый контур и убеждаться, что данные читаются и связи не потерялись. Это полдня работы и единственный способ узнать правду до того, как она понадобится. Как мы разграничиваем доступы к таким копиям и что фиксируем в договоре с подрядчиком, описано на странице о безопасности.
Схема из двух частей. Сверху «Как обычно»: блок «внешний сервис» с подписью «единственная полная копия», от него тонкая стрелка вниз «экспорт по требованию», перечёркнутая крестиком с пометкой «перестаёт работать вместе с доступом». Снизу «Как надо»: слева блок «источники: CRM, переписка, документы, учёт», от него сплошная стрелка «ежесуточная выгрузка» в блок «мастер-копия в своём контуре — 70 000 ₽ разово, 3 000 ₽ в месяц», а над мастер-копией пунктирный блок «внешний сервис — витрина, сменяемый». Отдельной строкой внизу: «раз в квартал — тестовое восстановление, полдня». Чертёжный стиль, подписи по-русски.
Узел третий: сценарии, живущие только в чужом облаке
Третий узел — самый обидный, потому что теряется не техника, а знание. Сценарий автоматизации в облачном конструкторе выглядит как схема из блоков: пришла заявка — создали сделку — отправили сообщение — подождали три дня — напомнили. Пока конструктор доступен, эта схема и есть документация. Когда доступ пропадает, выясняется, что правила работы компании нигде больше не записаны, и восстанавливать их приходится по памяти сотрудников и по следам в данных.
Отсюда два правила. Первое: у каждого сценария есть текстовое описание на пять-десять строк — что запускает, что делает, при каком условии останавливается, кто владелец. Второе: схемы регулярно выгружаются из платформы в ваше хранилище версий, и выгрузка автоматическая, а не «когда вспомним». Оба правила ничего не стоят, если заведены сразу, и стоят очень дорого, если заводить их задним числом.
Описание сценария — это не документация в общепринятом смысле и не техническое задание. Это пять строк в таблице, которые заполняет тот, кто сценарий собирал: что запускает (событие или расписание), какие системы участвуют, что происходит по шагам, при каком условии сценарий останавливается или передаёт дело человеку, кто владелец и к кому идти с вопросами. На 22 сценария такая таблица занимает три-четыре страницы и полтора рабочих дня, а стоит она столько же, сколько стоит время сотрудника: подрядчик для этого не нужен. Побочный эффект приятнее основного — при заполнении таблицы обычно выясняется, что часть сценариев дублирует друг друга, а у двух-трёх вообще нет владельца, потому что человек, который их придумал, уже не работает в компании.
Цифра в 22 сценария не случайна: в типовой инвентаризации из 34 работающих сценариев живыми оказываются 22, а 12 выключаются без последствий. Разбор того, как переносить сценарии после ухода зарубежных конструкторов и какие российские платформы для этого годятся, мы вынесли в отдельный материал — там же сравнение стоимости владения облаком и своей установкой за три года.
Сценарий, от которого зависит выставление счёта, напоминание об оплате или передача заказа на склад, стоит держать не в облачном конструкторе, а в своём сервисе. Разница в стоимости разработки — часы, разница в последствиях — остановка денежного потока в тот день, когда платформа стала недоступна. Всё остальное — уведомления, отчёты, вспомогательные оповещения — спокойно живёт в конструкторе.
Цена запаса: 140 000 ₽ вперёд и 8 000 ₽ в месяц
Теперь честная часть. Запасливость не бесплатна, и продавать её как «почти ничего не стоит» — обман. На модельном проекте в 900 000 ₽ развязка трёх узлов добавляет 140 000 ₽ разово, то есть около 16 % к бюджету, и 8 000 ₽ в месяц на хранение мастер-копии и сопровождение выгрузок.
Вывод из расчёта не тот, которого ждут. По деньгам на одном переезде за три года разница невелика — 116 500 ₽ при бюджете проекта под миллион. Настоящая разница в другом: восемь-двенадцать недель без нормально работающего контура против одной-двух. Всё это время заявки принимаются вручную, часть теряется, менеджеры работают без истории клиента, а уведомления об оплате не уходят. Посчитать эти потери можно только по упавшей выручке, и обычно они превышают всю разницу в смете. Если же переездов за три года будет два — а за последние полтора года их было именно два, — арифметика перестаёт быть спорной.
График накопленных расходов за 36 месяцев. Горизонтальная ось — месяцы, вертикальная — рубли. Линия «с запасом» стартует с 140 000 ₽ и растёт равномерно по 8 000 ₽ в месяц, на восемнадцатом месяце даёт небольшую ступеньку +247 500 ₽ с подписью «переезд, 1–2 недели», финиш 675 500 ₽. Линия «без запаса» идёт по нулю, на восемнадцатом месяце даёт резкую ступень +792 000 ₽ с подписью «переезд, 8–12 недель», финиш 792 000 ₽. Заштрихованная зона на восемнадцатом месяце подписана «работа вручную, потери не в этом графике». Подписи по-русски, единицы — рубли.
Тест из пяти вопросов: за сколько дней вы переедете
Проверить свою готовность можно за один разговор с тем, кто отвечает за системы. Вопросы намеренно сформулированы так, чтобы на них нельзя было ответить «в целом да».
- 1Если завтра закроется ваш основной канал связи с клиентами, за сколько часов вы сможете написать всем активным клиентам? Ответ «выгрузим из мессенджера» не засчитывается: выгружать будет неоткуда.
- 2Можете ли вы сегодня получить файлом полную базу контактов, сделок и переписки за последние 12 месяцев, не обращаясь к вендору и не заходя в его интерфейс?
- 3Сколько сценариев автоматизации существуют только как схема в чужом облаке и не описаны словами нигде больше? Назовите число, а не «у нас всё задокументировано».
- 4Сколько мест в коде и настройках надо изменить, чтобы подключить второй мессенджер? Правильный ответ — «одно, адаптер»; любой другой означает, что канал врос в логику.
- 5Кто, кроме подрядчика, знает, как устроена связка, и есть ли у вас на руках все ключи, токены и учётные записи внешних сервисов? Отдельная зависимость от человека опаснее зависимости от платформы.
| Сколько ответов уверенных | Оценка срока переезда | Что делать в первую очередь |
|---|---|---|
| Пять из пяти | 1–2 недели, около 247 500 ₽ | Ничего срочного: проверить, что мастер-копия восстанавливается, и жить дальше |
| Три-четыре | 3–5 недель | Закрыть слабый узел точечно — обычно это описания сценариев за 45 000 ₽ |
| Два и меньше | 8–12 недель, около 792 000 ₽ | Начать с мастер-копии данных: она защищает от необратимых потерь, остальное восстановимо |
Порядок в последней колонке не случаен. Если развязывать узлы приходится по очереди и с ограниченным бюджетом, первым идут данные: канал и сценарии можно пересобрать за деньги, а потерянную базу клиентов не пересобрать ни за какие. Вторым — сценарии, потому что описания стоят дёшево и делаются без подрядчика. Абстракция канала идёт третьей: она самая техничная и естественнее всего закладывается в момент, когда связка и так переделывается.
Лента времени из трёх этапов слева направо. Этап 1 «Мастер-копия данных» — подпись «70 000 ₽, 1–2 недели, защищает от необратимых потерь». Этап 2 «Описания и экспорт сценариев» — подпись «45 000 ₽, делается силами компании, экономит 269 500 ₽ при переезде». Этап 3 «Абстракция канала» — подпись «25 000 ₽, закладывается при следующей переделке связки, адаптер потом 35 000 ₽». Под лентой итоговая плашка: «140 000 ₽ — полная развязка трёх узлов». Чертёжный стиль, подписи по-русски.
Когда запас не нужен
Универсального ответа «закладывайте всегда» здесь нет, и продавать запасливость всем подряд было бы нечестно. Есть три ситуации, в которых мы сами советуем этого не делать.
- Короткий горизонт. Если система заводится под проект на год — сезонную кампанию, разовую поставку, пилот направления, — запас превращается в чистый убыток: 140 000 ₽ вложений плюс 96 000 ₽ содержания за двенадцать месяцев, то есть 236 000 ₽ за страховку от события, которое, скорее всего, не наступит в этот срок.
- Малый объём операций. При потоке до сотни обращений в месяц и базе в несколько сотен контактов ручное восстановление реально: список клиентов помещается в таблицу, сценариев три, переписка не критична. Здесь дешевле раз в месяц выгружать контакты руками и не строить контур вовсе.
- Сервис внутри своего контура. Если система стоит на вашем сервере, а данные и так у вас, дублировать развязку незачем — риск здесь не в потере доступа, а в отсутствии проверенных резервных копий, и лечится он регламентом восстановления, а не архитектурой.
И одно замечание, которое стоит всех расчётов выше. Развязка узлов не защищает от ухода сервиса — она защищает от того, чтобы уход сервиса стал вашей проблемой. Разница в том, что первое невозможно, а второе достигается тремя решениями, принятыми заранее, и стоит около 16 % проекта. Что именно из этого стоит зафиксировать в договоре с подрядчиком, чтобы архитектура получилась такой на деле, а не на словах, мы разбирали в материале о договоре на разработку.
Внешний сервис — расходуемый ресурс. Проектируйте не под него, а под его замену.
