Запуск интернет-магазина: технический чек-лист

1. Соберите товарную матрицу до массового импорта

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

Условный пример, не реальный ассортимент: футболка TS-01, синяя, размер M — вариант TS-01-B-M, доступно 3 штуки; тот же товар размера L — вариант TS-01-B-L, остаток 0. Покупатель не должен заказать отсутствующий размер только потому, что у группы есть другие варианты. Google также различает общую группу товара и характеристики отдельных вариантов; разметка не заменяет их правильный учёт.

• Определите источник цены и остатка: сайт, складская система или другой учёт.
• Согласуйте момент резерва, срок его действия и освобождение при отмене.
• Укажите, что делать при сбое синхронизации или продаже последней единицы одновременно двум покупателям.
• Проверьте изменение цены, снятие товара и повторный импорт без создания дублей.

Источник: Google: варианты товара и ProductGroup.

2. Проверьте путь от категории до нужного варианта

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

Для страниц, которые должны обнаруживаться в поиске, предусмотрите обычные ссылки из категорий. Google предупреждает, что робот не вводит запросы во внутреннем поиске магазина. Поэтому единственная строка поиска не заменяет навигацию. Не создавайте автоматически индексируемую страницу под каждое сочетание фильтров: это отдельная задача структуры, а не условие технического запуска.

Источник: Google: структура навигации интернет-магазина.

3. Опишите заказ и отдельно его оплату

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

Учебный образец: заказ TEST-001, покупатель «Тест приёмки», две кружки варианта TEST-BLUE, доставка в согласованный тестовый пункт. Цены, валюту и итог подставьте из своего тестового каталога — это не прайс и не реальный заказ. После создания заказ виден менеджеру, оплата ожидается, товар зарезервирован по согласованному правилу. После подтверждения платежа меняется только состояние оплаты; сборка и передача в доставку отмечаются отдельно. Повтор того же подтверждения не должен повторять резерв или отгрузку.

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

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

4. Проверьте отказ, повтор и серверное уведомление

Платёжный способ выбирайте после проверки договора, страны организации, валюты и доступных покупателям методов. Для приёмки используйте тестовый режим провайдера, если он предусмотрен. Настоящие списания и возвраты требуют отдельно согласованного сценария; не проверяйте магазин случайной оплатой клиента.

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

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

• Отказ оплаты оставляет понятный статус и возможность согласованного повторного действия.
• Повторное уведомление не создаёт новый заказ и не запускает повторную отгрузку.
• При неизвестном результате сотрудник видит необходимость сверки, а система не объявляет платёж успешным наугад.
• Номера карт, коды безопасности и секреты интеграции не попадают в CRM, переписку и материалы приёмки.

Источник: MDN: HTTP POST и повторные запросы.

5. Согласуйте доставку и изменение итоговой суммы

Для каждого способа доставки задайте обслуживаемую территорию, нужные поля, стоимость или правило расчёта и ответственного. Проверьте обычный адрес, недоступный регион, самовывоз и тяжёлый товар, если они есть в ассортименте. Если расчёт ручной, напишите это до отправки заказа, не изображая неизвестную стоимость нулевой.

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

6. Назначьте ответственных и проверьте CRM

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

Если подключена CRM, сравните номер, состав, сумму, контакт и статусы с исходным заказом. Уточните, какая система является главной для каждого поля. Попросите временно смоделировать недоступность CRM в безопасной тестовой среде: заказ должен оставаться доступным, ошибка — заметной, а повтор передачи — не создавать вторую сделку. Не проверяйте сбой отключением рабочего сервиса.

7. Пройдите мобильную приёмку покупателя и сотрудника

На реальном телефоне откройте категорию, выберите вариант, измените количество, заполните доставку и перейдите к тестовой оплате. Проверьте экранную клавиатуру, длинный адрес, исправление ошибки, кнопку возврата и восстановление корзины после перезагрузки. Повторите основной путь на компьютере.

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

8. Зафиксируйте решение о техническом запуске

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

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