Подрядчик пишет «всё готово», присылает ссылку на портал и счёт на остаток оплаты. Руководитель открывает CRM, видит новые стадии воронки, пару роботов и красивую карточку сделки. Кажется, что работа сделана. Через месяц менеджеры жалуются, что задачи ставятся не тем людям, заявки с сайта теряются по выходным, а доступ к половине настроек остался у сотрудника подрядчика, который уже не отвечает на звонки. Проблема почти всегда в том, что работу приняли на глаз.
Ниже практический чек-лист приёмки работ по Битрикс24, которым мы пользуемся сами, когда принимаем порталы после других интеграторов. Он подходит и для облака, и для коробки, а для коробочной версии в конце есть отдельный блок.
Почему приёмка работ по Битрикс24 срывается чаще, чем сама настройка
Битрикс24 плохо поддаётся проверке «по скриншотам». Воронка может выглядеть правильно, но робот на третьей стадии срабатывает только при определённом условии, которое никто не тестировал. Интеграция с сайтом работает в будни, а в субботу форма отправляет заявку в пустоту, потому что ответственный назначается по графику. Всё это видно только на реальных сценариях.
Вторая причина в том, что заказчик и подрядчик понимают «готово» по-разному. Для исполнителя готово, когда настройка сделана. Для бизнеса готово, когда менеджер прошёл полный путь от заявки до оплаты и нигде не споткнулся. Если этот путь не описан заранее, спорить при сдаче придётся о словах.
Третья причина организационная. Принимать работу обычно поручают тому, кто меньше всех занят. Люди, которые будут работать в системе каждый день, в приёмке участвуют редко. В итоге подпись в акте стоит, а руководитель отдела продаж видит воронку впервые уже после оплаты.
Что зафиксировать до старта, чтобы потом было что принимать
Хорошая приёмка начинается ещё на этапе договора. Если в техническом задании написано «настроить CRM под процессы компании», принять такую работу честно нельзя: любой результат формально соответствует формулировке. Перед стартом стоит договориться о нескольких вещах.
- Список сценариев, которые должны пройти от начала до конца. Например: «заявка с формы сайта создаёт лид, назначается дежурному менеджеру, через 15 минут без реакции уходит уведомление руководителю».
- Перечень сущностей: какие воронки, стадии, пользовательские поля, смарт-процессы, роботы и бизнес-процессы появятся на портале.
- Какие интеграции подключаются и под чьей учётной записью они будут работать после сдачи.
- Что считается документацией и в каком виде её передают: файл, статья в базе знаний портала, видеозапись.
- Кто со стороны заказчика принимает работу и сколько рабочих дней у него на тестирование.
Последний пункт часто недооценивают. Когда срок на проверку не оговорён, подрядчик считает работу принятой по умолчанию через пару дней, а заказчик находит ошибки через месяц и уже не может требовать исправления в рамках проекта.
Полезно заранее договориться и о формате сдачи. Лучше всего работает демонстрация, где подрядчик на созвоне проходит согласованные сценарии на портале, а заказчик задаёт вопросы и сразу записывает замечания. Час такой встречи экономит неделю переписки. После демонстрации начинается самостоятельное тестирование, и срок на проверку отсчитывается от него.
Чек-лист приёмки: CRM, воронки и карточки
С CRM удобнее начинать, потому что здесь ошибки видны быстрее всего. Проверку лучше проводить под учётной записью обычного менеджера. Администратор видит всё, и половина проблем с правами под ним просто не проявится.
- Воронки и стадии совпадают с согласованной схемой, лишних тестовых стадий нет.
- Обязательные поля действительно обязательны на нужных стадиях, и менеджер не может перевести сделку дальше без них.
- Пользовательские поля названы понятно. Поля вида «Новое поле 3» при сдаче считаются недоработкой.
- Карточка сделки, лида и контакта показывает то, что нужно менеджеру в работе, без десятка пустых блоков.
- Тестовые сделки, контакты и компании удалены или помечены, чтобы не попасть в отчёты.
- Справочники (источники, типы сделок, причины отказа) заполнены значениями компании, шаблонные варианты удалены.
Отдельно проверьте корзину CRM: раздел «CRM» → «Ещё» → «Корзина». По данным справки Битрикс24, удалённые элементы хранятся там до 30 дней, администратор видит всё удалённое, а сотрудник только то, что удалил сам. Если подрядчик в процессе настройки чистил базу, по корзине видно, что именно ушло. Если там оказались рабочие контакты, их ещё можно восстановить, но срок ограничен, поэтому смотреть стоит в первые же дни после сдачи.
Ещё два пункта, о которых вспоминают поздно. Первый касается отчётов: руководитель должен открыть свои привычные отчёты по воронке и менеджерам и увидеть там осмысленные цифры. Если стадии переименовали или объединили, старые отчёты и фильтры могут показывать пустоту, и лучше узнать об этом до планёрки в понедельник. Второй пункт про мобильное приложение. Многие менеджеры работают с телефона, поэтому попросите одного из них открыть сделку, сменить стадию и заполнить обязательные поля со смартфона. Карточка, удобная на широком мониторе, на маленьком экране иногда превращается в длинную ленту, где нужное поле приходится искать.
Роботы, бизнес-процессы и интеграции
Автоматизация составляет самую рискованную часть приёмки. Роботы и бизнес-процессы срабатывают по условиям, и проверить их можно только прогоном реальных сценариев. Мы советуем составить таблицу: сценарий, ожидаемый результат, фактический результат, кто проверял и когда.
Минимальный набор проверок по автоматизации:
- Каждый робот запускается на своей стадии и делает ровно то, что написано в ТЗ: ставит задачу, отправляет письмо, меняет поле.
- Условия роботов проверены на граничных случаях: пустое поле, сделка без контакта, повторная заявка от существующего клиента.
- Уведомления приходят адресатам из ТЗ. Частая ошибка: все сообщения уходят сотруднику, который создал робота.
- Бизнес-процессы доходят до конца и не зависают на шаге согласования.
- Заявки с сайта, из форм и открытых линий попадают в CRM в рабочее и нерабочее время.
- Интеграции (телефония, сайт, учётная система, мессенджеры) проверены на тестовой и на реальной записи.
Если бизнес-процесс ведёт себя странно, у подрядчика есть инструмент диагностики: журнал отладки бизнес-процессов. Справка Битрикс24 уточняет, что в облачной версии запись в журнал можно включить только на семь дней, после чего события перестают записываться. Поэтому просить подрядчика «посмотреть логи» через месяц после сдачи бесполезно. Сложные процессы стоит тестировать, пока исполнитель ещё на связи и может включить отладку.
Интеграции проверяйте без участия подрядчика. Попросите менеджера отправить заявку с сайта с мобильного телефона, позвонить на номер компании с личного номера, написать в подключённый мессенджер. Если хоть одно обращение не появилось в CRM, работа не готова, как бы аккуратно ни выглядели настройки.
Права доступа, вебхуки и учётные записи подрядчика
Этот блок чаще всего пропускают, и именно он создаёт самые дорогие проблемы после расставания с исполнителем. Приёмка работ по Битрикс24 без проверки доступов неполная, даже если CRM и автоматизация работают идеально.
Права в CRM настраиваются через роли: «CRM» → «Ещё» → «Настройки» → «Права доступа к CRM». Проверьте, что роли соответствуют структуре компании, а менеджер одного отдела не видит сделки другого, если так договаривались. Справка Битрикс24 отдельно предупреждает о конфликтах прав, когда одному сотруднику назначены противоположные права, например минимальные через отдел и максимальные лично. После сдачи такие конфликты находят, только когда кто-то внезапно видит чужую базу, поэтому лучше пройтись по ролям заранее.
Дальше учётные записи. Что нужно выяснить до подписания акта:
- Сколько администраторов на портале и кто они. Администраторские права сотрудников подрядчика после сдачи снимаются или фиксируются в договоре поддержки.
- Под чьими пользователями созданы входящие вебхуки и локальные приложения.
- Какие приложения установлены из Маркета, кто их устанавливал и на кого оформлены подписки.
- Не остались ли на портале приглашённые пользователи подрядчика, которые занимают платные места.
С вебхуками связана конкретная ловушка. Вебхук привязан к пользователю, под которым создан. В облачном Битрикс24 при увольнении сотрудника с активными интеграциями система предлагает выбор: «Сохранить интеграции и уволить», и тогда Битрикс24 создаёт системного пользователя и переносит вебхуки на него, или «Отключить интеграции и уволить», и тогда вебхуки перестают работать. Если интеграцию сделали под учётной записью сотрудника подрядчика, а вы отключите его без этого выбора, заявки с сайта или данные из учётной системы могут перестать приходить. Безопаснее сразу договориться, что рабочие интеграции создаются под служебной учётной записью компании.
Документация и передача дел
Портал без описания превращается в чёрный ящик. Через полгода никто не вспомнит, зачем в воронке стоит робот, который меняет поле «Сегмент», и можно ли его удалить. Новый подрядчик или штатный администратор будет разбираться с нуля, а это оплачиваемые часы.
Минимальный комплект документации при сдаче:
- Схема воронок со стадиями и пояснением, что означает каждая.
- Список роботов и бизнес-процессов: где стоят, что делают, от каких полей зависят.
- Список интеграций с указанием сервиса, способа подключения и учётной записи.
- Перечень пользовательских полей и смарт-процессов с назначением.
- Короткие инструкции для сотрудников по основным операциям.
- Контакты и порядок обращения, если что-то сломается после сдачи.
Документацию удобно хранить прямо на портале, чтобы она не потерялась в переписке. Формат менее важен, чем актуальность: описание, сделанное за неделю до финальных правок, уже не соответствует системе.
Как оформить замечания, чтобы их исправили без споров
Список замечаний в мессенджере вида «воронка не работает» подрядчик честно не сможет исправить: непонятно, что именно сломалось и как это повторить. Каждое замечание должно отвечать на три вопроса: что делали, что ожидали увидеть и что получили на самом деле. Хорошо, если к нему приложены ссылка на конкретную сделку и скриншот.
Замечания удобно сразу делить по критичности. Критичные мешают работать или ведут к потере данных: заявки не попадают в CRM, менеджер видит чужую базу, робот удаляет или перезаписывает поля. Существенные не блокируют работу, но расходятся с ТЗ: неправильный ответственный в задаче, лишнее уведомление. Косметические касаются названий, порядка полей и оформления. Акт логично подписывать, когда закрыты все критичные и существенные пункты, а косметику можно доделать в течение оговорённого срока.
Список лучше вести в одном месте, например в задаче на портале с чек-листом, где подрядчик отмечает исправления, а заказчик перепроверяет. Так через полгода легко восстановить, что было найдено при сдаче и что исправили. Если отношения с подрядчиком испортятся, такой список станет основой для разговора о гарантиях.
После исправлений повторите прогон тех сценариев, где были ошибки. Правка одного робота нередко ломает соседний, особенно если они зависят от одного поля.
Как провести приёмку на живых данных: пример из практики
Условный пример, собранный из типичных ситуаций, с которыми к нам приходят клиенты. Торговая компания в Алматы, 12 менеджеров, две воронки: розница и опт. Подрядчик за месяц настроил CRM, подключил форму сайта и телефонию, сдал работу и выставил акт.
Руководитель отдела продаж решил не подписывать акт сразу и выделил три дня на тестовый прогон. В первый день двое менеджеров вели все новые заявки только в Битрикс24 и отмечали в общей таблице всё, что шло не так. Во второй день проверяли права: менеджер оптового отдела зашёл под своей учётной записью и увидел все розничные сделки, хотя по ТЗ доступ должен был быть закрыт. Причина оказалась в том самом конфликте прав через отдел и личную роль. В третий день разбирали интеграции и выяснили, что вебхук формы сайта создан под личной учётной записью программиста подрядчика.
По итогам прогона набралось 14 замечаний, из них три критичных: права, вебхук и робот, который ставил задачу на уволенного сотрудника из шаблона. Подрядчик исправил всё за четыре рабочих дня в рамках проекта. Если бы акт подписали в день сдачи, эти правки стали бы отдельной платной работой, а утечка базы между отделами могла бы остаться незамеченной.
Из этого примера полезно забрать сам порядок: сначала реальная работа менеджеров, затем проверка под их учётными записями, затем интеграции и служебные доступы. Замечания фиксируются письменно, с критичностью и сроком исправления.
Особенности приёмки коробочного Битрикс24
В коробочной версии к списку выше добавляются вопросы инфраструктуры, за которые в облаке отвечает вендор. Сервер, резервные копии и обновления теперь на стороне компании или её подрядчика.
- Резервное копирование настроено и проверено восстановлением. В административной части это раздел «Настройки» → «Инструменты» → «Резервное копирование». Бэкап, который ни разу не разворачивали, нельзя считать бэкапом.
- Выполнена проверка системы средствами платформы, результаты сохранены.
- Доступы к серверу, базе данных и панели хостинга переданы заказчику, пароли сменены после сдачи.
- Изменения в коде описаны: какие модули и шаблоны правились, где лежат доработки. Правки ядра без описания могут сломаться при следующем обновлении.
- Понятно, кто и как устанавливает обновления продукта.
Если доработки в коробке серьёзные, спросите, где подрядчик их тестировал. Правки, которые сразу вносились на рабочий портал, без тестовой копии, увеличивают риск простоя при следующих изменениях. Для крупных проектов разумно требовать, чтобы новые доработки сначала проверялись на копии, а на рабочий сервер переносились по согласованию. Заодно стоит уточнить, как откатить изменение, если после переноса что-то пошло не так.
По коробке мы рекомендуем принимать работу вместе с человеком, который разбирается в серверной части. Руководитель проверит бизнес-сценарии, но оценить, выдержит ли сервер нагрузку и восстанавливается ли бэкап, без технического специалиста сложно.
Когда приёмку лучше доверить техподдержке Битрикс24
Самостоятельная приёмка работает, если в компании есть человек, который хорошо знает Битрикс24 и выделил на проверку несколько дней. Если такого человека нет, есть смысл пригласить независимую техническую поддержку Битрикс24 на этапе сдачи. Внешний специалист не заинтересован в том, чтобы работа была принята быстрее, и знает, где у интеграторов обычно остаются хвосты.
Команда B2BPRO.KZ проводит приёмку проектов других подрядчиков: проверяем CRM, роботов, права, вебхуки и документацию, готовим список замечаний с приоритетами, который можно передать исполнителю. После сдачи проекта портал можно оставить у нас на сопровождении, и тогда техподдержка Битрикс24 работает 24/7 и не зависит от графика прежнего исполнителя. Заявки по сломавшимся интеграциям или зависшим процессам мы принимаем 24/7, включая выходные, когда такие сбои обычно и случаются. Подробнее о формате сопровождения на странице техподдержка Битрикс24 24/7.
Независимая проверка особенно полезна в трёх ситуациях: проект крупный и оплачивается этапами, в портале завязаны деньги (оплаты, счета, интеграция с учётной системой), или вы уже однажды расстались с подрядчиком тяжело и не хотите повторения.
Частые вопросы
Сколько времени закладывать на приёмку работ по Битрикс24?
Для небольшого проекта с одной-двумя воронками обычно хватает трёх-пяти рабочих дней реальной работы менеджеров в системе. Для проектов с интеграциями и бизнес-процессами лучше закладывать от недели. Срок стоит прописать в договоре заранее.
Можно ли подписать акт частично?
Да, если договор разбит на этапы. Удобно принимать каждый этап отдельно: сначала CRM и воронки, затем автоматизацию, затем интеграции. Так замечания не копятся к финалу, и спорные пункты не блокируют оплату всего проекта.
Что делать с учётными записями подрядчика после сдачи?
Сначала выяснить, какие вебхуки и приложения созданы под этими пользователями, и перенести их на служебную учётную запись. В облачном Битрикс24 при увольнении пользователя с активными интеграциями система предлагает сохранить интеграции через системного пользователя. Только после этого снимать права администратора и отключать пользователей.
Кто отвечает за ошибки, найденные после подписания акта?
Это зависит от гарантийных условий договора. Если гарантийный срок не прописан, исправления после подписания акта подрядчик вправе выполнять как новую работу. Поэтому ключевые сценарии лучше проверить до подписи.
Нужна ли техподдержка Битрикс24, если подрядчик сдал проект без замечаний?
Портал меняется вместе с бизнесом: появляются сотрудники, новые воронки, обновления продукта. Техническая поддержка Битрикс24 нужна, чтобы кто-то отвечал за систему после завершения проекта и реагировал на сбои без ожидания нового договора.