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

| Маршрут | Что проверить |
|---|---|
| Обычная покупка | Поиск товара, выбор варианта, корзина, адрес, доставка, оплата и подтверждение заказа. |
| Покупка с ограничением | Товар закончился, промокод не подходит, адрес вне зоны доставки или нужного размера нет. |
| Сбой и повтор | Ошибка оплаты, возврат из платёжной формы, повторный клик, обновление страницы и повторный ответ внешнего сервиса. |
Используйте тестовые режимы оплаты и доставки, где они предусмотрены. Реальную транзакцию согласуйте отдельно: кто платит, как оформляется возврат и какие документы создаются. Не проверяйте интеграцию на заказах действующих покупателей.
Повторите маршруты на телефоне. Откройте клавиатуру, выберите доставку, исправьте ошибку в поле. Кнопка, видимая на большом экране, может оказаться за клавиатурой или перекрываться баннером.
Найдите один тестовый заказ на сайте, в письме, CRM и учётной системе, если они входят в проект. Сопоставьте артикул или идентификатор варианта, количество, цену, скидку, доставку, оплату и контактные данные. Совпадение общей суммы недостаточно: в заказ мог попасть другой размер по той же цене.
Подробнее о таких договорённостях: как подготовить и проверить обмен данными магазина.
Отправьте согласованную тестовую заявку через каждую форму. Проверьте не только сообщение «спасибо», но и запись обращения, письмо и другие подключённые уведомления. По записи должно быть понятно, с какой страницы и формы пришёл запрос.
Убедитесь, что цель срабатывает после подтверждённого приёма заявки, а не после любого нажатия на кнопку. Отдельно проверьте ошибку: отключённый или недоступный сервис уведомлений не должен незаметно уничтожать уже сохранённое обращение. Имя, телефон и текст заявки не нужно отправлять в параметры аналитики.
На боевых страницах не должен оставаться тестовый запрет индексации. Проверьте заголовки, основные адреса, карту сайта и важные ссылки со старого магазина. При смене CMS пригодится отдельный план SEO-переноса.
Войдите под учётной записью менеджера, а не администратора разработчика. Проверьте обработку заказа и работу с товарами в пределах выданных прав. У владельца должны быть собственные доступы к домену, платформе, аналитике и подключённым сервисам.

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