Подхват Bitrix24 от другого подрядчика

С короткой стартовой сессии и заявки на аудит. Обсуждаем, какой портал — облако или коробка, какие воронки и роботы критичны, какие интеграции подключены, что произошло с прошлой командой, какие доступы и аккаунты уже на вашей стороне. По запросу подписываем NDA. Дальше — аудит воронок, прав, автоматизаций, API, телефонии, мессенджеров и обменов с сайтом и 1С. Условия подхвата обсуждаем после отчёта.

Базовый аудит можно сделать на read-only-уровне: чтение настроек воронок и роботов, просмотр прав пользователей, журналы автоматизаций, список установленных приложений и webhook-эндпоинтов. Этого достаточно, чтобы построить карту рисков и список недостающих доступов. Изменения в портале без подтверждённых прав мы не делаем. Если каких-то разделов не видно даже на чтение, в отчёте отдельно фиксируем, какие выводы возможны без них, а какие — нет.

Снимаем фактическое состояние из самого портала: воронки, стадии, поля, роботы, триггеры, бизнес-процессы, установленные приложения, права. Сверяем с логами автоматизаций и реальным поведением системы. Дальше — короткая опорная документация по критичным сценариям и владельцам процессов. На этом основании можно безопасно вносить изменения, а не «по памяти прошлого подрядчика».

Да. Заходим и в облако, и в коробку. В облаке аудит и доработки идут через стандартные интерфейсы портала, REST API, webhooks и установленные приложения. В коробке добавляется серверная часть: репозиторий, ветки, внешние обработчики, инфраструктура и обновления. На стартовой сессии уточняем, что именно у вас и какие доработки сделаны поверх типовой конфигурации.

Да, если у выбранной воронки или процесса есть чёткие границы ответственности и понятные владельцы со стороны бизнеса. Аудит в этом случае фокусируется на выбранном куске, но обязательно описывает зависимости со смежными воронками, общими полями, ролями и интеграциями. Без понимания этих стыков подхват в одном месте быстро ломает соседнее.

На аудите смотрим обе стороны обмена. Часто «Bitrix24 теряет лиды» — это сломанный webhook на стороне сайта, неконсистентный контракт с 1С или потерянные ретраи на стороне внешнего сервиса. В отчёте отделяем часть, которая живёт в портале, от смежных систем и предлагаем план по каждой. При необходимости подхватим и смежные части отдельным форматом.

В первый месяц не меняем воронки и стадии без владельцев продаж, не отключаем роботов и бизнес-процессы без карты зависимостей, не перенастраиваем права массово без проверки критичных операций. Изменения, влияющие на автоматизации, идут через тестовое окружение там, где это возможно, и с возможностью отката. Доступы прошлой команды закрываем по письменному акту, а не «в фоне».

Действуем в рамках вашего права на портал, лицензию и согласованного доступа. Сначала письменный запрос со списком приложений, ключей и обработчиков от вас как владельца портала. Параллельно вы как заказчик восстанавливаете владение через консоль Bitrix24 и регистраторов внешних сервисов, где аккаунты оформлены на вас. Перевыпуск ключей идёт по согласованному плану с переключением интеграций без потери данных. Юридические переговоры с прошлым подрядчиком — зона юриста, не подрядчика.

Перед сменой администратора имеет смысл письменно зафиксировать: список активных воронок и стадий с владельцами процессов, активные роботы и бизнес-процессы, ключи API и установленные приложения, регламент изменений, доступы по ролям. Это та же база, что и для аудита, но в формате опорной документации. Если такой карты нет, риск передачи существенно выше — починить позже сложнее, чем зафиксировать сейчас.

Новое внедрение — это сборка процесса с нуля под текущие задачи бизнеса. Подхват — это работа с порталом, у которого уже есть пользователи, данные, воронки, роботы и интеграции, и который нельзя «остановить и переделать». Решения в подхвате принимаются с учётом текущего состояния и рисков для активной работы отдела продаж. Полный rewrite портала по умолчанию не предлагаем — это почти всегда длиннее и дороже, чем кажется.