Интеграции интернет-магазина: склад, доставка, CRM и статусы заказа, что подключать в каком порядке

Контур заказа в интернет-магазине: от клика до выдачи

Возьмите обычный заказ в интернет-магазине и проследите его путь. Клиент увидел в карточке «в наличии», положил товар в корзину, там посчиталась доставка до его города и показались пункты выдачи. Оформил, оплатил через СБП, получил чек. Позиция ушла в резерв, в CRM появилась сделка с источником заявки, в службе доставки создалось отправление и вернулся трек-номер. Дальше статусы: принят, собран, передан в доставку, прибыл в ПВЗ, получен.

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

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

Очередь подключения: сначала то, что стоит денег

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

Первая очередь: остатки, свои статусы заказа и расчёт доставки в корзине. Эти узлы видит клиент, и каждый режет выручку сейчас. Остатки закрывают продажу того, чего нет, расчёт доставки снимает торможение на последнем шаге оформления, а свои статусы (принят, оплачен, собран, передан в доставку) убирают половину вопросов «где мой заказ».

Вторая очередь: отправления, трек-номера и статусы от перевозчика. Автоматика экономит часы менеджера и добавляет то, что знает только служба: приняла, везёт, привезла в ПВЗ. Своими силами это не изобразить, поэтому подключается вместе с созданием отправлений.

Третья очередь: CRM, лояльность и аналитика. Эффект накопительный, а на кривых данных первых двух блоков решать нечего.

Товарный обмен с 1С мы разбирали в отдельной статье: номенклатура, цены, остатки, заказы обратно в базу, CommerceML, справочники. Повторяться не будем, здесь речь про соседние узлы: доставку, статусы, CRM, оплату и склад в другой системе.

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

Когда интеграция не нужна

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

Цифры для примера: 6 минут на заказ и 40 заказов дают 240 минут, то есть 4 часа; при 600 рублях за час это 2400 рублей в месяц, и интеграция за 60 тысяч окупится через два года. Добавьте потери на ошибках: отмены, неверные адреса, брошенные корзины. Три ситуации, где мы отговариваем клиента:

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

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

Статусы заказа и уведомления: с чего начинается автоматизация обработки заказов

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

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

Каналов четыре. E-mail несёт длинное: состав заказа, сумму, чек, адрес пункта выдачи с часами работы, ссылку на отслеживание. SMS платные за штуку, поэтому уходят на критичное: трек-номер, «курьер приедет сегодня», «посылка ждёт в ПВЗ до такого-то числа». Мессенджеры подключаются через официальные API с шаблонами, это отдельный бюджет, а пуш имеет смысл при своём приложении.

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

Текст решает не меньше, чем факт отправки. «Ваш заказ изменил статус на 4» вызывает звонок, а не снимает его. Пишите номер заказа, что едет и на какую сумму, куда ехать и до какого числа посылка хранится: напоминание за день до конца хранения в ПВЗ заметно уменьшает возвраты.

Расчёт доставки в корзине: где живёт правда о цене

Фраза «стоимость доставки уточнит менеджер» стоит денег. Клиент, который дошёл до корзины, хочет увидеть сумму сейчас. Особенно если он сравнивает вас с маркетплейсом.

Прямое подключение к службе или агрегатор

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

Как подключить СДЭК и другие службы к интернет-магазину

Модуль сам по себе ничего не решает. Прежде чем подключить СДЭК, Почту России или Boxberry к интернет-магазину, соберите то, без чего расчёт не поедет: договор и номер аккаунта, тестовые и боевые ключи API, режим тарификации (публичные ставки или ваши договорные), актуальный список ПВЗ и правило его обновления.

Дальше то, на чём калькуляторы обычно врут. Город должен выбираться из справочника службы, а не вводиться руками: «Ю-Сахалинск» служба не поймёт и вернёт ошибку или тариф до другого города. У Почты России логика своя: индекс, весовые категории и отделения вместо ПВЗ. Перед запуском прогоните десяток городов из разных зон и сравните с личным кабинетом. По срокам это 1-3 дня на модуль и 2-5 на зоны и правила.

Габариты - отдельная история. Служба считает по весу и объёму, а в карточках эти поля часто пустые: заполните вес с упаковкой, три размера коробки и признак негабарита, иначе разницу на приёмке заплатит магазин.

Дальний Восток, острова и разная география служб

Мы работаем из Владивостока, и тема доставки в ДФО для нас не абстрактная. Правило «бесплатная доставка по России от такой-то суммы» без ограничений превращается в убыток на каждой посылке во Владивосток, Петропавловск-Камчатский или Южно-Сахалинск. Бывает и обратное: продавец с Дальнего Востока отправляет в Москву и удивляется счёту.

География служб здесь расходится сильнее, чем в центральной России. В крупных городах ДФО есть и курьеры, и пункты выдачи, плотнее других представлен СДЭК. Присутствие Boxberry проверяйте по конкретному городу: карта пунктов у него в регионе заметно реже. В посёлках, на Курилах, в северной Якутии и на Чукотке остаётся Почта России. Отсюда требование к корзине: недоступные для адреса службы калькулятор обязан скрывать, а почтовый вариант оставлять запасным. Сроки для островов зависят от парома и погоды, поэтому «3-5 дней» на Курилы читается как обман.

И деталь, на которой спотыкаются подрядчики из Москвы. Владивосток опережает Москву на семь часов, поэтому заказы, оформленные ночью и ранним утром по местному времени, до семи утра, попадают во вчерашний московский день. Склад, который отбирает заявки «за сегодня» по Москве, теряет их до следующей смены. Лечится хранением времени в UTC.

CRM и источник заявки: что теряется по дороге

Ручной перенос заказов в CRM выглядит безобидно: менеджер копирует данные из админки в карточку сделки. Теряется больше, чем кажется. Первое - источник: UTM-метки и идентификатор посетителя из Метрики руками никто не переносит, и через месяц вы не скажете, какая кампания в Директе принесла деньги. Второе - время: в сделку попадает момент, когда у менеджера дошли руки. Третье - часть заказов не доезжает вовсе. Четвёртое - дубли.

Как оценить свои потери

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

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

Что подключать первым

Начинайте с одностороннего потока: заказ с сайта создаёт сделку и контакт. Для связки Битрикс24 и 1С-Битрикс это работает штатно. С WooCommerce, OpenCart или самописным магазином, а также с amoCRM в любой связке, задача закрывается готовым модулем из маркетплейса либо обменом через API, то есть отдельной работой с настройкой и бюджетом. Передавайте состав и сумму заказа, доставку и адрес, промокод и метки источника, а контакт ищите по нормализованному телефону.

Вторым шагом делается обратный поток: смена статуса сделки меняет статус заказа на сайте и запускает уведомление клиенту. Третьим идут сегменты и отчёты по источникам. А тащить в CRM просмотры карточек и каждый чат не стоит: воронка превращается в свалку.

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

Оплата и чек: возвраты, частичная отгрузка, предзаказ

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

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

Связку «оплата плюс касса» нельзя считать готовой, пока не проверены отмена, частичная отгрузка и возврат: мы прогоняем эти сценарии на тестовой кассе до запуска. Маркировка в Честном знаке проектируется вместе со складом.

Склад помимо 1С: МойСклад, таблицы и самописные системы

1С стоит далеко не у всех, и это не проблема. Интеграция интернет-магазина со складом собирается вокруг любой системы, где живут остатки и отгрузки. Вопрос один: есть ли у неё внятный интерфейс обмена.

Чаще прочих мы собираем связку с МойСклад: REST API, вебхуки, готовые модули под WooCommerce и Битрикс, документы и печать этикеток из коробки. Дописывать приходится резервы и правило выбора склада, а проверять - типы цен и лимиты запросов.

Учёт в таблицах тоже работает, если понимать ограничения. Excel и Google Sheets отдают остатки файлом по расписанию: резервов нет, остаток отстаёт на интервал выгрузки, нужен единый артикул. Со складскими программами всё упирается в описание формата и в человека со стороны поставщика, а самописная база или ERP - самый трудоёмкий вариант: обмен, очередь заданий и журнал ошибок пишутся с нуля.

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

Что берётся готовым модулем, а что придётся дописывать

Готовое решение закрывает механику: сходить в API, получить ответ, положить данные в базу. Дописывают бизнес-правила, ту часть, которая у каждого магазина своя.

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

С чего начать у себя

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

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

Опишите свой стек: CMS, учётную систему, службы доставки, CRM и кассу. Мы посмотрим и скажем, что закрывается готовым модулем, что настраивается руками, а что придётся дописывать, и во что это примерно обойдётся. Заполнить бриф можно за десять минут, а посмотреть, как мы работаем с магазинами, - на странице разработки сайтов и интернет-магазинов.