Смену CRM-интегратора лучше начинать с передачи управления системой: доступов, описания настроек, исходников доработок и ответственности за работающие связи. Отключать прежнего исполнителя стоит по согласованному плану после проверки зависимостей. Сам по себе вход нового администратора не доказывает, что передача завершена.
Результат перехода — акт с реестром переданных объектов, проверками и незакрытыми вопросами. Ниже приведён рабочий шаблон технической передачи. Он помогает принять систему, но не заменяет договор и юридическое оформление прав на разработки.
Что согласовать до передачи
Назначьте со стороны компании человека, который принимает систему и определяет приоритеты. Укажите дату и часовой пояс перехода, контакт прежнего исполнителя, нового ответственного и порядок разбора сбоев. На время передачи договоритесь о регистрации всех изменений: иначе описание будет устаревать быстрее, чем его проверяют.
Смена подрядчика не требует автоматически переносить CRM в новый аккаунт. Сначала выясните, можно ли сохранить действующую систему и передать управление. Переезд данных — отдельная задача со своими ограничениями; его не следует добавлять к смене исполнителя без причины.
Зафиксируйте исходное состояние: какие сценарии работают, какие уже неисправны, где есть недоделки. Для поиска разрывов пригодится самостоятельный аудит CRM. В акте отделите известные проблемы от ошибок, появившихся при переходе.
Какие доступы и материалы запросить
Запрашивайте управление рабочими ресурсами компании и сведения о зависимостях. Пароль к личной учётной записи подрядчика не должен становиться постоянным способом администрирования. Новому исполнителю нужен отдельный доступ с достаточными для задачи правами.
| Объект | Что получить | Как проверить |
|---|---|---|
| CRM и пользователи | Административный доступ компании, список ролей, способ восстановления | Вход уполномоченного сотрудника и проверка управления пользователями |
| Лицензии и подписки | Владельцы кабинетов, сроки продления, контакты поставщиков | Компания может проверить оплату и организовать продление |
| Сайт и каналы общения | Доступы к формам, телефонии, почте и мессенджерам в согласованном объёме | Контрольное обращение доходит до нужной карточки и сотрудника |
| Интеграции | Назначение каждой связи, её владелец, права, адрес обработчика, зависимости | Известно, где выполняется обмен и как проверить ошибку |
| Собственные доработки | Репозиторий или архив исходников, версия, зависимости, инструкция запуска | Новый специалист может воспроизвести запуск в подходящей тестовой среде |
| Серверы и задания | Управление хостингом, доменами, расписаниями и журналами | Понятны оплата, восстановление и ответственный за обслуживание |
| Документация | Схема процесса, поля, автоматизации, исключения, инструкции пользователей | Описание соответствует проверенным рабочим сценариям |
| Незавершённые работы | Задачи, договорённости, обращения к поставщикам и известные ограничения | У каждого пункта есть новый владелец и следующий шаг |
Секреты храните отдельно от акта: в нём достаточно указать место защищённого хранения, владельца и факт проверки. Не включайте действующие токены, пароли и полные секретные адреса вебхуков в общую таблицу или открытую переписку.
Как передать amoCRM новому интегратору
Сначала проверьте, есть ли у компании собственный административный доступ. Если он потерян, официальная инструкция amoCRM предусматривает обращение в поддержку и письмо владельца аккаунта с указанием нового администратора. Восстановление выполняется после проверки данных; наличие доступа у нового подрядчика само по себе не заменяет эту процедуру. Порядок восстановления доступа amoCRM.
- Зафиксируйте пользователей, воронки, поля, правила распределения, автоматизации и установленные интеграции.
- Предоставьте новому специалисту отдельную учётную запись и проверьте нужные права.
- Выясните, от чьей авторизации зависят внешние приложения и где работают собственные обработчики.
- Проверьте новые и повторные обращения, задачи, сообщения и используемые отчёты на контролируемых примерах.
- По согласованному плану отзовите ненужные доступы прежнего исполнителя, затем повторите проверки зависимых связей.
Изменение пароля пользователя не следует считать доказательством отключения всех внешних доступов. Для каждого подключения нужен отдельный ответ: кто имеет доступ, как он отзывается и что произойдёт с рабочим обменом.
Как передать Битрикс24 и сохранить рабочие связи
В Битрикс24 отдельно проверьте пользователей, приложения, вебхуки и внешние обработчики. Официальная документация описывает важную особенность: при редактировании администратором чужого вебхука меняется его секретный код и владелец. Поэтому даже действие, похожее на обычную правку настройки, может потребовать обновления подключения во внешней системе. Документация по вебхукам и приложениям.
Составьте перечень зависимых систем до изменения ключей. Для каждой связи определите окно переключения, исполнителя на обеих сторонах, тест и порядок действий при ошибке. Переключайте согласованные связи последовательно, чтобы было понятно, какое изменение повлияло на результат.
Для коробочной установки в акт дополнительно включают сервер, базу данных, файлы, резервные копии и процедуру восстановления. Для облачной CRM уточняют доступные способы выгрузки и восстановления у платформы. Экспорт списка сделок не равен полной копии системы: отдельно проверяются файлы, история, настройки и интеграции. Обещание «без потери данных» должно опираться на проверенный план, а не только на наличие архива.
Кому принадлежат доработки CRM
Разделите собственную разработку по заказу, готовый платный модуль и сторонние компоненты. Передача доступа к серверу, получение исходников и переход исключительного права — разные вопросы. Оплата работ сама по себе не объясняет условия для каждого компонента.
Для договоров, регулируемых российским правом, статья 1296 ГК РФ устанавливает общее правило об исключительном праве заказчика на произведение, специально созданное по договору заказа, если договором не предусмотрено иное. При этом статья содержит исключение для договора с самим автором. Нельзя применять одно правило ко всем доработкам без проверки предмета договора и состава исполнителей. Текст статьи 1296 ГК РФ.
Для каждого модуля запросите документальное основание использования, условия изменения и передачи на обслуживание, сведения о лицензиях зависимостей и составе выдаваемых исходников. Спорные условия конкретного договора стоит разобрать с юристом до переноса или изменения кода. Технический акт фиксирует, что получено и проверено, но не создаёт отсутствующие права.
Что делать, если документации нет
Начните с обследования текущей конфигурации, не меняя работающие настройки без необходимости. Сопоставьте путь заявки с полями, автоматизациями, интеграциями и внешними заданиями. Используйте доступные журналы и контролируемые тесты; сохраняйте найденные зависимости с указанием источника подтверждения.
Отмечайте степень уверенности: «подтверждено тестом», «со слов исполнителя», «не проверено». Если назначение обработчика неизвестно, не объявляйте его ненужным только потому, что он не сработал во время короткой проверки. Он может обслуживать редкий этап или периодическое событие.
Запросите у прежнего подрядчика запись демонстрации основных сценариев, описание нестандартных правил и список открытых задач. Если получить их невозможно, внесите пробелы в акт, назначьте ответственных за обследование и определите, какие изменения откладываются до выяснения зависимостей.
Шаблон акта технической передачи
Скопируйте структуру в рабочий документ. В каждой строке реестра используйте статус: «принято», «принято с ограничением» или «не передано».
- Система и участники: адрес CRM, компания, передающий, принимающий и уполномоченный представитель заказчика.
- Момент передачи: дата, время, часовой пояс и граница ответственности сторон.
- Реестр объектов: название, назначение, владелец, место хранения, версия или дата состояния, способ проверки и статус.
- Доступы: выданные роли, проверивший сотрудник, место хранения секретов, перечень отозванных доступов и запланированных замен.
- Копии и восстановление: состав копии, дата, место хранения, выполненная проверка восстановления и непокрытые данные.
- Приёмочные сценарии: ожидаемый результат, фактический результат, тестовая запись и проверяющий.
- Ограничения и открытые задачи: влияние на работу, ответственный, следующий шаг и срок пересмотра.
- Подтверждение передачи: замечания сторон, приложения и согласованная форма подтверждения.
Учебный пример строки: «Обработчик заявок сайта; версия из репозитория на дату передачи; развёрнут в тестовой среде; заявка создаёт сделку и назначает менеджера; принято с ограничением — повторная отправка требует проверки; ответственный и дата проверки указаны в задаче». Вместо оценки «всё работает» запись показывает проверенный сценарий и оставшийся риск.
Когда передачу можно считать завершённой
- Компания управляет административным доступом и восстановлением учётных записей.
- Новый исполнитель находит настройки, исходники и журналы без личных пояснений предшественника.
- Пройдены согласованные тесты заявок, звонков, сообщений, распределения и ключевых автоматизаций.
- После отзыва прежних доступов проверены затронутые интеграции.
- Ограничения копирования и восстановления известны; незакрытые вопросы имеют владельцев.
- Понятно, кто принимает обращения после даты перехода и кто согласует изменения.
Не закрывайте передачу формально, если единственный рабочий сервер или способ восстановления по-прежнему недоступен компании. Зафиксируйте частичную передачу и конкретный план завершения.
С заполненным реестром можно обсудить смену интегратора CHECK CRM. После приёмки удобно перейти к регулярному сопровождению с понятными границами; критерии такого формата разобраны в статье о составе и результате сопровождения CRM.