Как составить техническое задание на CRM

Внедрение CRM обещает порядок в продажах, но на практике многие проекты буксуют: по данным исследовательских агентств, значительная доля CRM-внедрений не достигает поставленных целей, и одна из ключевых причин — размытые требования. Аналитики Gartner из года в год относят нечёткие ожидания и слабую подготовку к запуску к главным факторам неудач, а классические обзоры Standish Group (отчёты CHAOS) десятилетиями фиксируют одно и то же: проекты чаще проваливаются из-за неполных и меняющихся требований, а не из-за плохого кода. Хорошая новость в том, что почти всё это лечится на старте — грамотным техническим заданием. Разберём, как составить ТЗ на CRM, чтобы система решала задачи бизнеса, а не превращалась в дорогую записную книжку.

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

Зачем нужно техническое задание на CRM

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

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

• Единое понимание. Заказчик, аналитик, разработчики и тестировщики видят одну и ту же картину результата, а не каждый свою.
• Оценка сроков и бюджета. По внятному ТЗ подрядчик даёт реалистичную смету, а не «вилку от и до», которая потом уползает вверх.
• Критерий приёмки. Готовый продукт сравнивают не с ощущениями, а с зафиксированными требованиями: сделано то, что описано, — работа принята.
• Защита от расползания задач. ТЗ отделяет согласованный объём от «хотелок на ходу», которые оформляются как отдельные доработки, а не бесконечно раздувают проект.

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

Что сделать до написания ТЗ

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

• Сформулировать цели и метрики. Зачем вам CRM: сократить время обработки заявки, перестать терять лиды, видеть прозрачную воронку, автоматизировать отчётность? Цели лучше выразить в измеримых показателях — так потом будет понятно, окупилось ли внедрение.
• Описать текущие процессы «как есть». Пройдите путь клиента и заявки от первого касания до сделки и повторной продажи. Зафиксируйте, кто, что и в какой момент делает — даже если сейчас это живёт в таблицах и мессенджерах.
• Собрать требования от будущих пользователей. Руководитель отдела продаж, менеджеры, маркетолог, бухгалтерия видят систему по-разному. Опросите тех, кто будет работать в CRM каждый день, — иначе получите красивую систему, которой никто не пользуется.
• Определить приоритеты. Разделите требования на «критично для запуска» и «желательно потом». Это основа для планирования этапов и MVP — первой рабочей версии, которую можно запустить быстро и начать получать пользу.

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

Структура ТЗ на CRM: обязательные разделы

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

• Общие сведения и цели. Название проекта, заказчик, краткое описание бизнеса, цели внедрения CRM и измеримые критерии успеха. Этот раздел задаёт контекст для всех, кто откроет документ.
• Глоссарий. Термины и сокращения, принятые в компании: что такое «лид», «сделка», «квалификация», «этап воронки». Единая терминология снимает половину недопониманий между заказчиком и командой.
• Роли и права доступа. Кто работает в системе и что каждому разрешено видеть и делать. Об этом подробнее ниже — раздел критичный.
• Функциональные требования. Что система должна уметь: управление лидами и сделками, карточки клиентов, воронки продаж, задачи и напоминания, отчёты, рассылки. Каждую функцию описывают через сценарий использования, а не одним словом.
• Бизнес-процессы. Как заявка проходит по этапам, какие статусы бывают, что происходит автоматически при смене статуса, кто получает уведомления. Здесь оживают роли и функции вместе.
• Интеграции. С чем CRM обменивается данными: телефония, почта, сайт и формы заявок, мессенджеры, бухгалтерия, склад, платёжные системы.
• Модель данных. Какие сущности хранятся (клиент, сделка, задача, счёт) и какие поля у каждой — обязательные и опциональные, их типы и допустимые значения.
• Нефункциональные требования. Нагрузка, число пользователей, требования к скорости, безопасности, хранению данных (в том числе 152-ФЗ), резервному копированию.
• Интерфейс и удобство. Ключевые экраны, логика навигации, требования к адаптивности и мобильной версии, если менеджеры работают «в полях».
• Этапы, сроки и приёмка. Как проект разбит на очереди, что входит в MVP, по каким критериям приёмка каждого этапа считается пройденной.

Не обязательно доводить каждый раздел до максимальной детализации сразу — но каждый должен быть хотя бы затронут. Пустой раздел «Интеграции» с пометкой «уточним позже» честнее, чем его отсутствие: он подсвечивает открытый вопрос, а не прячет его.

Пошаговый порядок написания ТЗ на CRM

На практике ТЗ пишут итерационно, а не линейно. Вот последовательность, которая работает:

1. Сбор целей и ограничений (1–2 встречи с руководством). Зафиксируйте, зачем нужна CRM, какой бюджет и сроки, что считается успехом через 6 месяцев. Запишите ответы — они станут введением документа.
2. Интервью с пользователями (2–5 встреч). Поговорите с каждой ролью отдельно: менеджер продаж видит систему иначе, чем руководитель. Фиксируйте не только «что хочу», но и «что мешает сейчас». Хорошо работает формат «пройди со мной путь заявки от входящего звонка до оплаты».
3. Описание процессов «как есть» (as-is). Нарисуйте или опишите текущий путь заявки и клиента. Это база, без которой легко написать систему, которая не совпадает с реальностью.
4. Определение процессов «как должно быть» (to-be). Вместе с командой договоритесь, какие этапы остаются, какие меняются, что автоматизируется. Зафиксируйте расхождения — они станут функциональными требованиями.
5. Составление списка требований с приоритетами. Разделите требования по категориям: обязательно для запуска (must have), важно (should have), желательно (nice to have). Используйте MoSCoW или любую другую систему — главное, чтобы приоритеты были явными.
6. Написание черновика ТЗ по структуре. Пройдитесь по всем разделам из предыдущей главы. Черновик не обязан быть идеальным — важно не оставить пустых разделов совсем.
7. Согласование и правки (1–3 итерации). Дайте черновик всем участникам: заказчику, будущим пользователям, команде разработки. Собирайте правки в едином документе, не в мессенджерах. Фиксируйте разногласия — иногда из них вырастают отдельные доработки.
8. Финальное утверждение и подписание. Утверждённый документ — это точка отсчёта. Изменения после подписания оформляются как доп. соглашения, а не «ну мы же говорили».

Время на каждый шаг зависит от масштаба. Простая CRM на 5–10 пользователей — 1–2 недели. Система с несколькими подразделениями и интеграциями — 4–8 недель. Корпоративная CRM для сотен пользователей — 2–3 месяца.

Минимальный шаблон ТЗ на CRM-систему

Ниже — упрощённая структура, которую можно использовать как отправную точку. Наполнение каждого раздела зависит от ваших процессов:

Раздел ТЗ	Что должно быть внутри	Приоритет
1. Введение и цели	Зачем нужна CRM, измеримые KPI успеха, бюджет и сроки, заказчик и ответственный	Обязательно
2. Глоссарий	Термины компании: лид, сделка, квалификация, этапы воронки	Обязательно
3. Роли и матрица доступа	Список ролей, что каждая видит и что может делать (таблица)	Обязательно
4. Бизнес-процессы	Этапы сделки, условия переходов, автоматизации, обработка отказов	Обязательно
5. Функциональные требования	Модули системы, сценарии использования для каждого	Обязательно
6. Интеграции	Список систем, направление обмена, триггеры, поведение при сбое	Обязательно
7. Модель данных	Сущности (клиент, сделка, задача), поля, типы, обязательность	Обязательно
8. Нефункциональные требования	Нагрузка, скорость, безопасность, 152-ФЗ, бэкапы	Обязательно
9. Интерфейс и UX	Ключевые экраны, мобильная версия, требования к навигации	Желательно
10. Миграция данных	Источник, формат, объём, логика переноса старой базы клиентов	При наличии
11. Этапы и критерии приёмки	MVP и последующие очереди, по каким критериям принимается каждый этап	Обязательно

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

Как описывать бизнес-процессы и роли

Сердце ТЗ на CRM — это описание ролей и процессов. Именно здесь чаще всего рождается разрыв между тем, что представлял заказчик, и тем, что построит команда. Разберём оба блока подробнее.

Роли и права доступа

Начните с перечня ролей: например, менеджер по продажам, руководитель отдела, маркетолог, оператор колл-центра, администратор. Для каждой роли опишите, что она видит и что может делать. Хороший приём — свести это в матрицу доступа, где по строкам роли, а по столбцам действия и данные.

Роль	Что видит	Что может делать
Менеджер по продажам	Только свои сделки и клиентов	Создавать и вести сделки, ставить задачи, писать клиентам
Руководитель отдела	Сделки всего отдела, отчёты и воронку	Перераспределять сделки, смотреть аналитику, настраивать этапы
Маркетолог	Лиды, источники, конверсии по каналам	Запускать рассылки, анализировать эффективность каналов
Администратор	Всю систему и настройки	Управлять пользователями, правами, интеграциями

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

Бизнес-процессы

Процессы удобнее всего описывать через жизненный цикл сущности. Возьмите сделку и проведите её по этапам: новый лид → квалификация → предложение → переговоры → оплата → выполнено (или отказ). Для каждого перехода зафиксируйте:

1. Какое условие переводит сделку на следующий этап и кто это делает.
2. Что происходит автоматически: создаётся задача, уходит уведомление, отправляется письмо клиенту.
3. Какие поля обязательны для перехода — например, нельзя перевести в «оплату» без суммы и контакта.
4. Что считается тупиком и как обрабатывается отказ или «подумаю».

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

Интеграции, данные и нефункциональные требования

CRM почти никогда не живёт в вакууме — она обменивается данными с другими системами, и этот блок ТЗ часто недооценивают. Интеграции стоит описать максимально конкретно: с какой системой, в какую сторону идут данные, что является триггером обмена и что происходит при сбое.

• Телефония. Всплывающая карточка клиента при звонке, запись разговоров, автоматическое создание сделки по пропущенному вызову.
• Почта и мессенджеры. Переписка внутри карточки клиента, единая история общения, шаблоны ответов.
• Сайт и формы заявок. Автоматическое попадание лида в CRM с сохранением источника и utm-меток.
• Бухгалтерия и склад. Выставление счетов, проверка остатков, статусы оплаты без ручного переноса данных.
• Платёжные системы. Онлайн-оплата по ссылке, автоматическое обновление статуса сделки при поступлении денег.

Отдельно опишите модель данных: какие сущности хранит система и какие у них поля. Для карточки клиента это может быть имя, телефон, почта, компания, источник; для сделки — сумма, этап, ответственный, дата закрытия. Укажите, какие поля обязательные, какие типы данных допустимы и какие значения запрещены. Это скучная, но крайне полезная работа: именно на уровне полей потом рождаются или не рождаются нормальные отчёты.

Нефункциональные требования отвечают не на вопрос «что делает система», а «как хорошо она это делает». Сюда входят число одновременных пользователей и ожидаемая нагрузка, требования к скорости отклика, безопасность и разграничение доступа, хранение персональных данных на территории России по 152-ФЗ, резервное копирование и отказоустойчивость. Для компаний из регулируемых отраслей эти пункты не менее важны, чем сами функции. Если вы планируете разрабатывать CRM-систему под свои процессы, а не настраивать готовую коробку, нефункциональные требования во многом определят и выбор технологий, и итоговую стоимость.

Типичные ошибки при составлении ТЗ

Большинство проблем с ТЗ на CRM повторяются из проекта в проект. Зная их заранее, вы сэкономите себе недели переделок:

• Абстрактные формулировки. «Удобная система», «понятный интерфейс», «быстрая работа» — это не требования, а пожелания. Каждый прочитает их по-своему. Пишите измеримо: «список сделок открывается не дольше 2 секунд при 10 000 записей».
• Описание решения вместо задачи. Заказчик пишет «сделайте кнопку тут», хотя его реальная задача — быстрее обрабатывать заявки. Опишите проблему и цель, а как её решить — совместно с командой, у неё больше вариантов.
• Игнорирование пользователей. ТЗ, написанное только руководителем без опроса менеджеров, часто описывает идеальный мир, а не реальную работу. Итог — система, которую саботируют «снизу».
• Отсутствие приоритетов. Когда всё «очень важно и срочно», проект невозможно разбить на этапы и запустить MVP. Разделяйте критичное и желательное с самого начала.
• Забытые интеграции и данные. Про телефонию, миграцию старой базы клиентов и обмен с бухгалтерией вспоминают в последний момент — а это часто самые трудоёмкие части проекта.
• ТЗ как разовый документ. Требования уточняются по ходу проекта, и это нормально. Плохо, когда изменения нигде не фиксируются. Ведите ТЗ как живой документ с версиями и историей правок.

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

Чек-лист готового ТЗ

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

1. Сформулированы цели внедрения и измеримые критерии успеха.
2. Описаны роли и матрица прав доступа для каждой из них.
3. Все ключевые бизнес-процессы разложены по этапам с условиями переходов.
4. Функции описаны через сценарии использования, а не одним словом.
5. Перечислены все интеграции с указанием направления обмена данными.
6. Определена модель данных: сущности, поля, обязательность, типы.
7. Зафиксированы нефункциональные требования: нагрузка, безопасность, 152-ФЗ, резервные копии.
8. Требования разделены на «критично для запуска» и «желательно потом».
9. Описан план миграции существующей базы клиентов, если она есть.
10. Заданы критерии приёмки этапов и всего проекта.

Этот чек-лист удобно использовать и как оглавление при написании: проходите пункты по порядку — и белых пятен в документе не останется.

Заключение

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

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

Найдем лучшее решение для вас

Частые вопросы о ТЗ на CRM (FAQ)

Что такое техническое задание на CRM простыми словами?

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

Кто должен составлять ТЗ на CRM — заказчик или подрядчик?

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

Нужно ли ТЗ, если мы внедряем готовую CRM, а не разрабатываем свою?

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

Насколько подробным должно быть ТЗ на CRM?

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

Сколько стоит составить ТЗ на CRM?

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

Сколько времени занимает составление ТЗ на CRM?

Для небольшой CRM на 5–10 пользователей с базовыми модулями — 1–2 недели с учётом интервью и согласований. Для системы с несколькими подразделениями и интеграциями — 3–5 недель. Для крупной корпоративной CRM — 1–3 месяца. Основной фактор — готовность заказчика быстро предоставлять информацию и принимать решения по спорным моментам.

Можно ли использовать готовый шаблон ТЗ на CRM?

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

Хотите спроектировать CRM, которая действительно закроет задачи ваших продаж? Оставьте заявку — мы разберём ваши процессы, поможем составить техническое задание и предложим оптимальное решение по срокам и бюджету. Узнайте больше о разработке CRM-систем в YuSMP Group.