Техзадание на автоматизацию: структура и образец

29 июля 2026 · 12 мин чтения

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

Короткий ответ: ТЗ на автоматизацию - это не техническая спецификация, а описание процесса «как есть» и «как надо» плюс критерии приёмки. Технические решения предлагает подрядчик, ваша часть - задача, границы и внятное определение слова «готово». Хорошее ТЗ помещается на 2–4 страницы.

Скажем прямо: этот каркас защищает вас в том числе от нас. С заполненным ТЗ вы возьмёте три предложения, сравните их по одному тексту и выберете не нас - нормальный исход. Размытая постановка выгодна исполнителю, а не заказчику: чем туманнее слово «готово», тем проще сдать половину работы, а остальное назвать доработками за отдельные деньги.

Зачем ТЗ, если можно договориться на словах

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

• Разное понимание готовности. Фраза «заявки не должны теряться» у заказчика и подрядчика раскладывается в разный набор работ. На сдаче выясняется, что половина ожиданий нигде не записана, и спор решает не документ, а тот, кто упрямее.
• Споры о доработках. Без списка «что входит» каждое «а ещё надо» превращается в переговоры о деньгах. Заказчик уверен, что это часть задачи; исполнитель - что это новая работа. Проигрывают оба.
• Невозможно сравнить предложения. Если три подрядчика услышали три разные задачи, их цены и сроки несравнимы. Выбирать приходится по обаянию или по нижней цене, а она часто означает, что человек понял меньше остальных.

Есть и побочная польза: ТЗ дисциплинирует самого заказчика. Часть пунктов из списка «надо автоматизировать» отваливается на попытке описать их шагами - потому что либо процесса нет, либо он делается раз в квартал за десять минут.

Готовая структура ТЗ: десять разделов

Дальше - каркас, который можно скопировать и заполнить своими словами. Пишите на языке процесса, а не техники: хороший признак - ваше ТЗ понимает новый сотрудник, не видевший ваших систем. Ориентир по объёму: 3–10 строк на раздел. Примеры ниже придуманы для наглядности.

1. Контекст и цель

Что писать. Чем занимается компания, какой процесс автоматизируем и по какому показателю поймём, что стало лучше. Цель - в терминах бизнеса, а не программ: не «внедрить бота», а «отвечать на обращения в рабочие часы за полчаса».

Пример. «Продажа и монтаж климатического оборудования, 6 человек. Автоматизируем приём и распределение заявок с сайта и из мессенджеров: сейчас часть обращений остаётся без ответа дольше суток. Цель - первый ответ в рабочие часы не больше 30 минут и один список заявок вместо трёх личных переписок.» Как перевести такую цель в деньги, разобрано в статье про окупаемость автоматизации.

2. Процесс «как есть»: шаги и роли

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

Пример. «1. Клиент оставляет заявку на сайте или пишет в мессенджер. 2. Письмо приходит на общий ящик, сообщения - в личку руководителя. 3. Руководитель пересылает заявку менеджеру голосом или в чат. 4. Менеджер вносит клиента в таблицу вручную, 5–7 минут. 5. Заявки без ответа не отслеживает никто: контроль по памяти. Объём: 60–80 обращений в месяц.»

3. Процесс «как надо»: что меняется

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

Пример. «1. Заявка из любого канала попадает в один список, со временем поступления и статусом. 2. Система назначает ответственного по правилу очереди и пишет ему в чат. 3. Если заявка не взята в работу 30 минут в рабочее время, уведомление уходит руководителю. 4. Данные из формы система заполняет сама, статус меняет менеджер.»

4. Данные и системы: что где лежит и у кого доступы

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

Пример. «Заявки - форма на сайте, доступ у веб-мастера на подряде. Клиенты и сделки - CRM, администратор аккаунта - коммерческий директор. Остатки - учётная программа, выгрузка раз в сутки. Персональные данные: имя, телефон, адрес монтажа.» Что всплывает при стыковке систем, показано в руководстве по интеграции с CRM, а требования к правам - в статье про безопасность автоматизации.

5. Что не входит в объём

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

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

6. Исключения и что делать при сбое

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

Пример. «Если CRM не отвечает, заявка сохраняется в промежуточном хранилище и отправляется повторно с интервалом 5 минут в течение часа; если не удалось - уведомление руководителю с текстом заявки. Повторное обращение с тем же телефоном в течение суток не создаёт новую заявку, а идёт комментарием к существующей.»

7. Критерии приёмки

Что писать. Список проверяемых утверждений: что и как вы будете проверять на сдаче. Каждый пункт - действие, измеримое условие и поведение при отклонении. Формулировки разобраны в следующем разделе, здесь важно правило: пункт, который нельзя проверить за один заход на тестовых данных, критерием не является.

Пример. «Тестовая заявка с сайта появляется в списке не позже 60 секунд; уведомление приходит назначенному менеджеру; при отключённой CRM заявка сохраняется и уходит повторно после восстановления связи.»

8. Кто владелец процесса и кто принимает работу

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

Пример. «Владелец процесса - коммерческий директор, он же принимает работу. Вопросы - в общем чате проекта, ответ в течение одного рабочего дня. Доступы к системам выдаёт системный администратор.»

9. Сроки и этапы

Что писать. Не одну дату сдачи, а этапы с осязаемым результатом на каждом. Узкий сценарий обычно занимает 2–4 недели, контур из нескольких сценариев собирают поэтапно и считают месяцами. Обозначьте свои ограничения: сезон, отчётный период, отпуска. И срок приёмки - иначе работа висит «почти сданной».

Пример. «Этап 1 - приём заявок в один список и уведомления, 2 недели. Этап 2 - распределение по правилу и контроль просрочки, 1–2 недели. Приёмка этапа - 3 рабочих дня после демонстрации. С 20 декабря по 10 января работы не ведутся: сезон.»

10. Эксплуатация: кто поддерживает и что при изменениях

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

Пример. «Решение размещается на нашем сервере, аккаунты сервисов оформлены на нашу почту. Сбои устраняются в течение одного рабочего дня. Изменение правил распределения - новая задача с отдельной оценкой. При сдаче передаются доступы, схема сценария и инструкция на одну страницу.» Как выглядит наведённый порядок с правами, видно в кейсе выдачи доступов новым сотрудникам.

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

Критерии приёмки: как формулировать

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

Проверка формулировки простая: дайте критерий человеку со стороны и спросите, как он будет это проверять. Придумает способ и получит однозначное «да» или «нет» - критерий годный. Начнёт уточнять, что значит «быстро», - переписывайте. Как измеримый срок ответа выглядит в работе, видно в кейсе контроля срока ответа по заявкам.

Про количество: на сценарий обычно хватает 5–12 критериев. Больше двадцати - признак того, что в список попали пожелания. И держите в критериях исключения из шестого раздела: сдача на идеальных данных ничего не доказывает.

Типичные ошибки в ТЗ

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

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

Что делать, если не знаете, как описать процесс

Нормальная ситуация: процесс живёт в головах, и на вопрос «как у вас принимают заявки» три сотрудника дают три ответа. Это не мешает написать ТЗ, просто добавляет одну неделю подготовки.

1. Неделя наблюдения. Таблица из пяти столбцов: дата, что произошло, кто сделал, сколько заняло, что помешало. Заполняют исполнители по ходу дела, без анализа. Через неделю у вас факты вместо представлений о них.
2. Разговор с исполнителями. Отдельно спросите каждого, что он делает руками и что бесит больше всего. Самые дорогие шаги обычно называют не руководители.
3. Карта процесса. Соберите наблюдения в линейную схему: шаг, кто, вход, выход. Достаточно листа бумаги. Приёмы описания разобраны в статье про карту бизнес-процессов.
4. Проверка на трёх реальных случаях. Прогоните по карте три последних обращения, включая одно проблемное. Тут и находятся исключения, которых нет в инструкциях.

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

ТЗ помогает сравнить подрядчиков

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

• Вопросы. Кто спросил про исключения, данные и доступы - тот читал. Кто ответил «всё понятно, делаем» - скорее всего, нет, и уточнять будет в процессе, за ваш срок.
• Разброс оценок. При одном тексте оценки нередко расходятся в разы. Это не жадность: обычно кто-то заложил другой объём. Попросите разбивку по этапам, и станет видно, кто что имел в виду.
• Свой список границ. Хороший ответ содержит собственный раздел «не входит», иногда более подробный, чем ваш. Это признак опыта, а не попытки уклониться.
• Отношение к критериям. Исполнитель, который сам предлагает измеримые формулировки, экономит вам приёмку. Тот, кто просит убрать конкретные цифры, экономит её себе.

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

Мини-кейс: две компании, одна задача

Задача одинаковая: собрать заявки с сайта и из двух мессенджеров в один список, распределять по менеджерам, напоминать о заявках без ответа. Компании похожего размера, около десяти человек.

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

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

Разница не в квалификации исполнителей и не в сложности - задачи однотипные. Разница в том, что в первом случае слово «готово» было записано до начала работ. Это опыт двух проектов: у вас сроки и число раундов будут другими, но природа задержек повторяется.

Итог

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

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

Техническое задание работает только тогда, когда оно приложение к договору, а не отдельный файл. Как это оформить и что ещё проверить перед подписанием - в чек-листе по договору.

Отдельная строка в задании - состояние данных: справочники, дубли и форматы полей, на которые смотрит сценарий. Что проверить заранее - в статье про порядок в данных перед автоматизацией.

Не готовы обсуждать проект? Оцените выгоду сами: калькулятор ROI автоматизации - 1 минута, без контактов. Или заберите чек-лист «Что автоматизировать первым».