ТЗ на Битрикс24: роли, данные, интеграции и проверка внедрения

Как подготовить ТЗ на Битрикс24

Внедрение Битрикс24 начинается с решения, как компания будет работать с обращениями, а не с перечня кнопок. Один отдел считает продажей поступивший запрос, другой — подписанный договор. Если перенести эти представления в общую воронку без согласования, отчёт не объяснит состояние бизнеса. Техническое задание должно связывать действия сотрудников, данные и проверяемые результаты настройки.

Этот материал посвящён подготовке конкретного проекта Битрикс24: границам конфигурации, владельцам данных, интеграциям и приёмке. Он не заменяет общую стратегию CRM и не обещает возможности определённого тарифа. Ниже — редакционная структура задания и учебные проверки. В конце можно скачать бриф и заполнить его на примерах своей компании.

Зафиксируйте исходную конфигурацию

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

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

Функции и ограничения проверьте на конкретном портале перед оценкой. В ТЗ фиксируется требуемое поведение и подтверждённый способ его реализовать. Формулировка «как в демонстрации» не определяет ни состав работ, ни доступность механизма в вашей конфигурации.

Опишите модель клиента и сделки

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

Для каждого поля определите смысл, формат, источник и право исправления. Если реквизиты приходят из учётной системы, решите, что произойдёт после ручной правки менеджером. Победа «последнего сохранения» может незаметно вернуть старое значение. Нужны правила разрешения конфликта, журнал и очередь спорных изменений.

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

Согласуйте роли и замещение

Составьте матрицу из действий: просмотр, изменение, назначение ответственного, экспорт, объединение и удаление. Разнесите её по менеджеру, руководителю, администратору и интеграции. Проверяйте доступ обычной учётной записью каждой роли. Успешная демонстрация под администратором не доказывает, что сотрудник сможет выполнить рабочий сценарий.

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

Задайте контракт интеграции

Для каждого обмена опишите систему-источник, событие, поля, направление, подтверждение результата и поведение при повторе. Документация Битрикс24 различает входящий вебхук для вызова методов и исходящий для доставки события. Права входящего вебхука связаны с выбранной областью доступа и сотрудником. Эти особенности нужно учесть в модели прав, а секретный URL нельзя размещать в открытой документации проекта.

ТЗ должно отвечать на вопрос: что делать, если запрос был отправлен, но ответ потерялся? Повтор без сверки может создать вторую сделку. Предусмотрите внешний ключ события, проверку существующей записи и видимую очередь ошибок. Для обновлений зафиксируйте порядок: старое событие не должно перезаписать более свежие реквизиты.

Массовую выгрузку согласуйте отдельно от повседневного обмена. Нужны размер контрольной партии, допустимая задержка, ограничение нагрузки, правила повторов и ответственная сторона. Конкретные лимиты берутся из актуальной документации и конфигурации, а не из универсальной цифры в брифе.

Проведите репетицию переноса

Выберите обезличенную выборку, в которой есть повторные контакты, несколько сделок одной компании, пустые поля, вложения и бывшие сотрудники. Сверьте не только число строк, но и связи, суммы, ответственных, даты и доступность истории. Для спорного совпадения заранее определите решение: пропуск, ручное сопоставление или создание новой записи.

План переключения должен объяснять, кто и когда прекращает запись в старую систему, как переносится последний прирост и как команда узнаёт о готовности. У отката есть граница: после начала новой работы простой возврат старой базы потеряет новые обращения. Поэтому отдельно продумывают перенос изменений, возникших после переключения.

Пример приёмочного сценария

Учебный пример: постоянный клиент оставляет повторную заявку с другим адресом почты, но прежним идентификатором договора. Система должна связать обращение с нужной компанией, не объединять двух разных контактных лиц, создать отдельную сделку и назначить доступного сотрудника. Повторная доставка того же события не создаёт ещё одну сделку.

Проверка включает исходные записи, роль проверяющего, входное событие и ожидаемые изменения. После выполнения сохраняют идентификаторы объектов и журнал обмена. Затем повторяют сценарий при недоступной учётной системе: заявка остаётся видимой, ошибка попадает в очередь, а восстановление не уничтожает ручную работу менеджера. Все значения и сроки в примере заполняются под проект.

Что передать на оценку

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

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