Обмен данными
Что ходит в обе стороны
| Поле | Направление | Комментарий |
|---|---|---|
| Заказ и позиции | 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 с явным указанием типа поиска
✓Составные объекты (например, курьер) передаются корректно сериализованными — это частая ошибка самописных интеграций
✓Идемпотентность: повторный вебхук по тому же заказу не создаёт дубль
✓Логирование обмена: видно, какой запрос ушёл и что вернулось
700
Заказов в пиковый день
< 1 сек
Проброс статуса
0
Ручных выгрузок
3 дня
Настройка
Итог
Что меняется у команды
Оператор продолжает работать в RetailCRM и не учит новый интерфейс. Всё, что он видит нового — актуальный статус доставки и курьера прямо в карточке.
Диспетчер переезжает в ADelivo и перестаёт вести параллельные таблицы: маршруты, изменения, геолокация и расчёты — в одном экране.
Курьер получает PWA вместо чата: только свои заказы, навигатор в тап, смена статуса из карточки, push при любом изменении.
Как это выглядит на реальном бизнесе — в кейсе цветочного магазина «Банч»: 700 заказов в день, около 100 курьеров на 8 марта и полностью автоматические выплаты.
Вопросы и ответы
RetailCRM и доставка
Не нашли ответ — напишите в Telegram, отвечаем в течение часа в рабочее время.
Это самая обкатанная интеграция?
Да. ADelivo вырос из проекта, где RetailCRM была основной системой, и связка прошла через пиковые нагрузки в 700 заказов за день. Работа с API v5, вебхуками и особенностями передачи составных объектов уже отлажена.
Какие статусы синхронизируются?
Соответствие настраивается под вашу схему. Типовая раскладка: «сборка» и «собран» приходят из CRM, а «передан курьеру», «в пути», «доставлен», «возврат» и «частичный возврат» формируются в ADelivo и уходят обратно.
Виден ли курьер в карточке заказа RetailCRM?
Да. При назначении маршрута курьер записывается в заказ CRM — с именем и телефоном, так что оператор поддержки может связаться с ним, не заходя в ADelivo.
Что с себестоимостью доставки?
Система считает стоимость доставки по зоне, типу передвижения курьера и надбавкам, и выгружает её в заказ RetailCRM одной кнопкой. Это позволяет видеть реальную маржу по заказу, а не среднюю по складу.
Что произойдёт, если API RetailCRM временно недоступен?
Заказы не теряются: изменения копятся и досылаются, плюс работает периодическая сверка. В диспетчерском экране при этом всё продолжает работать — курьеры не зависят от доступности CRM.
Оставить заявку
Подключим RetailCRM
Оставьте заявку — настроим тестовый обмен на ваших заказах и покажем, как статусы ходят в обе стороны.