Как составить грамотное техническое задание на разработку CRM

Как понять, что без технического задания не обойтись

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

• Компания запускает CRM без определения ролей и функций. В результате — менеджеры видят чужие сделки, руководитель не может настроить аналитику, в чате техподдержки — часовые споры, кто за что отвечает.
• Через два месяца после старта разработки клиент просит «добавить интеграцию с Telegram» и календарь задач. Команда объясняет: «Это не было в первоначальном плане. Нужно пересчитать сроки и бюджет».
• Бюджет вырос вдвое, потому что на ходу менялись требования, фронт работ постоянно расширялся, а оценка в начале давалась «на глаз» — без чёткой фиксации объема.

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

Что обязательно должно быть в ТЗ на CRM

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

• Описание бизнес-задачи
• Начинаем не с функций, а с того, что нужно автоматизировать. Например: управление потоком первичных заявок, контроль поэтапного выполнения заказов, автоматизация документооборота, ведение клиентской истории — и конкретные боли текущей системы (типа «теряются заявки с сайта, нет формы обратной связи»).
• Пользовательские роли и уровень доступа
• Кто будет работать в системе? Минимум 3 уровня: менеджер, руководитель отдела, администратор. Определите, какой ролью управляют сделки, кто может редактировать карточки клиента, а кто — только просматривать. Без этого не реализуете модели ответственности, не обеспечите безопасность и попадёте в конфликт интересов.
• Ключевые функции CRMКарточка клиента: структура полей, история взаимодействий, привязанные документы.
• Воронка продаж: этапы, условия перехода, автоматические действия при смене этапа.
• Задачи и напоминания: логика создания задач, автотрекинг, дедлайны, напоминания по сделкам.
• Отчёты и аналитика: какие метрики собираем (конверсия на каждом этапе, эффективность менеджеров), в каком виде отображаем (таблицы, графики, выгрузка в Excel/Google).
• Интеграции
• Сайт, формы заявок, онлайн-чаты (например, JivoSite), телефония (IP PBX, Asterisk, Zadarma, Mango), почтовые клиенты, 1С, Telegram-боты, мессенджеры в социальных сетях. Укажите, должна ли CRM сама забирать заявки или предоставлять API.
• Интерфейс и UX
• Нужна ли мобильная версия или приложение? Будет ли самостоятельная авторизация? Какие элементы интерфейса — критичные? Например, компания с большим потоком обращений по телефону требует CRM, где в 1 клик открывается карточка звонящего клиента.
• Безопасность
• Кто контролирует доступ? Поддержка двухфакторной авторизации? Возможность сегментировать пользователей (например, доступ к CRM по IP)? Обработка персональных данных на территории РФ с политикой обработки по ФЗ-152? Важно указать, кто будет оператором данных.
• Миграция данных
• Если у бизнеса есть существующая CRM или данные хранятся в таблицах — нужно заранее предусмотреть формат переноса: из какой системы, в каком формате, какие поля (например, сделки с историей просмотров, файлы, вложения).
• Масштабируемость
• Система должна предусматривать рост: от 10 до 100 пользователей, возможность подключения новых модулей по мере изменения бизнес-процессов. Пример: сегодня вы используете CRM как сделочный трекер, через 6 месяцев — подключаете сервисную часть для технической поддержки.

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

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

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

1. Вместо: «Хотим видеть все неоплаченные сделки»
2. Пишем: «Руководитель отдела продаж ежедневно в 09:00 получает отчёт по всем сделкам со статусом ‘Ожидает оплаты’ старше 3 дней».
3. Вместо: «CRM должна напоминать о задачах»
4. Пишем: «Менеджеру за 30 минут до установленного срока задачи приходит пуш-уведомление и письмо на почту; при пропуске — уведомление руководителю».

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

Пример бизнес-процесса:

• Поступает заявка с сайта → автоматически создаётся лид в CRM.
• Лид присваивается свободному менеджеру по очереди.
• Менеджер звонит ➝ при отсутствии ответа — устанавливает статус «Недозвон».
• Через 1 час CRM ставит повторную задачу.
• При первом успешном звонке — создаётся сделка, и лид переходит на этап «Контакт установлен».

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

Как выбрать между доработкой готовой CRM и разработкой с нуля

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

Подходят для доработки:

• Bitrix24: мощная, но избыточная, требует кастомизации и продвинутой настройки ролей, бизнес-процессов и прав доступа.
• amoCRM: удобная для работы с заявками и воронками, легко расширяется через виджеты и API, но имеет ограничения по хранилищу и кастомизации базы данных.
• RetailCRM, Мегаплан, HubSpot: хорошие экосистемы, если процессы вписываются в их модель данных.

Показания к разработке с нуля:

• Комбинация процессов: CRM + сервисный центр + поддержка + аналитика + три интерфейса (клиенты, менеджеры, сервис-инженеры).
• Нестандартные расчёты: автоматическое формирование КП по десятку параметров, интеграция с API расчета доставки, особые тарифные матрицы.
• Сложные роли: сценарии франчайзи, региональных представителей, роли с пересекающимися правами.

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

Распространённые ошибки в ТЗ на CRM и как их избежать

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

• «Удобный интерфейс» без конкретики
• Интерфейс должен отвечать на задачи, а не быть «приятным». Например, «в карточке клиента в один клик должен быть доступен журнал звонков и переписка» — это формализованный критерий. А «логично построенный личный кабинет» — слишком абстрактен. Решение — описывать действия: что должен сделать пользователь, где ищет информацию, какие элементы являются приоритетными.
• Противоречивые требования от разных стейкхолдеров
• Маркетинг хочет бесшовную интеграцию с соцсетями, продажи настаивают на простоте воронки, руководство ориентировано на отчёты. Все требования важны — но если они не согласованы между собой до начала разработки, в середине проекта начинается хаос. Лучшее решение — провести внутреннюю фасилитацию и зафиксировать согласованный документ целей.
• Отсутствие функционала поддержки и масштабирования
• ТЗ часто описывает только «процессы продаж», забывая о проверке ролей при росте команды, обновлении справочников, функциях службы поддержки. CRM без механизмов поддержки быстро превращается в «чёрную коробку», где изменения опасны.
• Игнорирование архитектуры данных
• Часто в ТЗ нет ни слова о том, как устроена структура сущностей: клиенты, сделки, продукты, документы, связки между ними. Как следствие — архитектурные слабости, невозможность строить отчёты, путаница в системе. Нужно заранее определить, какие справочники обязательны, какие имеют уникальные параметры, какие связи между таблицами важны (например, клиент может иметь несколько сделок, у каждой — свой набор документов).
• Запрос «делать как у X»
• Встречается формулировка «должно работать как в Bitrix/Тинькофф/СБИС», но без уточнения: какие именно функции имеются в виду? Подразумевается юзерфлоу, карточка, шаблон KPI? Даже ссылку на нужный компонент не приводят. Это недопустимо — и для вас, и для подрядчика. Используйте точечную декомпозицию: «хотим реализовать функциональность это–как-в–Trello/Notion, вот скрин-шот, поведение описано ниже».
• Отсутствие KPI и сценариев использования
• Без определения результатов невозможно оценить, успешен ли проект. Ключевое — формализовать цели: «Скорость первичного ответа — не более 15 минут», «Коэффициент воронки: конверсия из лида в сделку — не менее 12%». Также важны user stories, сценарии «как работает менеджер с CRM в первый рабочий день» — это снижает барьер входа и позволяет оценить интерфейс на этапе макетов, а не после релиза.

Полноценное ТЗ не просто описывает — оно минимизирует риски. Если вы пишете не just требования к ПО, а описание взаимодействий пользователей и системы — вы уже на стороне эффективности.

Пример готового фрагмента ТЗ

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

Функция: Отчёт по менеджерам за месяц

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

Роль: Руководитель отдела продаж

Сценарий использования:
1. Раз в месяц руководитель открывает CRM и заходит в раздел "Отчёты".
2. Выбирает фильтр "Период: последние 30 дней"; далее — "Разбивка по менеджерам".
3. Формируется таблица с колонками: ФИО, число новых лидов, число закрытых сделок, суммарный чек, средний чек.

Формат отображения:
- Визуальный вид: таблица + линейная диаграмма по чекам.
- Возможность сортировать данные по любой колонке.
- Экспорт в Excel и Google Sheets.

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

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

Скачать шаблон ТЗ на CRM

Чтобы не начинать с пустого листа, мы подготовили подробный шаблон технического задания. Он состоит из следующих блоков:

• Структура документа с пояснением, какие поля обязательны для любого проекта
• Примеры заполнения каждого раздела, включая список ролей, описание бизнес-процессов и интеграций
• Разметка под схемы, диаграммы потоков, трекеры данных

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

📥 Скачать шаблон ТЗ на CRM (DOCX, 1.2 MB)

Кому поручить составление ТЗ, если вы не уверены

Если ваш бизнес не связан с IT, составление понятного и реализуемого технического задания может стать вызовом. Решение есть — поручить его специалисту, который умеет «переводить» бизнес-потребности в цифровую архитектуру. Вот кто с этим действительно справляется:

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

Стоимость работ по ТЗ зависит от объема процесса и сложности логики. Средний диапазон: от 30 000 ₽ за ТЗ на кастомизацию существующей системы — до 150–200 тыс. ₽ за полное crm техническое задание на CRM-систему с десятками интерфейсных блоков и интеграций с внешними приложениями.

В 7 из 10 проектов хорошее ТЗ возвращает инвестиции на этапе реализации — за счёт сокращения коммуникаций, отказа от переделок, чёткого контроля права ошибок.

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

Мы создаём CRM под реальные бизнес-процессы

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

Оставьте заявку, чтобы обсудить, как будет выглядеть ваша CRM. Мы не начнём проект, пока вы не увидите и не утвердите точный план. Это лучшее вложение в эффективность команды и управляемость бизнеса.