AI-маршрутизація звернень, розібрана від початку до кінця.
Розібраний приклад: десять тижнів процесу, за яким ми справді працюємо, на одній реалістичній задачі — разом із тим, що йде не так. Назви й цифри тут ілюстративні; послідовність, рішення й компроміси — ті самі, що й у кожному нашому проєкті.
Оновлено 24 вересня 2026 року
Уявімо: команда підтримки з 40 людей отримує 4000 звернень на тиждень, і двоє співробітників витрачають увесь робочий день лише на те, щоб передати кожне звернення потрібному спеціалістові.
Принесіть нам свою задачу- Проєкт
- Що виявляється в роботі
- Рішення, яке закриває питання
Ми оцінюємо вартість процесу, а не запиту
Читати весь етап: Тиждень 0Розібраний приклад, а не історія клієнта — сценарій і цифри в ньому гіпотетичні. Справжній тут лише процес. Для такої маршрутизації потрібна навчена невелика модель, тому проєкт триває довше, ніж розробка двотижневого асистента.
Як працюють невеликі приватні моделі Принесіть нам свою задачу- 01 / 06 Тиждень 0 Scratch
Ми оцінюємо вартість процесу, а не запиту
Перші дні ми проводимо поруч із тими двома, хто насправді розподіляє звернення. Ми беремо вибірку звернень за тиждень, засікаємо час кожного кроку й рахуємо вартість процесу таким, як він працює сьогодні, а не таким, як він описаний в оргструктурі. Що більше ви розкажете нам на цьому етапі — про винятки, граничні випадки й звернення, за які ніхто не хоче братися, — то більша частина тижня піде на зважування варіантів, а не на уточнювальні запитання. Потім кожного кандидата на автоматизацію оцінюємо за чотирма критеріями: обсяг, ціна помилки, готовність даних і те, яку частину роботи модель чесно здатна взяти на себе.
Ризик — Не та задачаУ брифі написано «автоматизувати маршрутизацію». Вибірка часто каже інше — якщо третина звернень повертається, бо в першій відповіді довелося перепитувати серійний номер, маршрутизація ніколи не була найдорожчою частиною тижня.
Рішення — Оцінити обидва варіантиМи оцінюємо обидві задачі поруч в одній картці й беремося за ту, що швидше окупиться, — і збираємо її з найпростіших компонентів, які витримають навантаження. Велика модель не є автоматично правильною відповіддю на невелику задачу, а рішення, яке не здатне себе окупити, ми не рекомендуємо. Якщо перша постановка не проходить поріг, ми переформульовуємо її разом із вами — вужчий зріз, інша ділянка процесу — доки не з’явиться варіант, який варто будувати; фіксовану пропозицію ви отримуєте саме на нього, і за неї ми ручаємося самі.
- Виміряна базова вартість процесу
- Картка оцінки варіантів
- Фіксована пропозиція на розробку
- 02 / 06 Тиждень 1–2 Scratch
Домовитися, що означає «правильно», ще до початку розробки
Модель корисна рівно настільки, наскільки добрий еталон, за яким її оцінюють, тож з еталона ми й починаємо. Ми беремо звернення за дванадцять місяців, формуємо відкладену тестову вибірку з рішень, які вже ухвалила ваша команда, і фіксуємо поріг успіху: яка точність, на яких сегментах трафіку, за якої вартості одного звернення і хто це оцінює. Нульовий тиждень показав, у чому полягає задача; тут ми з’ясовуємо, як вона розв’язується насправді, а не вдовольняємося відповіддю, яка лише виглядає правдоподібно.
Ризик — Брудні міткиІсторичні призначення — ще не істина. Звернення перепризначають раз, два, іноді тричі, перш ніж вони потраплять туди, куди треба, тож навчання на першому призначенні вчить модель наявних помилок команди, а потім за цими самими помилками її й оцінюють. Результат виглядає як успіх — і це найдорожчий спосіб помилятися.
Рішення — Мітки за закриттямМи розмічаємо дані за чергою, яка справді закрила звернення, зберігаємо ланцюжок перепризначень як окремий сигнал і виводимо з вибірки останній місяць, щоб фінальне оцінювання проходило на зверненнях, яких система під час розробки ще не бачила. Далі перевірка йде етапами: що модель робить, чого вона робити відмовляється і як поводиться кожна частина бази знань за нею. Що більша ця база, то довший етап — ми закладаємо цей час у пропозицію, а не скорочуємо його.
- Відкладена тестова вибірка
- Письмово зафіксований поріг успіху та відповідальний
- Базові показники по кожній черзі
- 03 / 06 Тиждень 3 Prototype
Робоча система вже на третьому тижні — поки що осторонь
Одразу уточнимо: це демо — справжня система на справжніх даних, але ще не готова до продакшену. Жодне її рішення поки не доходить до клієнта.
Невеликий класифікатор і агент маршрутизації ми розгортаємо на вашій реальній черзі звернень і показуємо людям, які сьогодні їх розподіляють. Це справжнє розгортання — той самий шлях даних, та сама автентифікація, ті самі черги — але з вимкненою можливістю діяти: система нічого не вирішує й нічого не змінює. Читати ці рішення має хтось із вашого боку, хто розуміє, який результат справді хороший, і вже до кінця тижня їх набереться достатньо для першого чесного звіту про те, де система має рацію, а де ні.
Ризик — Довгий хвістВісім найбільших черг покривають більшу частину тижня. В інших сорока — лише по десятку прикладів, і саме там упевненість стає дорогою: лист, який три абзаци читається як скарга на рахунок, а потім згадує, що клієнт бачив чуже замовлення, — це звернення про безпеку. Таких дев’ять на рік, і відправити його в бухгалтерію коштує значно дорожче, ніж лишити людині.
Рішення — Дозволити не відповідатиАгенту дозволено сказати, що він не знає, і на такому зверненні «я не впевнений, це варто подивитися людині» — краща відповідь: упевнений здогад, побудований на хибному припущенні, створює роботу на місяці вперед. Ми налаштовуємо поріг упевненості на тестовій вибірці й віддаємо вам криву «покриття проти точності», тож компроміс — розподіляти більше чи безпечніше — стає вашим рішенням, підкріпленим цифрами. Коли агент утримується від відповіді, він передає звернення людині: так задумано, це не прогалина.
- Розгорнутий прототип на реальних зверненнях
- Крива покриття / точності
- Сесії з командою маршрутизації
- 04 / 06 Тиждень 4–5 Build
У стек — а потім два тижні в тіньовому режимі
Прототип стає частиною систем, у яких йому працювати: вашого хелпдеску, вашого провайдера ідентифікації, вашого графіка чергувань. Потім він працює в тіньовому режимі — прогнозує маршрут кожного звернення, але нічого не робить, — тож ви можете переглянути реальні рішення за два тижні, перш ніж хоч одне з них торкнеться бодай одного клієнта.
Ризик — Радіус ураженняАгент із ключем API до хелпдеску зазвичай може читати всі черги компанії, зокрема й ті, що належать HR і юридичному відділу. Це той ризик інтеграції, який ніколи не спливає під час демо.
Рішення — Обмежити доступ і логуватиОкремий сервісний акаунт на кожну чергу, письмовий перелік дозволених дій і аудит-лог кожного читання й запису. Разом із тіньовим режимом це означає, що перше рішення, яке торкнеться клієнта, буде вже тисячним рішенням системи.
- Обмежений доступ і повний аудит-лог
- Два тижні тіньових рішень
- Відкат одним перемикачем
- 05 / 06 Тиждень 6–8 Build
Різниця між демо і системою
Повтори запитів, резервні сценарії, ліміти вартості й навантажувальний тест на потрійний пік вашого тижня. Сповіщення надходять черговому за графіком, а не на дашборд, який ніхто не відкриває. Усе це має бути налагоджено, перш ніж команда зможе перестати наглядати за системою й просто нею користуватися.
Ризик — Дрейф вартості зверненняВартість одного звернення здається стабільною — доки не надходить ланцюжок на сорок повідомлень із трьома PDF-файлами у вкладенні. Кілька таких на день можуть непомітно коштувати більше, ніж уся решта черги разом узята.
Рішення — Каскад + лімітСпочатку класифікує невелика модель, а велику викликають лише за низької впевненості; ланцюжки листування обрізаються до частин, важливих для маршрутизації; а жорсткий ліміт на звернення зупиняє рахунок, перш ніж він стане темою розмови з вашим фінансовим директором.
- Ліміт вартості на звернення
- Навантажувальний тест на 3× піку
- Резервний перехід на людину за низької впевненості
- 06 / 06 Тиждень 9–10 Run
Працює, під наглядом і далі покращується
Система запускається на хостингу, який ми адмініструємо, або у вашій власній хмарі, якщо цього вимагають ваші правила щодо даних. Ми її експлуатуємо, моніторимо й викочуємо покращення ядра, щойно вони з’являються. Натомість ми просимо попереджати заздалегідь: коли змінюються дані, коли змінюється спосіб їх обробки або коли ви узгоджуєте новий стандарт хорошої відповіді, скажіть нам до того, як це набуде чинності, а не після — щоб система була до цього готова, а не тихо віддалялася від ваших очікувань.
Ризик — Тихий дрейфМинає пів року, запускається нова продуктова лінійка, структура звернень змінюється, і точність непомітно падає — система відповідає так само впевнено, але дедалі частіше помиляється.
Рішення — Тести на кожну змінуНабір тестів запускається після кожної зміни, а щомісяця — ще й на свіжій вибірці ваших звернень. Частка звернень, на які система не дала відповіді, — ранній тривожний сигнал: коли вона перетинає межу, узгоджену на другому тижні, ми дізнаємося про це першими, а одразу за нами — ви.
- Керований хостинг і моніторинг
- Тести на кожну зміну й щомісячний перезапуск
- Оновлення ядра й моделей
Розібраний приклад, а не історія клієнта — сценарій і цифри в ньому гіпотетичні. Справжній тут лише процес. Для такої маршрутизації потрібна навчена невелика модель, тому проєкт триває довше, ніж розробка двотижневого асистента.
Як працюють невеликі приватні моделі Принесіть нам свою задачуПринесіть нам один процес. Ми скажемо, що йому потрібно.
30-хвилинний дзвінок. Візьміть на дзвінок один реальний процес або зразок документа. Ми скажемо, чи потрібна тут LLM, невелика модель чи просто скрипт, і що для цього знадобиться. Без презентацій.