Что заложить в требования к новому сайту на Битрикс

01

Начните требования с бизнес-сценариев, а не с перечня страниц

Создание сайта на Битрикс часто начинают с карты разделов: главная, услуги, каталог, контакты. Такая карта нужна, но не отвечает на главный вопрос — что должен сделать посетитель и что после этого произойдёт в бизнесе. Если сценарий не описан, разработчик реализует форму по макету, а маркетинг после запуска обнаруживает: у лида нет источника, менеджер получает письмо вместо сделки, нужный товар нельзя заказать, а конверсию невозможно посчитать.

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

У сценария должен быть измеримый финал. Например: посетитель пришёл по рекламе с UTM, открыл страницу услуги, отправил форму; в CRM создан лид с телефоном, страницей, рекламным источником и согласием на обработку данных; менеджер получил задачу. Тогда команда может проверить цепочку целиком, а не спорить о том, «похожа ли форма на макет».

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

03

Зафиксируйте состав данных до настройки форм и CRM

Каждая форма на новом сайте должна иметь паспорт. Его можно вести в таблице требований: название формы, страницы размещения, цель, поля, обязательность, валидация, текст согласия, успешное сообщение и получатель. Не ограничивайтесь фразой «заявка должна попадать в Битрикс24»: заранее определите, что создаётся — лид, сделка, обращение или заказ, и по какому правилу система ищет дубль.

Отдельно договоритесь о служебных данных. Как минимум полезно передавать URL страницы, referer, дату и время, UTM-метки, тип формы и идентификатор рекламной кампании, если он используется. Эти поля не всегда показывают менеджеру, но без них маркетолог не свяжет расходы на трафик с обращениями. Проверьте, что поля существуют в CRM и доступны в отчётах.

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

04

Разделите требования на запуск, развитие и поддержку

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

Первый релиз — не обязательно «урезанный сайт». В него должны войти все критические процессы: корректный каталог или услуги, формы, обработка заказов, CRM, аналитика, безопасность, мобильная версия, SEO-основа и перенос нужного контента. Анимации, дополнительные калькуляторы, персонализация и сложные кабинеты можно планировать отдельными этапами, если они не блокируют продажи.

Каждой задаче присвойте приоритет, владельца решения и критерий готовности. Это защищает от ситуации, когда после макетов появляется фраза «мы думали, это уже включено». Оценку подрядчика проверяйте по составу результата, а не только по числу часов.

05

Включите SEO и аналитику в архитектуру, а не в финальную полировку

Для нового сайта SEO начинается не с заполнения метатегов. Уже на этапе структуры нужно согласовать будущие URL, логику разделов, шаблоны title и description, хлебные крошки, канонические адреса, пагинацию каталога и правила для фильтров. Если сайт заменяет старый, обязательна карта редиректов: старый URL, новый URL, тип 301, ответственный за проверку. Иначе трафик и накопленные позиции уходят на страницы 404.

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

Укажите, кому принадлежат аккаунты аналитики, рекламных систем, домен и контейнер тегов. Подрядчику предоставляют доступы, но владельцем должна оставаться компания. По документации API и событий Битрикса можно сверяться в разделе для разработчиков 1С-Битрикс; заказчику важнее получить перечень внедрённых событий и правила их проверки.

06

Проведите приемку по маршрутам, а не по списку экранов

Финальная демонстрация на тестовом сервере не заменяет приемку. Она показывает интерфейс, но не подтверждает, что сайт работает в реальных условиях. До запуска подготовьте сценарии проверки и назначьте исполнителей со стороны маркетинга, продаж и технической команды. Маркетинг тестирует источники, тексты и аналитику; продажи — качество лида и уведомления; технический ответственный — доступы, резервное копирование и поведение при ошибках.

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

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

1. 1

   Подготовьте тестовые данные. Создайте тестовые телефоны, почты, UTM-ссылки, товары и промокоды.

2. 2

   Пройдите путь посетителя. Проверьте страницы, поиск, фильтры, формы и мобильную версию.

3. 3

   Проверьте получателя. Найдите обращение в CRM, заказ в админке и уведомление менеджеру.

4. 4

   Сверьте атрибуцию. Сопоставьте UTM, URL, событие аналитики и данные карточки CRM.

5. 5

   Закройте критичные дефекты. Повторите весь маршрут после исправлений на боевом окружении.

08

Не забудьте о доступах, документации и границе ответственности

Сайт после запуска остаётся рабочей системой: в нём обновляют контент, обрабатывают ошибки, продлевают лицензии, меняют интеграции и реагируют на инциденты. Поэтому в требованиях к проекту нужно зафиксировать, что передаёт подрядчик и кто отвечает за эксплуатацию. Минимум — доступ администратора к 1С-Битрикс, хостингу, домену, резервным копиям, почте, CRM, аналитике и репозиторию, если он используется.

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

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

09

Требования к сайту — это договорённость о результате

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

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

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