Порахуйте, чим насправді зайнятий ваш диспетчер у п'ятницю ввечері. Замовлення падає кожні пару хвилин, і по кожному хтось має вирішити, який кур'єр його бере, у якій послідовності та коли виїжджає. За зміну набігає 150+ рішень, здебільшого з пам'яті, по телефону, між суперечками про те, кому їхати в дальню зону. Диспетчер, який робить це добре, коштує 25 000–35 000 ₴ на місяць. Поганий коштує дорожче — самою лише холодною їжею та кур'єрами, що простоюють.
Софт для розподілу замовлень між кур'єрами має ухвалювати ці рішення за вас. Але є суттєва різниця між софтом, який показує замовлення на мапі, щоб людина їх розібрала, і софтом, який призначає їх сам. Перший лише перейменовує роботу диспетчера. Другий її прибирає. Далі — про другий і про те, як він працює.
Призначення — це задача скорингу
Очевидний спосіб побудувати диспетчеризацію — черга: наступне замовлення отримує той, хто найдовше простоював. Виглядає справедливо і ламається на першому ж замовленні, бо кур'єр, який чекав найдовше, може стояти на протилежному краю вашої зони доставки.
Справжній рушій призначення робить інакше. Кілька разів на хвилину він оцінює кожного вільного кур'єра проти кожного замовлення, готового до виїзду. Що він зважує:
- Де кожен кур'єр перебуває — і, що не менш важливо, де його залишить поточна доставка. Кур'єр, який завершує доставку за три квартали від наступної точки видачі, кращий за того, хто без діла стоїть біля ресторану.
- Таймінг кухні. Відправити кур'єра на замовлення, якому ще 12 хвилин на грилі, — це платити людині за те, що вона обіперлася на стійку. Рушій читає статус кухні, щоб кур'єр приїжджав тоді ж, коли готова їжа.
- Чи можуть два замовлення поїхати разом. Якщо вони в один район з різницею в кілька хвилин — мають. Софт ловить такі пари щоразу; втомлений диспетчер — лише деякі.
- Наскільки завантажений кожен кур'єр і чим він їде. Велокур'єру не місце на маршруті у 10 кілометрів, а кур'єру, який уже везе два замовлення, не варто давати третє з жорстким дедлайном.
Саме ця логіка працює всередині нашого модуля оптимізації логістики: замовлення призначається саме тоді, коли кухня його підтверджує, а маршрут перебудовується, якщо дорогою щось змінюється. 150 рішень диспетчера перетворюються на результат роботи софту, а людина зазирає туди лише тоді, коли трапляється щось незвичне.
Що реально економлять оператори
Коли призначення стає автоматичним, рухаються три цифри. Спершу падає простій: оператори, що перейшли, кажуть, що кур'єри значно більшу частину зміни справді везуть їжу, тож той самий штат закриває на 15–25% більше замовлень у пік. Проміжок між тим, коли замовлення готове, і тим, коли кур'єр його бере, стискається майже до нуля, бо рушій обрав виконавця ще до того, як пакет заклеїли. І фонд оплати праці меншає, бо операція середнього розміру проводить весь вечірній пік без жодної людини в диспетчерському кріслі.
Саме на цій останній економії відпрацьовує себе наш AI-асистент. Delly, асистент доставки всередині Dots, стежить за всім потоком — призначеннями, затримками, статусами кур'єрів — і закриває винятки, які раніше вимагали людини: перепризначає замовлення, коли в кур'єра сів телефон, помічає адресу, яку геокодувало не туди, підганяє кухню, коли час приготування пливе. Для мережі, яка раніше платила комусь за це крісло, це 120 000+ ₴ на місяць, що повертаються в бюджет.
Візьміть цифри типової п'ятниці. Ми покажемо, що рушій зробив би з ними.
Мапа стає інструментом нагляду
Автоматизація призначення не забирає видимість — вона змінює те, на що ви дивитесь. Замість вирішувати по кожному замовленню менеджер зміни спостерігає за центром керування замовленнями: які замовлення йдуть до запізнення, який кур'єр застряг, де сьогодні скупчується попит. Ви втручаєтесь у 5% замовлень, що потребують судження, і лишаєте інші 95% у спокої.
Де людина досі перемагає алгоритм
Є три ситуації, де я не довіряв би софту наодинці. Новий кур'єр, який ще не знає району, спрацює гірше, ніж обіцяє його скоринг, — менеджеру варто супроводжувати його перші зміни. Велике кейтерингове замовлення з жорстким часом подачі заслуговує на кур'єра, обраного вручну, а не за балами. А коли снігопад удвічі сповільнює всіх, людина має розширити обіцяні терміни доставки, перш ніж рушій почне брати на себе обіцянки, яких не втримає. Хороший софт робить ручне втручання питанням одного дотику: політику контролюєте ви, а арифметику він бере на себе.
Що перевірити перед покупкою
Якщо ви обираєте софт для розподілу замовлень між кур'єрами для ресторану, кілька речей відділяють справжні системи від іграшкових мап. Чи синхронізується призначення зі статусом приготування на кухні, чи система вважає кожне замовлення готовим одразу, щойно його зробили? Чи вміє вона об'єднувати замовлення за правилами, які задаєте ви самі? Чи передає вона клієнту живе відстеження кур'єра — дзвінки «де моя їжа?» стихають, коли передає. І чи потрапляють замовлення з вашого застосунку й сайту прямо в диспетчеризацію без ручного передруку? Останнє питання — причина, чому ми зробили диспетчеризацію частиною однієї платформи, а не окремою надбудовою: замовлення, кухонний екран і застосунок кур'єра працюють з єдиним станом даних, і саме так через систему пройшло 3+ мільйони замовлень без армії диспетчерів позаду.
Дешевий спосіб оцінити масштаб, перш ніж витрачати гроші: протягом тижня фіксуйте кожне диспетчерське рішення, яке ваша команда ухвалює вручну, і кожну хвилину, коли готове замовлення стоїть без кур'єра. Помножте ці хвилини на середній чек і частку повторних замовлень. Це число — те, у що ручна диспетчеризація вже вам обходиться. Тож витратьте його на софт.
Автопризначення, застосунок кур'єра, живе відстеження і Delly, що стежить за винятками, — запуск приблизно за два тижні.