Главное за минуту
- Проверяйте тестовым заказом не только корзину, но и статус оплаты, доставки и карточку CRM.
- Сверяйте цену, остаток и доступность товара с учётной системой по приоритетным SKU.
- Фиксируйте UTM, client ID и состав заказа: иначе нельзя оценить окупаемость канала.
- После обновлений повторяйте критический сценарий на мобильном устройстве и в разных браузерах.
01
Контроль начинается с маршрута заказа
Интернет магазин на Битрикс нужно проверять не по списку страниц, а по цепочке: рекламный переход → карточка товара → корзина → оформление → оплата → заказ в административной части и CRM → отгрузка.
В типовом проекте ICONICA проблемы часто обнаруживаются на стыке систем: товар есть в каталоге, но недоступен для выбранного города; оплата прошла, но статус заказа не изменился; менеджер получил сделку без источника рекламы. Для контроля выберите 3–5 ходовых товаров, все способы доставки и оплаты и прогоняйте сценарий раз в неделю.
02
Карточка контрольного заказа
Единый набор полей позволяет быстро сопоставить сайт, платёжный сервис, CRM и учётную систему.
03
Четыре зоны, где магазин теряет деньги незаметно
Не все ошибки видны посетителю сразу. Часть из них искажает отчётность или создаёт ручную работу у менеджеров. Владелец сайта должен видеть не техническую причину, а наблюдаемый сигнал и ответственного за проверку.
Не доверяйте одному статусу
Сообщение «заказ оформлен» не подтверждает оплату и передачу данных. Проверяйте итог в журнале заказов, платёжном сервисе и CRM.
04
Что смотреть по расписанию
Разделите контроль на регулярные действия и проверки после релиза. Тогда срочная ошибка не маскируется среди второстепенных задач.
| Период | Проверка | Сигнал риска |
|---|---|---|
| Ежедневно | Заказы и неоплаченные корзины | резкое падение конверсии |
| Еженедельно | Тестовый заказ по всем методам | нет статуса или письма |
| После обмена | Цены и остатки приоритетных SKU | расхождение с учётом |
| После релиза | Мобильное оформление и цели | сломанная форма или событие |
05
Мини-кейс: заказ есть, маркетинг не видит канал
В типовом аудите заказ создавался корректно, но UTM-метки не сохранялись после перехода между каталогом и оформлением. В результате платный трафик попадал в «прямые» визиты.
Результат приёмки — в тестовом заказе сохранены исходные метки, сумма, состав корзины и идентификатор визита.
Готовое сообщение
Готовая постановка задачи
Цель: обеспечить контрольный маршрут заказа и передачу данных в CRM.
Проверить: цену и остаток SKU, промокод, доставку, оплату, письмо покупателю, создание заказа и сущности CRM.
Передавать: номер заказа, товары, сумму, способ оплаты и доставки, UTM-метки, client ID, телефон и e-mail.
Критерии приёмки: три тестовых заказа с разными оплатами видны в CRM; источники не теряются; неоплаченный заказ не отмечен как оплаченный; приложены ссылки на записи тестов.
06
Как принять доработку без доступа к коду
Приёмка строится на воспроизводимом сценарии. Разработчик готовит тестовую среду или согласованное окно на боевом сайте, маркетолог фиксирует результаты в таблице.
- 1
Согласуйте сценарии. Выберите товары, города, устройства, промокоды и способы оплаты, которые должны быть проверены.
- 2
Создайте чистый переход. Откройте ссылку с UTM в режиме инкогнито, чтобы не использовать старую сессию.
- 3
Оформите заказ. Сохраните номер, время, состав корзины и итоговую сумму до перехода к оплате.
- 4
Сверьте системы. Сопоставьте статус в магазине, платёжном сервисе, CRM и учётной системе.
- 5
Проверьте отчёт. Убедитесь, что заказ появился в аналитике с корректным каналом и выручкой.
07
Где искать первопричину
Если данные расходятся, не просите «починить интеграцию» без примера. Передайте номер заказа, время, URL входа, выбранные способы оплаты и доставки, ожидаемый и фактический результат.
Полезная граница ответственности
Маркетолог подтверждает пользовательский сценарий и данные отчёта. Разработчик проверяет обработчики, логи, обмен и настройки модулей. Правила работы с заказами описаны в документации 1С-Битрикс.
Сайт
форма и заказ
API
обмен и статусы
CRM
лид, сделка, источник
Логи
время, URL, ответ сервера
08
Когда нужна регулярная поддержка
Разовая проверка не заменяет контроль, если меняются цены, каталог, правила доставки, рекламные кампании или модули. Поддержка нужна, когда ошибки повторяются, а у команды нет владельца критических сценариев.
Для примеров работ и форматов аудита можно посмотреть портфолио ICONICA.
Контрольные SKU выбраны; тестовые UTM согласованы; статусы оплаты описаны; ответственный за CRM назначен; результаты теста сохранены; после обновлений запланирован повторный прогон.
FAQ
Частые вопросы
Нужно ли проверять магазин вручную, если есть автотесты?
Да. Автотесты контролируют заданные условия, а ручной тест подтверждает реальный путь пользователя, оплату и отчётность.
Какие товары брать для контрольного заказа?
Ходовой товар, товар со скидкой, вариативный товар и позицию с нестандартной доставкой или налогом.
Почему заказ не виден в CRM, хотя письмо покупателю пришло?
Заказ и CRM могут создаваться разными обработчиками. Нужны номер заказа, время и логи интеграции для диагностики.
Как часто обновлять чек-лист?
После подключения оплаты, доставки, CRM, изменения воронки, редизайна оформления или обновления модулей.
