Сначала определите продажу, которую магазин сможет выполнить

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

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

Каталог: товар отличается от его варианта

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

В 1С-Битрикс торговые предложения представляют отдельные ассортиментные позиции, отличающиеся свойствами. Покупатель видит общую карточку, затем выбирает вариант. Цена и наличие относятся к выбранному предложению. На этапе подготовки данных компания передаёт устойчивый идентификатор позиции, наименование и характеристики, которые действительно влияют на выбор. Фотографии также соответствуют варианту, если различие заметно визуально.

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

Платформу выбирают по операциям, а не по витрине

Внешне похожие магазины могут требовать разной работы сотрудников. Готовый сервис удобен, если поддерживает нужные правила продажи без обходных операций, а отдельная система управления оправданна, когда компания готова обслуживать её и действительно нуждается в более сложных связях или доработках. Список интеграций проверяют предметно. Логотип сервиса на странице продукта не описывает весь процесс.

В задании перечисляют источник товаров, способ обновления цен, движение заказа и возврат статуса покупателю. Для магазина на 1С-Битрикс производитель описывает обмен с 1С как публикацию номенклатуры, передачу заказов в учётную систему и возврат результатов обработки на сайт. Это три направления, которые можно проверить отдельно. Наличие модуля ещё не сообщает, какие из них настроены в конкретном магазине. Исполнитель показывает их на данных бизнеса. Не покупайте сложность про запас. Если первая очередь работает с ограниченной группой товаров и простыми правилами, полезнее сохранить возможность развития и ясную стоимость сопровождения, чем сразу оплачивать функции, которым пока нет владельца в компании.

Наглядный разбор

Задачи первой очереди

  1. Товар

    Кто обновляет описание, цену и наличие.

  2. Заказ

    Кто подтверждает покупку и принимает оплату.

  3. Исполнение

    Кто собирает, отгружает и сообщает статус.

  4. Поддержка

    Кто исправляет ошибку и помогает покупателю.

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

Корзина и оформление сохраняют выбор

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

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

Изменение цены и количества стоит принять вместе с остальными сценариями работы корзины интернет-магазина. В первом запуске важнее предсказуемый итог и полученный заказ, чем сложные акции, сочетания скидок и дополнительные продажи. Когда базовая покупка проходит без ошибок, новые правила легче проверять по одному.

Оплата подтверждается системой, а не возвращением на сайт

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

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

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

Доставка проверяется на неудобных условиях

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

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

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

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

Сотрудник получает заказ и знает следующее действие

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

В 1С-Битрикс форма управления находится в «Магазин → Заказы». Среди фильтров предусмотрены «Оплачен» и «Отгружен». Эти признаки помогают отделять ожидающие оплаты покупки от готовых к следующим действиям. Инструкция сотрудника объясняет смысл состояний и действия с ними. Отдельно описывают отмену, невозможность связаться с покупателем и возврат, чтобы проблемный заказ не исчезал из поля зрения после неудачного звонка.

Если используется обмен с учётной системой, проверяют и обратное направление: результат обработки возвращается на сайт и понятен покупателю. Период обновления согласуют с бизнесом, а задержку делают видимой сотрудникам. Точность обещания важнее красивой отметки о мгновенной синхронизации. Когда обмен остановился, команда знает, кто заметит сбой и как временно продолжит работу.

Наглядный разбор

Заказ проходит несколько независимых состояний

  1. Заказ создан

    Состав и условия сохранены, покупка появилась у ответственного.

  2. Оплата подтверждена

    Платёжный сервис сообщил результат, он отражён в учёте.

  3. Товар передан

    Сотрудник оформил отгрузку и сообщил сведения о получении.

  4. Проблема разобрана

    Отмена или возврат имеют владельца и понятное продолжение.

Оплату, обработку и отгрузку принимают отдельно, чтобы витрина не обещала покупателю действие, которое ещё не произошло.

Рабочий перечень перед первым трафиком

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

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

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

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

После запуска расходы становятся обязательствами

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

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

Источники и полезные ссылки

  1. 1С-Битрикс: управление заказами ↗
  2. 1С-Битрикс: торговые предложения ↗
  3. 1С-Битрикс: обмен с 1С ↗

Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.

Игорь Крещенко

Руководитель ШТАБ ИТ. Занимается управлением проектами, веб-разработкой, рекламой и PR. Подробнее об авторе →