Самат прислал мне документ на 47 страниц. Называлось это «Техническое задание на разработку интеллектуального чат-бота с элементами искусственного интеллекта для автоматизации клиентского сервиса».
Я открыл файл и через пятнадцать минут закрыл. Не потому что там было что-то плохое — там не было почти ничего полезного. Сорок семь страниц общих слов, красивых диаграмм, описания того, как «бот должен быть умным и понимать клиентов». И ни одного конкретного сценария, ни одной метрики успеха, ни одного ограничения.
«Мы полгода это согласовывали, — сказал Самат. — Юристы смотрели, безопасники визировали, директор подписал. А подрядчик говорит, что по этому ТЗ работать невозможно.»
Самат руководит клиентским сервисом в крупной логистической компании в Астане. 200 операторов, 15 000 обращений в день. Идея автоматизировать часть работы ботом — разумная. Но документ, который они написали, был бесполезен. Хуже того — он создавал иллюзию, что работа сделана.
Через три месяца мы переписали ТЗ заново. Получилось 12 страниц. Бот заработал ещё через два. И в этой статье я покажу, как написать техническое задание на AI-бота так, чтобы оно реально работало — а не пылилось в папке «согласовано».
«Хорошее ТЗ — это не документ для юристов. Это контракт между бизнесом и технологией: что именно мы автоматизируем, как измеряем успех и когда понимаем, что пора остановиться.»
Принцип продуктовой разработки
Адаптировано для AI-проектов
Почему традиционные ТЗ не работают для AI-ботов
Прежде чем разбирать, как писать правильно, давайте поймём, что обычно идёт не так. Потому что большинство неудачных проектов с ботами начинаются именно с плохого технического задания.
Классическое ТЗ на разработку ПО описывает функции. «Система должна позволять пользователю...», «При нажатии кнопки система отображает...». Это работает для детерминированного софта, где результат предсказуем: нажал — получил.
С AI-ботом всё иначе. Бот — это не программа с кнопками. Это агент, который ведёт диалог. И диалог этот каждый раз разный. Клиент может спросить одно и то же десятью способами. Может задать вопрос, которого вы не предусмотрели. Может вести себя агрессивно или, наоборот, слишком молчаливо.
Попытка описать бота как набор функций — это как пытаться написать инструкцию для живого сотрудника в формате «нажмите 1 — скажите фразу А, нажмите 2 — скажите фразу Б». Не работает.
Пять признаков бесполезного ТЗ на AI-бота
«Бот должен быть умным»
Нет критериев «умности». Что значит «умный»? Понимает сленг? Шутит? Решает уравнения? Без конкретики это пустые слова.
«Понимать естественный язык»
Естественный язык — это и «где мой заказ?», и сонет Шекспира. Какие именно формулировки должен понимать бот?
«Интеграция с существующими системами»
С какими? По какому API? Какие данные читаем, какие пишем? Без деталей — это не требование, а пожелание.
«Высокий уровень удовлетворённости»
Какой конкретно? 70% CSAT? 90%? Как будем измерять? Если нет цифры — нет способа проверить.
Нет примеров диалогов
Ни одного конкретного сценария «клиент говорит X — бот отвечает Y». Как разработчику понять, чего вы хотите?
Если в вашем ТЗ есть хотя бы два пункта из списка выше — документ нужно переписывать. Не редактировать, а именно переписывать с нуля, используя другой подход.
Какой? Сейчас расскажу.
Структура ТЗ на AI-бота: 7 обязательных разделов
За годы работы с разными компаниями — от стартапов до банков — мы выработали структуру, которая работает. Она не идеальна (идеального ТЗ не существует), но позволяет избежать большинства проблем.
Вот семь разделов, которые должны быть в любом техническом задании на AI-бота. Порядок важен — каждый следующий раздел опирается на предыдущий.
Бизнес-контекст и цели
Зачем нужен бот? Какую проблему решаем? Какие метрики хотим улучшить? Как поймём, что проект успешен?
Сценарии использования
Конкретные диалоги: кто спрашивает, что спрашивает, что бот должен ответить или сделать. С примерами.
База знаний и источники данных
Откуда бот берёт информацию? Прайс-листы, FAQ, документация, CRM. Кто отвечает за актуальность?
Интеграции и API
С какими системами взаимодействует бот? Какие операции выполняет? Какие данные читает и пишет?
Нефункциональные требования
SLA, допустимая задержка ответа, пиковые нагрузки, время работы, требования к uptime.
Безопасность и compliance
Какие данные обрабатываем? Где храним? Кто имеет доступ? Соответствие 152-ФЗ, GDPR, внутренним политикам.
Критерии приёмки и метрики успеха
Как проверяем, что бот работает правильно? Какие показатели считаем успехом? Что является провалом?
Обратите внимание: функциональных требований в классическом понимании здесь нет. Потому что для 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
- Если заказ найден — сформировать ответ по шаблону
- Если не найден — предложить проверить номер или связать с оператором
Шаблон ответа (успех)
📍 Текущее местоположение: {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
Для каждой интеграции важно также указать: что делать, если 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. Вопросы вне этих сценариев — эскалация на оператора с пометкой "вопрос вне компетенции".»
Как правильно: Укажите конкретные требования (latency, стоимость токена, локализация данных), а выбор модели оставьте подрядчику с обоснованием.
Как правильно: «Допустимый уровень ошибок — не более 5% на golden set. При любой неуверенности бот должен переспрашивать или эскалировать, а не угадывать.»
Как правильно: Описывайте что нужно получить, а не как это делать. Исключение — если у вас есть жёсткие ограничения по стеку (интеграция с существующей инфраструктурой).
Как правильно: Минимум 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 пунктов
Что проверить перед выходом в продакшен