Администратор меняет робота на стадии «Счёт выставлен», сохраняет, и через десять минут отдел продаж звонит с вопросом, почему клиентам ушли одинаковые письма по второму кругу. Ошибку исправляют быстро. Письма уже не вернуть, а трём клиентам приходится извиняться лично. Почти все подобные истории, с которыми к нам приходят, случились на живом портале, где правку проверяли прямо на реальных сделках. Тестовый портал Битрикс24 нужен ровно для того, чтобы такие эксперименты происходили в стороне от клиентов, данных и зарплатной ведомости.
Ниже о том, зачем бизнесу второй портал, как его завести в облаке и в коробке, что туда переносить и как организовать работу, чтобы тестовая среда приносила пользу, а не превращалась в ещё один забытый аккаунт.
Что такое тестовый портал Битрикс24 и кому он нужен
Тестовый портал Битрикс24 это отдельный портал, который повторяет устройство рабочего: те же воронки, стадии, пользовательские поля, роли и основные автоматизации. Реальных клиентов, настоящих звонков и боевых интеграций в нём нет. Всё, что может навредить, сначала запускают там, смотрят результат и только потом переносят на рабочий портал.
Кому он точно нужен:
- компаниям, где в CRM настроены роботы, триггеры и бизнес-процессы, которые сами отправляют письма, SMS, сообщения в мессенджеры или меняют суммы сделок;
- тем, у кого портал связан с учётной системой, телефонией, сайтом или маркетплейсом, и любая ошибка в обмене сразу портит документы;
- командам, которые заказывают доработки у подрядчика и хотят принимать работу до того, как она появится у менеджеров;
- владельцам коробочной версии, где обновления платформы и собственный код иногда конфликтуют между собой.
Если в портале пять пользователей и всё, что в нём есть, это задачи и календарь, отдельная тестовая среда, скорее всего, избыточна. Как только в CRM появляется автоматика, которая действует от имени компании, цена ошибки растёт, и второй портал окупается первой же предотвращённой рассылкой.
Что проверять на тестовом портале, а что можно менять сразу
Не каждая правка требует отдельного прогона. Переименовать стадию, добавить поле в карточку или поменять порядок колонок в канбане можно на рабочем портале: риск минимальный, откатить легко. Тестовая среда нужна там, где изменение запускает цепочку действий или затрагивает данные массово.
Что мы советуем всегда прогонять на тестовом портале:
- новых роботов и триггеры, особенно отправляющие сообщения клиентам;
- бизнес-процессы с условиями, циклами и изменением полей;
- массовый импорт контактов и компаний, чтобы заранее увидеть дубли и сбитые поля;
- новые приложения из Маркета, которые запрашивают широкие права доступа;
- вебхуки и собственные интеграции через REST API;
- изменения ролей и прав доступа, после которых кто-то может перестать видеть свои сделки;
- для коробки: обновления модулей и собственные доработки кода.
Хорошее правило для руководителя: если изменение может без участия человека что-то отправить клиенту, удалить или пересчитать деньги, оно сначала проходит через тестовый портал.
Как завести тестовый портал в облачном Битрикс24
В облаке отдельной кнопки «создать копию портала» нет. Тестовый портал заводят как новый портал и настраивают его по образцу рабочего.
Шаг 1. Создайте новый портал
Откройте сайт Битрикс24, нажмите кнопку бесплатной регистрации и войдите под той же учётной записью, которой пользуетесь в рабочем портале, через почту или один из доступных сервисов авторизации. Новый портал стартует на бесплатном тарифе. Дайте ему понятный адрес, по которому никто не спутает его с рабочим, например с пометкой test или sandbox в названии. В настройках портала смените название и, если хотите, цвет темы: сотрудник, открывший не ту вкладку, должен сразу понять, где он находится.
Всех сотрудников в тестовый портал приглашать не нужно. Достаточно администратора, того, кто пишет автоматизацию, и двух-трёх человек с разными ролями: руководителя отдела продаж, рядового менеджера и, если есть, бухгалтера. Так вы проверите не только работу роботов, но и то, что каждый из них видит в карточке сделки после изменения прав.
Шаг 2. Решите вопрос с тарифом
На бесплатном тарифе недоступна значительная часть инструментов автоматизации, поэтому проверить на нём сложных роботов и бизнес-процессы не получится. У Битрикс24 есть демо-режим: по справке сервиса это доступ на 15 дней к возможностям тарифа «Профессиональный», и подключить его можно только один раз. Включается он через виджет «Мой тариф» в правом верхнем углу кнопкой «Включить». После окончания демо инструменты, которых нет на текущем тарифе, отключаются, данные сохраняются, но доступ к ним ограничивается.
Из этого следует практичный вывод. Демо на тестовом портале подходит для разового крупного проекта: перестроить воронку, собрать и отладить набор бизнес-процессов, принять работу подрядчика. Для постоянной тестовой среды, где проверяют каждую правку в течение года, 15 дней мало, и тогда тестовый портал оплачивают на том же тарифе, что и рабочий. Такое решение стоит принимать, исходя из того, сколько стоит одна ошибка автоматики для вашего бизнеса.
Шаг 3. Воспроизведите структуру
Тестовый портал полезен ровно настолько, насколько он похож на рабочий. Минимальный набор для переноса:
- воронки и стадии сделок с теми же названиями и тем же порядком;
- пользовательские поля с теми же типами (строка, список, деньги, привязка к элементам CRM);
- справочники: источники, типы компаний, причины отказа;
- роли и права доступа для основных групп сотрудников;
- роботы и бизнес-процессы, которые вы собираетесь менять.
Штатного инструмента, который скопирует настройки одного облачного портала в другой целиком, в Битрикс24 нет. Для переноса данных между порталами в Маркете есть приложения-мигрёры: судя по их описаниям в справочном разделе Битрикс24, они переносят лиды, контакты, компании, сделки, задачи и проекты с сохранением связей. У каждого приложения свои лимиты, поэтому условия нужно читать на странице конкретного решения. Настройки автоматизации чаще воспроизводят вручную, и это полезно: заодно выясняется, какие роботы на рабочем портале давно никто не понимает.
Шаг 4. Заполните портал тестовыми данными
Для проверки роботов нужны сделки, контакты и компании. Здесь легко совершить главную ошибку тестовой среды: загрузить туда реальную клиентскую базу. О данных подробнее ниже, а на этом шаге достаточно создать 20-30 условных клиентов с вымышленными именами и служебными адресами почты, которые принадлежат вашей компании. Телефоны берите заведомо несуществующие или номера сотрудников, которые согласились получать тестовые сообщения.
Тестовая копия коробочного Битрикс24
С коробкой всё устроено иначе. Здесь тестовый портал обычно делают как копию рабочего: снимают резервную копию средствами продукта, разворачивают её на отдельном сервере или виртуальной машине и получают почти точный двойник со всеми настройками, модулями и доработками.
Лицензионное соглашение 1С-Битрикс допускает установку продукта для разработки и тестирования при определённых условиях, в частности без внешнего доступа к такой установке. Формулировки в разных редакциях соглашения отличаются, поэтому перед развёртыванием откройте актуальную версию для вашей редакции и сверьте условия. Если сомневаетесь, уточните у партнёра, через которого покупали лицензию.
Главная опасность копии коробки в том, что она не знает, что она копия. Сразу после восстановления тестовый портал попытается жить обычной жизнью: отправлять почту, забирать письма из подключённых ящиков, стучаться во внешние сервисы по старым ключам. Поэтому первые действия после развёртывания такие:
- отключить отправку почты: SMTP-подключения и почтовые шаблоны, чтобы клиенты не получили письма с тестового сервера;
- удалить или отключить подключённые почтовые ящики, иначе копия начнёт забирать почту параллельно с рабочим порталом;
- отключить открытые линии и коннекторы мессенджеров;
- сбросить ключи REST-приложений и переадресовать собственные интеграции на тестовые адреса внешних систем;
- поменять адрес портала в настройках сайта и главного модуля;
- очистить кеш.
Порядок важен. Если сначала запустить копию, а отключать интеграции потом, в промежутке она успеет отправить то, что накопилось в очереди. Мы делаем это на изолированной машине без выхода наружу и только потом открываем к ней доступ разработчикам.
Как переносить изменения с тестового портала на рабочий
Проверить правку мало, её ещё нужно аккуратно перенести. Именно на этом этапе теряется часть пользы от тестовой среды: робот на тестовом портале работал, а в бою ведёт себя иначе, потому что при переносе забыли одно условие или выбрали поле с похожим названием.
Порядок, которого мы придерживаемся при переносе:
- Зафиксировать, что именно переносится. Список роботов, процессов, полей и прав, которые изменились, с описанием каждого изменения. Без такого списка перенос превращается в воспоминания о том, что вроде бы меняли.
- Выбрать время. Автоматику лучше включать, когда менеджеры не ведут клиентов: вечером, рано утром или в выходной. Если что-то пойдёт не так, пострадает меньше сделок.
- Сохранить текущую версию. Перед заменой бизнес-процесса экспортируйте его шаблон, перед изменением робота сделайте скриншот его настроек. Откатиться по такой копии можно за несколько минут.
- Сначала поля и справочники, потом автоматика. Робот, который ссылается на ещё не созданное поле, либо не сохранится, либо сработает неправильно.
- Проверить на одной сделке. После переноса создайте на рабочем портале служебную сделку с вашим собственным контактом и проведите её по сценарию проверки. Только после этого снимайте ограничения и включайте автоматику для всех.
- Понаблюдать первые сутки. В первый день после переноса ответственный смотрит на новые сделки и задачи и готов быстро остановить робота, если что-то пошло не так.
Для бизнес-процессов удобно пользоваться экспортом и импортом шаблона: процесс, отлаженный на тестовом портале, выгружают в файл и загружают на рабочий. После импорта обязательно проверьте привязки к полям и пользователям, потому что внутренние идентификаторы в двух порталах могут отличаться, даже если названия совпадают.
Тестовый портал и обновления коробочной версии
Владельцам коробки тестовая копия нужна ещё по одной причине. Обновления платформы выходят регулярно, и если на портале есть собственные доработки, изменённые шаблоны или сторонние модули, обновление иногда ломает их без предупреждения. Узнавать об этом от менеджеров в понедельник утром неприятно.
Рабочая схема выглядит так: сначала обновления ставят на тестовую копию, прогоняют основные сценарии (создание сделки, движение по воронке, звонок, обмен с учётной системой, выгрузку отчётов) и смотрят журнал ошибок. Если всё в порядке, те же обновления ставят на рабочий сервер, предварительно сняв резервную копию. Если что-то сломалось, у команды есть время исправить доработку до того, как проблема затронет сотрудников. Копию для такой проверки стоит обновлять перед каждым крупным обновлением, иначе вы тестируете не тот портал, что работает в бою.
Персональные данные на тестовом портале
Самый частый аргумент против вымышленных данных звучит так: «на реальных клиентах тестировать проще, сразу видно, как будет». Это правда, и именно поэтому копия боевой базы в тестовой среде опасна. Тестовые порталы обычно защищены хуже рабочих: туда пускают подрядчиков, стажёров, временных разработчиков, пароли там проще, а контроль доступа слабее.
В Казахстане обработку персональных данных регулирует Закон РК «О персональных данных и их защите». Юридическую оценку вашей ситуации даст юрист, а с практической стороны мы рекомендуем три правила:
- в облачный тестовый портал реальную базу не переносить вообще, достаточно вымышленных клиентов;
- в коробочной копии, если без реальных данных нельзя, обезличить телефоны, почты и ИИН скриптом сразу после развёртывания;
- выдавать доступ к тестовой среде персонально и отзывать его после окончания работ подрядчика.
Как организовать работу с тестовой средой
Тестовый портал, которым никто не управляет, через полгода перестаёт быть похожим на рабочий. В нём остаются брошенные эксперименты, поля с названиями «новое2» и роботы, про которые никто не помнит, включены ли они в бою. Проверка на такой среде ничего не гарантирует.
Что помогает держать её в порядке:
- Один ответственный. Это администратор портала или ваш подрядчик по поддержке. Он решает, что и когда переносится на рабочий портал.
- Журнал изменений. Хватит простой таблицы: дата, что поменяли, кто проверил, когда перенесли. Когда через месяц кто-то спросит, откуда взялся новый робот, ответ займёт минуту.
- Одинаковые названия. Поля, стадии и роботы в тестовом и рабочем портале называются одинаково, иначе при переносе легко перепутать похожие элементы.
- Регулярная сверка. Раз в квартал сравнивайте структуру двух порталов и приводите тестовый к актуальному виду.
- Сценарии проверки. Для каждой крупной автоматизации записан сценарий: какую сделку создать, на какую стадию двинуть, что должно произойти. Тогда приёмку работы можно поручить любому сотруднику.
Пример: как тестовый портал сэкономил неделю разборов
Ниже обобщённая ситуация из практики, детали изменены. Торговая компания решила автоматизировать повторные продажи: через 30 дней после успешной сделки робот должен создавать новую сделку в отдельной воронке и ставить менеджеру задачу позвонить клиенту. Подрядчик собрал бизнес-процесс и предложил включить его сразу.
Решили сначала прогнать на тестовом портале с демо-режимом. Создали 25 вымышленных клиентов, закрыли их сделки с разными датами и сдвинули условие с 30 дней на 30 минут для ускорения. За час нашлись две проблемы. Процесс запускался повторно на каждое изменение сделки, и на одного клиента создавалось по три-четыре повторных сделки. Кроме того, задачи уходили ответственному по старой сделке, даже если этот менеджер уже уволен и деактивирован.
На рабочем портале с несколькими тысячами закрытых сделок первая ошибка создала бы сотни дублей, которые пришлось бы вычищать вручную, а вторая оставила бы часть клиентов без звонка. Исправление заняло у подрядчика полдня. После повторного прогона процесс перенесли на рабочий портал, и он работает до сих пор.
Когда тестовый портал ведёт техподдержка Битрикс24
Для многих компаний отдельный администратор, который следит за тестовой средой, сверяет структуру и ведёт журнал изменений, это лишняя ставка. Тогда эту работу берёт на себя подрядчик. Техподдержка Битрикс24 в таком формате обычно включает создание и настройку тестового портала, прогон всех изменений перед переносом в бой, контроль за приложениями из Маркета и откат, если что-то пошло не так уже после переноса.
Техническая поддержка Битрикс24 в агентстве B2BPRO.KZ работает 24/7. Для тестовой среды это важно по простой причине: переносить изменения на рабочий портал лучше всего вечером или в выходные, когда менеджеры не работают с клиентами, и в это же время должен быть на связи тот, кто сможет быстро откатить правку. Если у вас нет своего администратора или ему не хватает времени на тестовую среду, заказать техподдержку Битрикс24 24/7 можно у нас: заведём тестовый портал, перенесём структуру, пропишем сценарии проверки и возьмём на себя перенос изменений.
Стоит ли держать тестовую среду постоянно или заводить её под конкретный проект, зависит от того, как часто вы меняете автоматику. Если роботы и процессы правятся раз в год, хватит временного портала с демо-режимом. Если правки идут каждый месяц, постоянный тестовый портал с отдельной оплатой обходится дешевле, чем одна рассылка не тем клиентам.
Частые вопросы
Можно ли бесплатно пользоваться тестовым порталом Битрикс24?
Да, новый облачный портал стартует на бесплатном тарифе. Но на нём недоступна значительная часть инструментов автоматизации. Для проверки роботов и бизнес-процессов можно один раз подключить демо-режим: по справке Битрикс24 это 15 дней возможностей тарифа «Профессиональный».
Можно ли скопировать облачный портал целиком?
Штатной функции полного копирования облачного портала нет. Данные CRM, задачи и проекты переносят приложениями-мигрёрами из Маркета Битрикс24, а воронки, поля, роботов и права доступа обычно настраивают вручную по образцу рабочего портала.
Нужна ли отдельная лицензия для тестовой копии коробочного Битрикс24?
Лицензионное соглашение 1С-Битрикс допускает установку для разработки и тестирования на определённых условиях, например без внешнего доступа. Точные условия зависят от редакции соглашения, их нужно сверить в актуальной версии или уточнить у партнёра.
Можно ли загрузить в тестовый портал реальную базу клиентов?
Мы не рекомендуем. Тестовые среды защищены слабее рабочих, к ним чаще получают доступ подрядчики. Для проверки автоматики хватает 20-30 вымышленных клиентов, а в коробочной копии реальные контакты лучше обезличить сразу после развёртывания.