Как составить ТЗ для CRM-системы: подробная пошаговая инструкция

Зачем составлять ТЗ при разработке CRM, если «и так всё понятно»

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

Пример: вы говорите — «нужна клиентская база». Но для маркетолога это список с возможностью сегментации по кампаниям и UTM-меткам. Для отдела продаж — просмотр истории коммуникаций, сделок, комментариев и задач. А бухгалтер хочет видеть ИНН, статусы оплат и счета. Одна и та же фраза — три разных смысла, три разных CRM и три разных направления разработки.

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

Что обязательно должно быть в ТЗ: обязательные блоки и порядок

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

• Цель проекта. Не «внедрение системы», а зачем она нужна. Например:
• Автоматизация первичной обработки заявок с сайта
• Контроль выполнения задач менеджеров
• Построение воронки продаж с учётом этапов коммуникации
• Роли и доступы. Рекомендуем не ограничиваться только «админом» и «менеджером». Часто нужны:
• Руководитель отдела
• Агент подряда (ограниченный доступ)
• HR и бухгалтер (только на модуль зарплат или документов)
• Определяйте, кто имеет право:
• Создавать и редактировать карточки клиента
• Удалять объекты
• Запускать рассылки
• Видеть отчёты и аналитику
• Основные модули. Опишите, какие блоки нужны, какую функцию они выполняют:
• Лиды — запись входящих заявок из разных каналов: сайты, телефония, соцсети
• Сделки — визуальное представление пути клиента, перемещение по этапам
• Задачи — автоматическая и ручная постановка
• Уведомления — e-mail, в браузере, через Telegram или внутреннюю систему
• Отчёты — анализ эффективности по отделам, сотрудникам и каналам
• Важно: уточняйте, какие поля обязательные, где нужна история редактирования, что выводить в списке, а что — в карточке.
• Интеграции. CRM редко работает в вакууме. Уточните список внешних систем:
• Телефония (например, Zadarma, Mango, Телфин)
• Сайты и формы захвата (через API или виджеты)
• Почта (синхронизация с Gmail, корпоративной почтой или через SMTP/IMAP)
• 1С или ERP (обмен статусами, данными о клиентах и платежах)
• Мессенджеры — WhatsApp, Telegram, Facebook Messenger
• Укажите: кто инициатор интеграции, какие поля синхронизируются, нужна ли двусторонняя связь, какие сценарии предусмотрены при ошибке канала связи.
• Особенности интерфейса и мобильная версия. Опишите особенности:
• Будет ли мобильное приложение — iOS, Android
• Нужно ли отображение на планшетах
• Требуется ли кастомизация интерфейса (цветовые схемы, логотипы, порядок блоков)
• Поддержка различных языков
• Если сотрудники работают в полях — мобильная версия не вопрос удобства, а вопрос эффективности и доступа к информации в моменте.

Каждый блок ТЗ следует оформлять так, чтобы его можно было легко проверить: реализован он или нет и чего от него ожидать. Избегайте слов «удобный », «понятный », «интуитивный », — эти понятия слишком субъективны. Лучше описывать конкретный функционал: «в форме заявки есть выпадающий список со значениями А, B, C, значение по умолчанию — B».

Как описать свои процессы, если вы не системный аналитик

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

Мы предлагаем простую модель:

1. Опишите путь клиента от первого касания до завершения сделки. Достаточно плоской структуры:

• Клиент оставляет заявку на сайте
• Менеджер звонит в течение 2 часов
• Если интерес есть — создаём сделку
• Отправляем КП на email
• Через сутки — follow-up звонок
• После согласия — выставляем счёт
• Поступила оплата — закрываем сделку

1. Постройте таблицу процессов:

• Событие: Получена заявка
• Ответственный: Менеджер А
• Инструмент: Интеграция формы сайта с CRM
• Результат: Создан лид с UTM-метками

1. Сделайте «карты сценариев». Если клиент не ответил — будет повторный звонок? Сколько попыток? Когда лид признается “холодным”? Эти моменты влияют на логику CRM и запуск автозадач или “умных” уведомлений.

Пример: путь клиента от заявки до закрытия сделки

• Канал / касание: Форма “Рассчитать стоимость” на сайте
• Логика: Автоматически создается лид, назначается на одного из менеджеров по очереди
• Сценарий 1: Менеджер звонит в течение 1 рабочего часа
• Сценарий 2: Если клиент не ответил — CRM повторяет задачу через 24 часа
• Сценарий 3: Если через 3 дня не установлен контакт — перевод в статус «не дозвонились»

Чтобы собрать такую карту, достаточно:

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

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

Формат ТЗ: таблица, документ или Notion?

Выбор формата технического задания для CRM зависит от сложности задач, состава команды и объёма информации. Универсального формата нет, но есть проверенные подходы под разные ситуации:

• Google Docs / Word — простой и понятный вариант для небольших проектов. Удобно писать текст, вставлять скриншоты, давать подрядчику комментарии. Минус — сложно работать с несколькими соавторами одновременно, нет структурной навигации.
• Google Sheets / Excel — эффективно для табличного описания функций, ролей и сценариев. Особенно полезно, если нужно вписать перечень полей карточек, доступы или статусы сделок.
• Notion / Confluence — отличный формат для комплексных или командных проектов. Идеально подходит, если в CRM-системе участвует несколько отделов, и требуется структурировать информацию по разделам. Можно добавлять схемы, чек-листы, статусы реализации. Минус — требует минимального онбординга, если никогда не работали с такими системами.
• Jira / Trello — скорее таск-менеджеры, чем полноценные среды для ТЗ, но могут быть полезны на этапе детализации задач или отслеживания стадий разработки CRM.

Что выбрать? Если вы работаете с подрядчиком по модели «один проект — один ответственный» и проект несложный, достаточно документа в Google Docs и пары таблиц. Если же проект включает 10+ модулей, много ролей и будущих релизов — лучше вести ТЗ в вики-формате (например, Notion), объединяя описание, диаграммы и логику взаимодействия.

А можно всё просто объяснить разработчику «на словах»? Можно — но это путь к хаосу. Любое устное согласование со временем забывается или искажается. В итоге вы не сможете проверить, реализован модуль «как обсуждали» или нет. А значит, теряете контроль над результатом.

Подводные камни: что часто забывают включить в ТЗ на CRM

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

• Логи событий. Кто, когда и что изменил в системе? Эта информация важна и для аудита действий менеджеров, и для безопасности. Например:
• Менеджер изменил статус сделки — когда и почему?
• Удалён клиент — кем и на каком этапе?
• Отсутствие логов делает систему «чёрным ящиком».
• История изменений по клиенту. Менеджер открыл карточку клиента: видит ли он, какие действия производились ранее? Кто менял телефон? Был ли изменён статус? В каких рассылках участвовал? Без этой информации менеджеры действуют вслепую.
• Обработка ошибок. Предусмотрите сценарии, когда пользователь оставляет поле пустым, вводит невалидный email или пытается сохранить карточку без обязательных данных. Что должно произойти? Показывается подсказка? Отправляется уведомление?
• Что входит в “обучение сотрудников”. Это часто указывается в ТЗ как пожелание: «обучить всех менеджеров». Но кем? Когда? В каком формате? Разработка книги инструкций? Встреча в Zoom? Тестовые задания? Без этих деталей обучение превращается в “между делом”.
• Ответственность за справочники. В CRM обычно используются словари (статусы сделок, каналы обращения, категории клиентов). Кто их наполняет? Подрядчик или клиентская команда? Часто оказывается, что «настроить справочники» — это целый проект внутри организации.
• Поведение при удалении данных. Можно ли удалять клиента? Удаляются ли с ним связанные задачи и документы? Предусмотрена ли «корзина» или архив?
• Доступ к интерфейсу и IP-фильтрация. Многие компании хотят закрытый доступ — например, только с корпоративных IP-адресов или через VPN. Это следует указать заранее.
• Сценарии масштабирования. Предусмотрен ли резерв на случай роста базы? Например, сейчас 5 менеджеров, через год — 50. Есть ли возможность пересмотреть архитектуру без миграции?

Что точно не стоит описывать в ТЗ?

• Цвета кнопок, стиль иконок, отступы — если вы не дизайнер. Лучше приложите референсы интерфейса или закажите UI-дизайн параллельно.
• Описывать усложнённую логику без привязки к цели. Например: «пусть у нас будет вкладка “Партнёры”, где будет выводиться всё, что выводится в “Клиенты”, но наоборот». Что значит “наоборот”? Зачем?
• Фразы вроде «сделать лучше, чем у конкурентов» — это хорошая цель, но не техническое требование.

Всё, что не измеримо или непроверяемо, не является частью технического задания. Сделайте структуру — оставьте эмоции.

Технические детали, которые влияют на разработку, но часто игнорируются

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

• Среда размещения. Где будет размещаться система? Возможные варианты:
• На выделенном сервере внутри компании (on-premise)
• В облаке: Amazon, Azure, Google Cloud, российские провайдеры
• На сервере подрядчика
• Уточните: кто отвечает за хостинг, кто обеспечивает резервное копирование, как происходит доступ и обновление версий.
• Безопасность и доступ. Следующие требования надо обсудить заранее:
• Нужен ли доступ только с определённых IP-адресов
• Нужны ли двухфакторная аутентификация и логика блокировки при неудачных входах
• Как защищаются данные клиентов, особенно персональные (в соответствии с политикой обработки персональных данных)
• Необходимость API. Если CRM должна «общаться» с другими системами (сайты, почта, сторонние приложения), укажите, какие API доступны, какой формат данных нужен, кто отвечает за реализацию сторонней части.
• Offline-доступ. Часто забывается, но если сотрудники работают в полевых условиях (например, на объектах без интернета) — нужна offline-функциональность. Определите:
• Какие модули должны работать без подключения
• Как синхронизируются данные и решаются конфликты
• Планируемая нагрузка. Сколько:
• Активных пользователей будет в системе одновременно
• Заявок и лидов в сутки
• Звонков / писем / документов в день
• Без этих данных сложно выбрать архитектуру и компоненты системы, а также оценить потенциал масштабирования.

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

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

Даже объёмное ТЗ в 30 страниц может оказаться бесполезным, если оно не отвечает на главный вопрос: «Как должна работать система для достижения нужного бизнес-результата?» Проверить качество технического задания можно по следующим критериям:

• Можно ли по ТЗ понять, как система выглядит на уровне интерфейса? Хорошее ТЗ даёт возможность реставрировать интерфейс “на глаз” — какие блоки есть, какие поля доступны, какие действия может выполнить пользователь. Если возникают сомнения, значит, нужно дополнить примерами экранов или схемами.
• Можно ли по ТЗ запрограммировать логику без уточняющих звонков? Профессиональный разработчик должен иметь возможность развернуть бо́льшую часть системы по ТЗ и приёмочным критериям, не задавая десятки уточняющих вопросов. Если такие вопросы появляются — это повод дополнить документацию.
• Разделены ли границы ответственности? Кто загружает справочники? Кто проводит тестирование? Кто занимается обучением персонала? Чёткие обозначения этих зон позволяют избежать взаимных обвинений на финальном этапе.
• Прописаны ли нестандартные сценарии? В ТЗ не должно быть только успехов — опишите, что делать, если данные не заполнены, файл слишком тяжёлый, контакт не отвечает. Недоставленные письма, ошибки синхронизации, неверные статусы — всё это критически важно для стабильной работы.
• Документ прошёл внутреннюю проверку. Перед передачей подрядчику его должна прочитать не только команда проекта, но и:
• Менеджеры — как потенциальные пользователи
• IT-специалист — для валидации технической части
• Руководитель — для финального согласования требований и целей

Проведите внутреннее ревью по простым вопросам:

• «В какой момент сделка считается успешной?»
• «Что делает система, если контакт отправил два одинаковых лида?»
• «Как понять, что клиент “утеплён” — по количеству звонков? По активности?»
• «Сколько касаний до перевода в “повторный контакт”?»

Хорошее ТЗ не обязательно даёт на всё точные ответы. Главное — чтобы вопросы вообще появились. Это показывает, что бизнес начал размышлять в логике системной организации процессов, а не только “интуитивных привычек”. Чем больше таких вопросов — тем сильнее архитектура будущей CRM.

Заключение: Какой итог должны увидеть в ТЗ вы и разработчик

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

• ✔ Чёткое понимание процессов — кто, где и когда взаимодействует с системой, с каким результатом, кто за что отвечает.
• ✔ Полный перечень модулей и ролей доступа — включая описание функций, уровня прав и группировок пользователей.
• ✔ Прописаны важные исключения и нестандартные сценарии — от ошибок до нестандартного поведения клиента или системы.
• ✔ Уточнены ключевые интеграции и технические ограничения — API, email, телефония, сайты, безопасность, offline-доступ.
• ✔ Закреплены обязанности по обучению, наполнению справочников, тестированию — то, о чём часто забывают до релиза.
• ✔ Выбран понятный формат и инструмент реализации — будь то документ, Notion или wiki-платформа с табличной структурой и схемами процессов.

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