Клиент дошёл до оформления, выбрал товар, готов платить — и упирается в список из десяти способов доставки, половина которых для его города не работает, стоимость «уточним после заказа», а карта пунктов выдачи грузится десять секунд. На этом шаге теряется значимая доля заказов, хотя человек уже был готов купить. Выбор способа получения — не техническая формальность, а один из самых чувствительных этапов чекаута.
Разберём, как настроить выбор способа получения на 1С-Битрикс — курьер, ПВЗ, постамат, самовывоз: как устроены службы доставки и профили, как фильтровать варианты под клиента, показывать карту без тормозов, считать стоимость и связывать всё с наличием на складах. Привести доставку и обмен с 1С в порядок помогает аудит и оптимизация 1С.
Коротко
- Способы получения в 1С-Битрикс — это службы доставки с обработчиками и профилями; для каждого способа свой расчёт стоимости и сроков.
- Показывайте только доступные для адреса и заказа варианты; фильтруйте по региону, габаритам и наличию.
- Карту пунктов выдачи подгружайте асинхронно и кэшируйте точки, иначе она тормозит весь чекаут.
- Показывайте стоимость и срок до оформления — скрытая цена доставки — главная причина брошенных корзин на этом шаге.
Почему способ получения — критичный шаг
На шаге доставки в оформлении сходятся сразу несколько причин отказа: непонятный выбор, недоступные варианты, скрытая стоимость, медленная карта. Клиент уже прошёл путь от каталога до корзины, он мотивирован, но именно здесь его легко потерять из-за плохого UX или технических тормозов.
При этом способ получения — это ещё и деньги: разные способы стоят магазину по-разному, и грамотный выбор направляет клиента к выгодным вариантам (самовывоз, постамат) без принуждения. Поэтому этот шаг проектируют вдумчиво — и как UX, и как бизнес-логику. Мелочи вроде запоминания прошлого выбора или подсказки «ближайший пункт в 300 метрах» напрямую влияют на конверсию.
Четыре способа и их сценарии
Четыре основных способа получения закрывают разные потребности клиентов, и у каждого своя логика.
| Способ | Сценарий клиента | Особенность настройки |
|---|---|---|
| Курьер | Удобство, доставка до двери | Расчёт по адресу, интервалы, зоны |
| ПВЗ | Осмотр, возврат, экономия | Карта точек, фильтр по региону |
| Постамат | Быстро, без общения | Фильтр по габаритам ячейки |
| Самовывоз | Забрать сразу, бесплатно | Наличие в конкретном магазине |
Клиенту важно быстро найти свой сценарий, а не разбираться в различиях. Задача магазина — показать релевантные способы понятно и с ценой, а не вываливать всё подряд.
Службы доставки и профили в 1С-Битрикс
Технический фундамент — механизм служб доставки модуля «Интернет-магазин». Служба доставки имеет обработчик, который считает стоимость и сроки, и профили — конкретные варианты внутри службы.
- Обработчик. Логика расчёта: встроенная, из решения оператора или собственная под нестандартный тариф.
- Профили. Конкретные варианты — курьер по городу, ПВЗ оператора, постамат — каждый со своими условиями.
- Ограничения. Профиль привязан к региону, весу, габаритам, сумме заказа.
- Приоритет и показ. Порядок отображения и условия доступности на оформлении.
Правильно описанные службы и профили — основа того, что клиент видит на чекауте нужные варианты с корректной ценой. Обработчики операторов часто ходят во внешние API, поэтому их обкладывают обработкой ошибок — про надёжность таких интеграций мы писали в статье про безопасность REST и вебхуков в 1С-Битрикс.
Фильтрация вариантов под клиента
Главный принцип хорошего выбора доставки — показывать только то, что реально доступно этому клиенту с этим заказом. Список из десяти способов, половина которых не работает, снижает конверсию и раздражает.
Фильтровать варианты нужно по нескольким осям сразу: региону клиента (есть ли курьер, какие операторы работают), габаритам и весу заказа (поместится ли в постамат), наличию (возможен ли самовывоз из точки). Недоступные варианты либо скрывают, либо помечают недоступными с понятным объяснением — «для вашего города недоступно» лучше, чем молчаливое отсутствие. Умная фильтрация делает выбор коротким: клиент видит три подходящих способа, а не десять с оговорками.
Карта пунктов выдачи без тормозов
Карта ПВЗ и постаматов — самый тяжёлый элемент оформления. Если грузить тысячи маркеров при открытии страницы или дёргать API оператора на каждый показ, чекаут превращается в мучение. Карту нужно проектировать на скорость.
- Подгружайте асинхронно. Карта и список точек загружаются после выбора способа, а не со всей страницей.
- Фильтруйте точки. Только по региону клиента и габаритам заказа — не все точки страны.
- Кэшируйте данные. Точки оператора обновляются по расписанию, а не запрашиваются на каждый показ.
- Дайте поиск. Поиск по адресу и сортировка по расстоянию вместо ручного листания карты.
Так карта открывается быстро и не блокирует остальной чекаут. Общая скорость оформления — часть скорости сайта в целом; как держать её под нагрузкой, мы разбираем в статье про инфраструктуру и BitrixVM.
Расчёт стоимости и сроков
Стоимость и срок доставки клиент должен видеть до оформления, а не «узнать после заказа». Скрытая стоимость доставки — одна из главных причин брошенных корзин: человек не любит сюрпризов на финише.
Расчёт делает обработчик службы доставки по тарифам оператора, весу и габаритам заказа, региону и точке получения. Для ПВЗ и постаматов расчёт обычно идёт через API оператора или тарифные таблицы. Задача — показать клиенту итоговую цену и срок сразу при выборе способа, а не заглушку. Если расчёт зависит от внешнего API и тот недоступен, нужен запасной сценарий — резервный тариф или понятное сообщение, а не пустота. Отдельно стоит помнить про порог бесплатной доставки: как он взаимодействует с выбором способа, мы разбираем в теме конверсии корзины.
Связь с наличием на складах
Способ получения нельзя настраивать в отрыве от того, где физически лежит товар. Самовывоз возможен только из магазина, где есть остаток; курьер и ПВЗ — со склада, обслуживающего регион клиента. Игнорировать это — значит предлагать самовывоз оттуда, где товара нет, и срывать заказ уже после оформления.
Наличие по складам приходит на сайт обменом из 1С, поэтому корректность выбора способа опирается на качество интеграции. Клиенту показывают самовывоз только из точек с остатком, а срок доставки считают от склада, откуда реально поедет заказ. Синхронизацию остатков и складской логики мы закрываем услугой автоматизации продаж и склада на 1С, а современный подход к работе с этими данными описан в статье про D7 и ORM в 1С-Битрикс.
Габариты и постаматы
Постамат — удобный, но ограниченный способ: у ячейки есть максимальный размер, и крупный заказ в неё физически не влезет. Предлагать постамат клиенту, который заказал габаритный товар, — прямой путь к отменённому заказу и негативу.
Поэтому выбор постамата фильтруется по габаритам заказа: система сравнивает размеры товаров с ограничениями ячейки и не показывает постаматы, если заказ не помещается. Для этого у товаров должны быть заполнены габариты и вес — эти данные ведутся в каталоге и приходят из 1С. Без корректных габаритов фильтрация не работает, и постаматы предлагаются вслепую. Заполнение весогабаритных характеристик — часть подготовки каталога, которую нельзя пропускать.
Единый слой для операторов
Когда операторов доставки много, их API и форматы разные: у каждого свои тарифы, структура точек, статусы. Встраивать особенности каждого напрямую в витрину — путь к хрупкой системе, которую больно расширять.
Решение — единый интеграционный слой: обработчики служб доставки приводят разнородные данные операторов к общему виду, с которым работают чекаут и заказ. Витрина не знает о специфике конкретного оператора — она работает с унифицированными способами, стоимостью и точками. Это изолирует магазин от чужих особенностей и упрощает добавление новых операторов. Такой слой строят на современном ядре и обязательно покрывают обработкой ошибок, потому что внешние API нестабильны. Подход близок к описанному в материале про модульную архитектуру решений на Битрикс.
UX выбора и конверсия
Даже при верной технической начинке выбор доставки можно испортить интерфейсом. Несколько принципов, которые поднимают конверсию этого шага:
- Короткий список. Только релевантные способы, без десятка недоступных вариантов.
- Цена и срок сразу. Клиент видит стоимость и дату получения при выборе, а не после.
- Запоминание выбора. Прошлый способ и точка подставляются при повторном заказе.
- Подсказка ближайшего. «Ближайший пункт в 300 метрах» экономит клиенту усилия.
Эти детали недороги в реализации, но в сумме заметно снижают долю брошенных корзин на шаге доставки. Способ получения — прямой рычаг конверсии, а не второстепенная настройка.
Реализация пошагово
- Опишите службы и профили. Курьер, ПВЗ, постамат, самовывоз с обработчиками и условиями.
- Настройте фильтрацию. По региону, габаритам, весу, наличию — показ только доступного.
- Подключите карту точек. Асинхронная загрузка, кэш точек, поиск и сортировка по расстоянию.
- Настройте расчёт. Стоимость и срок до оформления с запасным сценарием при сбое API.
- Свяжите с наличием. Самовывоз из точек с остатком, срок от реального склада отгрузки.
- Проверьте габариты. Постаматы фильтруются по размеру заказа, весогабариты заполнены.
- Отшлифуйте UX. Короткий список, цена и срок сразу, запоминание выбора.
Частые ошибки
- Показывают все способы всем. Клиент видит недоступные варианты и путается.
- Скрытая стоимость. «Уточним после заказа» гонит клиента из корзины.
- Медленная карта. Тысячи маркеров грузятся синхронно и вешают чекаут.
- Постамат без фильтра габаритов. Крупный заказ предлагают в ячейку, куда он не влезет.
- Самовывоз без наличия. Клиенту предлагают забрать оттуда, где товара нет.
- Нет запасного сценария. API оператора упал — расчёт пустой, заказ не оформить.
- Специфика операторов в витрине. Особенности каждого зашиты напрямую — систему больно расширять.
Чек-лист внедрения
- Службы и профили описаны. Все способы получения с корректными обработчиками.
- Фильтрация работает. Показываются только доступные для клиента и заказа варианты.
- Карта быстрая. Асинхронная загрузка, кэш точек, поиск по адресу.
- Стоимость и срок видны. До оформления, с запасным сценарием при сбое.
- Наличие учтено. Самовывоз из точек с остатком, срок от склада отгрузки.
- Габариты проверяются. Постаматы фильтруются по размеру, весогабариты заполнены.
- Операторы унифицированы. Единый слой приводит разные API к общему виду с обработкой ошибок.
- UX отшлифован. Короткий список, цена сразу, запоминание выбора и подсказка ближайшего.
Вывод
Выбор способа получения — курьер, ПВЗ, постамат, самовывоз — это не формальная настройка, а один из самых конверсионных шагов оформления. Здесь клиент, уже готовый купить, легко теряется из-за лишних вариантов, скрытой цены или медленной карты. Каждая из этих проблем решается технически и приносит заказы напрямую.
Настройте службы доставки и профили, фильтруйте варианты под клиента по региону, габаритам и наличию, показывайте стоимость и срок сразу, делайте карту быстрой и связывайте выбор с реальными остатками из 1С. Сведите разных операторов к единому слою с обработкой ошибок. Тогда шаг доставки перестанет быть местом, где отваливаются заказы, и станет коротким понятным выбором, который клиент проходит без раздумий.
