ТЗ на автоматизацию процесса: шаблон технического задания и пример

Руководитель говорит: «Нужно автоматически переносить заявки в CRM». Менеджер подразумевает заполненную карточку без дублей, разработчик — передачу полей из формы, а ответственный за продажи ожидает ещё распределение заявок и уведомления. Формулировка одна, результаты — разные.

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

Зачем фиксировать требования до разработки

Сначала разделите три уровня:

• Задача бизнеса: какой результат нужен сотруднику или руководителю. Например, менеджер должен получить заявку с контактом и сутью обращения.
• Техническое решение: как системы передадут и сохранят данные. Его выбирают после проверки доступов, интерфейсов подключения и ограничений.
• Документ договорённостей: что именно входит в работу, как выглядит результат и кто его принимает.

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

Неоднозначность проявляется уже во время разработки. Фраза «создать карточку клиента» не отвечает, что делать с повторной заявкой, пустым телефоном или временно недоступной CRM. Исполнитель закладывает одно поведение, заказчик ожидает другое, и команде приходится возвращаться к уже сделанному этапу. Цена такой неопределённости — дополнительные обсуждения, переделка логики и перенос зависимых работ. Конкретная сумма зависит от состава проекта, поэтому её считают после уточнения требований.

Как собрать требования у участников процесса

Начните с сотрудника, который выполняет операцию сейчас. Попросите показать один обычный случай и один сложный: что приходит на входе, где сотрудник ищет сведения, что проверяет, куда переносит данные и кому передаёт результат. Вопрос «что вы делаете?» часто даёт общее описание; демонстрация выявляет таблицы, переписку, ручные проверки и неформальные правила.

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

Зафиксируйте участников процесса:

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

Нарисуйте текущий путь от события до результата простым списком. Отмечайте ручные переходы и места, где сотрудник принимает решение. Затем разделите требования на три группы: обязательные для первого рабочего сценария, желательные после проверки основы и исключённые из текущего этапа. Пометка «желательно» без приоритета бесполезна: укажите, можно ли принять результат без этой функции.

Что включить в шаблон ТЗ

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

Заполняйте таблицу конкретными наблюдаемыми условиями:

Данные, роли и интеграции

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

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

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

Что входит в работу и что исключено

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

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

Как описать правила, ветвления и исключения

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

Обычный путь и исключения

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

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

Кто принимает спорное решение

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

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

Учебный фрагмент ТЗ для обработки заявки

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

Пример требования

Требование R-01. Если заявка содержит телефон и в CRM нет карточки с тем же нормализованным номером, система создаёт карточку. В карточку она переносит имя, телефон и комментарий без смыслового дополнения. Если телефон отсутствует, карточка не создаётся. Если найдено совпадение, новая карточка не создаётся, а заявка передаётся менеджеру для проверки.

Входной пример:

Ожидаемый результат: при отсутствии совпадения CRM возвращает идентификатор новой карточки; система связывает его с DEMO-104 и записывает успешный статус в журнал. Она не меняет комментарий, не назначает скидку и не удаляет существующие записи.

Проверка приёмки по исходным данным

Трассировка связывает требование с наблюдаемой проверкой:

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

Если нужно настроить подобный маршрут между формой, CRM и уведомлениями, Switch On AI может помочь разобрать процесс, выбрать между обычной интеграцией, ботом и ИИ-агентом и закрепить состав работ. Сравнить направления услуг можно после подготовки исходных примеров.

Как согласовать стоимость, этапы и изменения

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

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

Свяжите этапы с результатами: описание процесса, согласованное ТЗ, прототип ключевого сценария, разработка, приёмка и передача. У Switch On AI бесплатный прототип помогает сверить понимание ключевой операции, но не считается полноценным внедрением. Последовательность проекта описана на странице «Как работаем», а состав оценки — в разборе стоимости.

У ТЗ должна быть версия, дата, владелец и согласующий. Изменения заносите в журнал:

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

Ошибки ТЗ и проверка перед передачей

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

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

Перед передачей исполнителю проверьте ТЗ:

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

Не откладывайте подготовку из-за желания сразу написать идеальный документ. Возьмите одну повторяющуюся операцию, обезличьте обычный и сложный пример и заполните таблицы из статьи. Затем обсудите процесс со Switch On AI: на первом разборе можно уточнить границы, подходящий формат автоматизации и данные, которые понадобятся для оценки. Пароли, ключи и персональные данные для такого обращения не нужны.