Покрокова демонстрація AI-помічника логіста
Це супровідна інструкція до живої демонстрації. Демонстрація це не відео і не презентація, а робочий стіл логіста на даних транспортно-експедиційної компанії: 60 своїх авто, 180 залучених перевізників, 40 до 60 заявок на добу, біржі вантажів, CRM, GPS, вайбер з водіями і папка зі скан-копіями ТТН. Тут зібрані всі 17 сценаріїв і всі 98 кроків з кадрами екранів, щоб можна було подивитись зміст, не проходячи все підряд, і перейти одразу на потрібний крок.
Як користуватись демонстрацією
- Стрілки «назад» і «далі» внизу екрана або клавіші ← →. Можна тиснути прямо по підсвіченій кнопці.
- Кнопка «Кроки» показує весь сценарій, будь-який крок відкривається одним кліком.
- На кроках зі значком «можна ввести своє» приклад замінюється вашими цифрами, і крок перебудовується.
- Кнопка «Посилання» копіює адресу саме цього кроку, щоб надіслати колезі.
- Клавіша P вмикає режим презентації: ховає бічну панель і збільшує шрифт для показу на екрані.
- Місце, де ви зупинились, зберігається. Можна закрити вкладку і повернутись пізніше.
Важливо про цифри
Усі клієнти, перевізники, ставки, маршрути і суми в демонстрації умовні. Це приклад, зібраний за типовим процесом транспортно-експедиційної компанії в Україні: назву компанії приховано, цифри змінені пропорційно. Жодних реальних даних жодного клієнта тут немає. На реальному прогоні всі ці екрани заповнюються вашими цифрами.
Заявка з вайбера: від «є вантаж на Львів» до ставки клієнту за чотири хвилини
Розбір повідомлення, перевірка історії клієнта, розрахунок ставки, відповідь
Що показує цей сценарій
Заявки прилітають у вайбер, у пошту і в телефон, часто одним рядком без половини даних. Логіст витрачає на кожну від 20 до 40 хвилин, поки перепитає обсяг, адресу і час. Агент розбирає повідомлення, сам добирає те, що вже знає про цього клієнта, і повертає готову ставку з розрахунком.
- Пошта, вайбер, телеграм і форма з сайту зводяться в один список
- Агент не чекає повного опису, він одразу бачить, чого бракує
- Заявки від постійних клієнтів підтягують історію попередніх рейсів

- З тексту: маршрут, вага, дата, тип кузова
- З історії клієнта: адреси, вимоги до машини, контакт на складі, звична ставка
- Те, чого немає ніде, агент помічає і питає, а не вигадує

- Історія рейсів по клієнту і по напрямку за 12 місяців
- Середній простій на завантаженні і розвантаженні
- Фактична оплата: за скільки днів гроші реально приходили

- Пальне за фактичною нормою саме цієї машини, а не за паспортом
- Порожній пробіг до місця завантаження враховується
- Зарплата водія, амортизація і адмінвитрати рознесені на рейс


- Відповіді з переписки самі лягають у картку рейсу
- Номер рейсу створюється один раз і живе до оплати
- Усе, що далі, привʼязане до цього номера: машина, документи, гроші

- Швидкість першої відповіді це головний фактор на споті
- Уточнення на вході знімають половину дзвінків на маршруті
- Логіст лишається тим, хто ухвалює рішення про ціну

Підсумок
Перша відповідь клієнту за 4 хвилини замість 40. Це не про ввічливість: на споті вантаж бере той, хто відповів першим. За місяць на тих самих заявках компанія почала вигравати на 18 відсотків більше замовлень, і жодного нового логіста для цього не найняли.
Що потрібно від компанії, щоб це працювало на реальних даних
- Доступ до пошти і до робочих чатів у вайбері або телеграмі, де падають заявки.
- Історія перевезень за останній рік: клієнт, маршрут, вантаж, ставка. Excel цілком підходить.
- Ваші правила ціноутворення: націнка, мінімальна маржа, коли ставка узгоджується з керівником.
- Хто підтверджує ставку клієнту перші два тижні.
Машина на рейс: свої, залучені і біржа в одному екрані
Хто вільний, скільки просить, скільки коштує насправді, кому дзвонити першим
Що показує цей сценарій
Пошук машини це десятки дзвінків і повідомлень, у яких логіст тримає в голові, кому вже писав. Агент показує всі варіанти одразу з реальною ціною, обдзвонює тих, кого ви дозволили, і повертає готові відповіді.
- Свої машини беруться з графіка, а не «здається, 14-та вільна»
- Залучені відбираються за напрямком, кузовом і історією саме цього маршруту
- Біржа підтягується, тільки якщо своїх і перевірених не вистачає

- Історія по кожному перевізнику: зриви, запізнення, стан машин, претензії
- Ціна зриву рахується не абстрактно, а за конкретним минулим випадком
- Агент не забороняє, він показує цифру і лишає рішення людині

- Пишемо тільки тим перевізникам, кого ви дозволили в налаштуваннях
- Ставка в повідомленні це та, яку ви погодили, агент не торгується сам
- Відповіді розбираються автоматично, навіть якщо написані як завгодно

- Різниця показується і в грошах, і у відсотку маржі рейсу
- Альтернатива це не «є ще хтось», а конкретна цифра і конкретний ризик
- Останнє слово завжди за людиною

- Спершу перевіряються всі свої резерви, включно зі зсувом інших рейсів
- Далі перевізники з сусідніх напрямків, кому цей рейс по дорозі
- Біржа останньою, бо вона потребує перевірки і часу

- Графік це не картинка, а робочий стан: зміна в ньому міняє і рейс
- Видно, де машина простоює і де вікно, у яке можна дати ще один рейс
- Свої і залучені в одному графіку, бо клієнту байдуже, чия машина

- Приведена ціна перевізника враховує його історію
- Свої машини і залучені порівнюються чесно, з урахуванням знятих рейсів
- Усі домовленості лишаються в картці рейсу, а не в чиємусь вайбері

Підсумок
Час на пошук машини впав з 50 хвилин до 12. Найважливіше не швидкість, а те, що перестали віддавати рейси першому, хто відповів: у 3 з 10 випадків другий за списком просив на 1 500 гривень менше.
Що потрібно від компанії, щоб це працювало на реальних даних
- Ваша база перевізників: контакти, тип кузова, напрямки, історія ставок.
- Доступ до бірж вантажів, якщо ви ними користуєтесь.
- Правило, кому можна писати автоматично, а кому тільки після вашого дозволу.
- Хто підтверджує бронювання машини.
Перевірка перевізника: 40 секунд замість «та наче нормальні»
Документи, страховка, реєстри, суди, історія ринку, підміна машини на завантаженні
Що показує цей сценарій
Найдорожча помилка в експедиції це віддати вантаж не тому. Перевірка займає час, тому в пік її роблять поверхово або не роблять взагалі. Агент робить її завжди і за 40 секунд, а показує лише те, що справді має значення.
- Список однаковий для новачка і для перевізника з 34 рейсами
- Різниця лише в тому, що по знайомому все вже є і перевірка займає секунди
- Що не перевіряється автоматично, те чесно позначено

- Дані беруться з відкритих реєстрів і з вашої підписки, якщо вона є
- Кожен факт з посиланням на джерело і датою
- Порожнє поле це порожнє поле, а не «все добре»

- Номер машини звіряється з тим, що в заявці, автоматично
- Розбіжність це не звинувачення, а привід підтвердити
- Поки логіст не підтвердив, вантаж не відвантажується

- Строки беруться з документів, які перевізники вже надсилали
- Нагадування йде і вам, і перевізнику, за 14 днів
- Прострочений документ автоматично блокує нові рейси до оновлення

- Перевірка це фільтр, а не гарантія
- Головний захист це страхування і документи, а не наша перевірка
- Агент чесно каже, чого він не бачить

- Однаковий список для всіх, без винятків для «своїх»
- Строки документів під контролем автоматично
- Кожна перевірка лишається в історії з датою і джерелом

Підсумок
Перевірка перестала залежати від завантаженості логіста. За три місяці двічі відбили спробу підміни перевізника на завантаженні і один раз побачили, що страховий поліс закінчився за день до рейсу.
Що потрібно від компанії, щоб це працювало на реальних даних
- Пакет документів, який ви вимагаєте від перевізника: перелік і у якому вигляді.
- Доступ до сервісу перевірки контрагентів, якщо у вас є підписка. Якщо немає, працюємо на відкритих реєстрах.
- Ваші стоп-правила: з ким не працюємо ні за яких умов.
План рейсу: маршрут, вікна і час, який справді реальний
Відстань, режим праці водія, черга на розвантаженні, наряд і документи
Що показує цей сценарій
Обіцянка клієнту «будемо о девʼятій» найчастіше береться зі стелі. Агент рахує час з відстані, режиму праці водія і того, скільки ця машина реально стояла на цьому складі минулого разу, і показує чесне вікно замість оптимістичного.
- Швидкість береться з ваших минулих рейсів по цьому маршруту, не з карти
- Режим праці водія враховується як обовʼязковий, а не «якщо встигне»
- Час на складі береться з історії саме цього складу

- Усе, що водій зазвичай перепитує, підставляється заздалегідь
- Контакти на обох складах у повідомленні, а не в голові диспетчера
- Водій підтверджує однією кнопкою, і це видно в графіку

- Перевірка робиться ввечері напередодні, коли ще можна щось змінити
- Кожен пункт це реальний випадок з історії компанії
- Те, що не можна перевірити дистанційно, помічено окремо

- Дані в документах беруться з картки рейсу, тому не розходяться
- Шаблони ваші, ми нічого не переписуємо
- Те, що підписується руками, позначено окремо

- Клієнт бачить тільки свій рейс і тільки те, що ви дозволили показувати
- Точна геопозиція машини не показується, показується етап і час
- Посилання живе до закриття рейсу

- Чесне вікно замість оптимістичної цифри
- Перевірка дрібниць напередодні, коли ще можна виправити
- Документи готові до виїзду, а не після

Підсумок
Обіцяний час почав збігатися з фактичним у 88 відсотках рейсів замість 61. Це прямо впливає на претензії за простій і на те, чи дає клієнт наступний рейс.
Що потрібно від компанії, щоб це працювало на реальних даних
- Історія рейсів з часом подачі і часом розвантаження по кожному складу.
- Ваші правила режиму праці водіїв.
- Контакти складів отримувачів і їхні вікна прийому.
Машина стоїть третю годину: як це стає видно одразу, а не ввечері
GPS, відхилення від плану, попередження клієнту, перепланування
Що показує цей сценарій
Проблема в рейсі майже завжди виявляється пізно: коли клієнт подзвонив або коли водій сам написав. Агент бачить відхилення в момент, коли воно ще коштує пів години, і піднімає питання диспетчеру, а не власнику.
- Позиція оновлюється кожні 10 хвилин
- Відхилення до 20 хвилин це нормальний рух, а не подія
- Повідомлення йде, лише коли потрібна дія людини

- Зупинка сама по собі не подія, подія це зупинка довша за норму і не в точці зупинки
- Агент спершу перевіряє очевидне: заправка, перерва, затор
- Тільки після цього пише людині

- Новий ETA рахується від фактичної точки і залишку робочого часу водія
- Перевіряється, чи не ламає це наступний рейс машини
- Наслідки показуються одразу, а не «завтра розберемось»

- Повідомлення пишеться фактами, без виправдань і без «на жаль»
- Обовʼязково новий час і що робимо, а не тільки вибачення
- Відправляє людина, бо це стосунки, а не операція

- Лічильник вмикається з моменту прибуття за GPS, а не зі слів водія
- За 20 хвилин до кінця безкоштовного часу йде попередження
- Кожна година понад норму це рядок у рахунку з підставою

- Ескалація йде за часом і за сумою наслідку, а не за настроєм
- Власнику пишемо тільки те, що справді того варте
- Кожна ескалація лишається в журналі з причиною

- Агент мовчить, поки все нормально
- Перед тим як турбувати людину, перевіряє очевидне
- Наслідки рахуються одразу, у годинах і гривнях

Підсумок
Про запізнення клієнт дізнається від нас, а не ми від клієнта. За квартал це прибрало 14 претензій за простій зі 17 і жодного разу не коштувало нам довіри, бо попереджали заздалегідь.
Що потрібно від компанії, щоб це працювало на реальних даних
- GPS на машинах або хоча б на своїх. По залучених працює геолокація від водія.
- Ваші правила ескалації: після скількох хвилин це вже проблема і кого повідомляти.
- Контакти отримувачів, щоб попереджати їх, а не тільки замовника.
Документи: чому рахунок клієнту йде через тиждень і як це виправляється
Скан ТТН з телефону, звірка з рейсом, акт, рахунок, реєстр для бухгалтерії
Що показує цей сценарій
Гроші приходять не після розвантаження, а після документів. У більшості компаній між цими двома подіями лежить від пʼяти до десяти днів, бо ТТН везе водій, а рахунок робить людина в порядку черги.
- Розпізнається текст з фото, навіть з поганого
- Кожне поле звіряється з тим, що в картці рейсу
- Те, що не розпізналось впевнено, позначається для людини

- Кожен рядок має підставу: договір, GPS або документ
- Спірні позиції виносяться окремо, а не ховаються в підсумку
- Документ не йде клієнту, поки людина не подивилась

- Фото це підстава для рахунку, оригінал це підстава для бухгалтерії
- Реєстр показує, де фізично лежить кожен комплект
- Нагадування водію і перевізнику йдуть автоматично

- Реєстр збирається з тих самих даних, що і рахунки
- Формат під вашу облікову систему
- Розбіжності позначені окремо, щоб бухгалтер не шукав їх сам

- Звіряються заявка, ТТН, акт і рахунок між собою
- Помилка це не привід зупиняти рейс, це привід показати людині
- Агент не виправляє документи сам ніколи

- Фото ТТН це підстава для рахунку вже сьогодні
- Оригінали під контролем окремим реєстром
- Розбіжності видно до оплати

Підсумок
Рахунок іде клієнту в день закриття рейсу. На обороті це зсув дебіторки на 6 днів раніше, тобто постійні гроші в обороті замість кредитної лінії.
Що потрібно від компанії, щоб це працювало на реальних даних
- Ваші шаблони акта і рахунку.
- Домовленість з водіями фотографувати ТТН одразу після підпису.
- Доступ до пошти, з якої відправляються документи клієнтам.
Недостача три місця: хто платить і чим це доводиться
Збір доказів, ланцюг відповідальності, страховка, претензія перевізнику
Що показує цей сценарій
Претензія це завжди про докази і про строки. Обидва зазвичай втрачаються: фото ніхто не зробив, а строк повідомлення страховій сплив. Агент збирає доказову базу автоматично, поки вона ще існує.
- Подія фіксується в момент виявлення, з часом і джерелом
- Збираються всі дані рейсу, а не тільки ті, що здаються потрібними
- Строк повідомлення страхової починається зараз, і агент його рахує

- Агент викладає ланцюг фактів, а не робить висновок про винного
- Кожна версія має те, що її підтверджує або спростовує
- Остаточний висновок робить людина, бо це претензія і гроші

- Строки беруться з ваших договорів і з умов страхування
- Нагадування йде за 24 години до кінця строку
- Прострочений строк лишається в журналі як факт, а не зникає

- Структура претензії ваша, ми лише заповнюємо її фактами
- Усі додатки вже зібрані і пронумеровані
- Підписує і відправляє людина

- Кожна закрита претензія перетворюється на правило або лишається як факт
- Правило створюється тільки після підтвердження людини
- Наступного разу агент нагадає про перерахунок ще до завантаження

- Докази збираються в момент події, а не коли знадобились
- Строки рахуються від дати події автоматично
- Переговори лишаються людині, і це правильно

Підсумок
Три претензії з чотирьох закриті на користь компанії, бо докази були зібрані в день події, а не через два тижні. Одна закрита не на нашу користь, і це теж результат: стало видно, що на тому складі треба перераховувати місця при завантаженні.
Що потрібно від компанії, щоб це працювало на реальних даних
- Ваш порядок роботи з претензіями і строки за договорами.
- Контакти страхової і форма повідомлення про подію.
- Домовленість з водіями фотографувати вантаж при завантаженні. Це головне.
Маржа, яка виглядає доброю в заявці і зникає до кінця рейсу
Порожній пробіг, простої, штрафи, доплати і те, скільки насправді дає кожен клієнт
Що показує цей сценарій
Маржа рейсу рахується в момент, коли її називають клієнту, і більше ніколи. Усе, що сталося далі, простій, порожній пробіг, доплата за другу точку, не повертається у цю цифру. Агент перераховує маржу після закриття рейсу і показує, де вона поділась.
- Заявлена маржа це ставка мінус ставка перевізника
- Фактична це те саме мінус усе, що сталося
- Обидві цифри показуються поруч, бо перша теж потрібна

- Порожній пробіг привʼязується до конкретного рейсу, а не розмазується
- Видно напрямки, з яких повертатись порожнім доводиться завжди
- Це не привід відмовлятись від напрямку, це привід рахувати ставку інакше

- Маржа рахується після всіх фактичних витрат по рейсах цього клієнта
- Враховуються простої, доплати і те, як швидко він платить
- Вартість грошей у відстрочці теж рахується

- Порівнюється ставка, собівартість і ринок по цьому маршруту
- Ринок береться з ваших власних відмов і з бірж
- Рекомендація це діапазон, а не одна цифра


- Перерахунок автоматичний після закриття місяця в обліку
- Показуються зміни, а не вся картина заново
- Кожна цифра розкривається до конкретних рейсів

- Фактична маржа замість заявленої
- По кожному клієнту і напрямку окремо
- Рішення про ставки і про клієнтів лишається за власником

Підсумок
Стало видно, що два клієнти з двадцяти возились у мінус увесь рік, а один напрямок давав маржу тільки на папері. Після перегляду ставок по цих трьох позиціях місячний результат виріс на 214 тисяч гривень без жодного нового клієнта.
Що потрібно від компанії, щоб це працювало на реальних даних
- Витрати по рейсах з обліку: пальне, ставки перевізникам, зарплати, ремонти.
- Історія рейсів з фактичним часом і кілометражем.
- Ваш спосіб рознесення постійних витрат на рейс. Якщо його немає, домовляємось один раз.
Клієнти платять через 46 днів, а перевізникам треба через 7
Дебіторка з прізвищами, оплати перевізникам, касовий розрив і чим його закрити
Що показує цей сценарій
Експедиція живе в розриві: перевізнику платимо за тиждень, клієнт платить за місяць. Агент тримає обидва боки в одному календарі і показує розрив датою і сумою, а не відчуттям «щось грошей мало».
- Дебіторка збирається з рахунків і звіряється з виписками
- Дні рахуються від дати за договором, а не від дати рахунку
- Прострочення понад 14 днів піднімається окремо

- Перелік рейсів у повідомленні, щоб бухгалтеру не треба було шукати
- Жодних погроз і жодних емоцій
- Ескалація до менеджера клієнта тільки після третього нагадування

- Оплати перевізникам беруться з умов заявок-договорів
- Надходження з умов клієнтів і з історії фактичних оплат
- Історія важливіша за договір: якщо клієнт завжди платить на 10 днів пізніше, календар це враховує

- Ставки беруться з ваших реальних умов, а не середні по ринку
- Домовитись про відстрочку з перевізником це теж варіант з ціною
- Найдешевший варіант часто не фінансовий, а розмова

- Оплата привʼязана до комплекту документів, а не до дати
- Спірні рейси не потрапляють у платіжку автоматично
- Реєстр на оплату готується сам, підписує людина

- Обидва боки в одному календарі
- Нагадування вчасно, а не коли згадали
- Оплата перевізнику тільки проти документів

Підсумок
Розрив стало видно за два тижні, а не в день платежу. Прострочена дебіторка впала з 6,3 до 2,9 мільйона, бо нагадування пішли вчасно, а не тоді, коли бухгалтер згадав.
Що потрібно від компанії, щоб це працювало на реальних даних
- Виписки по рахунках або доступ до банк-клієнта на читання.
- Умови оплати по клієнтах і по перевізниках.
- Хто у вас має право нагадувати клієнту про оплату і в якому тоні.
Звідки агент бере дані, якщо половина роботи живе у вайбері
Пошта, месенджери, CRM, 1С, GPS, біржі, телефонія, папір
Що показує цей сценарій
Перше питання на кожній зустрічі. Відповідь чесна: агент бере дані звідти, де вони вже є, і не вимагає спершу навести лад. Там, де даних немає взагалі, він каже про це прямо.
- Агент не вимагає «спершу впровадьте TMS»
- Кожне джерело підключається окремо і дає свою частину користі
- Те, чого немає ніде, агент позначає як діру, а не домальовує

- Агент завжди показує, на скількох відсотках даних побудована цифра
- Якщо даних менше половини, він не робить висновок
- Діри в даних це окремий екран, а не прихована проблема

- Спершу те, що дає результат без інтеграцій
- Облік найдовше, тому не першим
- На кожному етапі є видимий результат

- Це не обмеження системи, це фізика: чого немає в даних, того немає ніде
- Частина з цього вирішується дисципліною, а не технологією
- Про кожну діру ми говоримо одразу

- Це не демонстрація, а робота на ваших цифрах
- Показуємо і те, що вийшло, і те, чого в даних не вистачило
- Якщо на цьому етапі користі немає, далі йти не варто

Підсумок
Видно, що для старту достатньо трьох джерел з восьми, а решта підключається поступово. І видно, чого агент не покаже, поки цього ніхто не фіксує.
Що потрібно від компанії, щоб це працювало на реальних даних
- Один технічний контакт з вашого боку або від підрядника, який веде вашу систему.
- Вивантаження рейсів за минулі 6 до 12 місяців, щоб перевірити на реальних даних до інтеграцій.
- Доступ на читання. Записувати в облік агент не буде і таких прав не просить.
Як перевірити будь-яку цифру агента за 10 секунд
Журнал, джерело кожної цифри, що рахує код, а що робить модель
Що показує цей сценарій
Довіра будується не на словах, а на можливості перевірити. Кожна цифра розкривається до документа, кожна дія лежить у журналі з часом і причиною, а розрахунок можна повторити руками.
- Кожен доданок має джерело: акт, виписка, GPS або документ
- Розрахунок видно повністю, а не тільки результат
- Якщо джерело змінилось, цифра перерахується і це буде видно в журналі

- Записи людською мовою, без кодів помилок
- Кожен запис має джерело і наслідок
- Журнал не можна відредагувати заднім числом

- Арифметику рахує код, а не модель
- Модель читає скани, розбирає повідомлення і формулює текст
- Там, де модель щось витягла з документа, це позначено

- Жодна дія агента не рухає гроші і не змінює дані в обліку
- Найгірше, що може статись, це неправильна порада, яку відхилить людина
- Кожна помилка розбирається і стає правилом

- Історія лишається у вас незалежно від того, працюємо ми далі чи ні
- Вона не залежить від того, хто з людей звільнився
- Усе вивантажується у звичайні файли

Підсумок
Питання «звідки він це взяв» перестає бути риторичним. Логіст перевіряє три цифри, бачить, що вони сходяться, і далі перевіряє вибірково. Це нормальний шлях.
Що потрібно від компанії, щоб це працювало на реальних даних
- Людина, яка перевірить перші розрахунки руками. Зазвичай це старший логіст або фінансист.
- Ваша згода на те, що журнал зберігається: це основа перевірки.
Межа: що агент робить сам, що пропонує і чого не робить ніколи
Три рівні автономності і як вони змінюються з часом
Що показує цей сценарій
Найчастіший страх власника це не «а раптом не запрацює», а «а раптом воно почне робити щось саме». Тут показано жорсткий поділ: три рівні, і перехід між ними лише за вашим рішенням.
- Рівень 1 нічого не змінює
- Рівень 2 це підготовлена дія, яку запускає людина
- Рівень 3 не буває доступним ніколи

- Лічильник ведеться окремо по кожному типу дії
- Одне виправлення обнуляє лічильник
- Навіть після переходу лишається поріг за сумою і можливість відкотити

- Пороги задаєте ви, ми пропонуємо стартові значення
- Вихід за поріг це не блокування, а повернення до підтвердження
- Уночі агент тільки читає і рахує

- Стоп доступний керівнику і тому, кого він призначить
- Після зупинки дані нікуди не діваються
- Повернення в роботу теж ваше рішення

- Пропорція 70 на 30 це типовий сталий стан
- Далі вона майже не рухається, і це нормально
- Мета не віддати все, а віддати рутину

Підсумок
Стає зрозуміло, що агент починає майже без прав і отримує їх поступово, за фактом статистики. І що є речі, які не переходять на автопілот ніколи.
Що потрібно від компанії, щоб це працювало на реальних даних
- Ваше рішення, хто що підтверджує.
- Пороги, вище яких потрібне підтвердження навіть на автопілоті.
Навчання: агент вчиться тільки з того, що підтвердила людина
Як досвід логіста стає правилом і чому агент не вчиться сам
Що показує цей сценарій
Питання, яке ставлять завжди: а якщо йому підкажуть неправильно. Відповідь у конструкції: агент не вчиться з випадкових дій, тільки з явних підтверджень, і кожне правило проходить через людину, яка має на це право.
- Правило зʼявляється тільки з явного виправлення
- Автор правила завжди зафіксований
- Правило можна прочитати звичайною мовою і скасувати

- Право навчати мають не всі
- Суперечність з наявним правилом зупиняє навчання
- Раз на тиждень усі нові правила показуються списком

- Формулювання зрозумілі без технічної підготовки
- Видно, скільки разів правило вже спрацювало
- Скасування діє одразу

- Правила рівня 3 не створюються взагалі
- Пороги за сумами не змінюються навчанням
- Правила «ігноруй перевірку» не існує в принципі

- Правила експортуються в будь-який момент
- Вони написані людською мовою
- Навіть якщо ви припините працювати з нами, документ лишається корисним

Підсумок
За сезон з голів логістів витягуються десятки правил, які ніде не були записані. Це лишається в компанії назавжди і не залежить від того, хто працює.
Що потрібно від компанії, щоб це працювало на реальних даних
- Одна людина на напрямок, чиї підтвердження вважаються правилом.
- Півгодини на тиждень на розбір нових правил, перші два місяці.
Як ми перевіряємо агента до того, як він щось порадить
Прогін на ваших минулих рейсах, розбір розбіжностей, ваш тест, пілот
Що показує цей сценарій
Агент не виходить у роботу з обіцянкою «має працювати». Він виходить з цифрою: на ваших минулих рейсах збіг такий-то, розбіжності розібрані поіменно.
- Агент не бачить підсумкових цифр
- Порівняння по кожному розрахунку окремо
- Прогін повторюється після кожної правки

- Частина розбіжностей це не помилки, а інша методика рознесення витрат
- Кожна справжня помилка стає правилом або виправленням
- Після виправлень прогін повторюється з нуля

- Без обмеження за часом і кількістю перевірок
- Можна давати спеціально складні випадки
- Кожне зауваження або виправляється, або чесно позначається як обмеження

- Одна ділянка, а не весь бізнес одразу
- Критерій успіху узгоджується до старту
- Якщо критерій не досягнутий, розширення не буває

- На кожному етапі ви можете зупинитись
- До оперативної роботи агент доходить не раніше третього тижня
- Це довше, ніж «увімкнули і працює», і в цьому сенс

Підсумок
До першої реальної поради агент уже пройшов ваш минулий квартал, розбір кожної розбіжності і ваш власний тест. Це займає 2 до 3 тижнів і знімає питання «а раптом він помиляється».
Що потрібно від компанії, щоб це працювало на реальних даних
- Дані за 2 минулі квартали. Чим більше, тим точніша оцінка.
- Ваша оцінка, що вважати збігом. Наприклад, маржа зійшлась, якщо різниця менше 3 відсотків.
- Людина, яка дивиться результати прогону разом з нами.
Скільки це коштує на ваших обсягах
Живий калькулятор: ставите свої рейси і бачите ціну і окупність
Що показує цей сценарій
Ціна не зі слайда, а порахована при вас. Ви ставите свою кількість рейсів, кількість логістів і ту вигоду на рейсі, у яку вірите, і бачите вартість впровадження, підписку і окупність.
- Впровадження залежить від обсягу і кількості ділянок
- Підписка це підтримка, оновлення і робота з вашими правилами
- Курс для перерахунку 41 гривня за долар

- Кожні 100 рейсів на місяць це приблизно 3 нові правила
- Більше логістів це більше різних звичок, які треба звести
- Цінність росте швидше за ціну, і це видно в калькуляторі

- Немає плати за повідомлення, розрахунок або рейс
- Немає плати за кількість користувачів
- Є межа за обсягом обробки документів, і вона висока

- Головна умова це наявність хоч якихось даних
- Друга умова це людина, яка відповідає за результат з вашого боку
- Третя це готовність щось міняти за результатами

- Прогін робиться на вивантаженні, без доступів до систем
- Рішення ухвалюється після того, як ви побачите свої цифри
- До цього моменту жодних зобовʼязань

Підсумок
Видно, що від 400 рейсів на місяць окупність рахується місяцями, а не роками, а на менших обсягах треба рахувати уважніше і починати з одного напрямку. Це чесна відповідь: не всім і не завжди.
Що потрібно від компанії, щоб це працювало на реальних даних
- Ваші реальні обсяги, щоб рахунок був не абстрактним.
- Рішення, з якої ділянки починаємо.
Що потрібно від вас: список без води
Доступи, дані, люди і час, з реальними строками
Що показує цей сценарій
Перелік того, що доведеться зробити з вашого боку. Він короткий, але без нього нічого не працює. Краще подивитись його до договору, ніж дізнаватись поступово.
- Не потрібен окремий працівник і не потрібна нова посада
- Потрібен час наявних людей, і небагато
- Головний ризик проєкту завжди тут, а не в техніці

- Спершу вивантаження, доступи потім
- Тільки читання, ніколи не запис
- Кожен доступ можна забрати за хвилину з вашого боку

- Це три невеликі зміни, а не перебудова компанії
- Кожна корисна сама по собі, навіть без агента
- Ми не вимагаємо міняти облік або переходити на іншу систему

- Перший результат на четвертий день, без будь-яких доступів
- Найдовше зазвичай чекають доступ до обліку
- Пілот 4 до 6 тижнів, і його не можна пропустити

- Це весь список, нічого не додасться потім
- Якщо чогось з цього немає, ми скажемо одразу
- Усе інше робимо ми

Підсумок
Видно, що основна робота лягає на нас, а з вашого боку це приблизно 10 годин за перший місяць, розподілені між трьома людьми.
Що потрібно від компанії, щоб це працювало на реальних даних
- Рішення, хто з вашого боку веде проєкт. Це найважливіший пункт зі списку.
Безпека: де лежать дані, хто їх бачить і що буде без звʼязку
Контур, доступи, ставки і клієнтська база, робота без світла і без інтернету
Що показує цей сценарій
Два різні питання в одному блоці. Перше класичне: де дані і хто до них має доступ. Друге українське: що буде, коли немає світла, немає звʼязку, а машина в дорозі.
- За замовчуванням дані в європейському дата-центрі
- Варіант з вашим сервером повністю робочий
- У будь-якому варіанті дані вивантажуються у файли за вашим запитом

- Ролі налаштовуються під вашу структуру
- Маржа і ставки це окреме право доступу
- Масове вивантаження помітне і лишається в журналі

- Агент це підказка, а не система керування
- Дані накопичуються і синхронізуються, коли звʼязок повертається
- Критичні попередження дублюються в SMS

- Обмеження на маршрутах і комендантська година враховуються в плані рейсу
- Документування пошкоджень це те, що потім неможливо відновити
- Про небезпеку агент не знає сам, він тримає ваші відмітки

- Забрати доступ можна з вашого боку
- Вивантажити дані можна будь-коли
- Зупинити агента можна однією кнопкою

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