Александр Руин

Консультант по проектированию AI‑систем

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

Дашборд для службы доставки 2026: SLA, failed delivery, route time, fuel и возвраты

Дашборд для службы доставки нужен не для того, чтобы показать диспетчеру еще одну красивую карту. Его задача практичнее: вовремя увидеть заказы, которые уже рискуют нарушить SLA, понять, где курьеры теряют время на маршруте, сколько стоит failed delivery, какие возвраты блокируют товар и почему маркетплейс или клиент видит один срок доставки, а операционная команда - другой.

SimpleDashboard подходит для первого рабочего экрана из CSV/XLSX/API-выгрузки CRM, TMS, курьерского приложения, 1С, маркетплейса или таблицы диспетчера. AI может быстро собрать прототип по описанию на русском языке, но формулы SLA, исключения, timezone, статусы курьеров и контрольные строки должен подтвердить владелец операционного процесса.

Дашборд для службы доставки время доставки, SLA, failed delivery и нагрузка курьеров

Главное

  • Для первого экрана доставки обычно хватает 8-10 KPI: OTD/SLA, OTIF при необходимости, failed delivery rate, first-attempt success, average route time, stops per hour, cost per delivery, fuel per route, returns/RTO и data quality.
  • McKinsey отдельно подчеркивает, что у OTIF нет единого стандартного определения: участники цепочки могут по-разному понимать promised date, requested date, time window и "in full". Поэтому SLA на дашборде нельзя выводить без словаря.
  • Shipium в документации On-Time Performance считает показатель как процент shipments, доставленных on or before desired delivery date, и отдельно показывает разрезы по carrier, service method, origin/destination и service level. Это хороший шаблон для структуры доставки, даже если у вас не Shipium.
  • DHL eCommerce в опросе 2025 года на 24 000 онлайн-покупателей пишет, что 73% global shoppers не купят у retailer, если не доверяют delivery provider. Доставка и возвраты - не "последний шаг", а часть конверсии и повторной покупки.
  • NRF в 2025 Retail Returns Landscape оценивает, что 19.3% online sales будут возвращены в 2025 году. Для дашборда доставки это значит: возвраты и RTO должны быть отдельным процессом, а не серой строкой "не доставлено".
  • Форумы, Reddit и courier communities использованы ниже только как сигналы полевых проблем: невозможные SLA, same-day route changes, адреса без деталей, возвраты на склад, ночные маршруты, спор "курьер виноват или обещание было нереальным". Точные формулы проверяются по официальным docs и вашим данным.

Эта статья для владельца интернет-магазина, руководителя доставки, диспетчера, COO или marketplace operations, которому нужен дашборд службы доставки для ежедневного управления, а не общий текст про "аналитику логистики".

В нашем тесте прототипа SimpleDashboard для операционного экрана доставки чаще всего ломался не график, а словарь статусов. В одной выгрузке delivered означает вручение клиенту, в другой - размещение в ПВЗ, в третьей - скан курьера без подтверждения клиента. failed может означать недозвон, неверный адрес, отказ, отсутствие клиента, отмену продавцом, техническую ошибку или возврат после нескольких попыток. Поэтому хороший дашборд начинается с KPI/risk table, а не с выбора цвета gauge.

Logistics KPI/risk table для первого экрана

KPI Формула для пилота Что проверить в данных Риск неверного вывода Управленческое действие
OTD / SLA доставлено в обещанное окно / все доставленные заказы * 100% Promise date, delivery window, timezone, переносы по просьбе клиента Команда спорит, late это 1 минута после окна или следующий день Пересмотреть слот, capacity, carrier, обещания на сайте
OTIF on time and complete orders / total orders * 100% Полная комплектация, partial delivery, split shipment Заказ вовремя, но не весь; клиент все равно недоволен Разделить проблемы склада и доставки
Failed delivery rate failed attempts / all attempts * 100% Причина failed, attempt number, кто инициировал отмену Курьер выглядит виноватым, хотя адрес неполный или клиент недоступен Ввести pre-dispatch проверку адреса/телефона
First-attempt success orders delivered on first attempt / orders attempted * 100% Повторные попытки, ПВЗ, курьерская доставка, COD Повторные попытки съедают смену и fuel, но не видны в delivered rate Отдельно считать повторные маршруты и cost per reattempt
Average delivery time delivered_at - accepted_at или другое согласованное окно От какого события считать: заказ, сборка, pickup, out for delivery Смешиваются складская задержка и курьерский маршрут Разделить order-to-ship, ship-to-deliver, route time
Route time route_finished_at - route_started_at Возврат на базу, break, ожидание клиента, offline gaps Курьер "медленный", хотя маршрут был невозможен по плотности/пробкам Пересобрать зоны, stop density, cut-off time
Stops per hour completed stops / active route hours Доставки, заборы, возвраты, ПВЗ, ожидание Нельзя сравнивать центр города, пригород и крупногабарит Сегментировать по зоне, типу заказа, весу и окнам
Fuel / km per order fuel или km / delivered orders Пробег по GPS, личный/служебный транспорт, холостой пробег Экономия на fuel может ухудшить SLA и first-attempt success Смотреть вместе с SLA, route density и failed attempts
Courier load активные заказы / курьер / смена и active hours Статусы online/offline/break, тип транспорта, зона Перегруз одного курьера скрывается средним числом по смене Балансировать назначение и лимиты по зонам
Returns / RTO returned orders / shipped orders * 100% Возврат клиента, отказ от получения, брак, failed COD, marketplace return Возврат списывается на доставку, хотя причина в товаре/описании Разделить причины и стоимость reverse logistics
Data quality Пустые статусы, дубли order_id, нет courier_id, нет promise date Поля, timezone, дубли попыток, пропуски GPS/status KPI выглядят точными, но собраны из неполной выгрузки Показывать ошибки данных рядом с KPI

Не все метрики нужны одинаково крупно. Для диспетчера на смене важнее опаздывающие заказы, route exceptions, курьеры без связи, next SLA breach и failed attempts сегодня. Для руководителя важнее SLA по зонам, cost per delivery, first-attempt success, fuel/km, returns и тренды по причинам.

Что считается late delivery, а что failed delivery

Late delivery - это нарушение обещанного клиенту или партнеру времени. Но обещание бывает разным: дата доставки на сайте, слот 10:00-14:00, SLA маркетплейса, внутренний cut-off, договорной срок B2B или requested date клиента. McKinsey на примере OTIF показывает, что разные стороны могут считать "on time" по разным датам и окнам. В дашборде поэтому рядом с SLA нужно показывать sla_basis: promised date, requested date, delivery slot, carrier desired delivery date или marketplace metric.

Failed delivery - это не просто "заказ не доставлен". Для управления нужны причины:

  • клиент недоступен или не ответил на звонок;
  • адрес неполный, неверный подъезд, нет домофона, нет landmark;
  • курьер не успел в маршрутное окно;
  • заказ отменен продавцом или клиентом до попытки;
  • клиент отказался от COD/оплаты при получении;
  • товар поврежден, некомплектен или не подходит;
  • заказ перенесен клиентом и не должен портить SLA курьера;
  • маркетплейс или carrier изменил обещанную дату;
  • техническая ошибка статуса или скана.

Если эти причины не разделены, дашборд будет подталкивать к неправильным решениям: штрафовать курьеров за невалидные адреса, увеличивать смену вместо проверки cut-off, покупать TMS вместо исправления карточки товара или обещать same-day там, где зона физически не выдерживает маршрут.

Какие данные нужны для пилота

Минимальный CSV/XLSX для первого дашборда:

  • заказ: order_id, created_at, paid_at, cancelled_at, source, marketplace, payment_type, cod_flag;
  • обещание: promised_from, promised_to, desired_delivery_date, sla_type, cutoff_time;
  • маршрут: route_id, courier_id, vehicle_type, zone, route_started_at, route_finished_at;
  • статусы: status, status_at, attempt_number, failure_reason, reschedule_reason;
  • фактическая доставка: out_for_delivery_at, delivered_at, proof_type, recipient_confirmed;
  • стоимость: delivery_fee, courier_cost, fuel_cost или km, carrier_cost, return_cost;
  • возвраты: return_requested_at, returned_at, return_reason, rto_flag, restocked_at;
  • качество данных: timezone, источник выгрузки, last_updated_at, дубли order/attempt/status.

Если нет fuel или GPS, можно начать с route time, stops per hour и cost per delivery. Если нет причин failed delivery, первым результатом дашборда должен стать список строк "failed без причины", а не уверенный график виновников.

Marketplace delivery data: что не забыть

Маркетплейсы измеряют доставку не так, как внутренний Excel диспетчера. Amazon OTDR для seller-fulfilled units считает delivered on or before seller-promised "Deliver by" date, использует rolling 14-day evaluation и ожидает минимум 90% OTDR для Amazon.co.uk FBM, рекомендуя 95% и выше. Это не универсальный норматив для всех служб доставки, но хороший пример: маркетплейс формализует окно, выборку, исключения и последствия.

Ozon для realFBS в метрике Delivery on time смотрит заказы за последние 7 дней без текущего дня, сравнивает promised и actual delivery dates и показывает показатель в Analytics -> Ratings. В документации указано рекомендуемое значение не ниже 80%, а ошибки на стороне delivery service не должны снижать метрику продавца. Для собственного дашборда это сигнал хранить не только факт опоздания, но и ownership: продавец, склад, курьерская служба, клиент, маркетплейс.

Yandex Market API для продавцов покрывает orders, shipments FBS, DBS-delivery, non-purchases and refunds, reports/documents и API notifications по изменению заказов, статусов, cancellation requests, order cancellation, non-purchases и refunds. Если вы доставляете заказы маркетплейса своими силами, дашборду нужны не только курьерские статусы, но и события маркетплейса.

Wildberries API описывает доступ к up-to-date and statistical information, интеграцию с ERP/WMS/OMS/CRM, seller rating, reports, buyer returns и rate limits. Для регулярного dashboard refresh это важно: API-лимиты, задержки и ошибки 429/5xx должны отображаться как data freshness issue, а не молча превращаться в "сегодня заказов меньше".

Практический вывод: для marketplace delivery нельзя смешивать "внутренне доставлено", "маркетплейс принял статус", "клиент получил", "ПВЗ разместил", "возврат оформлен" и "деньги разблокированы". Это разные события и разные риски.

Риски, которые ломают доставочный дашборд

Риск Как проявляется Что ломается Как закрыть перед запуском
SLA без явного окна "Опозданий 12%", но непонятно: дата, слот или promised timestamp Сравнение зон, курьеров и marketplace metrics Завести sla_basis, promised_from/to, timezone и правило переносов
Attempt и order смешаны Один заказ с 3 попытками считается как 3 заказа Failed rate, first-attempt success, нагрузка Разделить order_id и attempt_id
Возврат считается как failed delivery Клиент вернул товар через 5 дней, а курьер попал в "не доставил" Рейтинг курьера, SLA, cost per delivery Разделить failed attempt, return, RTO, cancellation, defect
Не видно причины failed Все статусы "undelivered" в одном ведре Нельзя понять, что чинить Обязать reason code и показывать "unknown reason" отдельно
Route time включает break и ожидание склада Курьер выглядит медленным Нагрузка, stops/hour, премии Разделить pickup wait, route active, customer wait, return-to-base
Fuel смотрят отдельно от SLA Экономный маршрут ухудшает окна доставки Ложная экономия Считать fuel/km вместе с late orders и failed attempts
Marketplace статусы приходят позже Внутри доставлено, в кабинете еще "в пути" Штрафы, спор с клиентом, cash flow Показывать delay между internal status и marketplace accepted status
ПВЗ и courier delivery в одном KPI ПВЗ "доставлено на полку", курьер "вручено клиенту" SLA и first-attempt success несравнимы Сегментировать delivery_mode
AI угадал колонку по названию duration принят за route time, хотя это total order time Все средние времена Словарь полей и 10-20 контрольных заказов
Нет data freshness API упал, а график выглядит спокойным Решения по устаревшим данным last_updated_at, status refresh, ошибки API/лимитов на экране

Как собрать дашборд доставки через SimpleDashboard

Шаг 1. Выгрузите 30-60 дней заказов

Для пилота подойдет CSV/XLSX из CRM, 1С, МойСклад, RetailCRM, TMS, курьерского приложения, Яндекс Маркета, Ozon, Wildberries, Shopify, самописной админки или Google Sheets. Лучше взять период с обычными днями, выходными, пиками, возвратами и хотя бы несколькими маршрутными зонами.

Шаг 2. Приложите словарь статусов

Отдельно напишите, что у вас означает new, packed, assigned, out_for_delivery, delivered, failed, rescheduled, returned, cancelled, lost, partial, customer_not_home, wrong_address. Если словаря нет, SimpleDashboard может собрать черновик, но спорные статусы будут вынесены в таблицу проверки.

Шаг 3. Отправьте файл в Telegram

Напишите в @coderboxbot:

Собери дашборд службы доставки: SLA по обещанному окну, failed delivery rate, first-attempt success, среднее route time, stops per hour, нагрузка курьеров, fuel/km по маршрутам, возвраты/RTO и список заказов с риском опоздания сегодня.

AI предложит структуру графиков и найдет подозрительные колонки, но формулы фиксируются явно: от какого события считается delivery time, что делать с переносом клиента, как считать ПВЗ, что считается failed delivery и где граница ответственности курьера.

Шаг 4. Сверьте контрольные числа

До публикации сверяем минимум 10-20 заказов и 5 итогов:

  1. Количество заказов за период.
  2. Количество attempts.
  3. Доставлено в срок.
  4. Failed attempts по причинам.
  5. Возвраты/RTO и стоимость повторной логистики.

Если цифры не сходятся с CRM/TMS/маркетплейсом, сначала исправляем mapping, timezone, дубли статусов или фильтры. Дашборд с неверной базой вреднее, чем отсутствие дашборда.

Что показывать на первом экране

Зона экрана Что показывает Зачем диспетчеру или руководителю
SLA risk now Заказы, которые нарушат окно в ближайшие 30-90 минут Переназначить курьера, предупредить клиента, снять нереальное обещание
Active routes Курьер, зона, активные заказы, route progress, last status Видеть смену без ручного обзвона
Exceptions Failed, rescheduled, no contact, wrong address, lost scan Быстро разбирать проблемы, пока заказ еще можно спасти
SLA trend OTD/SLA по дням, зонам, delivery mode и источникам Понять, где системный провал, а не случайный курьер
First attempt Успешность первой попытки и причины повторов Снижать повторные выезды и reverse logistics
Route efficiency Route time, stops/hour, km/order, fuel/order Находить неэффективные зоны и перегруженные маршруты
Returns/RTO Возвраты, COD refusals, restock delay, return cost Видеть margin leakage, а не только "заказ не доставлен"
Data quality Дубли, пустые причины, stale API, unknown courier, missing promise Не принимать решения по грязным данным

Последний блок выглядит скучно, но именно он часто окупает дашборд. Если на экране видно "18% failed без reason", "43 заказа без promise date", "API маркетплейса не обновлялся 2 часа" или "route_id пустой у 31 заказа", команда перестает спорить о графиках и чинит источник.

Форумные и courier/ops signals: что проверять руками

Community-сигналы не являются источником нормативов, но хорошо показывают, где ломается реальная эксплуатация.

В r/logistics участники обсуждают same-day route changes и невозможные обещания продаж: один комментарий описывает, что route перестраивался по time commitment, ближайшей следующей точке и знанию района, а другой - что sales обещает 2-day transit без проверки carrier lane, border backlog и driver hours. Для дашборда это сигнал: нужен transit matrix, lane history и флаг "promise requires logistics approval".

В courier communities и Amazon Flex обсуждениях повторяются проблемы apartment access, lockers, ночные маршруты, возвраты на склад, маршруты, которые физически не помещаются в block time, и спорные отметки undeliverable. Для дашборда это сигнал: показывать access issues, return-to-station, route overload, safe delivery exceptions и time-window realism.

В ecommerce/dropshipping обсуждениях failed COD/RTO считают не только как reverse shipping fee, а как сумму outbound shipping, return shipping, labor, ad spend/CAC и blocked inventory. Это не доказательная база для конкретной суммы, но сильный сигнал для таблицы cost per failed delivery: считать всю экономику, а не только стоимость обратной посылки.

Когда достаточно Excel, а когда нужен SimpleDashboard

Ситуация Excel еще подходит Нужен SimpleDashboard
5-10 доставок в день, один диспетчер Да, если статусы дисциплинированы Только для еженедельного отчета владельцу
20-100 доставок в день и несколько курьеров Временно Да, чтобы видеть SLA, failed, нагрузку и маршруты
Есть ПВЗ, курьеры и маркетплейсы одновременно Риск смешанных статусов Да, нужна сегментация delivery_mode/source
Есть возвраты, COD или повторные попытки Excel быстро скрывает стоимость Да, нужен failed/RTO/cost блок
Нужно спорить с carrier или маркетплейсом Excel слаб для доказательства Да, если есть события, timestamps и audit trail
KPI влияют на штрафы/премии курьеров Риск конфликтов Нужны утвержденные формулы, контрольные строки и права доступа

SimpleDashboard не заменяет TMS, курьерское приложение, CRM или маркетплейс-кабинет. Его роль - быстрый управленческий слой поверх ваших данных: увидеть SLA, failed delivery, route time, fuel, returns и качество источников в одном месте.

Часто задаваемые вопросы

Как считать процент опозданий доставки?

Минимальная формула: заказы, доставленные позже обещанного окна / все заказы с обещанным окном * 100%. Но перед расчетом нужно определить basis: promised date, requested date, delivery slot, marketplace SLA или internal deadline. Без этого процент опозданий нельзя сравнивать между системами.

Failed delivery и возврат - это одно и то же?

Нет. Failed delivery - неуспешная попытка доставки. Возврат/RTO - отдельный обратный процесс, который может начаться после failed attempt, отказа клиента, брака, неподходящего товара или marketplace return. В дашборде их нужно разделять.

Что важнее: среднее время доставки или SLA?

SLA важнее для обещания клиенту, среднее время - для анализа процесса. Среднее может быть нормальным, но длинный хвост опозданий испортит клиентский опыт. Поэтому полезно смотреть SLA, p90/p95 delivery time и список будущих SLA breaches.

Как учитывать fuel и route time?

Не отдельно от качества. Fuel/order и km/order должны смотреться рядом с SLA, first-attempt success и failed attempts. Самый дешевый маршрут может оказаться дорогим, если растут опоздания и повторные выезды.

Можно ли подключить CRM или маркетплейсы напрямую?

Да, если источник отдает API или регулярный экспорт. Для маркетплейсов важно учитывать API-лимиты, задержку статусов и разные события: order, shipment, cancellation, non-purchase, refund, return.

Какие данные нельзя отправлять без подготовки?

Не отправляйте лишние персональные данные клиентов, полные адреса, телефоны и комментарии курьеров, если они не нужны для KPI. Для пилота часто достаточно обезличенного order_id, зоны, временных меток, статуса и reason code.

AI сам поймет все статусы доставки?

AI может предложить mapping, но не должен утверждать формулы без проверки. Статусы failed, returned, cancelled, delivered и rescheduled в разных системах означают разное. Нужны словарь, контрольные строки и ручная сверка.

Что подготовить перед внедрением

  • выгрузку заказов и attempts за 30-60 дней;
  • словарь статусов и failure reasons;
  • правило SLA: promised date, delivery window, timezone, переносы;
  • справочник курьеров, зон, vehicle type и смен;
  • данные по маршрутам: start/finish, stops, km или fuel при наличии;
  • данные по возвратам/RTO и причинам;
  • события маркетплейсов, если доставляете Ozon/Wildberries/Yandex Market/Amazon/Shopify orders;
  • 10-20 реальных заказов для ручной сверки формул.

Стоимость SimpleDashboard - 5 000 ₽/мес. Напишите в Telegram: @coderboxbot - соберем первый экран службы доставки по вашим данным и отдельно покажем, где KPI нельзя считать финальными без исправления источника.

Попробовать бесплатно | SimpleDashboard

Смотрите также

Источники и проверка

Официальные и исследовательские источники:

Community-сигналы, использованные только как индикаторы практических проблем:

AI disclosure: материал обновлен 2026-05-05 для wave simple-dashboard-wave-5 по issue #113. AI-инструмент использовался для первичного исследования logistics/delivery KPI docs, отбора courier/ops community-сигналов, черновой структуры и проверки Google 2026 quality gaps. Факты о SLA/OTD/OTIF, failed delivery, route time, fuel/cost, returns и marketplace delivery metrics сверены по официальным или исследовательским источникам; форумы использованы только как сигналы практических проблем, не как единственное основание для точных утверждений. Финальные формулы, caveats, источники, CTA и продуктовые ограничения проверил Александр Руин, основатель habab.ru.

О сервисе "AI-конструктор бизнес-дашбордов"

Платформа для создания аналитических дашбордов через AI-чат. Загрузите CSV/Excel или подключите API, опишите какие метрики нужны — получите готовый дашборд с графиками, KPI и фильтрами. Без программирования, за минуты.

Ключевые преимущества:

  • Не нужен программист или BI-аналитик
  • Дашборд готов за минуты, а не за недели
  • AI сам предлагает подходящие визуализации
  • Данные остаются на вашем сервере
  • Интеграция с любыми источниками через API
  • Автоматическое обновление и рассылка отчётов

Для кого подходит:

Руководители малого и среднего бизнеса Маркетологи и аналитики Руководители отделов продаж Финансовые директора Продакт-менеджеры стартапов

Сценарии использования:

💡 Дашборд продаж с воронкой и KPI
💡 Маркетинговая аналитика (трафик, конверсии, ROI)
💡 Финансовый дашборд (выручка, расходы, прогнозы)
💡 Мониторинг операций (заказы, склад, логистика)
💡 CRM-аналитика (лиды, сделки, pipeline)
💡 Управленческие отчёты для руководителя
💡 Воронка продаж — визуализация этапов и конверсий
💡 KPI менеджеров по продажам — план/факт и рейтинг
💡 Сквозная аналитика — от рекламы до сделки
💡 Отчёт менеджера по продажам — ежедневный/недельный
💡 Дашборд отдела продаж — сводка по команде

📰 Промо-статьи наших решений

Изучите детальные обзоры наших технологических решений для различных отраслей:

🚀 Работаю до результата

🚀 Разработка и автоматизация

📈 Бизнес и автоматизация

💰 FinTech и медиа

🎓 Образование и ИИ

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