Ви вирішили автоматизувати якийсь процес за допомогою AI. Знайшли підрядника, домовились про зустріч. А далі — підрядник питає: «Надішліть нам ТЗ». Або, що трапляється ще частіше, ви підписуєте договір без жодного ТЗ, потім три місяці погоджуєте, що мається на увазі під «AI відповідає точно», і врешті платите вдвічі більше запланованого. Ця стаття — практичний шаблон технічного завдання на AI-автоматизацію, написаний з позиції консультанта на вашому боці. Не для IT-відділу. Для власника бізнесу, який хоче отримати результат, а не витратити гроші.
Чому ТЗ — це не «папірець для IT», а ваш захист і гроші
Більшість власників малого бізнесу сприймають технічне завдання як бюрократичну формальність: «ну, напишіть щось, підпишемо і почнемо». Насправді ТЗ — це єдиний інструмент, який захищає вас від трьох класичних пасток AI-проєктів.
Що відбувається, коли власник приходить до підрядника «поговорити»
Уявімо типовий сценарій. Власник інтернет-магазину приходить до агентства: «Хочу чат-бот, щоб клієнти не телефонували менеджерам по дрібниці». Агентство каже: «Зрозуміло, зробимо». Через 6 тижнів бот відповідає на питання про статус замовлення. Але власник мав на увазі ще й повернення товару, оформлення гарантії і консультацію з вибору розміру. Бот нічого цього не вміє. «Але ж ви не сказали», — відповідає агентство. І технічно вони праві.
Без письмового ТЗ неможливо довести, що щось «не те», бо «те» ніколи не було сформульовано. Починаються доробки, кожна з яких оплачується окремо. Типовий перерахунок у таких ситуаціях — плюс 40–80% до початкового бюджету.
Інша пастка — невизначений кінець проєкту. Без чіткого розділу «критерії прийняття» (acceptance criteria) ви не можете офіційно закрити проєкт. Підрядник завжди може сказати, що «є ще нюанси», а ви — що «ще не те, що хотів». Проєкт тягнеться місяцями.
Як погано складене ТЗ подвоює вартість проєкту
Є просте правило: виправити помилку в ТЗ коштує 1 годину. Виправити ту саму помилку в готовому коді — 10–40 годин. Виправити після запуску в продакшені — від 80 годин і репутаційний збиток.
Конкретний приклад з практики: компанія замовила AI-агента для обробки вхідних заявок. У ТЗ не було зазначено, що агент повинен розпізнавати заявки українською та англійською. Агент навчили на українських даних. Коли виявилось, що 30% клієнтів пишуть англійською, довелось перенавчати модель — додаткові 45 000 ₴ і 3 тижні. Одне речення в ТЗ врятувало б і гроші, і нерви.
Інший поширений сценарій: не описані інтеграції. Власник хотів, щоб AI-бот передавав дані в CRM. Але яку саме CRM, які поля, в який момент — не зафіксовано. Підрядник зробив «якийсь» варіант. Переробка — ще 2 тижні і 25 000 ₴.
За приблизними оцінками на ринку AI-розробки: кожна година, витрачена на якісне ТЗ, рятує від 8 до 15 годин розробки. Якщо ваш пілотний проєкт коштує 80 000 ₴ — 4 години на ТЗ статистично захищають вас від 30 000–40 000 ₴ перевитрат.
Чим ТЗ на AI-автоматизацію відрізняється від звичайного
Якщо ви раніше замовляли сайт або CRM, ви вже стикались із ТЗ. Але ТЗ на AI-проєкт має принципові відмінності — і саме їх ігнорують у більшості готових шаблонів з інтернету.
Специфіка AI: що треба описати, чого немає в шаблонах для сайтів
Стандартне ТЗ для IT-продукту описує функціональність: «кнопка робить X», «форма надсилає Y». AI-системи недетерміновані — одне й те саме питання може отримати різну відповідь залежно від контексту, формулювання, версії моделі. Тому в ТЗ на AI потрібно описати те, чого ніколи немає в шаблонах для сайтів:
Базу знань. Звідки AI бере інформацію для відповідей? Які документи, таблиці, бази продуктів він повинен «знати»? Хто відповідає за їх актуальність? Якщо база застаріла — AI видаватиме неправильні відповіді, і це буде ваша провина, а не підрядника.
Допустимий рівень помилок (галюцинацій). AI іноді «вигадує» факти, яких немає в базі. Скільки таких помилок допустимо? Як ви будете їх виявляти? Хто відповідальний за моніторинг?
Поведінку при невизначеності. Якщо AI не знає відповіді — що він має зробити? Сказати «не знаю»? Переключити на менеджера? Запропонувати зателефонувати? Це не деталь — це бізнес-рішення, яке впливає на досвід клієнта.
Вартість використання. LLM-моделі (Large Language Models) тарифікуються за кількістю токенів. Якщо ваш бот відповідає на 500 питань на день і кожна відповідь потребує 1 000 токенів — місячний рахунок може вас здивувати. Прийнятна вартість на одну взаємодію має бути зафіксована в ТЗ.
Три типи AI-проєктів і що важливо зафіксувати в кожному
Різні типи AI-рішень мають різні критичні параметри. Перш ніж складати ТЗ, визначте, до якого типу належить ваш проєкт:
Тип 1: Чат-бот / AI-асистент для спілкування з клієнтами. Критично: точність відповідей, тон і стиль спілкування, ескалація до людини, підтримувані канали (сайт, Telegram, Viber), мови спілкування. Детальніше про AI-чат-боти — на сторінці послуги AI-чатботів.
Тип 2: AI-агент для обробки заявок і документів. Критично: джерела вхідних даних (email, форми, таблиці), формати документів, правила класифікації та маршрутизації, куди передавати результат, що робити з некоректними даними.
Тип 3: Автоматизація внутрішніх процесів (аналітика, генерація звітів, документообіг). Критично: джерела даних, розклад виконання, формат вихідних результатів, хто отримує результати і як, правила виключень.
Крок 1 — Опишіть процес «як є»: що автоматизуємо і чому
Найчастіша помилка в ТЗ — стрибнути одразу до «що хочемо отримати», оминаючи «що відбувається зараз». Підрядник не знає вашого бізнесу. Без опису поточного процесу він буде проєктувати систему у вакуумі.
Формат опису бізнес-процесу (без flowchart і BPMN)
Ви не зобов’язані малювати блок-схеми (flowchart) або використовувати методологію BPMN. Достатньо відповісти на сім запитань у довільній формі:
- Хто виконує цей процес зараз? (посада, кількість людей)
- Звідки надходять дані або запити? (email, форма на сайті, месенджер, телефон)
- Що людина робить з кожним запитом? (кроки по порядку)
- Скільки часу займає один цикл?
- Скільки таких запитів обробляється на день/тиждень?
- Що може піти не так у поточному процесі? (помилки, виключення)
- Куди потрапляє результат? (CRM, таблиця, наступний відповідальний)
Відповіді на ці сім запитань — це 80% опису поточного процесу. Решта деталей підрядник уточнить сам.
Приклад: як описати процес обробки заявок у відділі продажів
Поточний стан:
- Хто: 3 менеджери з продажів, кожен веде свою частину клієнтів.
- Звідки: заявки надходять через форму на сайті (60%), email (25%), Instagram Direct (15%).
- Що робить менеджер: отримує заявку → перевіряє, чи є цей клієнт у CRM (KeyCRM) → якщо немає, створює контакт → з’ясовує потребу через дзвінок або переписку → робить комерційну пропозицію вручну → вносить результат у CRM.
- Час на один цикл: 25–40 хвилин за умови, що клієнт відповідає одразу.
- Кількість: 15–25 нових заявок на день.
- Проблеми: менеджери витрачають до 2 годин на день лише на первинну кваліфікацію (чи реальний клієнт, чи спам, що саме потрібно). Відповідь у вихідні — до 16 годин очікування.
- Результат: заповнена угода в KeyCRM зі статусом «Перший контакт».
Такий опис займає 15 хвилин і повністю замінює будь-яку блок-схему. Підрядник одразу бачить обсяг роботи, інтеграції та больові точки.
Крок 2 — Сформулюйте результат «як буде»
Якщо опис «як є» — це карта поточної ситуації, то «як буде» — це координати, куди ми хочемо потрапити. І тут більшість власників роблять помилку: описують бажання замість результатів.
«Хочу, щоб AI обробляв заявки» — це бажання. «AI кваліфікує 80% вхідних заявок без участі менеджера за 5 хвилин після надходження» — це результат.
Конкретні метрики замість розмитих цілей
Хороший опис результату завжди містить:
- Що AI повинен робити (конкретна дія)
- Скільки або як часто (числовий показник)
- До якого моменту (часовий критерій)
- Як це перевірити (критерій вимірювання)
Таблиця поганих і хороших формулювань:
| Погане формулювання | Хороше формулювання |
|---|---|
| «AI швидко відповідає клієнтам» | «Час першої відповіді — не більше 2 хвилин для 95% звернень» |
| «AI точно відповідає на питання» | «Частка відповідей, підтверджених оператором як правильні, — не менше 85%» |
| «AI інтегрується з CRM» | «AI автоматично створює контакт у KeyCRM протягом 1 хвилини після першого звернення» |
| «AI обробляє заявки без менеджера» | «AI самостійно кваліфікує щонайменше 70% заявок без залучення менеджера» |
| «AI знижує навантаження на відділ» | «Середня кількість звернень, що ескалуються до менеджера, знижується з 25 до 7 на день» |
Приклад: ТЗ на AI-чат-бот для підтримки клієнтів
Очікуваний результат:
- Бот самостійно відповідає на 70% запитів клієнтів без залучення оператора.
- Час відповіді — не більше 30 секунд для 95% запитів.
- Бот веде діалог українською та англійською мовами.
- Якщо бот не може відповісти — переключає на оператора з повним контекстом діалогу (не змушує клієнта повторювати питання).
- Ескалація на оператора відбувається не пізніше ніж через 2 хвилини після виявлення, що бот «не справляється».
- Всі розмови зберігаються та доступні для перегляду в адмін-панелі протягом 90 днів.
Детальніше про впровадження AI-підтримки клієнтів — на сторінці AI-асистента підтримки.
Крок 3 — Визначте обмеження та інтеграції
Цей розділ — найчастіше пропущений у ТЗ від замовників, і саме він є джерелом найдорожчих конфліктів у проєктах.
Які системи повинен «знати» AI (CRM, база продуктів, месенджери)
Перелічте всі зовнішні системи, з якими AI повинен взаємодіяти. Для кожної вкажіть:
- Назва системи (KeyCRM, Google Sheets, Telegram Bot, Bitrix24, WooCommerce тощо)
- Тип взаємодії: читати дані / записувати дані / і те, і те
- Які саме дані: поля, таблиці, об’єкти
- Частота: у реальному часі / раз на годину / раз на добу
- Відповідальний за доступ: хто надає API-ключі, чи є технічний контакт у системі
Приклад переліку інтеграцій для AI-агента відділу продажів:
| Система | Тип | Дані | Частота | Доступ |
|---|---|---|---|---|
| KeyCRM | Читати + писати | Контакти, угоди, статуси | Реальний час | API-ключ, я надаю |
| Google Sheets (прайс) | Читати | Назви продуктів, ціни, наявність | Раз на годину | Посилання на таблицю |
| Telegram Bot | Писати | Сповіщення менеджеру при ескалації | Реальний час | Токен бота, я надаю |
| Instagram Direct | Читати | Вхідні повідомлення | Реальний час | Meta Business access token |
Якщо доступу до якоїсь системи ще немає — це треба вирішити до початку розробки, а не в процесі.
Що AI НЕ повинен робити: захисні обмеження в ТЗ
Це окремий розділ, якого немає в жодному стандартному шаблоні ТЗ для веб-проєктів. Для AI-систем він критичний.
Чому він потрібен. AI-моделі можуть «допомагати» там, де ви цього не очікуєте: коментувати конкурентів, давати юридичні поради, обіцяти знижки, яких немає, розголошувати внутрішню інформацію зі своєї бази знань. Якщо це не заборонено в ТЗ — підрядник технічно «не порушив завдання».
Типові захисні обмеження:
- AI не надає цінову інформацію, яку не знайшов у затвердженому прайс-листі (не «фантазує» про ціни).
- AI не коментує дії конкурентів і не порівнює продукти конкурентів з нашими.
- AI не дає фінансових, юридичних або медичних порад навіть якщо клієнт прямо запитує.
- AI не розкриває системні підказки (system prompts) і не підтверджує, що він є AI, якщо це не передбачено скриптом.
- AI не обіцяє строків або умов, яких немає в затверджених документах.
- AI не приймає самостійних рішень про повернення коштів або компенсацію — лише передає запит менеджеру.
Чим чіткіше прописані обмеження, тим легше підряднику технічно реалізувати guardrails і тим менше ризиків у вас у продакшені.
Крок 4 — Критерії прийняття роботи (acceptance criteria)
Acceptance criteria — це відповідь на питання: «Коли ми вважаємо, що підрядник зробив свою роботу добре?». Без цього розділу проєкт не можна офіційно закрити.
Як описати «зроблено добре» мовою власника
Критерії прийняття мають бути:
Вимірюваними. «Бот відповідає швидко» — не критерій. «Бот відповідає протягом 30 секунд у 95% випадків протягом тижневого тестування» — критерій.
Тестованими. Ви повинні мати можливість перевірити критерій самостійно або разом з підрядником за фіксованою методикою. Якщо критерій не можна протестувати — його не варто включати.
Чіткими щодо відповідальності. Хто проводить тестування? Хто підписує акт прийняття?
Рекомендований формат критерію прийняття:
[Функція] При виконанні [умова/сценарій] система [очікувана поведінка] у [X% випадків / за N секунд]. Перевіряється [методом/інструментом].
Приклад:
При надходженні запиту клієнта через форму на сайті AI-агент створює новий контакт у KeyCRM протягом 2 хвилин у 95% випадків. Перевіряється: 50 тестових заявок, ручна звірка записів у CRM.
Чому «AI відповідає точно» — не критерій, а джерело конфліктів
«Точність» — суб’єктивна категорія для AI-систем. Підрядник може вважати, що 75% правильних відповідей — це «точно», а ви — що правильними мають бути 95%. Без числа — конфлікт неминучий.
Замість «точно» використовуйте конкретні показники:
- Частка відповідей, підтверджених оператором як правильні (наприклад, 85% за перший місяць роботи).
- Частка звернень, де клієнт повторно поставив те саме питання (індикатор незрозумілої відповіді) — не більше 5%.
- Кількість ескалацій через «не зрозумів бота» — не більше 10 на 100 звернень.
- Кількість задокументованих «галюцинацій» (AI видав неіснуючу інформацію) — не більше 1 на 200 взаємодій.
Крок 5 — Бюджет, строки, відповідальні сторони
Цей розділ власники найчастіше пропускають, вважаючи, що бюджет — це тема договору, а не ТЗ. Але ТЗ без фінансової рамки залишає простір для розширення скоупу за ваш рахунок.
Як оцінити реальний бюджет до початку проєкту
Якщо у вас немає досвіду AI-проєктів, орієнтуйтесь на такі приблизні рамки для українського ринку (оцінки станом на 2026 рік, можуть варіюватись):
| Тип рішення | Орієнтовний бюджет пілоту | Терміни |
|---|---|---|
| AI-чат-бот на готовій платформі (Tidio, Intercom + GPT) | 15 000–40 000 ₴ | 2–4 тижні |
| AI-агент з кастомною логікою і CRM-інтеграцією | 50 000–120 000 ₴ | 4–8 тижнів |
| Автоматизація документообігу (парсинг + генерація) | 30 000–80 000 ₴ | 3–6 тижнів |
| Складна мультиагентна система | від 150 000 ₴ | від 10 тижнів |
У ТЗ зафіксуйте: – Загальний бюджет проєкту (або межі: «від Х до Y»). – Бюджет операційних витрат (щомісячна вартість LLM API, хостингу, підтримки). – Що не включено у вартість (навчання персоналу, наповнення бази знань, юридичний супровід).
Що фіксувати в договорі поруч із ТЗ
ТЗ і договір — різні документи, але вони мають бути узгоджені між собою. Попросіть підрядника включити в договір посилання на ТЗ як додаток і окремо зафіксуйте:
- Порядок внесення змін до ТЗ (change request process): хто ініціює, хто затверджує, як це впливає на бюджет і строки.
- Гарантійний період: скільки часу підрядник виправляє помилки безкоштовно після прийняття.
- Умови передачі прав: код, моделі, дані — що залишається у вас після завершення.
- Підтримка і моніторинг: хто стежить за системою після запуску, як і коли ви дізнаєтесь про помилки.
Готовий шаблон ТЗ на AI-автоматизацію
Нижче — структурований шаблон, який ви можете скопіювати і заповнити за 2–3 години. Кожне поле прокоментовано: навіщо воно і що в нього писати.
Секція 1: Загальна інформація та мета
| Поле | Що заповнити | Навіщо |
|---|---|---|
| Назва проєкту | «AI-агент кваліфікації заявок» | Унікальна назва для референсу |
| Дата складання ТЗ | 2026-05-31 | Версія документа |
| Замовник | Назва компанії, контактна особа | Відповідальний на стороні замовника |
| Виконавець | Назва агентства, менеджер проєкту | Відповідальний на стороні підрядника |
| Мета проєкту | Конкретний результат у 1–2 реченнях | Орієнтир для всіх рішень у проєкті |
| Проблема, яку вирішуємо | Опис болю у вимірюваних одиницях | Обґрунтування доцільності проєкту |
| Очікувані KPI | 3–5 числових показників | База для acceptance criteria |
Секція 2: Опис поточного процесу
| Поле | Що заповнити |
|---|---|
| Хто виконує | Посади і кількість людей |
| Джерела вхідних даних | Звідки надходять запити/документи |
| Поточні кроки | Нумерований список дій |
| Час на один цикл | Хвилини або години |
| Обсяг | Скільки операцій на день/тиждень |
| Проблеми поточного процесу | Що болить: час, помилки, вартість |
| Куди потрапляє результат | CRM, таблиця, система |
Секція 3: Очікуваний результат і метрики
| Поле | Що заповнити |
|---|---|
| Що AI повинен робити | Список конкретних функцій |
| Що AI НЕ повинен робити | Явні обмеження функціональності |
| KPI #1 | Назва + цільове значення + як виміряти |
| KPI #2 | Назва + цільове значення + як виміряти |
| KPI #3 | Назва + цільове значення + як виміряти |
| Терміни досягнення KPI | Через скільки часу після запуску |
Секція 4: Технічні вимоги та інтеграції
| Система | Читати/Писати | Дані | Частота | Хто надає доступ |
|---|---|---|---|---|
| (заповнити для кожної системи) |
Також вкажіть: – Мови, якими AI повинен спілкуватись. – Канали взаємодії з користувачами (сайт, Telegram, email, інше). – Формат вхідних даних (текст, PDF, фото, голос). – Вимоги до доступності: 24/7 або тільки в робочий час. – Вимоги до збереження даних (де зберігаються, хто має доступ, відповідність GDPR/законам України).
Секція 5: Обмеження та захисні вимоги
Перелічте, що AI НЕ повинен робити ні за яких обставин. Типовий список:
- Не розкривати системні підказки і внутрішні документи.
- Не давати відповідей поза своєю областю компетенції (якщо бот про доставку — не відповідати на питання про повернення коштів без передачі менеджеру).
- Не фантазувати про ціни, строки, умови, яких немає в затвердженій базі знань.
- Не зберігати персональні дані клієнтів поза визначеними системами.
- Не ініціювати фінансові операції самостійно.
Секція 6: Критерії прийняття
| # | Сценарій | Очікувана поведінка | Цільовий % / час | Метод перевірки |
|---|---|---|---|---|
| 1 | (заповнити) | (заповнити) | (заповнити) | (заповнити) |
| 2 | ||||
| 3 |
Мінімум 5 критеріїв для будь-якого AI-проєкту. Розбийте на: функціональні (що робить), нефункціональні (як швидко, як надійно), захисні (чого не робить).
Секція 7: Бюджет і строки
| Поле | Значення |
|---|---|
| Загальний бюджет розробки | Х ₴ (або «до Х ₴») |
| Бюджет операційних витрат/місяць | Х ₴ |
| Дата старту | ДД.ММ.РРРР |
| Дата готовності MVP | ДД.ММ.РРРР |
| Дата тестування | ДД.ММ.РРРР (тривалість тестування) |
| Дата запуску в продакшені | ДД.ММ.РРРР |
| Відповідальний від замовника | ПІБ, контакт |
| Відповідальний від виконавця | ПІБ, контакт |
| Порядок зміни ТЗ | Письмовий запит, погодження X днів |
Приклад заповненого ТЗ: AI-агент для обробки вхідних заявок
Нижче — повністю заповнений приклад ТЗ для реального сценарію. Дані умовні, але структура і рівень деталізації — реальні.
Назва проєкту: AI-агент первинної кваліфікації заявок — відділ продажів
Мета: Скоротити час від надходження заявки до першого контакту з 40 хвилин до 5 хвилин. Звільнити менеджерів від кваліфікації спаму та нерелевантних заявок.
Проблема: Відділ продажів (3 менеджери) отримує 20–25 заявок на день. Половина з них — некваліфіковані (спам, нецільові запити, запити від студентів). Менеджери витрачають 1,5–2 години на день лише на первинний розбір. У вихідні заявки чекають до 16 годин.
Поточний процес: 1. Заявка надходить через форму на сайті або Instagram Direct. 2. Менеджер отримує email-сповіщення. 3. Менеджер відкриває CRM, знаходить заявку, читає її. 4. Оцінює, чи цільова (за розміром бізнесу, бюджетом, нішею). 5. Якщо цільова — телефонує або пише у відповідь, відкриває угоду. 6. Якщо нецільова — закриває заявку зі статусом «відхилено».
Очікуваний результат: – AI-агент автоматично відповідає на кожну нову заявку протягом 5 хвилин (24/7). – Ставить 3–5 уточнюючих питань для кваліфікації (розмір компанії, задача, бюджет, строки). – На основі відповідей визначає категорію: «гарячий лід», «потребує прогріву», «нецільовий». – Передає «гарячий лід» менеджеру з контекстом (стислий підсумок діалогу) через Telegram-сповіщення і запис в CRM. – «Нецільових» закриває автоматично з ввічливою відповіддю.
Інтеграції:
| Система | Тип | Дані | Частота |
|---|---|---|---|
| KeyCRM | Читати + писати | Контакти, угоди, статуси | Реальний час |
| Telegram Bot | Писати | Сповіщення менеджеру | При появі «гарячого ліду» |
| Instagram Direct (Meta) | Читати + писати | Вхідні повідомлення | Реальний час |
| Сайт (форма) | Читати | Нові заявки через webhook | При надходженні |
Мови: українська та англійська.
Обмеження: – Агент не обговорює конкретні ціни або строки до ручного підтвердження менеджером. – Агент не обробляє заявки на теми, не пов’язані з профілем компанії — передає менеджеру. – Агент не зберігає персональні дані клієнтів поза KeyCRM.
Критерії прийняття:
| Сценарій | Очікувана поведінка | Ціль | Перевірка |
|---|---|---|---|
| Нова заявка з форми сайту | Автовідповідь з уточнюючими питаннями | ≤ 5 хвилин, 95% заявок | 50 тестових заявок, замір часу |
| Кваліфікований лід | Запис в KeyCRM + Telegram менеджеру | ≤ 2 хвилини після завершення діалогу | Ручна звірка 20 записів |
| Нецільова заявка | Ввічлива відповідь, закриття угоди | Без залучення менеджера | Ревізія 20 «нецільових» закритих угод |
| AI «не знає» відповідь | Ескалація до менеджера | ≤ 3 хвилини | 10 тестових нестандартних питань |
| Запит поза нішею | Відмова + пропозиція звернутись деінде | Без помилкової кваліфікації | 5 тестів |
Бюджет: 60 000–80 000 ₴ на розробку і запуск. Операційні витрати: до 3 000 ₴/місяць (API LLM + хостинг). Строки: 6 тижнів від підписання договору до запуску в продакшені.
Типові помилки власників при складанні ТЗ
Навіть маючи шаблон, є кілька поширених помилок, які зводять нанівець весь ефект від ТЗ.
«Зробіть як у конкурентів» — чому це не ТЗ
«Хочу чат-бот, як у Rozetka» або «зробіть автоматизацію, як у [великий e-commerce]» — це не ТЗ. Ви не знаєте технічного стека конкурента, його бюджету, специфіки їхніх процесів. Підрядник візьметься за таке завдання, але реалізує «своє розуміння» — і воно може не збігатись з вашим.
Використовуйте конкурентів як джерело натхнення, але в ТЗ описуйте власні процеси і власні метрики. «Хочу, щоб клієнт міг перевірити статус замовлення без дзвінка оператору, через Telegram-бота, протягом 30 секунд, у 80% випадків» — ось ТЗ.
Пропущений розділ обмежень — звідки беруться «галюцинації» в продакшені
Якщо ви не описали, що AI НЕ повинен робити, підрядник оптимізує систему лише під функції, що є. LLM-модель за замовчуванням намагатиметься дати відповідь на будь-яке питання — навіть якщо у неї немає точних даних. Результат: бот вигадує ціни, строки, характеристики продуктів.
Власник однієї компанії розповів: їхній AI-бот для підтримки назвав ціну на послугу, якої вже не існувало в прайсі. Клієнт скріншотнув, вимагав виконати. Конфлікт вийшов дорожчим, ніж вся розробка бота.
Розділ обмежень — це guardrails системи. Без нього ви будуєте автомобіль без гальм.
Відсутні критерії прийняття — як не потрапити в безкінечний цикл доробок
Без acceptance criteria проєкт формально ніколи не «готовий». Підрядник завжди може сказати «є нюанс, треба доробити», а замовник — «я маю на увазі трохи інше». Кожен цикл доробок без погодженого критерію — це або ваш додатковий бюджет, або збиток підрядника.
Фіксуйте мінімально 5 чітких acceptance criteria перед стартом. Якщо підрядник відмовляється їх підписувати — це сигнал. Хороший підрядник сам попросить деталізувати критерії.
Що далі після ТЗ: від документа до запущеного пілоту
Технічне завдання — це не кінцева мета, а відправна точка. Хороше ТЗ дає вам три речі: чіткий скоуп для підрядника, інструмент контролю під час розробки і захист при здачі проєкту.
Але ТЗ не замінює розуміння того, які процеси у вашому бізнесі найвигідніше автоматизувати. Перш ніж складати ТЗ, потрібно відповісти на питання: де в моїх процесах AI дасть найшвидший ROI? Які процеси можна автоматизувати прямо зараз, а які потребують підготовки? Детальніше про це — в матеріалі про автоматизацію бізнес-процесів.
Типовий шлях від першої розмови до результату в пілотних проєктах:
- AI-аудит (1–5 днів). Аналіз поточних процесів, визначення найвищого пріоритету для автоматизації, орієнтовна оцінка ROI. Результат: конкретні рекомендації + пріоритезований список сценаріїв.
- Складання ТЗ (2–5 днів). На основі аудиту — фіксація скоупу, метрик, інтеграцій, обмежень.
- Пілот (2–3 тижні). Обмежений запуск на одному процесі або одному каналі. Фіксована ціна, чіткий результат.
- Оцінка і масштабування. За результатами пілоту — рішення про повноцінне впровадження або коригування підходу.
Якщо ви ще не визначили, з чого починати, — замовте безкоштовний AI-аудит. За 5 днів визначимо пріоритетний сценарій, оцінимо ROI і підготуємо основу для ТЗ. Розрахувати вартість пілоту можна на сторінці автоматизації замовлень або через форму нижче.
Часті питання
Чи обов’язково складати ТЗ для невеликого AI-проєкту?
Так, навіть для малого проєкту. ТЗ на 2–3 сторінки займає 2–3 години вашого часу, але може врятувати 30–50% бюджету від переробок. Чим менший бюджет проєкту — тим критичніша кожна гривня. Для проєктів до 30 000 ₴ достатньо скороченого варіанту шаблону з секціями 1, 2, 3 і 6.
Хто повинен складати ТЗ — замовник або підрядник?
Залежить від домовленостей. Варіант 1: замовник заповнює шаблон, підрядник деталізує і технічно уточнює. Варіант 2: підрядник складає ТЗ на основі інтерв’ю із замовником (зазвичай платна послуга, 5 000–15 000 ₴). У будь-якому випадку замовник повинен перевірити і підписати ТЗ — відповідальність за зміст не можна повністю делегувати.
Що робити, якщо підрядник каже, що ТЗ «не потрібне, ми гнучкі»?
«Гнучкість» без фіксації вимог — це ризик для вас, а не комфорт. Хороший Agile-підхід передбачає детальні User Stories для кожного спринту. Якщо підрядник відмовляється фіксувати що-небудь письмово — це червоний прапорець. Мінімум, який ви повинні мати: список функцій, метрики успіху і критерії прийняття.
Як часто потрібно оновлювати ТЗ під час проєкту?
ТЗ — живий документ. Зміни неминучі, але кожна зміна повинна проходити через погоджений change request process: письмовий запит, оцінка впливу на бюджет і строки, підписання обома сторонами. Це захищає і вас, і підрядника від непорозумінь.
Чи можна використовувати один шаблон ТЗ для різних AI-проєктів?
Так, базова структура підходить для більшості AI-проєктів: чат-ботів, агентів обробки заявок, автоматизації документообігу. Але секції 3 (метрики) і 4 (інтеграції) потрібно заповнювати заново для кожного проєкту — вони унікальні. Секція 5 (обмеження) теж вимагає окремого опрацювання залежно від типу доступу до даних і ризиків.
Скільки часу займає складання якісного ТЗ?
Від 2 до 8 годин залежно від складності проєкту і повноти вашого розуміння власного процесу. Найчастіше 4 години — достатньо для пілотного проєкту середньої складності. Якщо ви не можете описати власний процес за 4 години — це сигнал, що спершу треба провести внутрішній аудит процесу.
Що робити, якщо я не розумію технічні вимоги до AI?
Заповнюйте бізнесову частину ТЗ — процес «як є», очікувані метрики, обмеження, бюджет. Технічні деталі (модель, архітектура, стек) — зона відповідальності підрядника. Ваше завдання — чітко сформулювати «що» і «навіщо», а не «як».
Підсумок
Технічне завдання на AI-автоматизацію — це не бюрократія і не «додатковий папірець». Це ваш інструмент контролю, захисту бюджету і єдиний спосіб порівняти, що ви замовили і що отримали.
Почніть з семи запитань про поточний процес. Додайте конкретні метрики результату. Зафіксуйте інтеграції і захисні обмеження. Визначте acceptance criteria. Все це займе 4 години — і врятує вас від 30 000–80 000 ₴ можливих переробок.
Якщо ви ще не визначились, який процес автоматизувати першим, — почніть з безкоштовного AI-аудиту. За 5 днів ви отримаєте конкретні рекомендації та основу для ТЗ. Замовити аудит або розрахувати вартість пілоту.
