Короткий ответ
Рабочее ТЗ на внедрение CRM состоит из пяти блоков:
- Кто — заказчик, роли, кто принимает решения.
- Зачем — какая задача закрывается и почему сейчас.
- Как есть — процесс продажи до автоматизации.
- Как поймём, что получилось — критерии приёмки в измеримом виде.
- Ограничения — сроки, бюджет, системы, требования безопасности.
Ниже — структура целиком, которую можно скопировать и заполнить, с пояснением к каждому пункту. А в конце честная оговорка: ТЗ нужно не всегда, и мы объясним, когда достаточно брифа.
Шаблон ТЗ на внедрение CRM: таблица для заполнения
Каркас, который можно перенести в документ и заполнить. Колонка «Пример» показывает не образец текста, а уровень конкретики: если ваша формулировка расплывчатее примера, раздел пока не готов.
| Раздел | Что написать | Пример формулировки |
|---|---|---|
| Заказчик | Кто инициатор, кто решает спорные вопросы, кто пользуется системой | Решение по спорным вопросам — коммерческий директор. Пользователи — 12 менеджеров, 2 руководителя групп |
| Цель | Задача одним предложением и её тип | Собрать заявки из пяти каналов в одну воронку. Задача тактическая |
| Процесс сейчас | Каналы, шаги обработки, где теряется | Заявки с сайта падают на почту, менеджер переносит их в таблицу вручную |
| Роли и доступы | Кто что видит и кто что меняет | Менеджер видит только свои сделки, руководитель группы — сделки группы |
| Интеграции | Система, данные, направление, частота, главная система | 1С → CRM: остатки и цены раз в час, главная — 1С |
| Требования к данным | Персональные данные, хранение, резервное копирование | Согласия на обработку ПД хранятся в карточке контакта |
| Критерии приёмки | Метрика, значение, срок замера, кто принимает | За контрольную неделю ни одной заявки без ответственного |
| Ограничения | Срок, бюджет, чего делать нельзя | Не менять учётную политику в 1С |
| Вне рамок | Что точно не входит в проект | Телефония второго офиса, обучение бухгалтерии |
Ниже — что стоит за каждым разделом и где в нём чаще всего ошибаются.
Что должно быть в техническом задании: структура
1. Кто заказчик
- Компания, отрасль, размер, оборот.
- Кто инициатор проекта и какую должность занимает.
- Кто принимает решения по спорным вопросам — один человек, с именем.
- Кто будет пользоваться системой: отделы, число сотрудников, уровень подготовки.
Пункт про решающего выглядит формальностью, пока проект не упирается в разногласие между коммерческим директором и руководителем отдела продаж. Если заранее не написано, чьё слово последнее, проект встаёт.
2. Зачем внедряем
- Задача одним предложением, без слова «автоматизировать».
- Тип задачи: тактическая (подключить канал, переделать воронку) или стратегическая (подготовить систему к масштабированию, сменить бизнес-модель).
- Что происходит, если не делать ничего.
Различие типов задач меняет объём работ принципиально. Под тактическую не строят контур на вырост, под стратегическую не хватит перенастройки воронки.
3. Как процесс устроен сейчас
- Откуда приходят обращения: каналы и примерная доля каждого.
- Что происходит с обращением по шагам, до автоматизации.
- Где сейчас теряется: с точки зрения руководителя и с точки зрения менеджера — это часто разные ответы.
- Какие системы уже есть: 1С, телефония, сайт, мессенджеры.
- Что уже пробовали и почему не сработало.
Самый полезный раздел и самый пропускаемый. Описание текущего процесса ценнее описания желаемого: желаемое подрядчик умеет предлагать, а текущее знаете только вы.
4. Критерии приёмки
- Какие метрики меняем и с какого значения на какое.
- Через какой срок меряем.
- Что считается «работает»: например, все заявки из всех каналов попадают в воронку в течение минуты и имеют ответственного.
- Кто и как принимает работу.
Без этого раздела приёмка превращается в спор об ощущениях. С ним — в сверку с документом.
5. Ограничения
- Срок и что к нему привязано.
- Бюджет или вилка.
- Системы, с которыми обязательно связаться, и в каком режиме обмена.
- Требования безопасности: персональные данные, права доступа, хранение.
- Чего делать нельзя: например, менять учётную политику в 1С.
6. Что вне рамок проекта
Отдельный короткий список того, что не входит. Пишется в момент, когда всё понятно, и спасает на этапе приёмки, когда «ну это же логично было включить».
7. Роли, интеграции и данные
Три раздела, которые в коммерческих ТЗ чаще всего сводят к одной строке — и которые потом дают больше всего доработок.
Роли и права доступа. Не список должностей, а ответ на два вопроса для каждой роли: что человек видит и что может менять. «Менеджер видит свои сделки, руководитель — сделки своей группы, собственник — всё, удалять не может никто, кроме администратора». Права, не описанные заранее, настраиваются по умолчанию — то есть все видят всё. Подробнее о том, что ломается при настройке прав.
Интеграции. Для каждой связи с другой системой — четыре пункта:
- какие данные передаются;
- в какую сторону;
- как часто: в реальном времени, раз в час, раз в сутки;
- какая система главная, если данные разошлись.
Строка «интеграция с 1С» без этих пунктов может означать и выгрузку контрагентов раз в сутки, и двусторонний обмен заказами с остатками — объём работ различается в разы. Что обычно передаётся между 1С и CRM и где обмен ломается — в отдельном разборе.
Данные и безопасность. Где хранятся персональные данные и согласия на их обработку, кто может выгружать базу, нужна ли двухфакторная авторизация, как часто делается резервная копия. Для облачной CRM часть пунктов закрывает платформа, но решение о том, кому что разрешено, остаётся за вами.
Как заполнить ТЗ: пример двух ключевых разделов
Структура сама по себе мало помогает — трудность в формулировках. Ниже те же разделы, но заполненные. Компания вымышленная, ситуация типовая.
Как выглядит плохо
Зачем внедряем: автоматизировать отдел продаж, повысить эффективность работы менеджеров, внедрить современную CRM-систему для роста продаж.
Критерии приёмки: система работает корректно, сотрудники обучены, руководство довольно.
Это ни к чему не обязывает ни одну из сторон. Принять такую работу можно в любом состоянии и не принять тоже.
Как выглядит рабочее
Зачем внедряем. Заявки приходят в пять каналов: сайт, телефон, почта, Telegram, Авито. Менеджеры обрабатывают их вручную, часть теряется — руководитель не может сказать, сколько именно. Задача тактическая: собрать все каналы в одну воронку и сделать поток заявок видимым.
Если не делать ничего: при плановом росте числа заявок вдвое к следующему сезону нагрузка распределяется вручную, и доля потерь вырастет.
Критерии приёмки.
- Заявки из всех пяти каналов попадают в воронку автоматически, каждая имеет ответственного. Проверка: за контрольную неделю ни одной заявки без ответственного.
- Руководитель видит отчёт по источникам с конверсией в сделку. Проверка: отчёт открывается и цифры сходятся с ручной выгрузкой за месяц.
- Среднее время до первого ответа — не более 15 минут в рабочее время. Замер через месяц после запуска, база сравнения — текущие 4 часа.
- Обучение: каждый менеджер самостоятельно проводит сделку от заявки до закрытия на своём рабочем месте.
Вне рамок проекта: интеграция с 1С, телефония для второго офиса, обучение бухгалтерии.
Разница не в объёме, а в проверяемости. По второму варианту можно провести приёмку, не приходя к согласию заранее: критерий либо выполнен, либо нет.
Как написать ТЗ: порядок работы
- Собрать заказчиков. Всех, чьи интересы затрагивает проект, и договориться, кто решает спорные вопросы. До этого писать бессмысленно.
- Описать текущий процесс. Пройти путь одной заявки от канала до оплаты вместе с менеджером, а не по рассказу руководителя.
- Сформулировать цель и критерии приёмки. Сначала цифры, потом требования: требования выводятся из того, что нужно изменить.
- Выписать интеграции, роли и ограничения. По таблице выше.
- Отдать на проверку тому, кто будет исполнять. Подрядчик должен назвать, что из написанного платформа делает штатно, а что требует доработки, — и это меняет смету.
Как проверить своё ТЗ за десять минут
Шесть вопросов к готовому документу:
- Назван ли по имени человек, решающий спорные вопросы? Если «руководство» — не назван.
- Есть ли хоть одна цифра в критериях приёмки? Если ни одной — приёмки не будет, будет обсуждение.
- Описан ли процесс, как он идёт сейчас? Если только желаемое — подрядчик будет проектировать вслепую.
- Есть ли раздел «вне рамок»? Если нет, он появится на приёмке в виде конфликта.
- Нет ли в тексте описания реализации — конкретных полей, стадий, типов? Если есть, вы уже спроектировали за подрядчика.
- Расставлены ли приоритеты? Если все сорок требований обязательные, приоритеты расставит исполнитель.
Если на четыре и больше вопросов ответ «нет» — документ пока не рабочий, и дорабатывать его дешевле сейчас, чем спорить на приёмке.
Чего в техническом задании быть не должно
Описания реализации. «Сделать поле типа „список” на стадии „Переговоры”» — это не задача, а решение. Написав его, вы лишаете подрядчика возможности предложить вариант лучше и берёте ответственность на себя. Задача звучит иначе: «менеджер должен фиксировать причину отказа так, чтобы по ней потом строился отчёт».
Списка функций из презентации вендора. Пункты вроде «внедрить сквозную аналитику, роботов и бизнес-процессы» — это не требования, а перечень возможностей. Половина окажется ненужной, но за неё заплатят.
Пожеланий без приоритета. Если в ТЗ сорок требований и все обязательные, значит приоритеты не расставлены и расставит их подрядчик — по своему усмотрению.
Когда ТЗ пишут по ГОСТ, а когда в свободной форме
Всё описанное выше — рабочая структура для обычного коммерческого проекта. Но есть случаи, когда ТЗ пишется не как удобно, а как положено.
Мы работаем по двум стандартам:
ГОСТ 34.602-2020 — «Техническое задание на создание автоматизированной системы». Действующая редакция, введена приказом Росстандарта от 19.11.2021 № 1522-ст, действует с 1 января 2022 года, заменила ГОСТ 34.602-89. Это основной стандарт для внедрения CRM как автоматизированной системы.
ГОСТ 19.201 — «ЕСПД. Техническое задание», единая система программной документации. Применяется, когда в проекте есть собственная разработка: своё приложение, нестандартный обмен, доработка на уровне кода. На него, кстати, есть нормативная ссылка в самом 34.602 — стандарты связаны.
Обязательные разделы по ГОСТ 34.602
- Общие сведения.
- Цели и назначение создания системы.
- Характеристика объектов автоматизации.
- Требования к системе.
- Состав и содержание работ по созданию, с перечнем этапов и сроков.
- Порядок разработки: организация работ, перечень документов, экспертиза, гарантийные обязательства, технико-экономическая оценка.
- Порядок контроля и приёмки: виды, состав и методы испытаний.
- Требования к подготовке объекта к вводу в действие: условия функционирования, организационно-штатные мероприятия, обучение персонала.
- Требования к документированию.
- Источники разработки.
Сравните с пятью блоками выше — по смыслу это то же самое, просто в формализованном виде и с обязательными разделами, которые в коммерческом проекте часто опускают.
Когда ГОСТ обязателен
- Госзаказ и тендеры. Там формат не обсуждается.
- Крупные компании с регламентом закупок. Внутренние правила часто прямо ссылаются на 34.602.
- Проекты с приёмочными испытаниями. Раздел про виды и методы испытаний — сильная сторона стандарта: он заставляет описать приёмку до начала работ.
Когда ГОСТ мешает
Для малого и среднего бизнеса с задачей «собрать заявки в одну воронку» полный ГОСТ-документ — это несколько недель работы над бумагой, которая никому не понадобится после запуска. Формализация имеет цену, и платить её надо осознанно.
Мы держим оба формата: если проект требует ГОСТ — пишем по ГОСТ, если нет — по структуре выше. Решение принимается на старте, и это тоже часть обсуждения, а не что-то, что подрядчик решает молча.
Нужно ли вам вообще писать ТЗ
Мы начинаем работу не с технического задания, а с трёх вопросов: кто на стороне клиента заказчик, чтобы что внедряем, как поймём, что пришли туда, куда планировали. Подробнее про метод.
Если вы можете внятно ответить на все три — полноценное ТЗ вам, скорее всего, не нужно. Хватит брифа на две страницы, а дальше подрядчик сам предложит решение и зафиксирует его в смете по этапам.
ТЗ действительно нужно в двух случаях.
Первый: заказчиков несколько, и они между собой не договорились. Коммерческому директору нужен прогноз, руководителю отдела продаж — контроль исполнения, собственнику — рост выручки. Это три разных проекта. Документ в такой ситуации фиксирует не требования к системе, а договорённость между людьми — и в этом его настоящая ценность.
Второй: закупка требует формального документа. Тендер, госзаказ, внутренний регламент. Тут вопрос не в пользе, а в процедуре.
Во всех остальных случаях толстое ТЗ чаще вредит: оно фиксирует представление о решении, сложившееся до того, как кто-то посмотрел на процесс.
Сколько стоит написать техническое задание
От 60 000 ₽. Цену называем сразу, потому что вопрос возникает у всех, а «рассчитаем индивидуально» здесь означает ровно то же, что и везде.
Что влияет на итоговую сумму:
- Форма документа. Свободная структура дешевле, ГОСТ 34.602 дороже: там обязательные разделы, которые нужно заполнить содержательно, а не формально.
- Число заказчиков. Один инициатор — одна серия интервью. Три подразделения с разными интересами — это ещё и работа по согласованию между ними, и она занимает больше времени, чем само написание.
- Глубина обследования. ТЗ пишется по реальному процессу, а не по рассказу о нём. Чем сложнее процесс продажи и чем больше систем в контуре, тем дольше обследование.
- Наличие собственной разработки. Если в проекте есть доработка на уровне кода, добавляется ГОСТ 19.201 и раздел с техническими требованиями.
Важное следствие, о котором стоит подумать заранее. Если ТЗ пишет тот же подрядчик, который потом будет внедрять, — вы получаете документ, написанный под его возможности. Это не обязательно плохо: он знает платформу и не напишет невыполнимого. Но если планируете проводить тендер, ТЗ разумнее заказать отдельно, а исполнителя выбирать уже по нему.
Мы делаем и так, и так, и говорим об этом прямо на старте.
Как мы работаем с ТЗ
Мы просим заполнить бриф — он занимает пятнадцать минут и отвечает на те же три вопроса. Дальше проводим обследование реального процесса продажи и предлагаем решение, которое обсуждается и правится.
Смета раскладывается по этапам до подписания договора, чтобы решение принималось на цифрах. Если по итогам обследования выясняется, что задача решается перенастройкой, а не внедрением, — мы говорим это прямо.
Цены и этапы — на странице услуги. Бриф — здесь, без регистрации и водяных знаков.
Часть обследования, которая обычно даётся сложнее всего, — проектирование самой воронки продаж: как её строить с нуля, вопросом «а что дальше».