Більшість AI-проектів гальмує не через технології. Модель підключається за день, RAG налаштовується за тиждень — а проект стоїть три місяці, бо ніхто в компанії не може сказати, звідки брати актуальний прайс і хто підтверджує правильність відповідей. У SUDUS·TEAM ми пройшли цей шлях достатньо разів, щоб скласти графік, який реально працює.
Нижче — план на 30 днів: що відбувається щотижня, що робить підрядник, а що доведеться зробити вам. З чесними позначками, де зазвичай усе зупиняється. План розрахований на single-purpose AI-агента — це той обсяг, який справді вкладається в місяць.
Перед стартом: три рішення, без яких не починати
Рішення 1. Один процес, а не «AI для компанії»
Найчастіша причина провалу — розмита мета. «Хочемо впровадити AI» не є задачею. «Хочемо, щоб агент відповідав на питання про статус замовлення, умови доставки й повернення без участі менеджера» — задача.
Оберіть процес, який одночасно: повторюваний, обсяговий (від 200 випадків на місяць), має чіткі правила й не потребує юридичної відповідальності за рішення.
Рішення 2. Метрика успіху в цифрах
Домовтеся заздалегідь, за яким числом ви визнаєте проект вдалим. Наприклад: «70% звернень закриваються без менеджера при оцінці клієнтів не нижче 4 з 5». Без цього через місяць почнеться суперечка про відчуття.
Рішення 3. Власник проекту з вашого боку
Потрібна конкретна людина, яка знає предмет, має 4–6 годин на тиждень і право вирішувати спірні питання. Не директор «загалом», не «хтось із підтримки». Проекти без цієї ролі зриваються найчастіше.
Тиждень 1: аудит і підготовка даних
Що робить підрядник
- Розбирає обраний процес по кроках, дивиться реальні діалоги за останні місяці
- Класифікує звернення за типами й частотою — стає видно, які 20% питань дають 80% навантаження
- Проектує персону агента: тон, межі компетенції, коли передавати людині
- Складає список потрібних інтеграцій
Що робите ви
- Вивантажуєте 200–500 реальних звернень клієнтів
- Збираєте документи в базу знань: прайс, умови, регламенти, FAQ
- Прибираєте суперечності — якщо ціна в трьох файлах різна, вирішуєте, яка правильна
- Даєте тестові доступи до систем, з якими агент має працювати
Тут зупиняється більшість проектів. «Документи зберемо наступного тижня» повторюється чотири рази поспіль. Закладіть на це 10–40 годин роботи своєї команди і призначте відповідального. Що саме потрібно збирати і в якому вигляді — розписано в матеріалі RAG простими словами.
Тиждень 2: прототип у пісочниці
Що робить підрядник
- Індексує базу знань, налаштовує гібридний пошук
- Пише системний промпт і персону
- Підключає першу модель, збирає робочий прототип у закритому середовищі
- Готує контрольний набір: 50–100 питань із заздалегідь відомими правильними відповідями
Що робите ви
- Вичитуєте перші відповіді агента й позначаєте, де він помиляється
- Уточнюєте тон: занадто офіційно, занадто фамільярно, надто багатослівно
- Кажете, чого агент не має говорити ніколи
До кінця другого тижня має існувати прототип, з яким можна поговорити. Він ще помиляється, але вже видно, чи взагалі задача розв'язується. Якщо на цьому етапі якість відверто погана — краще зупинитись і переглянути постановку, ніж їхати далі.
Тиждень 3: інтеграції та guardrails
Що робить підрядник
- Підключає агента до бойових систем: сайт, месенджер, CRM, поштова скринька
- Реалізує інструменти-функції: перевірити статус, створити заявку, забронювати час
- Налаштовує guardrails: захист від маніпуляцій промптом, заборона видавати чужі дані, ліміти вартості
- Прописує сценарій передачі складних випадків живому менеджеру
- Розгортає дешборд: діалоги, оцінки, помилки, витрати
Що робите ви
- Надаєте бойові доступи й погоджуєте права
- Визначаєте, за яких умов агент зобов'язаний покликати людину
- Готуєте команду підтримки до того, що частина звернень тепер приходитиме вже опрацьованою
Тут випливають технічні сюрпризи: у CRM немає потрібного поля, API віддає дані в дивному форматі, стара облікова система не має документації. Закладіть буфер — саме на цьому тижні найчастіше зсуваються терміни.
Тиждень 4: тестування на людях і запуск
Що робить підрядник
- Проганяє контрольний набір, рахує точність — цільове значення від 85%
- Перевіряє поведінку на питаннях поза базою знань: агент має чесно казати «не знаю»
- Ітеративно покращує промпт і чанкінг за результатами
- Оптимізує вартість токенів: роутинг моделей, кешування, обмеження історії
- Запускає спершу на частині трафіку
Що робите ви
- Даєте агента реальним співробітникам-експертам на 2–3 дні
- Збираєте зауваження структуровано, а не в чаті одним потоком
- Приймаєте рішення про запуск за узгодженою метрикою
Правильний запуск — поступовий
Не вмикайте агента одразу на 100% звернень. Робоча схема: спершу він відповідає лише в неробочі години, потім на 30% трафіку вдень, потім повністю. Кожен етап — 3–5 днів із переглядом логів. Так помилки коштують дешево.
Що відбувається після 30-го дня
Запуск — це не фініш. Перші місяць-два визначають, чи стане агент робочим інструментом:
- Тижневий розбір логів. Дивитесь, де агент передав людині те, що міг закрити сам, і де, навпаки, не мав братися.
- Поповнення бази знань. Кожне питання без відповіді — привід дописати документ.
- Контроль вартості. Реальний рахунок за токени порівнюється з прогнозом. Розрахунок — у статті скільки коштує AI-агент насправді.
- Розширення на суміжні задачі. Коли перший процес стабільний, другий агент робиться вдвічі швидше — база знань і інтеграції вже є.
Чек-лист готовності до старту
Пройдіться по ньому до того, як підписувати договір. Кожен пункт, на який відповідь «ні», — це мінус кілька днів до терміну або мінус якість на виході.
- Обрано один конкретний процес, а не «AI загалом»
- Процес дає щонайменше 200 однотипних випадків на місяць
- Записано метрику успіху в цифрах і хто її вимірює
- Призначено власника проекту з 4–6 годинами на тиждень
- Є вивантаження реальних звернень за останні 3–6 місяців
- Зібрано актуальний прайс і умови в текстовому вигляді, не картинками
- Усунуто суперечності між документами — один факт має одне джерело
- Відомо, з якими системами агент інтегрується, і хто дає доступи
- Погоджено, у яких випадках агент зобов'язаний покликати людину
- Команда підтримки попереджена про зміну в потоці звернень
Вісім «так» із десяти — можна стартувати спокійно. Менше шести — спершу тиждень підготовки, інакше платитимете підряднику за очікування.
Типові граблі, на які наступають
Погодження за принципом «покажіть готове»
Замовник не хоче дивитись проміжні версії й чекає фінал. На четвертому тижні з'ясовується, що тон не той, а половина відповідей суперечить політиці компанії. Переробка з'їдає ще два тижні. Дивіться прототип на другому тижні, навіть якщо він сирий.
«Хай агент відповідає взагалі на все»
Спокуса зробити універсального помічника з першого разу. На практиці це розмиває базу знань, знижує точність на основних питаннях і робить помилки непередбачуваними. Вузький агент, який добре робить одну річ, приносить більше користі, ніж широкий, якому не довіряють.
Немає доступу до реальних діалогів
«Ми приблизно знаємо, що питають клієнти» — не працює. Уявлення менеджменту про частотність питань зазвичай розходиться з фактами вдвічі. Вивантаження переписки — найцінніший матеріал усього проекту.
Запуск одразу на весь трафік
Спокусливо, бо «навіщо чекати». Але перші дні завжди дають несподіванки, і краще, щоб їх побачили 30% користувачів, а не всі. Поступове ввімкнення нічого не коштує й рятує репутацію.
Ніхто не дивиться логи після запуску
Проект здали, всі видихнули, дешборд ніхто не відкриває. Через три місяці виявляється, що агент половину звернень віддає менеджерам через одне питання, якого немає в базі. П'ять хвилин на тиждень у логах окупаються багатократно.
Реалістичний графік: коли 30 днів не вийде
Чесно про терміни. У місяць укладається single-purpose агент за умови, що дані готові й доступи є. Не вкладеться:
- Multi-agent система — 35–60 днів, бо додається оркестрація й контроль якості між агентами
- Проекти з розпізнаванням документів — плюс 2–3 тижні на роботу зі сканами й фото
- Компанії з узгодженням у кількох відділах — терміни визначає не розробка, а календар нарад
- Локальне розгортання моделі — плюс місяць на інфраструктуру й безпеку
Як виміряти результат: п'ять метрик
Щоб через квартал розмова про ефективність спиралася на цифри, а не на враження, зафіксуйте базові значення до запуску і порівнюйте з ними.
1. Частка звернень, закритих без людини
Головна метрика. Рахується як відсоток діалогів, після яких клієнт не звернувся до менеджера протягом доби. Реалістична ціль для першого місяця — 55–70%, через квартал роботи над базою знань — 75–85%.
2. Точність на контрольному наборі
Той самий набір із 50–100 питань проганяється щомісяця. Падіння точності — ранній сигнал, що база застаріла. Нижче 85% — привід зупинитись і розібратись.
3. Час першої відповіді
Тут зміна найпомітніша: замість 40 хвилин у робочі години й ночі очікування у неробочі — секунди цілодобово. Ця метрика найкраще пояснює цінність проекту людям поза IT.
4. Оцінка клієнтів
Проста форма на дві кнопки в кінці діалогу. Важлива не абсолютна цифра, а динаміка й тексти негативних оцінок — вони показують, чого бракує в базі знань.
5. Вартість одного закритого звернення
Витрати на токени й підтримку поділені на кількість закритих без людини діалогів. Це число можна покласти поруч із вартістю години менеджера — і саме воно робить розмову про ROI предметною.
Усі п'ять збираються автоматично на дешборді, який ми віддаємо разом з агентом. Дивитись їх варто раз на тиждень у перший місяць і раз на місяць далі.
Часті питання
Скільки часу забере проект у нашої команди?
Орієнтовно 30–50 годин за місяць, з них більшість на першому тижні. Це переважно збір і вивірка документів плюс вичитування відповідей. Розподіляється між власником проекту й одним-двома експертами.
Чи можна запустити швидше, ніж за 30 днів?
Можна за 10–14 днів, якщо звузити задачу до відповідей на топ-20 питань без інтеграцій із зовнішніми системами. Це хороший спосіб перевірити гіпотезу дешево, а вже потім розширювати.
Що робити, якщо після запуску якість просіла?
Найчастіша причина — база знань застаріла або з'явився новий тип питань. Дивляться логи звернень, які агент не закрив, і доповнюють базу. Другий за частотою випадок — змінили модель на дешевшу без переналаштування промпту.
Хто відповідає, якщо агент помилився перед клієнтом?
Відповідальність завжди на компанії, тому й потрібні guardrails і поступовий запуск. Технічно ризик знижується забороною говорити поза межами компетенції, обов'язковою передачею людині в чутливих темах і логуванням усіх діалогів для розбору.
Чи потрібен окремий співробітник для підтримки агента?
Для одного агента — ні, достатньо 2–4 годин на місяць у контент-менеджера плюс підтримка з боку підрядника. Окрема роль з'являється на рівні від п'яти агентів у різних відділах.
Підсумок
30 днів — реалістичний термін для першого AI-агента, але лише за умови, що компанія прийшла з готовими даними, однією чіткою задачею й людиною, яка за неї відповідає. Технічна частина рідко буває вузьким місцем; вузьким місцем буває неготовність відповісти на питання «а де у нас актуальний прайс».
Хочете пройти цей шлях із підрядником, який скаже про ризики на першій зустрічі, а не на третьому місяці — напишіть нам. Розбір із конкретними цифрами під ваш процес займає 30 хвилин і нічого не коштує. Приклади результатів у різних нішах — у гайді AI-агенти для бізнесу: 12 кейсів.