Коротко
Зачем связывать RetailCRM с доставкой
RetailCRM хорошо ведёт заказ до момента, когда его нужно везти: карточка, оплата, статус сборки. Дальше начинается доставка, и она обычно живёт отдельно — в чатах, таблицах и звонках диспетчера. Из-за этого в CRM не видно, где курьер, когда заказ доставлен и сколько эта доставка стоила.
Интеграция закрывает именно этот разрыв. Заказы приходят вебхуком в экран заказов, адреса геокодируются, маршруты собираются автоматически, а статус, курьер и себестоимость возвращаются в карточку заказа RetailCRM. Оператору при этом не нужно менять привычные процессы: он продолжает работать там же, где работал.
Если вы только выбираете систему, начните с обзорной страницы CRM для доставки — там разобрано, что остаётся в вашей CRM, а что забирает на себя ADelivo.
Ноль ручных выгрузок
Заказы и статусы ходят автоматически — без выгрузок в Excel и пересылки списков курьерам.
Доставка видна в CRM
Оператор поддержки отвечает клиенту, не выходя из RetailCRM: статус и курьер прямо в карточке.
Понятная себестоимость
Стоимость доставки по зоне и надбавкам возвращается в заказ — маржа считается по факту, а не в среднем.
Границы систем
Что остаётся в RetailCRM,
а что забирает ADelivo
Это не замена CRM и не второй интерфейс для операторов. Линия раздела одна: всё до передачи заказа курьеру остаётся у вас, всё после — в ADelivo.
| Задача | RetailCRM | ADelivo |
|---|---|---|
| Клиент, заказ, оплата, сборка | Да | — |
| Распределение заказов по своим курьерам | — | Да |
| Маршрут с учётом зон, слотов и загрузки | — | Да |
| Приложение курьера и геолокация | — | Да |
| Статус доставки в карточке заказа | Показывает | Источник |
| Себестоимость конкретной доставки | Поле в заказе | Расчёт |
| Выплаты курьерам, акты, самозанятые | — | Да |
Поэтому у операторов ничего не меняется: они остаются в RetailCRM и видят там актуальный статус и курьера. Отдельный экран появляется только у диспетчера, а курьер вместо чата получает своё рабочее место с маршрутом на день.
Обмен данными
Что ходит в обе стороны
| Поле | Направление | Комментарий |
|---|---|---|
| Заказ и позиции | CRM → EW | Состав нужен, чтобы курьер видел, что везёт, и мог зафиксировать пересорт |
| Адрес доставки | CRM → EW | Чистится и геокодируется, исправленная версия уходит обратно |
| Интервал доставки | CRM → EW | Текстовый слот разбирается в диапазон «с — по» |
| Комментарий клиента и менеджера | CRM ↔ EW | Виден курьеру, курьерский комментарий возвращается |
| Статус доставки | EW → CRM | Передан, в пути, доставлен, возврат, частичный возврат |
| Курьер | EW → CRM | ФИО и телефон назначенного курьера |
| Стоимость доставки | EW → CRM | По зоне и надбавкам, выгрузка одной кнопкой |
Сценарий дня
Как проходит обычный день
Утро: заказы подтягиваются
Все заказы на сегодня с нужными статусами уже в диспетчерском экране, адреса геокодированы, проблемные подсвечены.
Распределение
AI собирает маршруты по зонам и слотам, диспетчер правит спорные точки и подтверждает.
Курьеры выходят
Push с маршрутом, ссылка в навигатор, чат с диспетчером — всё в PWA.
Изменения по ходу дня
Оператор в RetailCRM переносит время или меняет состав — изменение прилетает в ADelivo и попадает на «табло изменений» менеджера, курьер получает push.
Закрытие дня
Статусы доставлены обратно в CRM, себестоимость выгружена, расчёт по курьерам сформирован.
Выплаты
Акты и переводы самозанятым уходят через Консоль.Про — без участия бухгалтера.
Технические детали
Для вашего интегратора
✓Работа через REST API v5 RetailCRM и подписку на вебхуки
✓Поиск заказа по внутреннему идентификатору CRM с явным указанием типа поиска
✓Составные объекты (например, курьер) передаются корректно сериализованными — это частая ошибка самописных интеграций
✓Идемпотентность: повторный вебхук по тому же заказу не создаёт дубль
✓Логирование обмена: видно, какой запрос ушёл и что вернулось
500+
Заказов в пиковый день
< 1 сек
Проброс статуса
0
Ручных выгрузок
3 дня
Настройка
Запуск
Как проходит подключение за три дня
Настройку делаем мы, участие вашего разработчика не требуется.
День 1: доступы и первый обмен
Вы выдаёте ключ API RetailCRM с нужными правами, мы поднимаем подписку на вебхуки и показываем первые тестовые заказы в экране диспетчера.
День 2: статусы, зоны и ставки
Раскладываем ваши статусы на схему доставки, заводим зоны, ставки курьеров и надбавки, проверяем, как разбираются слоты и адреса.
День 3: боевой день и обучение
Проходим один реальный день вместе с диспетчером, дособираем мелочи и подключаем курьеров — установка приложения занимает около полуминуты.
Подключение бесплатное, первая неделя работы — тоже. Выплаты курьерам можно сразу завести через Консоль.Про: после закрытия дня акты и переводы уходят без бухгалтера.
Итог
Что меняется у команды
Оператор продолжает работать в RetailCRM и не учит новый интерфейс. Всё, что он видит нового — актуальный статус доставки и курьера прямо в карточке.
Диспетчер переезжает в ADelivo и перестаёт вести параллельные таблицы: маршруты, изменения, геолокация и расчёты — в одном экране.
Курьер получает PWA вместо чата: только свои заказы, навигатор в тап, смена статуса из карточки, push при любом изменении.
Как это выглядит на реальном бизнесе — в кейсе цветочного магазина «Банч»: 500+ заказов в день, около 100+ курьеров на 8 марта и полностью автоматические выплаты.
Вопросы и ответы
RetailCRM и доставка
Не нашли ответ — напишите в Telegram, отвечаем в течение часа в рабочее время.
Это самая обкатанная интеграция?
Да. ADelivo вырос из проекта, где RetailCRM была основной системой, и связка прошла через пиковые нагрузки в 500+ заказов за день. Работа с API v5, вебхуками и особенностями передачи составных объектов уже отлажена.
Чем это отличается от штатной доставки в RetailCRM?
В RetailCRM доставка — это поля заказа: служба, дата, стоимость. Чего в ней нет: распределения заказов по своим курьерам, маршрута с учётом зон и слотов, приложения курьера, геолокации и расчёта выплат. ADelivo закрывает именно эту часть и возвращает результат в карточку, поэтому отказываться от RetailCRM не нужно.
Сколько стоит интеграция с RetailCRM?
Подключение бесплатное: настройка обмена, маппинг статусов и зоны доставки входят в запуск. Платите вы только за фактические заказы, прошедшие через систему, а первая неделя идёт без оплаты и без привязки карты.
Нужен ли свой разработчик или интегратор?
Нет. От вас нужен доступ к RetailCRM с правами на API и понимание, какими статусами вы пользуетесь. Остальное настраиваем мы, обычно за три рабочих дня. Если у вас есть свой интегратор, он может забрать настройку на себя — схема обмена открытая.
Можно ли подключить несколько магазинов в одной RetailCRM?
Да. Заказы делятся по магазину, складу или зоне и уходят на разные группы курьеров. Это же нужно сети с несколькими городами: у каждого свой набор зон и ставок, а CRM остаётся одна.
Что будет со старыми заказами при подключении?
Историю не трогаем: в работу подтягиваются заказы с нужными статусами начиная с даты запуска. При желании догружаем предыдущие дни, чтобы диспетчер сразу видел привычную картину.
Какие статусы синхронизируются?
Соответствие настраивается под вашу схему. Типовая раскладка: «сборка» и «собран» приходят из CRM, а «передан курьеру», «в пути», «доставлен», «возврат» и «частичный возврат» формируются в ADelivo и уходят обратно.
Виден ли курьер в карточке заказа RetailCRM?
Да. При назначении маршрута курьер записывается в заказ CRM — с именем и телефоном, так что оператор поддержки может связаться с ним, не заходя в ADelivo.
Что с себестоимостью доставки?
Система считает стоимость доставки по зоне, типу передвижения курьера и надбавкам, и выгружает её в заказ RetailCRM одной кнопкой. Это позволяет видеть реальную маржу по заказу, а не среднюю по складу.
Что произойдёт, если API RetailCRM временно недоступен?
Заказы не теряются: изменения копятся и досылаются, плюс работает периодическая сверка. В диспетчерском экране при этом всё продолжает работать — курьеры не зависят от доступности CRM.
Оставить заявку
Подключим RetailCRM
Оставьте заявку — настроим тестовый обмен на ваших заказах и покажем, как статусы ходят в обе стороны.