Доставка: ETA выросло, NPS падает, что делать с диспетчеризацией

Ситуация: Сервис доставки еды (~10K заказов/день) заметил что среднее время доставки выросло с 35 до 48 минут, NPS упал с 60 до 35. Команда подозревает алгоритм диспетчеризации. Разобраться и предложить план.

Текущий алгоритм: greedy nearest-courier (берём ближайшего свободного к ресторану). 350 курьеров активны в часы пик. CAC юзера = ₽800, LTV = ₽3000. Если ETA > 60 мин — юзер с вероятностью 25% перестаёт заказывать совсем (cohort study).

Доступные данные

• orders: order_id, user_id, restaurant_id, courier_id, ordered_at, picked_up_at, delivered_at, distance_km
• couriers: courier_id, vehicle_type (bike/scooter/car), avg_orders_per_hour, login_at, logout_at
• restaurants: restaurant_id, prep_time_min, peak_hours_load
• dispatch_decisions: order_id, considered_couriers (json), selected_courier_id, decision_time
• user_complaints: user_id, complaint_type, severity, created_at

Задачи

• Декомпозиция ETA: на сколько минут выросли prep_time / dispatch_wait / pickup_to_delivery? Где основной рост?
• Сегментация: рост ETA одинаков по всем районам/часам или локализован? Может это часы пик?
• Capacity check: есть ли реально дефицит курьеров (utilization > 80%) или проблема в распределении?
• Алгоритм: чем плох greedy? Симулируй на исторических данных альтернативу (consider next 5 ближайших, batched dispatch).
• Дизайн A/B: как протестировать новый алгоритм на части города без full rollout? Какой MDE и sample?
• Дополнительные действия: ценовое стимулирование (surge pricing), наём, переоптимизация ресторанов.

Все кейсы для подготовки → ← Все кейсы