Самат прислал мне документ на 47 страниц. Называлось это «Техническое задание на разработку интеллектуального чат-бота с элементами искусственного интеллекта для автоматизации клиентского сервиса».
Я открыл файл и через пятнадцать минут закрыл. Не потому что там было что-то плохое – там не было почти ничего полезного. Сорок семь страниц общих слов, красивых диаграмм, описания того, как «бот должен быть умным и понимать клиентов». И ни одного конкретного сценария, ни одной метрики успеха, ни одного ограничения.
«Мы полгода это согласовывали, – сказал Самат. – Юристы смотрели, безопасники визировали, директор подписал. А подрядчик говорит, что по этому ТЗ работать невозможно.»
Самат руководит клиентским сервисом в крупной логистической компании в Астане. 200 операторов, 15 000 обращений в день. Идея автоматизировать часть работы ботом – разумная. Но документ, который они написали, был бесполезен. Хуже того – он создавал иллюзию, что работа сделана.
Через три месяца мы переписали ТЗ заново. Получилось 12 страниц. Бот заработал ещё через два. И в этой статье я покажу, как написать техническое задание на AI-бота так, чтобы оно реально работало – а не пылилось в папке «согласовано».
«Хорошее ТЗ – это не документ для юристов. Это контракт между бизнесом и технологией: что именно мы автоматизируем, как измеряем успех и когда понимаем, что пора остановиться.»
Почему традиционные ТЗ не работают для AI-ботов
Прежде чем разбирать, как писать правильно, давайте поймём, что обычно идёт не так. Большинство неудачных проектов с ботами начинаются именно с плохого технического задания. Я это вижу снова и снова.
Классическое ТЗ на разработку ПО описывает функции. «Система должна позволять пользователю...», «При нажатии кнопки система отображает...». Это работает для детерминированного софта, где результат предсказуем: нажал – получил. Всё просто.
А вот с AI-ботом всё совсем иначе. Бот – это не программа с кнопками. Это агент, который ведёт диалог. И диалог этот каждый раз разный. Клиент может спросить одно и то же десятью способами. Может задать вопрос, которого вы вообще не предусмотрели. Может вести себя агрессивно или, наоборот, уйти в глухую оборону. А бот должен как-то реагировать на всё это.
Попытка описать бота как набор функций – это примерно как пытаться написать инструкцию для живого сотрудника в формате «нажмите 1 – скажите фразу А, нажмите 2 – скажите фразу Б». Забавно, но не работает.
Пять признаков бесполезного ТЗ на AI-бота
«Бот должен быть умным»
Нет критериев «умности». Что значит «умный»? Понимает сленг? Шутит? Решает уравнения? Без конкретики это пустые слова.
«Понимать естественный язык»
Естественный язык – это и «где мой заказ?», и сонет Шекспира. Какие именно формулировки должен понимать бот?
«Интеграция с существующими системами»
С какими? По какому API? Какие данные читаем, какие пишем? Без деталей – это не требование, а пожелание.
«Высокий уровень удовлетворённости»
Какой конкретно? 70% CSAT? 90%? Как будем измерять? Если нет цифры – нет способа проверить.
Нет примеров диалогов
Ни одного конкретного сценария «клиент говорит X – бот отвечает Y». Как разработчику понять, чего вы хотите?
Если в вашем ТЗ есть хотя бы два пункта из списка выше – документ нужно переписывать. Не редактировать, а именно переписывать с нуля, используя другой подход.
Какой? Сейчас расскажу.
Структура ТЗ на AI-бота: 7 обязательных разделов
За годы работы с разными компаниями – от стартапов до банков – мы выработали структуру, которая работает. Она не идеальна (идеального ТЗ не существует), но позволяет избежать большинства проблем. По крайней мере, таких, как у Самата.
Семь разделов. Каждый следующий опирается на предыдущий, поэтому порядок здесь важен.
1
Бизнес-контекст и цели
Зачем нужен бот? Какую проблему решаем? Какие метрики хотим улучшить? Как поймём, что проект успешен?
2
Сценарии использования
Конкретные диалоги: кто спрашивает, что спрашивает, что бот должен ответить или сделать. С примерами.
3
База знаний и источники данных
Откуда бот берёт информацию? Прайс-листы, FAQ, документация, CRM. Кто отвечает за актуальность?
4
Интеграции и API
С какими системами взаимодействует бот? Какие операции выполняет? Какие данные читает и пишет?
5
Нефункциональные требования
SLA, допустимая задержка ответа, пиковые нагрузки, время работы, требования к uptime.
6
Безопасность и compliance
Какие данные обрабатываем? Где храним? Кто имеет доступ? Соответствие 152-ФЗ, GDPR, внутренним политикам.
7
Критерии приёмки и метрики успеха
Как проверяем, что бот работает правильно? Какие показатели считаем успехом? Что является провалом?
Обратите внимание: функциональных требований в классическом понимании здесь нет. Потому что для AI-бота важнее не «что он умеет», а «какие задачи решает» и «как мы это проверяем». Это принципиально разные вещи.
Теперь разберём каждый раздел подробно. С примерами и шаблонами, которые можно взять и использовать.
Раздел 1: Бизнес-контекст и цели
Это самый важный раздел. Если он написан плохо – всё остальное не имеет смысла.
Бизнес-контекст отвечает на вопросы «зачем» и «для кого». Без него разработчик не понимает, что на самом деле нужно заказчику. И начинает делать то, что ему кажется правильным. А то, что кажется правильным разработчику, редко совпадает с ожиданиями бизнеса.
Вот что должно быть в этом разделе:
Шаблон: Бизнес-контекст
1.1. Описание текущей ситуации
Пример:
«Отдел клиентского сервиса компании "Альфа-Логистика" обрабатывает 15 000 обращений в день. 45% обращений – это однотипные вопросы о статусе доставки, которые не требуют квалификации оператора. Среднее время ответа – 4 минуты, целевое – 30 секунд. Штат операторов – 200 человек, текучка – 35% в год.»
1.2. Проблема, которую решаем
Пример:
«Операторы тратят 45% времени на рутинные ответы, которые не требуют экспертизы. Это приводит к выгоранию, высокой текучке и очередям в пиковые часы. Клиенты ждут ответа по 4-5 минут, NPS падает.»
1.3. Целевые показатели (KPI)
Пример:
- Автоматизировать 40% обращений без участия оператора
- Снизить среднее время ответа до 15 секунд (для автоматизированных)
- Поддерживать CSAT на уровне не ниже 4.2 из 5
- Снизить текучку операторов на 20% за счёт уменьшения рутины
1.4. Ограничения и риски
Пример:
- Бот не должен давать информацию о содержимом посылки (конфиденциально)
- Бот не может принимать решения о компенсациях – только передавать оператору
- При любой неуверенности – эскалация на человека, а не догадки
Видите разницу с «бот должен быть умным»? Здесь конкретика: цифры, метрики, ограничения. Разработчик сразу понимает масштаб, приоритеты и красные линии.
Важный момент: ограничения часто важнее возможностей. Легче сделать бота, который умеет всё, но говорит чушь, чем бота, который знает свои границы. Поэтому раздел «что бот НЕ должен делать» – обязателен.
Подробнее о том, как собирать требования к CRM и автоматизации, мы писали в статье Как собрать требования к CRM: интервью, user stories, BRD.
Раздел 2: Сценарии использования – сердце ТЗ
Если бизнес-контекст – это «зачем», то сценарии – это «как именно». Это самый объёмный и самый важный для разработки раздел.
Сценарий – это не абстрактное «бот отвечает на вопросы о доставке». Это конкретный диалог: что говорит клиент, что отвечает бот, какие действия бот выполняет в системах.
Хороший сценарий включает:
- Триггер – что запускает сценарий (вопрос клиента, событие в системе)
- Вариации запроса – как клиент может сформулировать одно и то же разными словами
- Необходимые данные – что бот должен узнать или получить из систем
- Действия бота – запросы в API, записи в CRM, отправка уведомлений
- Ответ клиенту – что именно бот говорит (с примерами формулировок)
- Ветвления – что делать, если данных нет, если ошибка, если клиент недоволен
Пример сценария: Статус доставки
Триггер
Клиент спрашивает о статусе заказа/доставки
Приоритет
Критичный – 35% всех обращений
Варианты запроса клиента
- «Где мой заказ?»
- «Когда приедет курьер?»
- «Статус доставки»
- «Заказ 12345 где?»
- «Трек-номер ABC123»
- «Посылка не пришла»
Алгоритм работы бота
- Если номер заказа указан в сообщении – использовать его
- Если не указан – запросить: «Подскажите номер заказа или трек-номер»
- Запрос в TMS API: GET /orders/{order_id}/tracking
- Если заказ найден – сформировать ответ по шаблону
- Если не найден – предложить проверить номер или связать с оператором
Шаблон ответа (успех)
Ваш заказ №{order_id} находится в статусе «{status}».
📍 Текущее местоположение: {location}
🕐 Ожидаемая доставка: {eta}
Если у вас есть вопросы, я могу связать вас с оператором.
Ветвления (edge cases)
| Заказ не найден | «Не нашёл заказ с таким номером. Проверьте, пожалуйста, или напишите номер телефона, на который оформляли.» |
| API недоступен | «Извините, сейчас не могу проверить статус. Попробуйте через 5 минут или я переключу на оператора.» |
| Доставка просрочена | Автоэскалация на оператора с пометкой «Просрочка доставки, клиент ждёт» |
Таких сценариев в хорошем ТЗ – от 10 до 30, в зависимости от сложности бота. Каждый сценарий – это отдельная «единица полезности». Чем детальнее вы их опишете, тем точнее будет результат.
Совет: начните с анализа реальных обращений. Выгрузите 1000 последних чатов, сгруппируйте по темам, выделите топ-10 – вот ваши приоритетные сценарии.
Больше примеров сценариев – в статье 25 готовых сценариев для CRM-бота: продажи, поддержка, операции.
Нужна помощь с техническим заданием?
Мы помогаем компаниям в Казахстане правильно формулировать требования к AI-ботам. Проведём аудит процессов, соберём сценарии и подготовим ТЗ, по которому можно работать.
Раздел 3: База знаний и источники данных
AI-бот – не волшебник. Он не может знать то, чему его не научили. Поэтому третий раздел ТЗ должен чётко описывать: откуда бот берёт информацию.
Это важнее, чем кажется. Половина провальных проектов с ботами – не из-за плохой технологии, а из-за того, что боту просто нечего было отвечать. Не было актуального прайса, не было ответов на частые вопросы, не было доступа к истории клиента.
| Источник данных | Формат | Частота обновления | Ответственный |
|---|---|---|---|
| Прайс-лист услуг | Excel / Google Sheets | При изменении цен (уведомление боту) | Коммерческий отдел |
| FAQ – частые вопросы | Notion / Confluence | Еженедельно | Отдел поддержки |
| Условия доставки | PDF / веб-страница | При изменении условий | Логистика |
| История заказов клиента | API CRM (REST) | Real-time | IT-отдел |
| Статусы доставки | API TMS | Real-time | IT-отдел |
| Акции и спецпредложения | JSON-фид | Ежедневно | Маркетинг |
Обратите внимание на колонку «Ответственный». Это критично. Если никто не отвечает за актуальность прайса в базе знаний – бот будет называть старые цены. И клиенты будут злиться не на маркетолога, который забыл обновить, а на бота.
Ещё один важный момент: формат данных. Бот на базе LLM может работать с текстом, PDF, таблицами. Но если у вас информация в 50 разных Excel-файлах с разной структурой – это проблема. Часть работы по ТЗ – это как раз понять, какие источники нужно привести в порядок до запуска.
О том, как строить базу знаний для бота, читайте в статье RAG для бизнеса: как подключить LLM к базе знаний компании.
Раздел 4: Интеграции и API
Бот, который только разговаривает – это справочник. Бот, который делает что-то полезное – это инструмент. Разница – в интеграциях.
Этот раздел описывает, с какими системами бот взаимодействует и какие операции выполняет. Для каждой интеграции нужно указать:
CRM (Bitrix24 / amoCRM)
Чтение: карточка клиента, история сделок, открытые задачи
Запись: создание лида, добавление комментария, смена статуса
API: REST API, OAuth 2.0
TMS (система доставки)
Чтение: статус заказа, местоположение, ETA
Запись: запрос на перенос доставки
API: REST API, API Key
Календарь записи
Чтение: свободные слоты, занятость специалистов
Запись: создание записи, отмена, перенос
API: Google Calendar API
Система уведомлений
Чтение: –
Запись: отправка SMS, push, email
API: Webhook / REST
Для каждой интеграции важно также указать: что делать, если API недоступен. Бот не должен молча ломаться – он должен сообщить клиенту о временных проблемах и предложить альтернативу.
Детали интеграции бота с CRM и другими системами – в статье Интеграция бота с ERP/CRM: 8 ошибок в ТЗ.
Раздел 5: Нефункциональные требования
Это то, что часто забывают – а потом удивляются, почему бот «тормозит» или «падает».
Нефункциональные требования (NFR) описывают не что бот делает, а как он это делает: быстро или медленно, надёжно или с перебоями, под какой нагрузкой справляется.
| Параметр | Требование | Комментарий |
|---|---|---|
| Время ответа | ≤ 3 секунды для 95% запросов | Для сложных запросов с API – до 5 сек |
| Доступность (uptime) | 99.5% в месяц | ≈ 3.5 часа простоя максимум |
| Пиковая нагрузка | 500 одновременных диалогов | Сезонный пик – до 800 |
| Часы работы | 24/7 | Бот доступен всегда |
| Языки | Русский, казахский | Автоопределение языка клиента |
| Логирование | Все диалоги хранятся 1 год | Для аудита и обучения |
Почему это важно? Потому что от NFR зависит архитектура и стоимость. Бот с uptime 99% и бот с uptime 99.99% – это разные деньги. Бот на 100 диалогов и бот на 5000 – разная инфраструктура.
Если вы не укажете NFR – подрядчик сделает «как обычно». А «обычно» может не подойти под вашу нагрузку.
Раздел 6: Безопасность и compliance
AI-бот обрабатывает данные клиентов. Иногда – персональные данные. Иногда – платёжную информацию. Это зона ответственности, и её нужно описать в ТЗ.
Чек-лист безопасности для ТЗ
Данные
- Какие персональные данные обрабатывает бот?
- Где хранятся диалоги и как долго?
- Передаются ли данные третьим сторонам (OpenAI, облако)?
- Как реализовано право на удаление данных?
Доступ
- Кто имеет доступ к диалогам?
- Как логируются действия администраторов?
- Какая авторизация для API-интеграций?
- Как отзывается доступ уволенных сотрудников?
Compliance
- Соответствие Закону РК о персональных данных
- Локализация данных (если требуется)
- Согласие клиента на обработку (как получаем, где храним)
Особенно важно для компаний в Казахстане: если вы работаете с персональными данными граждан РК, нужно учитывать требования местного законодательства. Это влияет на выбор инфраструктуры и провайдеров AI.
Подробнее о юридических аспектах – в статье Юридически безопасные боты: согласия, уведомления, хранение записей.
Раздел 7: Критерии приёмки и метрики успеха
Последний раздел – но не по важности. Это ответ на вопрос: «Как мы поймём, что бот работает правильно?»
Без чётких критериев приёмки вы попадаете в ловушку бесконечных доработок. Подрядчик говорит «готово», вы говорите «не совсем то», и так месяцами. Критерии снимают субъективность.
Критерии приёмки AI-бота
Функциональные тесты
- 100% описанных сценариев работают корректно
- Golden set из 50 диалогов проходит без ошибок
- Все интеграции подключены и работают
Качественные метрики
- Accuracy на тестовой выборке ≥ 90%
- Containment rate (без эскалации) ≥ 40%
- CSAT по опросу после диалога ≥ 4.0
Технические метрики
- Время ответа ≤ 3 сек (P95)
- Нагрузочный тест: 500 диалогов без деградации
- Uptime за тестовый период ≥ 99%
Документация
- Руководство администратора
- Инструкция по обновлению базы знаний
- Playbook для операторов по эскалациям
Обратите внимание на «Golden set» – это набор эталонных диалогов, которые бот должен отработать идеально. Вы готовите его заранее, подрядчик тестирует бота на этих диалогах. Если golden set проходит – бот готов к пилоту.
Подробнее о тестировании и метриках качества – в статье Оценка качества AI-бота: golden set, метрики, A/B-тесты.
Чего НЕ надо писать в ТЗ: антипаттерны
Напоследок – список того, что часто встречается в плохих ТЗ. Если узнаёте свой документ – пора его переписать.
«Бот должен понимать все вопросы клиентов»
Почему плохо: «Все» – это бесконечность. Клиент может спросить рецепт борща или расписание автобусов. Бот не должен знать всё – он должен хорошо знать своё.
Как правильно: «Бот должен корректно обрабатывать сценарии 1-15 из раздела 2. Вопросы вне этих сценариев – эскалация на оператора с пометкой "вопрос вне компетенции".»
«Использовать современные технологии AI»
Почему плохо: «Современные» – понятие размытое. GPT-4? Claude? LLaMA? Это влияет на стоимость, скорость, качество. Заказчик должен понимать компромиссы.
Как правильно: Укажите конкретные требования (latency, стоимость токена, локализация данных), а выбор модели оставьте подрядчику с обоснованием.
«Бот не должен ошибаться»
Почему плохо: AI ошибается. Всегда. Вопрос не в «ноль ошибок», а в минимизации и правильной обработке.
Как правильно: «Допустимый уровень ошибок – не более 5% на golden set. При любой неуверенности бот должен переспрашивать или эскалировать, а не угадывать.»
Описание технической реализации вместо требований
Почему плохо: «Использовать React для фронтенда и FastAPI для бэкенда» – это не требование заказчика, это решение разработчика. Вы платите за результат, а не за конкретный стек.
Как правильно: Описывайте что нужно получить, а не как это делать. Исключение – если у вас есть жёсткие ограничения по стеку (интеграция с существующей инфраструктурой).
50+ страниц без единого примера диалога
Почему плохо: Как в истории с Саматом. Много слов, ноль конкретики. Разработчик не понимает, чего вы хотите, и делает по-своему.
Как правильно: Минимум 10-15 примеров диалогов. Лучше меньше текста и больше примеров, чем наоборот.
Заключение: ТЗ – это инвестиция, а не формальность
Хорошее техническое задание на AI-бота – это не бюрократия. Это инвестиция, которая экономит месяцы переделок, сотни тысяч тенге и нервы всей команды.
Вот ключевые принципы, которые стоит запомнить:
- Конкретика важнее объёма. 12 страниц с примерами лучше 50 страниц общих слов.
- Сценарии – сердце ТЗ. Без них разработчик не понимает, что строить.
- Ограничения важнее возможностей. Что бот НЕ должен делать – критично.
- Метрики снимают субъективность. Без цифр невозможно принять работу.
- Golden set – ваш страховой полис. Эталонные диалоги для тестирования.
История Самата закончилась хорошо. Новое ТЗ на 12 страниц позволило запустить бота за два месяца. Бот закрывает 43% обращений без оператора. Среднее время ответа – 8 секунд вместо 4 минут. CSAT вырос с 3.8 до 4.4.
А те 47 страниц «согласованного документа» так и лежат в архиве. Никто их не открывал с тех пор, как начали работать по-новому.
Готовы написать ТЗ на AI-бота правильно?
Мы помогаем компаниям в Казахстане с полным циклом: от сбора требований до запуска бота. Напишите – обсудим ваш проект и покажем примеры успешных ТЗ.
Читайте также
Шаблон техзадания на LLM-бота
Готовый шаблон ТЗ с разделами и примерами
Интеграция бота с ERP/CRM: 8 ошибок
Как не провалить интеграционную часть проекта
Оценка качества AI-бота: метрики и тесты
Как проверить, что бот работает правильно
Чек-лист запуска AI-бота: 30 пунктов
Что проверить перед выходом в продакшен