Технічне завдання на розробку чат-бота: шаблон з 9 розділів і типові помилки
Технічне завдання на чат-бот описує, яку бізнес-задачу розв'язує бот, для кого, в яких каналах, з якими системами він обмінюється даними і як ви зрозумієте, що результат прийнято. Хороше ТЗ не обов'язково довге: 3–5 сторінок з чіткими сценаріями й критеріями приймання корисніші за 40 сторінок загальних побажань. Нижче шаблон з 9 розділів, приклади формулювань і помилки, через які оцінки підрядників відрізняються в рази.
Навіщо потрібне ТЗ і чи можна без нього
ТЗ потрібне, щоб підрядники оцінювали однаковий обсяг робіт, а ви могли прийняти результат за заздалегідь узгодженими критеріями. Без нього одна агенція рахує FAQ-бот, інша бот з CRM і оплатами, і їхні пропозиції неможливо порівняти.
Писати ТЗ самостійно не обов'язково. Часто ефективніше підготувати короткий бриф (задача, аудиторія, канали, системи, бюджет, терміни), а детальне ТЗ скласти разом з підрядником на етапі discovery. Але навіть бриф має відповідати на питання з розділів нижче.
Для орієнтиру у вимогах до програмних систем існує міжнародний стандарт ISO/IEC/IEEE 29148 про інженерію вимог. Для чат-бота середнього бізнесу він надлишковий, але його головна ідея корисна: кожна вимога має бути однозначною, перевірюваною і пов'язаною з метою.
Шаблон ТЗ на чат-бот: 9 розділів
Мінімальне ТЗ на чат-бот складається з дев'яти розділів: мета, користувачі, канали, сценарії, контент, інтеграції, адмін-панель, нефункціональні вимоги і критерії приймання.
| № | Розділ | Що описати | Приклад формулювання |
|---|---|---|---|
| 1 | Мета і метрика | Яку проблему розв'язуємо, як вимірюємо | «Скоротити час першої відповіді на заявку з 4 годин до 5 хвилин» |
| 2 | Користувачі та ролі | Хто користується ботом і адмінкою | «Клієнти, менеджери відділу продажів, адміністратор контенту» |
| 3 | Канали | Telegram, Viber, сайт, Mini App | «Telegram і Viber з однаковою логікою» |
| 4 | Сценарії | Кроки кожного сценарію, розгалуження | «Заявка: 4 питання → підтвердження → угода в CRM» |
| 5 | Контент | Хто пише тексти, скільки мов, FAQ | «FAQ з 40 питань надає замовник українською» |
| 6 | Інтеграції | Системи, напрям, події, поля | «KeyCRM: створення контакту й угоди, статус назад у бот» |
| 7 | Адмін-панель | Що команда змінює без розробника | «Тексти, FAQ, розсилки з сегментацією» |
| 8 | Нефункціональні вимоги | Навантаження, дані, доступи, хостинг | «До 5 000 користувачів, дані на серверах замовника» |
| 9 | Приймання | Як перевіряємо готовність | «30 тест-кейсів з таблиці пройдено без помилок» |
Як описувати сценарії, щоб їх правильно зрозуміли
Сценарій описується як послідовність кроків з умовами і результатом, а не як перелік функцій. «Бот має приймати заявки» можна реалізувати десятьма способами; «користувач відповідає на 4 питання, отримує підтвердження, менеджер бачить угоду в CRM за хвилину» значно точніше задає очікувану поведінку.
Для кожного сценарію вкажіть:
- Тригер: як користувач потрапляє в сценарій (кнопка, посилання, QR, повідомлення).
- Кроки: питання, кнопки, варіанти відповідей.
- Розгалуження: що робити, якщо відповідь нестандартна чи користувач пропав.
- Результат: що має з'явитися в CRM, адмінці чи в повідомленні менеджеру.
- Помилки: що бачить користувач, якщо зовнішня система недоступна.
Схеми зручно малювати в будь-якому інструменті діаграм, але головне, щоб текстовий опис і схема не суперечили одне одному.
Що писати в ТЗ про інтеграції
Розділ про інтеграції найчастіше недооцінюють, хоча він може суттєво впливати на бюджет і ризики. Для кожної системи потрібні назва, напрям обміну, події, поля і наявність API.
Мінімальний набір питань:
- Яка CRM, облікова система, телефонія, платіжний сервіс?
- Чи є в них документація API і тестове середовище?
- Що передаємо в систему і що отримуємо назад?
- Що робимо з дублікатами контактів?
- Хто з боку замовника відповідає за доступи?
Покрокову схему інтеграції ми розібрали в статті інтеграція чат-бота з CRM. Якщо ваша облікова система змінюється, додайте в ТЗ окремий пункт про це: див. перехід з 1С/BAS.
Якщо в боті буде AI
Для AI-бота ТЗ має описувати не «розумність», а джерела знань, межі відповідей і спосіб перевірки якості.
Додайте в ТЗ:
- Джерела знань: які документи, хто їх оновлює.
- Заборонені теми й дії: ціни поза прайсом, медичні чи юридичні поради, обіцянки знижок.
- Правило «не знаю»: коли бот передає розмову людині.
- Контрольний набір: 30–50 реальних питань з очікуваними відповідями для приймання.
- Ліміти: бюджет на AI API на місяць і що відбувається при його вичерпанні.
Додатковий контекст про обмеження й доступи є у статті про безпеку AI-чат-ботів.
Типові помилки в ТЗ
Найдорожчі помилки ТЗ пов'язані не з формою, а з невизначеністю: вимоги без критеріїв перевірки та інтеграції без деталей.
- «Як у конкурента» без опису, що саме потрібно.
- Функції без мети: Mini App, AI і гейміфікація в першій версії «про всяк випадок».
- Немає розділу про адмін-панель, і кожна зміна тексту потребує розробника.
- Немає критеріїв приймання, тож «готово» кожна сторона розуміє по-своєму.
- Інтеграції описані одним рядком «інтеграція з CRM».
- Не вказано, хто готує контент, і проєкт стоїть, поки тексти пишуться.
Ми на discovery завжди починаємо з меж першої версії: один головний сценарій, одна метрика, мінімум інтеграцій. Решта йде окремими етапами, і це прямо впливає на бюджет. Логіку ціни ми описали на сторінці скільки коштує чат-бот.
Приклад короткого брифу замість ТЗ
Якщо часу на повне ТЗ немає, бриф з семи пунктів дає підряднику достатньо, щоб поставити правильні питання й дати попередню оцінку.
- Задача і метрика успіху.
- Хто користувачі й скільки їх очікується.
- Канали: Telegram, Viber, сайт.
- Три головні сценарії одним реченням кожен.
- Системи для інтеграції з назвами.
- Бажаний термін запуску першої версії.
- Орієнтовний бюджет або діапазон.
Приклади реалізованих ботів з різним обсягом є в нашому портфоліо: від FAQ-бота в Viber для REHAU до Telegram-системи для мережі зі 100+ точок «Файні Льоди».
Висновок
Корисне ТЗ на чат-бот відповідає на дев'ять питань: мета, користувачі, канали, сценарії, контент, інтеграції, адмін-панель, нефункціональні вимоги й приймання. Сценарії описуйте як кроки з результатом, інтеграції як події й поля, а для AI задайте джерела знань, межі й контрольний набір питань. Якщо часу мало, почніть з брифу з семи пунктів і доопрацюйте ТЗ разом з підрядником.
Поширені запитання
Мета й метрика, користувачі та ролі, канали, сценарії, контент, інтеграції, адмін-панель, нефункціональні вимоги та критерії приймання.
Для типового бізнес-бота достатньо 3–5 сторінок з чіткими сценаріями й критеріями приймання. Обсяг менш важливий, ніж однозначність вимог.
Так, якщо підготувати короткий бриф, а детальне ТЗ скласти разом з підрядником на етапі discovery. Без жодного опису оцінки різних підрядників неможливо порівняти.
Назву системи, напрям обміну, події (новий контакт, заявка, статус), мапінг полів, правило дублікатів і наявність документації API.
Вказати джерела знань, заборонені теми й дії, правило передачі людині, контрольний набір питань для приймання і місячний ліміт бюджету на AI API.
Опишіть перевірювані результати для кожного ключового сценарію: вхідні дані, очікувану поведінку, винятки та те, хто підтверджує результат.
Джерела
- ISO/IEC/IEEE 29148:2018. Systems and software engineering, Life cycle processes, Requirements engineering
- BotLabs: скільки коштує чат-бот, логіка ціни та межі першої версії
- BotLabs: кейс REHAU, FAQ-бот у Viber з веб-панеллю
---
Консультація щодо ТЗ на чат-бота
За 15 хвилин із фахівцем BotLabs із впровадження обговоримо, як ви приймаєте заявки чи замовлення та що має потрапляти в CRM. Визначимо, які вимоги й приклади потрібно підготувати для ТЗ першої версії.
Опишемо процес.
Уточнимо вимоги.
15 хвилин із фахівцем із впровадження: обговоримо заявки, CRM і вимоги для першої версії.
