«Сделайте красиво и чтобы всё работало» - так начинается половина проектов автоматизации. Через два месяца выясняется: подрядчик сделал то, что понял, а не то, что нужно бизнесу. Споры про «это не входило в объём работ», переделки, срыв сроков.
ТЗ на автоматизацию - не формальность для договора. Это договорённость о результате: какие данные, как часто, кто видит, когда считаем проект принятым. Ниже - 12 пунктов, которые закрывают 80% конфликтов ещё до старта. Пройдите по своему черновику или допишите то, чего не хватает.
Перед цифрами полезно прикинуть ROI автоматизации - так проще отделить «хочется» от «окупается». О типичных ошибках при постановке задачи на дашборд - в «7 ошибок при заказе дашборда».
1. Цель в одном предложении и 2-3 KPI успеха
«Автоматизировать отчётность» - не цель. Цель: «владелец видит выручку и маржу по каналам до 10:00 без участия аналитика» или «менеджеры не тратят более 15 минут в день на перенос заявок между системами».
Как проверить: прочитайте цель человеку из другого отдела. Он называет, какую цифру или действие изменится через месяц после запуска.
Что сделать: зафиксируйте KPI успеха проекта: время на отчёт, частота ошибок, доля сделок с заполненной карточкой - что измеримо у вас сейчас.
2. Источники данных: система, владелец, формат
Список «CRM, 1С, Excel» недостаточен. Нужно: какая CRM, какая версия, кто выдаёт API-ключ, есть ли тестовый контур, куда падают выгрузки, если API недоступен.
Как проверить: для каждого источника есть контакт ответственного и дата, когда подрядчик получил тестовый доступ (не «обещали на следующей неделе»).
Что сделать: таблица источников - система, ответственный, способ доступа (API, автоуведомление, безопасная передача файлов, ручная выгрузка на старте), частота обновления в источнике.
3. Словарь полей и сущностей
«Сделка», «заказ» и «оплата» в разных системах - разные сущности. Без словаря подрядчик сопоставит поля наугад, а вы узнаете об этом на приёмке.
Как проверить: есть документ «поле X в CRM = поле Y в отчёте = формула Z» для всех KPI из п.1.
Что сделать: выпишите 10-20 ключевых полей: ID сделки, сумма, статус, дата оплаты, канал, менеджер. Укажите допустимые значения статусов и что делать с пустыми.
4. Срок обновления данных
«В реальном времени» для финансового дашборда часто избыточно и дорого. Для операционки - критично. Зафиксируйте: как часто данные должны обновляться и максимальная задержка (например, «не старше 1 часа для воронки, не старше суток для маржи»).
Как проверить: в ТЗ есть цифры в минутах/часах, не формулировки «быстро» и «актуально».
Что сделать: разделите метрики на «операционные» (час) и «управленческие» (сутки). Опишите, что показывать, если цепочка загрузки данных упала.
5. Роли и права доступа
Кто видит выручку целиком, кто - только свою воронку, кто - без зарплатных полей. Это не «настроим потом»: ошибка в правах = утечка или недоверие к системе.
Как проверить: список ролей (владелец, РОП, менеджер, бухгалтер) и матрица «роль × экран/метрика».
Что сделать: минимум три роли с явными ограничениями. Отдельно - гостевой доступ для аудита или инвестора, если нужен.
6. Сценарии автоматизации: условие → действие
Для каждого процесса: когда срабатывает, что делает, куда пишет результат. Пример: «новая заявка с сайта → создание сделки в CRM → уведомление в Telegram ответственному → запись в журнал».
Как проверить: не менее трёх сценариев описаны по шаблону условие-действие-результат, включая негативный (ошибка API).
Что сделать: нарисуйте 3 главных потока от заявки до цифры на дашборде. Подрядчик должен подтвердить каждый стрелкой в своей схеме.
7. Исключения и ручные кейсы
Не всё автоматизируется с первого дня: возвраты, split-платежи, сделки без источника, дубли контактов. Если не описать - их «проглотит» система или отчёт поедет.
Как проверить: есть раздел «что делаем, если…» минимум для пяти частых исключений из вашей практики.
Что сделать: соберите у операционки список «каждую неделю правим руками вот это» - это кандидаты в исключения или отдельные правила.
8. Критерии приёмки
Самый недооценённый пункт. «Работает» - не критерий. Нужно: «за тестовую неделю расхождение выручки дашборда и CRM не более 0,5%», «100% заявок с формы попадают в CRM за 5 минут», «алерт приходит при превышении порога X».
Как проверить: у каждого KPI из п.1 есть числовой критерий приёмки и способ проверки (скрин, выгрузка, сверка с эталоном).
Что сделать: оформите чек-лист приёмки на одну страницу - подрядчик подписывает до старта разработки.
9. Формат выхода: дашборд, отчёт, алерт
Где пользователь видит результат: веб-дашборд, PDF по расписанию, сообщение в Telegram, запись в Google Sheets. Для каждого - макет или референс (можно скетч), список виджетов, мобильная версия да/нет.
Как проверить: приложен эскиз экрана или ссылка на референс + перечень KPI на первом экране (не больше 5).
Что сделать: один «экран для руководителя» и один «операционный» - не смешивайте в одном ТЗ без приоритета.
10. Интеграции: лимиты, версии API, запасной вариант
У CRM и маркетплейса есть лимиты запросов, устаревшие методы, платные тарифы для автоуведомлений. Укажите допустимые посредники (no-code сервисы или свой сервер) и кто платит за лицензии.
Как проверить: для каждой интеграции указана версия API и запасной план при недоступности (очередь, повтор, ручная догрузка).
Что сделать: попросите подрядчика перечислить внешние зависимости и ежемесячную стоимость инфраструктуры отдельной строкой.
11. Этапы, сроки, бюджет по фазам
Разбейте проект: прототип на реальных данных (1-2 недели), первая рабочая версия (4-6 недель), доработки. К каждой фазе - результат этапа и оплата. Иначе «почти готово» тянется месяцами.
Как проверить: в календаре есть дата первого рабочего результата, который бизнес уже использует (не «показали на созвоне»).
Что сделать: привяжите оплату к приёмке фазы по критериям из п.8, не к «проценту готовности».
12. Поддержка после запуска
Кто чинит, если упал API? Кто добавляет новое поле? Срок реакции на инциденты (4 часа / 1 рабочий день). Передача документации и доступов - часть приёмки, не «бонус».
Как проверить: в договоре или приложении есть контакт, регламент тикетов и стоимость часа доработок после гарантийного периода.
Что сделать: заложите 10-15% бюджета на первый месяц «привыкания» - правки порогов, новые фильтры, обучение команды.
Красные флаги в ТЗ и ответах подрядчика
- Нет доступа к данным до подписания - «сначала дизайн».
- Отказ фиксировать критерии приёмки: «посмотрим на результат».
- Один огромный этап без промежуточной сдачи.
- «Любая CRM / любая система отчётов» без привязки к вашим системам.
- Нет упоминания мониторинга и алертов при падении цепочки загрузки данных.
- Объём работ «и дашборд, и CRM, и сайт» в одном фикс-прайсе без приоритетов.
С чего начать на этой неделе
- Сформулируйте цель одним предложением и 2 KPI (п.1).
- Заполните таблицу источников с именами ответственных (п.2).
- Напишите 5 критериев приёмки с цифрами (п.8).
- Отправьте подрядчику только эти три блока - по ответу видно, задаёт ли он уточняющие вопросы или сразу «сделаем».
- Сверьте с ROI: если экономия не бьётся с бюджетом - режьте объём работ до одного потока.
Готовите ТЗ и хотите вторую пару глаз? Оставьте заявку - за 30-60 минут пройдём чек-лист по вашим системам и подскажем, что вынести в первую фазу.