Реализация собственной курьерской доставки на сайте

Объём доставок растёт — 50, 100, 300 заказов в день. Комиссии агрегаторов съедают маржу. Собственная курьерская служба решает обе проблемы: вы контролируете качество и экономите до 40%. По данным нашего опыта, после внедрения собственной системы операционные расходы снижаются на 25–40%, а время доставки сокращается в среднем на 20%. Наши инженеры реализовали 30+ проектов курьерской доставки для e-commerce и доставки еды. За 8–12 недель вы получаете систему под ключ с диспетчерской панелью, мобильным приложением курьера и трекингом для клиента. Система управления курьерами состоит из трёх компонентов: бэкенда, веб-панели и мобильного приложения. В этой статье — архитектура, модели данных, алгоритмы распределения и ответы на ключевые вопросы внедрения. Свяжитесь с нами для детального расчёта вашей системы.

Архитектура системы

Компоненты

• Backend: REST API + WebSocket-сервер для реалтайм-координат. Обрабатывает до 1000 заказов в день.
• Диспетчерская панель: веб-интерфейс для управления курьерами и маршрутами.
• Мобильное приложение курьера: React Native или PWA для приёма заданий и отправки GPS-координат каждые 30 секунд.

Модель данных

couriers (
  id, user_id, name, phone, vehicle_type,
  status: offline | available | busy | on_break,
  current_lat, current_lng, last_seen_at,
  zone_ids (jsonb)  -- зоны доставки, за которые отвечает курьер
)

delivery_tasks (
  id, order_id, courier_id (nullable),
  status: pending | assigned | picked_up | in_transit | delivered | failed,
  pickup_address, delivery_address,
  scheduled_at, picked_up_at, delivered_at,
  proof_photo_url,  -- фото при вручении
  recipient_signature_url,  -- подпись получателя
  failure_reason
)

courier_routes (
  id, courier_id, date,
  task_ids (jsonb, ordered),  -- очерёдность доставок
  total_distance_km, estimated_duration_min
)

Диспетчерская панель

Карта с курьерами в реальном времени (Яндекс.Карты или Leaflet). Доступен список нераспределённых заказов, drag-and-drop назначение, очередь задач с перестановкой. Мониторинг: если курьер не двигается 20 минут — алерт диспетчеру. История маршрутов и эффективность за день.

Мобильное приложение курьера

Основные экраны:

• Список заданий — текущий маршрут, следующая точка.
• Навигация — интеграция с Яндекс.Навигатором через deep link.
• Подтверждение доставки — фото вручения, подпись или код подтверждения из SMS.
• Обработка ошибок — причина: не открыли дверь, перенос, отказ.

Трекинг для покупателя

Покупатель получает SMS/push с ссылкой на трекинг-страницу. На странице — карта с курьером в реальном времени и ETA, пересчитываемая каждые 2 минуты.

Зоны доставки

Географические зоны — полигоны на карте, хранятся в PostgreSQL с расширением PostGIS. Запрос выполняется за 5–10 мс:

SELECT * FROM delivery_zones
WHERE ST_Contains(polygon, ST_SetSRID(ST_MakePoint(lng, lat), 4326));

Обработка неудачных доставок

Курьер не застал получателя — статус failed с причиной. Автоматически планируется повторная доставка на следующий день или клиент выбирает новое время. Диспетчер получает уведомление.

Как работает автоматическое распределение заказов?

Ручное назначение: диспетчер перетаскивает заказ на курьера на карте — подходит до 50 заказов в день. Автоматическая маршрутизация использует алгоритм Vehicle Routing Problem (VRP). Для небольших объёмов — жадный алгоритм (ближайший свободный курьер). Для серьёзной оптимизации — Google OR-Tools или сервисы OptimoRoute, Route4Me.

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

# Простая эвристика: назначить ближайшего свободного курьера
def assign_courier(task):
    available_couriers = Courier.objects.filter(status='available')
    nearest = min(available_couriers,
                  key=lambda c: haversine(c.location, task.pickup_address))
    task.assign(nearest)

Сравнение инструментов маршрутизации

Почему собственная доставка выгоднее?

Собственная доставка обходится в 2–3 раза дешевле агрегаторов при объёме от 100 заказов в день. Система окупается при объёме от 50 заказов в день. Экономия на комиссиях агрегаторов достигает 40% при 100+ заказах, а окупаемость системы — 6–8 месяцев. Стоимость разработки системы под ключ начинается от 1 500 000 ₽, что сопоставимо с комиссиями агрегатора за 3 месяца при 100 заказах в день. Вы получаете полный контроль над брендом, гибкие тарифы и расчёт стоимости доставки, а также все данные для аналитики. Точность ETA составляет ±3 минуты. Гарантируем стабильную работу даже в пик — проверено на 30+ проектах.

Процесс внедрения

1. Аналитика: изучаем ваш бизнес-процесс, объём заказов, географию.
2. Проектирование: архитектура, модель данных, прототип интерфейса.
3. Реализация: разработка бэкенда, диспетчерской панели, мобильного приложения.
4. Тестирование: нагрузочное тестирование, юзабилити-тесты с реальными курьерами.
5. Деплой: развёртывание на вашем сервере или в облаке, обучение команды.

Что входит в работу

• REST API и WebSocket-сервер для реалтайм-трекинга
• Диспетчерская панель на React с картой и drag-and-drop
• Мобильное приложение курьера (React Native) с навигацией и фотофиксацией
• Интеграция с CRM/ERP через API
• Документация и обучение
• Гарантийная поддержка 3 месяца

Срок разработки полной системы под ключ — 8–12 недель. Стоимость рассчитывается индивидуально, средний проект — от 1 500 000 ₽. Для консультации и расчёта свяжитесь с нами.

Как интеграция служб доставки влияет на конверсию?

Интернет-магазин теряет клиентов не на странице товара, а на шаге выбора доставки — это подтверждают наши проекты. Слишком мало вариантов, неверные тарифы, отсутствие калькулятора — и покупатель уходит. По данным Baymard Institute, 22% пользователей отказываются от заказа из-за неудобных условий доставки. Если магазин не предлагает хотя бы две-три службы с прозрачным расчётом, потеря выручки становится системной.

Мы занимаемся подключением логистических сервисов более шести лет и реализовали свыше 30 проектов для магазинов разного масштаба — от нишевых брендов до маркетплейсов с миллионными оборотами. Интеграция — это не просто «вывести список ПВЗ». Это актуальные тарифы по весу и габаритам, автоматическое создание заявок, отслеживание статуса, обработка ошибок API. Подход «под ключ» гарантирует, что система будет работать без сбоев даже при пиковых нагрузках в Черную пятницу.

Какие проблемы решает настройка доставки?

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

СДЭК API v2 — наиболее зрелый из российских перевозчиков. OAuth 2.0 авторизация (токен живёт 24 часа, нужна логика рефреша), REST JSON. Расчёт тарифов через POST /v2/calculator/tariff, список ПВЗ через GET /v2/deliverypoints. Типичная ошибка: забыть передать from_location и packages с реальными весом и размерами — в ответ приходит error_code: 3 без объяснений. ПВЗ нужно кешировать (список меняется нечасто), иначе каждый запрос к чекауту генерирует отдельный API-вызов.

Boxberry API — проще по функционалу, XML в ряде методов (legacy), часть API — REST. Токен передаётся как GET-параметр (не Authorization header), что нетипично. Список ПВЗ возвращает всё сразу (~2MB JSON), его обязательно нужно кэшировать в Redis или БД с ночным обновлением.

Почта России API — самый сложный из российских. SOAP + REST гибрид, требует договора и настройки в ЛК. x-user-authorization + Authorization — два разных заголовка одновременно. Нормативные отправления, EMS, 1-й класс — разные тарифные группы. Индексы ПВЗ (почтовые отделения) — отдельный справочник, не всегда актуальный.

DHL Express API — для международной доставки. XML-based API (DHL XML Services), хотя есть более новый MyDHL+ API. Требует зарегистрированного account number. Rate Request для расчёта, Shipment Request для создания накладной, возвращает PDF с label.

Почему кэширование ПВЗ и тарифов обязательно?

Кэширование — не опция, а необходимость. API СДЭК имеет лимит 1000 запросов в минуту, Boxberry — 300. Без кэша даже средний магазин с 1000 посетителей в час рискует получить 429 ошибку. Мы используем Redis или PostgreSQL с TTL 30 минут для тарифов и ночное обновление для ПВЗ. Это снижает нагрузку на API на 70–80% и ускоряет отображение на странице. Параллельные запросы с кэшем сокращают время расчёта в 7 раз по сравнению с последовательными — вместо 2,8 секунд клиент получает тарифы за 380 мс.

Что входит в работу по подключению?

Каждый проект включает:

• документацию: описание архитектуры, схемы данных, инструкции по эксплуатации
• предоставление доступов: API-ключи, вебхуки, тестовые контуры
• обучение команды: вебинар или письменная инструкция по работе с админкой
• поддержку на старте: 2 недели пост-релизного мониторинга и исправлений

Как строим интеграцию

1. Абстракция над провайдерами. Ни один магазин не использует одну службу доставки вечно. Строим единый интерфейс: DeliveryProvider с методами calculateRates(), createShipment(), trackShipment(), getPickupPoints(). Каждая служба — отдельная реализация. Переключить провайдера или добавить нового — не означает переписывать checkout.

2. Кэширование ПВЗ. Геопоиск ПВЗ по координатам или городу — частый запрос. Тянуть с API каждый раз нельзя (лимиты, задержка). Схема: ночное задание обновляет таблицу pickup_points в PostgreSQL с PostGIS или просто с lat/lng. Поиск ближайших — ORDER BY ST_Distance() или простая формула Хаверсина, если PostGIS избыточен.

3. Виджет на фронтенде. СДЭК предоставляет официальный JS-виджет (@cdek-it/widget) — быстро, но ограниченно в кастомизации. Для нестандартных дизайнов — кастомный виджет: карта (Яндекс.Карты API или Leaflet с тайлами 2GIS), список ПВЗ с фильтрами, детальная карточка точки с режимом работы.

4. Трекинг статусов. Статусы заказов приходят либо через webhook (СДЭК поддерживает), либо через периодический polling (Boxberry, Почта России). Для polling — очередь задач (Laravel Queue, Bull для Node.js), проверка раз в 4–6 часов, нотификация покупателю при смене статуса через email или SMS.

Кейс: мультиперевозчик для WooCommerce. Магазин спортивного питания: СДЭК + Boxberry + самовывоз из 3 магазинов. Плагин Доставки WooCommerce не давал нужной гибкости — написали кастомный Shipping Method. calculate_shipping() делает параллельные запросы к обоим API через GuzzleHttp\Pool, агрегирует тарифы, фильтрует по зоне доставки (нет СДЭК — показываем только Boxberry). Кэш тарифов в Redis на 30 минут по ключу delivery:{city}:{weight}:{dimensions}. Время расчёта: было 2.8s (последовательные запросы), стало 380ms (параллельно + кэш), что дало рост конверсии на 15% на этапе чекаута.

Процесс и сроки

Стоимость рассчитывается индивидуально — зависит от количества провайдеров, необходимости кастомного виджета и сложности трекинга. Интеграция одной службы доставки в среднем обходится от 45 000 до 90 000 ₽. При автоматизации обработки 500 заказов в месяц экономия на операционных расходах достигает 360 000 ₽ в год. Для точной оценки свяжитесь с нами: мы проанализируем ваш магазин и предложим решение.

Типичные ошибки при самостоятельной настройке

• Забыть про квоты API — приводит к блокировке доступа
• Не кэшировать список ПВЗ — страница загружается 5+ секунд
• Игнорировать обработку ошибок (timeout, 504) — потеря заказов
• Не тестировать граничные веса и размеры — расчёт уходит в бесконечность

Наш опыт (30+ интеграций) подтверждает: правильная архитектура с кэшем и параллелизацией сокращает время ответа до 300–400 мс даже при трёх провайдерах. Закажите интеграцию служб доставки — получите консультацию инженера без обязательств. Свяжитесь с нами, и мы подберём оптимальное решение для вашего магазина.