ТЗ на ИИ-бота: какие данные нужны разработчику

В итоге смета получается примерной, сроки расплываются, а проект превращается в разведку боем. Иногда разведка возвращается. Иногда нет.

ТЗ на ИИ-бота нужно не для бюрократии. Оно помогает заранее договориться о задаче, сценариях, базе знаний, интеграциях, ограничениях и критериях качества. Чем понятнее входные данные, тем точнее разработчик оценит работу и тем меньше сюрпризов появится после запуска.

ИИ-бот без ТЗ — это не быстрый старт, а разработка вслепую

ИИ-бот не работает в пустоте. Он отвечает пользователю, задаёт вопросы, ищет информацию, передаёт данные в CRM, подключает менеджера, использует документы компании и соблюдает ограничения.

Если всё это не описать до старта, разработчик будет выяснять детали уже в процессе. А это почти всегда приводит к лишним созвонам, переделкам и спорным ожиданиям.

Бизнес думает: «Мы просто хотим, чтобы бот отвечал клиентам».

Разработчик слышит: «Нужно спроектировать сценарии общения, подготовить базу знаний, настроить ограничения, продумать интеграции, передачу заявок, логи, тестирование и поддержку».

Обе стороны вроде говорят об одном и том же. Но в голове у них два разных проекта.

Что не является ТЗ на ИИ-бота

«Нужен бот как у конкурентов» — не ТЗ.

«Чтобы отвечал клиентам» — не ТЗ.

«Чтобы был умный и сам всё понимал» — не ТЗ.

«Вот сайт, пусть по нему отвечает» — уже ближе, но всё ещё не полноценное ТЗ.

«Нужно что-нибудь на базе ChatGPT» — тоже не ТЗ. Модель — это не проект. Это только один из инструментов. Так же как дрель не равна ремонту квартиры. Хотя шуму иногда примерно столько же.

Нормальное ТЗ объясняет, какую задачу решает бот, с кем он общается, какие сценарии поддерживает, откуда берёт данные, куда передаёт результат и в каких ситуациях не должен отвечать самостоятельно.

ТЗ на ИИ-бота — это не промпт

Промпт важен, но он не заменяет ТЗ.

Промпт описывает, как бот должен отвечать: каким тоном, в какой роли, с какими правилами и ограничениями. ТЗ описывает более широкий контур: зачем бот нужен бизнесу, кто им пользуется, какие данные он использует, с какими системами связан, какие сценарии поддерживает и где заканчиваются его полномочия.

Если упростить: промпт — это инструкция для поведения бота. ТЗ — это постановка задачи для всего решения.

Поэтому фраза «напишите хороший промпт» не решает проблему. Можно написать прекрасный промпт для бота, который не знает актуальных цен, не понимает бизнес-процесс, не передаёт заявки в CRM и уверенно отвечает там, где должен позвать менеджера.

Такой бот будет звучать умно. Польза — по настроению.

Начните с задачи: что должен изменить бот в бизнесе

Первый вопрос не технический.

Не «какую модель использовать?».
Не «можно ли подключить ИИ к сайту?».
Не «сколько стоит бот?».

Первый вопрос: какую проблему должен решить бот.

ИИ-бот может снижать нагрузку на поддержку, собирать заявки, консультировать по услугам, помогать менеджерам искать информацию, отвечать по базе знаний, подбирать товар или проверять статус заказа.

Но «сделать ИИ-бота» — это не задача. Это способ. Задача должна быть привязана к бизнес-процессу.

Плохо: «Бот должен консультировать клиентов».

Лучше: «Бот должен определить, какая услуга нужна клиенту, задать уточняющие вопросы, собрать имя и телефон, передать заявку в CRM и уведомить менеджера».

В первом случае непонятно почти ничего. Во втором уже видны сценарий, данные, интеграция и результат.

Ещё пример.

Плохо: «Нужен внутренний AI-ассистент для сотрудников».

Лучше: «Ассистент должен отвечать менеджерам по внутренним регламентам, находить инструкции, подсказывать порядок обработки заявки и ссылаться на актуальный документ».

Так разработчик понимает, что нужен не просто чат, а система с базой знаний, ролями доступа и проверкой источников.

Хорошая постановка задачи отвечает на несколько вопросов: что сейчас делается вручную, где сотрудники или клиенты теряют время, какие вопросы повторяются чаще всего, какой результат должен появиться после общения с ботом и что будет считаться успешным запуском.

Результат лучше описывать не общими словами, а через наблюдаемые изменения. Например: снизить число типовых обращений к менеджерам, увеличить долю заявок с заполненными контактами, ускорить первичную квалификацию клиента, сократить время поиска информации сотрудниками.

Если результат нельзя описать словами, его потом сложно проверить. Бот вроде есть, диалоги идут, интерфейс красивый. А пользы нет. Это не автоматизация, это цифровой сувенир.

Опишите, кто будет пользоваться ботом и где он будет работать

ИИ-бот для клиентов и внутренний ассистент для сотрудников — это разные продукты.

Клиентский бот работает наружу. Он отвечает посетителям сайта, помогает выбрать услугу, объясняет условия, собирает заявку, передаёт сложный вопрос менеджеру. Здесь важны понятный язык, аккуратные формулировки, сбор контактов, ограничения по обещаниям и корректная передача диалога человеку.

Внутренний ассистент работает внутри компании. Он помогает сотрудникам искать информацию в регламентах, документах, базе знаний, CRM или внутренних инструкциях. Здесь важны права доступа, актуальность документов, ссылки на источники и контроль того, какие данные можно показывать конкретному сотруднику.

Снаружи оба варианта могут выглядеть одинаково: пользователь пишет вопрос, бот отвечает. Но внутри у них разные данные, риски и логика.

Поэтому в ТЗ важно указать, для кого делается бот: для внешних пользователей, сотрудников, партнёров или администраторов. Клиентский сценарий обычно связан с консультациями и заявками, внутренний — с документами и процессами, партнёрский — с отдельными правами доступа и ограничениями.

После этого нужно описать, где бот будет работать: на сайте, в Telegram, WhatsApp, email, CRM, личном кабинете, мобильном приложении или корпоративном портале.

Канал запуска влияет не только на внешний вид. Он влияет на сценарии, хранение истории, авторизацию, передачу данных, уведомления и поддержку.

Бот на сайте чаще всего работает с анонимным посетителем и должен сначала собрать контакт. Бот в личном кабинете может знать пользователя и работать с его заказами. Бот в CRM может помогать менеджеру, а не клиенту. Бот в Telegram удобен для быстрых уведомлений, но потребует отдельной логики авторизации и доступа.

Если этот пункт не описать заранее, разработчик не сможет точно оценить работу. Бот «на сайт» и бот «на сайт, в Telegram и с передачей заявок в CRM» — это не одно и то же. Даже если в обоих случаях слово «бот» звучит одинаково.

Опишите сценарии: что бот должен делать в диалоге

Сценарии — центральная часть ТЗ.

Именно они показывают, что бот должен делать в диалоге: отвечать, уточнять, подбирать, собирать данные, передавать заявку, отказывать, подключать менеджера или искать информацию в базе знаний.

Начать лучше с реальных вопросов пользователей. Не надо придумывать идеальные формулировки из головы. Живые люди редко пишут как в презентации: спрашивают коротко, неполно и с ошибками. Именно на таких вопросах бот и должен работать.

Лучшие источники сценариев — уже существующие точки общения с клиентами: переписки менеджеров, чаты поддержки, звонки, заявки с сайта, CRM, комментарии, FAQ и типовые возражения. Там лежат не красивые, а настоящие вопросы.

Например, для бота на сайте сценарий может выглядеть так: пользователь спрашивает об услуге, бот уточняет задачу, предлагает подходящий вариант, объясняет условия, собирает контакт, передаёт заявку менеджеру и сообщает, что специалист свяжется с клиентом.

Если бот собирает заявку, нужно заранее определить поля. Бизнесу может понадобиться имя, телефон, email, компания, город, задача, бюджет, сроки, параметры заказа, комментарий или удобный способ связи.

Если эти поля не указать, бот может собрать неполную заявку. Например, оставит только имя и вопрос без телефона. Формально диалог был. Практически менеджер получил загадку.

Если бот должен подбирать услугу, товар или решение, нужны критерии подбора: цель клиента, бюджет, сроки, регион, объём работ, тип продукта, ограничения, приоритеты и уровень подготовки клиента.

Без критериев подбор превращается в угадайку. ИИ может угадывать очень уверенно. Но уверенность — не доказательство.

Отдельно нужно описать нестандартные ситуации. Что делать, если клиент жалуется, просит скидку, задаёт юридический вопрос, хочет нестандартные условия, пишет агрессивно, даёт слишком мало данных или спрашивает не по теме компании?

Хорошее ТЗ описывает не только нормальный маршрут, где пользователь вежлив, данные полные, CRM открыта, солнце светит. Оно описывает и места, где сценарий может сломаться. Потому что именно там бот чаще всего показывает, насколько он продуман.

Соберите данные и документы для базы знаний

ИИ-бот отвечает не «из воздуха». По крайней мере, не должен.

Если бот должен отвечать по компании, ему нужны источники: сайт, FAQ, описания услуг, регламенты, документы, прайсы, инструкции, база знаний, коммерческие предложения, шаблоны ответов.

Для старта обычно берут страницы сайта, FAQ, описания услуг, коммерческие предложения, прайсы, инструкции менеджеров, регламенты поддержки и шаблоны сообщений. Но перед использованием эти материалы нужно проверить: что устарело, где есть противоречия, какие данные можно показывать клиентам, а какие должны остаться внутри компании.

Проблема в том, что материалы часто писались в разное время, разными людьми и для разных задач. На сайте одно, в презентации другое, в старом прайсе третье, менеджер в чате объясняет четвёртое.

Для человека это неудобно. Для ИИ-бота это опасно. Он может взять устаревший или противоречивый источник и уверенно выдать неправильный ответ.

Опасные данные для ИИ-бота

Особенно аккуратно нужно работать с ценами, сроками, скидками, гарантиями, условиями договора, персональными данными, статусами заказов, внутренними регламентами, юридическими формулировками, медицинскими и финансовыми рекомендациями.

Если бот отвечает про цены, сроки или условия, эти данные должны быть актуальными и структурированными. Ошибка в общей фразе неприятна. Ошибка в цене может стоить денег.

Для внутреннего ассистента нужны другие материалы: инструкции, регламенты, порядок обработки заявок, правила общения с клиентами, база знаний для сотрудников, описания процессов, шаблоны ответов. Но важно помнить: ИИ-бот не создаёт порядок из хаоса. Он использует то, что вы ему дали. Если в документах бардак, бот не станет мудрым архивариусом. Он просто начнёт использовать бардак быстрее.

Поэтому перед стартом важно понять, какие документы можно использовать, какие устарели, где есть противоречия, какие данные нельзя показывать клиентам, кто отвечает за актуальность базы знаний и как часто она будет обновляться.

База знаний — это не «загрузили и забыли». У компании меняются цены, услуги, процессы, акции, правила, сотрудники, юридические формулировки. Если база не обновляется, бот постепенно начинает жить в прошлом. Иногда очень убедительно.

Укажите интеграции: куда бот передаёт и откуда получает данные

ИИ-бот редко нужен сам по себе.

Если он просто отвечает на вопросы, это уже полезно. Но в бизнесе обычно нужно больше: собрать заявку, передать данные менеджеру, создать лид в CRM, проверить статус заказа, отправить уведомление, записать диалог, показать аналитику.

Поэтому в ТЗ нужно указать, с какими системами бот должен работать.

Самая частая интеграция — CRM. Если бот собирает лиды, нужно описать, какие поля он заполняет, на какой этап воронки попадает заявка, кто становится ответственным, какой источник указывается, как менеджер получает уведомление и нужно ли сохранять историю диалога.

Без этого бот может собрать контакт, но дальше заявка потеряется. А потерянный лид — это уже не проблема ИИ. Это классика жанра.

Если бот работает на сайте, нужно указать, какие данные он получает и куда передаёт результат: в форму обратной связи, карточку товара, корзину, личный кабинет, историю заказов, статус заявки или профиль пользователя.

Если бот работает в мессенджере, нужно описать канал и маршрут сообщения. Telegram, WhatsApp, email и другие инструменты отличаются не только интерфейсом. У них разные ограничения, разные способы авторизации, разные сценарии передачи диалога менеджеру и разные варианты хранения истории.

Аналитику тоже лучше продумать заранее. Минимально стоит отслеживать количество диалогов, количество заявок, популярные вопросы, вопросы без ответа, передачи менеджеру и повторяющиеся ошибки. Без логов бот становится чёрным ящиком. Вроде работает. Вроде отвечает. Вроде кто-то доволен. Отличная система управления, если вы капитан пиратского корабля.

Для удобства входные данные можно собрать в таблицу.

Эта таблица не заменяет полноценное ТЗ, но помогает быстро увидеть, где данных хватает, а где пока пусто.

Пропишите ограничения и правила передачи человеку

Хороший ИИ-бот должен не только отвечать. Он должен понимать, где отвечать нельзя.

Это особенно важно для тем, где ошибка может привести к деньгам, конфликту или юридическим последствиям.

Бот не должен:

• обещать точные сроки и цены без проверки;
• назначать индивидуальные скидки и нестандартные условия;
• давать юридические, медицинские или финансовые советы;
• подтверждать возврат денег, изменение договора или наличие товара без доступа к системе;
• раскрывать персональные, внутренние или партнёрские данные.

Если бот не знает ответа, он не должен фантазировать. Лучше честно уточнить данные, сослаться на ограничение или передать вопрос человеку.

Отдельно нужно описать данные, которые бот не имеет права раскрывать: внутренние регламенты, персональные данные клиентов, коммерческие условия партнёров, закрытые инструкции, данные из CRM без авторизации, информацию о других заказах и служебные комментарии менеджеров.

Для внутреннего ассистента это особенно важно. Сотрудники могут иметь разные роли и права. То, что доступно руководителю, не всегда должно быть доступно стажёру. ИИ-боту нужно объяснить эти границы не после инцидента, а до запуска.

Правила передачи человеку тоже нужно прописать заранее.

Не «если что-то сложное — пусть зовёт менеджера». Это слишком туманно.

Нужно определить, какие ситуации передаются человеку, кому именно они передаются, какие данные бот прикладывает, где фиксируется обращение, как менеджер видит историю диалога, что получает пользователь после передачи и кто обновляет базу знаний, если вопрос повторяется.

Схема может быть простой:

Вопрос пользователя → уточнение данных → ограничение → передача менеджеру → история диалога → ответ → обновление базы знаний

Нормальная эскалация — это не «позовите кого-нибудь». Это понятный маршрут. Иначе пользователь останется в подвешенном состоянии, менеджер получит обрывок фразы, а компания снова будет делать вид, что автоматизация почти работает.

Назначьте ответственного со стороны бизнеса

Для разработки ИИ-бота нужен не только разработчик.

Нужен человек со стороны бизнеса, который понимает задачу и может принимать решения.

Он должен отвечать на вопросы, давать материалы, согласовывать сценарии, проверять ответы, подтверждать спорные формулировки и принимать тестовую версию.

Если ответственного нет, проект начинает зависать на каждом спорном моменте.

Разработчик спрашивает: «Можно ли боту обещать срок до 5 дней?»

Один менеджер говорит: «Можно».

Другой говорит: «Нельзя».

Руководитель в отпуске.

Маркетолог предлагает написать «обычно быстро».

Бот ждёт. Разработчик ждёт. Сроки идут. Красота.

Ответственный со стороны бизнеса подтверждает цель бота, собирает материалы, проверяет актуальность данных, согласует сценарии, уточняет спорные вопросы, принимает тестовые ответы и решает, какие темы нужно передавать человеку.

Это не обязательно должен быть технический специалист. Важнее, чтобы человек понимал бизнес-процесс и имел право принимать решения.

Если такого человека нет, проект может технически двигаться, но содержательно стоять на месте. Код пишется, интерфейс собирается, интеграция подключается, а правильного ответа на вопрос «что бот должен сказать клиенту в спорной ситуации?» всё ещё нет.

Что влияет на сроки и стоимость разработки

Разработчик не может точно оценить ИИ-бота по одной фразе «нужен бот на сайт».

На сроки и стоимость влияет не само слово «бот», а состав проекта.

Хорошее ТЗ не всегда делает проект дешёвым. Но оно делает оценку честнее.

Без ТЗ разработчик либо закладывает большой запас на неизвестность, либо называет красивую низкую цену, а потом выясняется, что «ещё нужна CRM, Telegram, статусы заказов, личный кабинет и чтобы всё само обновлялось».

Так рождаются конфликты. Причём без участия ИИ. Люди пока прекрасно справляются сами.

Чек-лист: что отправить разработчику перед стартом

Перед разговором с разработчиком не обязательно готовить документ на 40 страниц. Но стоит собрать базовую информацию.

• 1. Задача и аудитория
  Опишите, зачем нужен бот, какую проблему он должен решить, кто будет им пользоваться и где он будет работать: на сайте, в мессенджере, CRM, личном кабинете или внутри компании.
• 2. Сценарии
  Соберите основные сценарии общения, типовые вопросы пользователей, действия бота в диалоге, поля заявки и нестандартные ситуации, где обычный маршрут может сломаться.
• 3. Данные
  Подготовьте материалы для базы знаний: страницы сайта, FAQ, описания услуг, прайсы, условия, регламенты, инструкции, шаблоны ответов. Отдельно отметьте документы, которые устарели или требуют проверки.
• 4. Интеграции
  Укажите, нужна ли CRM, какие поля должна заполнять заявка, нужно ли сохранять историю диалогов, какие уведомления должны получать менеджеры и должен ли бот работать с сайтом, личным кабинетом, заказами или другими системами.
• 5. Ограничения
  Опишите, что бот не должен обещать, какие данные не должен раскрывать, в каких случаях обязан уточнять информацию и когда должен передавать вопрос человеку.
• 6. Проверка качества
  Подготовьте тестовые вопросы, примеры правильных ответов и красные зоны: жалобы, спорные вопросы, неполные данные, запросы на скидки, юридические темы и ситуации вне компетенции бота.
• 7. Ответственный и результат
  Назначьте человека со стороны бизнеса, который будет отвечать на вопросы разработчика, согласовывать сценарии, проверять ответы и принимать результат. Отдельно опишите, что должно измениться после запуска бота.

Этот чек-лист уже помогает разработчику быстрее понять объём работы. А бизнесу — увидеть, где пока нет ясности.

Если на половину вопросов нет ответа, это не катастрофа. Это нормальная точка старта для предпроектного разбора.