«Бот должен собирать заявки» каждый понимает по-своему.
Без полей, правил и результата одна и та же фраза описывает несколько разных проектов. ТЗ нужно для согласования поведения продукта, а не для объёма документа.
Начните с результата и границ
Опишите, кто пользуется ботом, какое действие завершает и что меняется в бизнесе. Затем перечислите то, что входит в первую версию. Неизвестные параметры вынесите в открытые вопросы с ответственным за решение.
Каждый сценарий имеет вход и выход
Для заявки укажите начало диалога, вопросы, проверку введённых данных и следующий шаг. Опишите возможность исправить ответ, прекратить процесс и обратиться к человеку. Выходом может быть подтверждённая запись в CRM, а не просто экран «спасибо».
Демонстрационный пример требования
Пользователь выбирает тему обращения, оставляет контакт и подтверждает отправку. Система сохраняет заявку и передаёт согласованные поля в CRM. Повторная отправка одного события не создаёт вторую заявку. Если CRM недоступна, событие получает статус ожидания, а ответственный видит ошибку. Это пример поведения, не описание клиентского внедрения.
Данные и интеграции описываются отдельно
Для каждого поля задайте смысл, обязательность и допустимые значения. Для системы — объект, доступное действие, способ авторизации и подтверждение результата. Секреты, пароли и персональные данные реальных клиентов не включаются в публичный образец.
Приёмка превращает текст в проверку
Запишите сценарии: корректное обращение, пустой контакт, возврат к предыдущему шагу, двойное подтверждение и недоступная CRM. Для каждого укажите ожидаемый результат. Затем согласуйте передаваемые доступы, документацию и порядок изменения требований.
Применим эти принципы к вашему продукту.
