Техническое задание на разработку CRM: структура, примеры, советы

Почему без внятного ТЗ CRM‑проект разваливается: цели и риски

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

Без ТЗ у каждой роли в голове своя CRM‑система: маркетолог ждёт автоматизации email‑рассылок, руководитель продаж — прозрачную воронку, а подрядчик видит «карточку клиента и список задач». В итоге ожидания не совпадают, а спорить уже поздно — деньги потрачены, сроки сдвинуты, мотивация команды просела.

Документ с понятным описанием целей и функциональных требований помогает:

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

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

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

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

Что нужно решить до того, как открывать документ «ТЗ на разработку CRM»

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

Мини‑чек‑лист вопросов, на которые необходимо ответить заранее:

• — Зачем внедряется CRM именно сейчас? 1–3 ключевые цели: увеличить конверсию из лида в сделку, сократить срок обработки заявки, сделать прозрачной работу менеджеров, уйти от файлов Excel и разбросанных таблиц.
• — Кто основные пользователи системы: только отдел продаж, кол‑центр, маркетинг, служба поддержки или вся компания?
• — Как выглядит текущий путь клиента: от первого обращения с сайта, телефона или из социальных сетей до оплаты и повторной покупки?
• — Какие системы и сервисов уже используются: телефония, почта, мессенджеры, 1С/ERP, интернет‑магазин, сайт, мобильные приложения, сторонние CRM систем?

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

Следующий шаг — сбор требований от разных ролей. Полезно провести короткие интервью:

• — с менеджерами по продажам: где они теряют клиентов, что мешает им выполнять план;
• — с руководителями отделов: какие отчёты и показатели им нужны для управления;
• — с маркетологами: какие сегменты, базы и сценарии взаимодействия клиентами важно автоматизировать;
• — с IT‑специалистами: какие ограничения по безопасности, доступу, интеграциям и использованию внутренних систем есть у компании.

Фокус — не на хотелках («хочу красивый дизайн»), а на реальных проблемах: где теряются заявки, почему нет полной истории взаимодействия, какие ручные операции съедают больше всего времени. Это помогает отделить ключевых требований от опциональных.

Сразу зафиксируйте ограничения проекта:

• — бюджетный диапазон и ожидаемые сроки запуска первой версии;
• — регуляторные требования: политика обработки персональных данных, соблюдение 152‑ФЗ, GDPR, внутренних стандартов безопасности;
• — технические рамки: корпоративные правила по размещению систем (облако/свой сервер в Москве или другом регионе), резервному копированию и управлению доступом.

Ответы на эти вопросы лягут в основу разделов ТЗ «Цели», «Ограничения» и «Описание процессов» и позволят не тратить время на переписывание документа после первых встреч с подрядчиком.

Структура технического задания на разработку CRM

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

• — Общие сведения о проекте. Краткое описание компании, региона (например, «основной офис — Москва»), сферы деятельности. Контактные лица: кто заказчик, кто владелец продукта, кто принимает ключевые решения, кто отвечает за выполнение договора.
• — Цели и задачи CRM. Что должно измениться: прозрачность воронки, контроль задач, рост повторных продаж. Здесь же фиксируются измеримые KPI: скорость обработки лида, доля сделок с заполненными полями, количество активных пользователей системы.
• — Описание бизнес‑процессов. Последовательность шагов: от поступления заявки до закрытия сделки и постпродажного обслуживания. Можно сослаться на отдельные схемы или карту процессов в приложении к документу.
• — Пользователи и роли. Типы пользователей (менеджер, руководитель отдела, маркетолог, администратор), их задачи и уровни доступа к информации. Например: «Менеджер видит только свои сделки, руководитель — сделки отдела, администратор управляет настройками и правами».
• — Функциональные требования. Перечень основных функций: работа с лидами, сделки и воронки, карточка клиента, задачи и напоминания, отчёты, сегментация, интеграции, инструменты маркетинга. Для каждой функции — краткое описание ожидаемого поведения.
• — Нефункциональные требования. Надёжность, производительность, масштабируемость, требования к интерфейсу и дизайну, ограничения по времени отклика, поддержка мобильных устройств и браузеров.
• — Интеграции. Перечень систем, с которыми CRM должна обмениваться данными: сайт, формы «Заказ», интернет‑магазин, IP‑телефония, email, мессенджеры, 1С/ERP, платёжные сервисы, аналитика.
• — Требования к данным. Какие сущности и поля нужны (клиент, контакт, сделка, продукт, задача), какие поля обязательны, как устроена миграция из старых баз и файлов, какие правила валидации.
• — Отчёты и аналитика. Список ключевых отчётов, периодичность, уровни агрегирования, параметры фильтрации.
• — Этапы внедрения и критерии приёмки. Поэтапное выполнение: MVP, пилот, тиражирование. Для каждой фазы — перечень функций, которые считаются реализованы, и критерии, по которым заказчик подтверждает успешную приёмку.

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

Пошаговое руководство: как написать ТЗ на CRM, если вы не программист

Ниже — практический алгоритм составления ТЗ. Можно открыть пустой документ и двигаться по шагам, отвечая на вопросы и копируя формулировки под свою компанию.

Шаг 1. Сформулируйте 3–5 целей CRM

Цели — это не список функций, а ожидаемые изменения в бизнесе. Примеры формулировок:

• — «Сократить срок от первого контакта до сделки с 14 до 7 дней»;
• — «Убрать ведение клиентов в Excel, чтобы не терялись заявки с сайта и телефона»;
• — «Повысить долю повторных продаж на 20% за счёт автоматизации напоминаний».

Хороший тест: если цель нельзя измерить или проверить по итогам внедрения, это не цель, а пожелание. Фраза «нужен отчёт по продажам» — это функциональное требование, а не цель. Цель звучит так: «Руководитель за 5 минут получает ответы на вопросы: кто выполняет план, где затыки во воронке, какие каналы приводят прибыльных клиентов».

Шаг 2. Опишите текущий путь клиента

Не нужно рисовать сложные схемы. Достаточно линейного описания стадий:

• — откуда приходят лиды: сайт, звонок, мессенджер, выставка, партнёры;
• — кто первый обрабатывает обращение и в какие сроки это должно происходить;
• — на каких этапах чаще всего всё «зависает»;
• — когда клиент становится постоянным и кто отвечает за его сопровождение.

Такое описание помогает увидеть реальные узкие места и понять, какие функции CRM действительно нужны, а какие можно отложить на следующие версии.

Шаг 3. Составьте перечень пользователей и их задач

Полезно представить простую таблицу (её можно вставить текстом в ТЗ): «Роль — регулярные задачи — какие данные нужны». Например:

• — Менеджер по продажам: видит свои задачи на сегодня, быстро фиксирует исход звонка, создаёт новую сделку за 20–30 секунд.
• — Руководитель отдела: контролирует выполнение плана продаж, видит просроченные задачи, анализирует эффективность каналов привлечения.
• — Маркетолог: формирует сегменты клиентов, запускает рассылки и кампании, оценивает результаты по каналам и продуктам.
• — Администратор CRM: настраивает права доступа, справочники, интеграции с внешними системами.

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

Шаг 4. Переведите задачи в функциональные требования

Формулируйте требования конкретно. Не «нужна удобная карточка клиента», а, например:

• — «Карточка клиента содержит: название компании, ИНН, адрес, ответственного менеджера, контактные лица, телефоны, email, источники привлечения, историю взаимодействий, связанные сделки и задачи»;
• — «Из карточки клиента в один клик можно: позвонить по телефону через IP‑телефонию, отправить email, открыть чат в мессенджере, создать задачу»;
• — «Система автоматически фиксирует историю: входящие и исходящие звонки, письма, сообщения, статусы сделок».

Неудачная формулировка: «Сделайте всё максимально просто». Удачная: «Создание новой сделки занимает не более 5 полей ввода: клиент, контактное лицо, сумма, этап, ответственный».

Шаг 5. Опишите воронки и статусы сделок

Для каждой ключевой услуги или продукта опишите путь сделки. Например, для B2B‑продаж:

• — Новый лид;
• — Квалификация;
• — Коммерческое предложение отправлено;
• — Переговоры;
• — Договор согласован;
• — Оплачено / Успешно;
• — Проиграно (с указанием причин).

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

Шаг 6. Пропишите требования к интеграциям

Для каждой интеграции опишите:

• — с какой системой идёт связь (сайт, интернет‑магазин, телефония, мессенджеры, ERP);
• — кто источник данных и кто «истина» при конфликте (например, статусы оплат определяет 1С);
• — в каком направлении идёт обмен (односторонний или двусторонний);
• — какие события создают записи в CRM.

Пример формулировки: «При поступлении заявки с формы “Заказать звонок” на сайте создаётся лид в CRM с полями: имя, телефон, адрес электронной почты (если указан), источник — “Сайт / форма Заказать звонок”. Менеджеру назначается задача перезвонить в течение 30 минут».

Шаг 7. Определите отчёты и метрики

Не пытайтесь перечислить все возможные отчёты. Достаточно 5–7 ключевых:

• — воронка продаж по этапам и менеджерам;
• — количество и скорость обработки новых лидов;
• — план/факт по выручке и количеству сделок;
• — источники лидов и их конверсия в оплату;
• — повторные продажи и активность по существующим клиентам.

Для каждого отчёта опишите, кто его смотрит, как часто, какие решения он помогает принимать. Это направляет работу аналитики и разработки.

Шаг 8. Добавьте нефункциональные требования и критерии приёмки

Нефункциональные требования можно описывать человеческим языком:

• — «CRM должна стабильно работать при одновременной работе до 100 пользователей»;
• — «Время открытия списка сделок при объёме до 100 000 записей — не более 2 секунд»;
• — «Резервное копирование данных происходит не реже одного раза в сутки, хранение копий — не менее 30 дней»;
• — «Система соответствует политикой обработки персональных данных компании, включая шифрование каналов и разграничение доступа».

Критерии приёмки: «Функция считается реализованной, если пользователь с ролью “Менеджер” может за не более чем 30 секунд создать сделку, добавить задачу и зафиксировать результат звонка; данные появляются в соответствующих отчётах в течение 15 минут».

Как описывать интерфейс и пользовательские сценарии без UX‑дизайнера

От описания интерфейса в ТЗ зависит, насколько удобно пользователям работать в системе. Но не требуется профессиональный дизайн или сложные прототипы. Гораздо важнее ясно описать сценарии и ограничения по времени.

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

Удобный формат описания сценариев:

• — «Когда [ситуация], пользователь с ролью [кто] должен иметь возможность [действие], чтобы [результат]».

Пример: «Когда менеджер завершает звонок, он должен иметь возможность за 10–15 секунд выбрать исход звонка (дозвонились/не дозвонились), добавить комментарий, назначить следующий контакт и связать звонок с существующей или новой сделкой».

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

• — Для карточки клиента — список обязательных полей и действий;
• — для списка задач — какие фильтры и сортировки нужны;
• — для воронки продаж — какие статусы отображаются и какие показатели подсчитываются.

Чего лучше избегать:

• — попыток детально описать каждый пиксель и цвет;
• — противоречивых требований («минимум полей» и одновременно «подробная анкета из 40 пунктов»);
• — фиксации частных предпочтений одного пользователя как обязательных для всей команды.

Оставляйте пространство для профессионального UX‑дизайна, но чётко фиксируйте сценарии, от которых зависит эффективность работы пользователей.

Интеграции, данные и безопасность: разделы, о которых вспоминают в последний момент

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

Интеграции

Задайте себе несколько вопросов:

• — нужно ли отслеживать путь клиента от первого касания на сайте до оплаты и повторных покупок;
• — как сейчас передаются данные между системами, есть ли уже какие‑то связки;
• — какие сервисы точно должны «общаться» с CRM: телефония, мессенджеры, почта, 1С, интернет‑магазин, рекламные сети.

Для каждой интеграции укажите формат данных (JSON, CSV, API), частоту обмена, правила при расхождении (что делать, если в двух системах разные статусы). Это определяет объём работ для команды подрядчика.

Данные

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

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

Безопасность и доступ

Уровни доступа стоит продумать заранее:

• — разграничение по ролям (менеджер, руководитель, администратор);
• — по отделам или направлениям (Москва/регионы, опт/розница);
• — по проектам или брендам, если компания ведёт несколько независимых линий бизнеса.

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

Типичные ошибки в ТЗ на CRM и как их избежать

Даже опытные заказчики наступают на одни и те же грабли. Вот ошибки, которые чаще всего приводят к затяжным проектам и конфликтам.

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

Перед тем как отправлять ТЗ подрядчику, пройдитесь по мини‑чек‑листу:

• — цели внедрения и ожидаемые эффекты сформулированы;
• — ключевые процессы и путь клиента описаны;
• — роли пользователей, их задачи и права доступа понятны;
• — функциональные и нефункциональные требования зафиксированы;
• — описаны данные, интеграции и требования к безопасности;
• — есть список основных отчётов и метрик;
• — определены критерии приёмки и границы первой версии (MVP).

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

Как согласовать ТЗ с подрядчиком и довести проект до результата

Даже хорошо подготовленное ТЗ требует доработки совместно с исполнителем. Важно превратить документ в понятную обеим сторонам «карту проекта», а не в формальность для подписи.

Признаки того, что подрядчик действительно проработал ТЗ:

• — задаёт вопросы по бизнес‑процессам, а не только по дизайну интерфейса;
• — предлагает упростить или поэтапно внедрить сложные функции;
• — уточняет детали интеграций, миграции баз и безопасности.

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

В договор стоит отдельно зафиксировать:

• — состав первой версии CRM и границы проекта;
• — как оформляются изменения ТЗ (дополнительные работы, новые интеграции, отчёты);
• — как именно проходит приёмка: по каким пунктам ТЗ проверяется выполнение и какие тесты выполняются.

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

Если вы хотите превратить черновик требований в рабочее техническое задание на разработку CRM, получить реалистичную оценку сроков и бюджета и запустить систему, которая действительно помогает управлять клиентами, оставьте заявку на консультацию. Напишите в форме ваш адрес сайта, краткое описание компании, телефон для связи и пару ключевых вопросов по проекту — мы свяжемся, уточним детали, предложим варианты решений и поможем заказать разработку CRM, веб‑сервиса или другого цифрового продукта, который будет работать на ваши цели.