Впровадження власної кур'єрської доставки

Обсяг доставок зростає — 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 місяців. Ви отримуєте повний контроль над брендом, гнучкі тарифи та розрахунок вартості доставки, а також всі дані для аналітики. Точність ETA становить ±3 хвилини. Гарантуємо стабільну роботу навіть у пік — перевірено на 30+ проєктах.

Процес впровадження

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

Що входить у роботу

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

Термін розробки повної системи під ключ — 8–12 тижнів. Вартість розраховується індивідуально. Для консультації та розрахунку зв'яжіться з нами.

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

Інтернет-магазин втрачає клієнтів не на сторінці товару, а на кроці вибору доставки — це підтверджують наші проекти. Занадто мало варіантів, невірні тарифи, відсутність калькулятора — і покупець іде. За даними 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% на етапі чекауту.

Процес та терміни

Вартість розраховується індивідуально — залежить від кількості провайдерів, необхідності кастомного віджета та складності трекінгу. Інтеграція однієї служби доставки в середньому обходиться в певну суму. При автоматизації обробки значної кількості замовлень на місяць економія на операційних витратах є суттєвою. Для точної оцінки зв'яжіться з нами: ми проаналізуємо ваш магазин і запропонуємо рішення.

Типові помилки при самостійному налаштуванні

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

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