Как составить техническое задание на CRM-систему
Кто составляет задание на CRM и зачем это нужно
Составление задания на CRM редко бывает чьей-то единоличной задачей. Это — совместная работа трёх ключевых ролей: владельца бизнеса (определяет цели и масштаб), project-менеджера (формализует и структурирует требования), технического специалиста (оценивает реализуемость и ограничения).
Даже если инициатива идёт «сверху» (от генерального), без участия менеджера, который понимает работу отделов, и технаря, знающего, где возможны подводные камни, документ получится либо абстрактным, либо нереализуемым. Каждый участник закрывает часть картины — и только в связке получается контролируемый и точный результат.
Расплывчатая передача идеи в духе “мы хотим, чтобы была воронка, напоминания и аналитика” приводит к ситуации, где 50% функционала делают не тем, кто будет пользоваться, а в MVP попадают нерабочие сценарии. Всё это задержки, откаты, переработки, потери денег и времени. Проект проваливается на старте, даже не выходя в разработку.
Письменное структурированное задание — это не формальность. Это документ, который:
- выравнивает ожидания всех участников проекта;
- помогает определить реальную сложность задачи и сроки реализации;
- даёт подрядчику возможность точно оценить бюджет;
- становится точкой отсчёта: что сделано, где отклонения, почему задержка.
Когда задание составлено правильно, компания получает не просто CRM, а систему, которая работает под процессы, закрывает слабые места в отделах, автоматизирует рутину, строит аналитику и помогает продавать лучше.
Что должно быть в задании: обязательные блоки
Задание на CRM — это не поток мыслей руководителя отдела продаж. Это чёткая структура, которая включает ключевые разделы. Упускается один блок — пострадает весь проект: либо не поймут, кто пользователь, либо не реализуют критичную интеграцию.
Обязательные элементы задания:
- Суть проекта и цели CRM
- Зачем внедряется система? Повысить прозрачность продаж? Увеличить скорость обработки заявок? Минимизировать потери лидов? Ответ на эти вопросы задаёт вектор всего проектирования. Выглядит просто — но именно этот блок чаще всего пишут общими словами. Цель должна быть измеримой: не «улучшить», а «сократить цикл сделки с 10 до 7 дней».
- Пользователи, роли, уровни доступа
- Опишите всех типов пользователей: менеджеров отдела продаж, руководителя, маркетолога, бухгалтера, внешнего агента. У каждого — своя зона действий. Например, менеджер видит только своих клиентов и задачи, руководитель — сводную статистику по всей группе.
- Функциональность и сценарии
- Что должен делать сотрудник в CRM: завести заявку, прикрепить документ, прозвонить клиента по встроенной телефонии, поставить задачу? Расписывайте по ролям. Например: «Менеджер может создавать клиента, просматривать историю коммуникаций, запускать рассылку, готовить коммерческое предложение».
- Бизнес-процессы и их автоматизация
- Какие процессы должны быть перенесены в CRM: обработка заявок, документы, оплата, контроль статуса поставки, просрочки задач? Иллюстрируйте на небольших сценариях: «После этапа “Уточнение” автоматически создается задача “Отправить КП” с дедлайном 24 часа».
- Интеграции
- Не упустите: внешние сервисы — половина пользы в CRM. Сюда входят: IP-телефония, email, сайт, лендинги, 1C, ERP, WMS-системы, мессенджеры. Укажите не только, что надо подключить, но и зачем. Например: «Отчёты по прибытию товаров подтягиваются из 1C, и триггерят смену стадии сделки».
- Аналитика и отчёты
- Какие метрики нужны руководству? Конверсия на этапах, среднее время отклика, активность менеджеров, качество входящих лидов? Отчет без смысла — бесполезен. Примеры: “Динамика продаж по месяцам”, “ТОП-5 источников лидов по конверсии”.
- Мобильность, языки, офлайн-доступ
- Нужно ли приложение под телефон? Работает ли CRM в отсутствии сети (полевая торговля)? Есть ли пользователи, кому нужен английский интерфейс?
- Приоритеты и MVP
- Главная защита от перегрузки — определить, что критично в первой версии (MVP). Выделите 3–5 функций, без которых CRM бессмысленна для бизнеса. Остальное — на этап 2. Например:
- Нельзя начать без: фиксации заявок, воронки, напоминаний и истории коммуникаций;
- Можно отложить: кастомные отчеты, геоаналитику, интеграцию с WhatsApp.
Совет: даже если вы уверены, что “всё понятно” — проверьте, отражены ли в задании детали кого-то из отделов, кто будет работать с CRM. Иначе они получат интерфейс, где половина кнопок не нужна, а нужное — есть только “через настройки”.
Как собрать требования к CRM, если вы не технарь
Владельцы процессов обычно говорят на языке действий, а не систем: “менеджер обзванивает заявки с сайта”, “клиенты теряются, если письмо не ушло вовремя”, “руководитель не понимает, чем занят персонал”. Ваша задача — превратить это в список функциональных требований.
Подход в 4 шага:
- Пообщайтесь с ключевыми пользователями.
- Отдел продаж, бухгалтерия, маркетинг — спросите, что болит. Используйте вопросы:
- На чём теряются сделки?
- Что удобно/неудобно в текущей системе?
- Чем вы недовольны в процессе взаимодействия с клиентом?
- Опишите пользовательские кейсы.
- Например:
- “Рекламный лид приходит с сайта, CRM сама распределяет по менеджерам и создаёт задачу на звонок в 30 минут”
- “При смене стадии на “Ожидание оплаты” автоматически уходит письмо с реквизитами”
- Наблюдайте за работой.
- Никакие опросы не заменят час наблюдения за живым процессом. Вы увидите, где сотрудники переключаются между окнами, дублируют информацию, делают списки вручную.
- Составьте карту бизнес-процесса.
- Даже простая схема “Заявка → Звонок → Встреча → Сделка” помогает видеть, где может вмешаться CRM для автоматизации.
Полезный приём: «Раньше мы делали так… теперь хотим, чтобы в CRM это выглядело как…». Например, из Excel в интеграции с телефонией и шаблонами КП за 2 клика. Это задаёт техническому специалисту вектор без навязывания решения.
Мини-чеклист «что обязательно проговорить с каждым отделом»:
- Как фиксируются заявки и где теряются;
- Какие задачи повторяются и требуют автоматизации;
- Какие метрики нужны руководству;
- С кем происходит коммуникация (клиент, партнёр, подрядчик);
- Какие каналы привлечения и общения используются.
Итог — не чисто техническая спецификация, а понимание «что у нас устроено так-то, а хочу — вот так». Этого более чем достаточно, чтобы составить рабочее задание на CRM.
Чем задание на CRM отличается от ТЗ
Ошибочно считать, что задание = полноценное ТЗ. На практике грамотно составленное задание — это первый уровень формализации требований. Оно помогает оценить объём, бюджет и срок. Техническое задание (ТЗ) — это уже формализованный документ с архитектурой, схемами, форматами интеграций, режимами доступа, API.
Почему не стоит начинать сразу с ТЗ:
- Вы потратите недели на детализацию, которая может быть не нужна (или изменится после первых интервью пользователей);
- Без подрядчика и архитектора ТЗ всё равно придётся переделывать — требования без технической экспертизы неточны;
- Для тендера или запроса оценки достаточно задания — опытный разработчик быстро подготовит смету и предложит доработки.
“Хорошее” задание — это документ, где:
- Понятны цели и задачи CRM;
- Описаны ключевые пользователи и их роли;
- Разобраны основные процессы и сценарии;
- Обозначены требования к доступу, каналам, аналитике.
Оформлять начальное задание можно в любом формате: текстовый документ, таблица, слайд-презентация. Главное — логика и полнота. ТЗ будет позже, уже со стороны подрядчика или в связке с внутренним архитектором.
Готовые шаблоны vs задание с нуля: что выбрать
Многие компании, особенно на старте, ищут шаблон задания на CRM — для экономии времени. В сети действительно можно найти десятки «универсальных» форм, типовых брифов и Excel-таблиц с чек-боксами. Вопрос в другом: насколько они подходят под ваш бизнес?
Готовый шаблон экономит 30–50% времени на базовую структуру, если:
- CRM проект типовой: онлайн-запись, заявки, простая воронка, небольшой штат пользователей;
- Задача — протестировать MVP за 1–2 месяца;
- Вы работаете по модели, близкой к стандартным решениям лидеров рынка (B2B-продажи, сервис, IT-продукт).
Но если бизнес уникален — шаблон даст ошибочное ощущение “всё учли”, хотя ключевых нюансов не будет. Примеры:
- HR-агентство, где нужны сложные связи кандидат-вакансия-заказчик;
- Логистическая компания с отслеживанием грузов и маршрутами;
- Аутсорс-бухгалтерия, где важные процессы — документы, подписания и многопользовательский доступ.
При создании задания с нуля важно определить 3 вещи:
- Бизнес-цель внедрения. Без неё любые функции — бессмысленный набор.
- Пользовательские роли и сценарии работы. Отдел продаж ≠ отдел подбора, у них совершенно разные паттерны.
- Границы MVP. Что обязательно в первой версии? Что можно отложить? Это критично.
Оптимальная стратегия зачастую — гибрид:
- Берёте типовую структуру (например, 8 базовых разделов);
- Добавляете детали по конкретным процессам в вашей компании;
- Проходите ревизию через специалиста или проджекта.
Если в проекте до 10 пользователей и 1–2 бизнес-процесса — шаблон ускорит старт. Если интеграций больше двух, бизнес-модель специфична, а роли нетиповые — разрабатывайте задание индивидуально.
Ошибки, которые ломают проект ещё на этапе задания
80% проблем при внедрении CRM начинаются в момент формулировки требований. И чем позже вы их исправите — тем дороже переделка.
Типовые ошибки, которые встречаются в проектах снова и снова:
- “Хотим как у конкурентов”. Без анализа собственных процессов вы получите решение для чужой реальности — и оно почти наверняка будет неработающим: другие каналы, структура отдела, цикл сделки, интеграции.
- Слишком сложный MVP. Попытка засунуть всё сразу в первую версию — гарантия затянувшегося проекта. Система не запускается вовремя, команда выгорает, а пользователи привыкают работать “как раньше”.
- Дублирование функциональности других систем. Например: в компании уже есть Trello для задач и отдельная программа для рассылок. CRM не должна копировать — она должна интегрироваться. Иначе вы создадите две несовместимые экосистемы.
- Нет приоритезации. Все функции — “важные”. Нет разделения на must / nice to have. Команда разработки не понимает, какой сценарий критичен, а какой — просто «было бы хорошо».
- Постоянные правки уже на ходу. Если сотрудники или руководитель отдела регулярно добавляют “а ещё давайте сделаем…”, проект теряет фокус. Нельзя строить CRM на лету.
Мини-чеклист: если у вас хотя бы 3 из 5 пунктов ниже — остановитесь и перепроверьте задание:
- Функциональность описана “по ощущениям”, не по процессам.
- Нет конкретных ролей и сценариев использования.
- В задании нет упоминаний текущих точек боли (где теряем, где дублируем).
- Ничего не сказано про то, какие системы уже используются.
- В блоке аналитики указано “нужны все отчёты” без конкретики.
Как избежать этих ошибок:
- Работать с проджектом или бизнес-аналитиком, который фиксирует реальные процессы.
- Проводить короткие интервью с отделами — 15–20 минут на каждую роль дают больше, чем неделя теоретизирований.
- Протестировать идею MVP на бумаге — “живые” сценарии, переписка, флоу пользователя.
- Заранее оговорить механизм внесения правок — что можно править в процессе, а что — только после итерации 1.0.
Важно: если вы не имеете чёткой приоретизации, разработка затянется в 3–4 раза дольше. Мы видели проекты, где слабое задание увеличивало срок на 8 месяцев.
Как проверить, что задание действительно готово
Хорошее задание на CRM — это не красиво оформленный документ. Его главное качество: любой специалист, которому вы его передадите, должен понять, что делать и зачем, без уточняющих вопросов.
Признаки полноценного задания:
- Чётко сформулирована цель. Например: “Увеличить конверсию в сделку на e-commerce от звона до покупки на 15%”.
- Указаны роли пользователей и права. Менеджер, Супервайзер, Руководитель отдела, Финансист — у всех разные сценарии.
- Описаны ключевые процессы — не выше уровня “общая логика”, а на уровне действий. Как идёт заявка? Кто её принимает? Когда система отправляет напоминание?
- Определено, что входит в первую версию, а что откладывается.
- Названы все ожидаемые интеграции. Телефония, SMTP-почта, ERP, мессенджеры, маркетинговые инструменты.
Практика: перечитайте задание «глазами подрядчика». Задайте себе 2 вопроса:
- Понимаю ли я, что именно нужно сделать с технической точки зрения?
- Могу ли я сориентироваться, какие блоки более критичны, где возможны альтернативы, а где нет?
Если вы чувствуете, что некоторые блоки всё ещё требуют пояснений — лучше пройти ревизию со стороны. Даже краткий аудит от архитектора или продакта может сэкономить месяцы переделок.
В любой непонятной ситуации используйте технику “сухого собеседника”: дайте задание человеку, не вовлечённому в проект и без технического бэкграунда. Если он поймёт — всё структурировано верно.
Куда с этим дальше: как передать задание подрядчику и не потерять управление
Правильная передача — это не только отправка документа. Нужно передать задание с пояснением контекста и правилами взаимодействия.
Передаём:
- Файл / ссылка с заданием (Google Doc, Notion, Confluence, Figma);
- Сопроводительный файл / блок с приоритетами и ограничениями;
- Комментарий: что открыто для обсуждения, а что жёстко фиксировано;
- Контактную точку для быстрых согласований (внутренний project / product).
Контроль соответствия задачам происходит на каждом из 4 шагов:
- Этап пресейла. Подрядчик возвращает вопросы, уточнения, предложения. Это важно: по ним видно, как глубоко он вошёл в суть.
- Отчеты по проекту. Проверяйте не только факт задач, но и соответствие логике сценариев из задания.
- Демоверсии, клик-прототипы. Идеальны, чтобы проверить не на кодовом уровне, а на логике действий.
- Финальное тестирование приёмки функций. По каждому блоку — мини-чеклист соответствия пунктам задания.
Если у вас нет технической компетенции самой команды — обязательно привлекайте project-менеджера или аналитика с вашей стороны. Это гарант, что задачи будут трактоваться корректно.
Задание удобно передавать через:
- документ в Google Docs с комментариями по сценариям и процессам;
- доску в Notion с блоками, категориями, ссылками и чек-листами;
- Figma-пототип, где сценарии размечены визуальными подсказками и логикой переходов.
Задание — это не бюрократия, а инструмент управления результатом. И если вы хотите, чтобы CRM решала задачи бизнеса, а не просто “была” — поможем разработать систему под конкретные процессы.
Позвольте нам задать правильные вопросы и реализовать сильное решение.