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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

Частые вопросы (FAQ)

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

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

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

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

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

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

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

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

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

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

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