CRM и планирование
Техническое задание на внедрение CRM
ТЗ на CRM должно описывать не список красивых функций, а рабочий процесс: кто создает лид, какие данные обязательны, как меняются статусы, кто видит карточку, какие системы обмениваются данными и по каким проверкам этап считается готовым.
Коротко
Техническое задание на внедрение CRM включает цель и метрики, текущий и целевой процесс, роли и права, воронки и статусы, поля карточек, автоматизации, интеграции, правила миграции, требования к безопасности, отчеты и сценарии приемки. Каждое требование должно быть связано с действием пользователя или бизнес-правилом.
Что должно решать ТЗ на внедрение CRM
Техническое задание синхронизирует бизнес и исполнителя. Оно фиксирует, какой процесс меняется, какие действия выполняют пользователи и как проверить результат. Документ не должен копировать маркетинговое описание CRM или перечислять каждый пункт интерфейса.
Начните с текущей проблемы и измеримого результата. Например: сейчас 18% заявок остаются без задачи, отчет собирается два дня, а передача клиента другому менеджеру требует ручного пересказа. Цель: все новые лиды получают ответственного и следующую задачу, а отчет строится из фактических статусов.
| Слабая формулировка | Рабочее требование |
|---|---|
| Удобная CRM | Менеджер видит новые лиды и назначенную задачу на одном экране |
| Автоматизация продаж | После отправки формы создается лид с источником и ответственным |
| Гибкие права | Менеджер видит свои сделки, руководитель — сделки отдела |
| Понятные отчеты | Отчет показывает входящие лиды, переходы и отказы за период |
| Интеграция с сайтом | Поля формы сопоставляются с карточкой и не создают дубль по телефону |
Опишите текущий и целевой процесс
До настройки нужно разобрать несколько реальных сделок. Для каждой отметьте источник, действия, данные, решения, исключения и результат. Так появляются реальные стадии, а не абстрактная воронка из шаблона.
Статус нужен, если он меняет ответственность, обязательное действие или управленческое решение. Названия «думает», «теплый» и «в процессе» трудно проверять. Формулировки «назначена встреча», «ожидаем документы» и «счет отправлен» описывают конкретное состояние.
- Зафиксируйте событие входаЧто создает лид: форма, звонок, письмо, импорт или сотрудник.
- Опишите квалификациюКакие данные нужны, чтобы решить, подходит ли обращение.
- Согласуйте стадииДля каждой — условие входа, обязательное действие и условие выхода.
- Добавьте исключенияДубль, спам, возврат на предыдущий этап, повторное обращение.
- Определите завершениеПродажа, отказ, отложенный спрос или передача в другой процесс.
Зафиксируйте роли, права и структуру данных
В ТЗ перечисляют роли через действия: что пользователь видит, создает, редактирует, экспортирует и удаляет. Права лучше строить по принципу минимально необходимого доступа. Отдельно описывают замещение, смену ответственного и действия администратора.
Поля карточки делят на обязательные, вычисляемые, системные и справочные. Для каждого важного поля указывают тип, источник, допустимые значения, кто может менять и где оно используется. Не добавляйте данные «на будущее», если никто не принимает по ним решение.
| Объект | Минимум в ТЗ |
|---|---|
| Лид | Источник, контакт, ответственный, задача, результат квалификации |
| Контакт | Уникальность, компания, каналы связи, согласия |
| Сделка | Сумма, стадия, вероятность, продукты, документы |
| Задача | Тип, срок, исполнитель, результат и просрочка |
| Пользователь | Роль, отдел, руководитель, активность и замещение |
| Справочник | Владелец, значения, импорт и история изменений |
Пример правила доступа
«Менеджер видит и редактирует сделки, где он ответственный; руководитель отдела видит сделки сотрудников своего отдела; финансовый сотрудник видит сумму и оплату, но не меняет коммуникацию; администратор управляет ролями, но каждое критичное действие записывается в журнал».
Опишите интеграции как обмен событиями
Фраза «интегрировать сайт, телефонию и 1С» недостаточна. Для каждой системы нужны направление данных, момент передачи, ключ сопоставления, поведение при дубле, ошибка, повтор и способ ручной проверки.
Назначьте источник истины. Например, контакт и сделка принадлежат CRM, остаток — ERP, подтвержденная оплата — платежной системе, а сайт только инициирует заказ. Без этого одна и та же сущность будет независимо меняться в нескольких местах.
| Интеграция | Пример проверяемого сценария |
|---|---|
| Сайт | После формы создается один лид с URL, UTM и выбранной услугой |
| Телефония | Входящий звонок находится по номеру и сохраняется в историю |
| Почта | Письмо привязывается к контакту и доступно ответственному |
| Платежи | Подтвержденный вебхук меняет оплату без повторной операции |
| ERP / 1С | Состав заказа и статус синхронизируются по внешнему ID |
- Название системы и ссылка на актуальную документацию API.
- Тестовые и боевые доступы, ограничения и владелец аккаунта.
- Событие запуска обмена и список передаваемых полей.
- Уникальный идентификатор для сопоставления и защиты от дублей.
- Таймаут, повтор, журнал ошибки и уведомление ответственного.
- Проверка результата в CRM и внешней системе.
Включите миграцию, безопасность и эксплуатацию
Миграция начинается с инвентаризации, а не с загрузки всех старых файлов. Определите актуальные справочники, открытые сделки, необходимую историю и архив. Проведите тестовый перенос, сравните количество записей, дубли и обязательные поля, затем повторите на согласованную дату.
В требованиях к безопасности укажите вход, многофакторную аутентификацию при необходимости, роли, журнал критичных действий, резервные копии, срок хранения данных и процедуру отключения сотрудника. Секреты интеграций не должны находиться в браузере или общей таблице.
Эксплуатация описывает мониторинг, ответственного, SLA, резервное восстановление и выпуск изменений. Без этого проект формально заканчивается запуском, а бизнес остается без понятного способа реагировать на ошибку.
- Очистить источникУдалить явные дубли и согласовать обязательные поля.
- Сделать тестовый импортПроверить небольшую выборку и сопоставление связей.
- Сверить результатКоличество объектов, ошибки, права и поиск карточек.
- Запланировать переключениеВремя остановки старого ввода и финальный перенос.
- Сохранить архивДанные, не нужные в ежедневной работе, остаются доступными по правилам.
Добавьте сценарии приемки и границы проекта
Приемка должна повторять реальную работу. Для каждого критичного пути опишите исходные данные, действия, ожидаемые записи, права и результат. Фраза «интеграция работает» заменяется сценарием: форма отправлена, создан один лид, источник сохранен, ответственному поставлена задача, ошибка видна в журнале. В кейсе Arc CRM видно, как роли, статусы и рабочие действия складываются в единый ежедневный процесс.
Отдельно перечислите, что не входит в этап: полный перенос архива, разработка сайта, изменение внешней 1С, аналитический BI-модуль или процессы других отделов. Границы защищают проект от скрытого расширения и помогают планировать следующие релизы.
- Пользовательский сценарий и роль.
- Тестовые входные данные.
- Ожидаемые карточки, поля, статусы и задачи.
- Ожидаемое поведение при ошибке и повторе.
- Проверка прав доступа и журнала действий.
- Критерий завершения и ответственный за приемку.
Хорошее ТЗ на CRM описывает не то, как выглядит система, а то, как компания надежно выполняет работу и проверяет результат.
FAQ
Частые вопросы
01Кто должен писать ТЗ на CRM?
Бизнес-владелец процесса и аналитик или интегратор совместно. Компания определяет правила и приоритеты, а техническая команда переводит их в данные, роли, интеграции и критерии приемки.
02Можно ли внедрять CRM без подробного ТЗ?
Небольшой пилот можно начать с карты процесса и короткого backlog. Но роли, данные, интеграции и критерии готовности все равно нужно зафиксировать до настройки критичных сценариев.
03Нужно ли описывать каждый экран?
Нет. Важнее действия, данные, права и состояния. Макеты нужны для нестандартных интерфейсов, но типовые формы CRM можно принимать по сценариям и согласованной конфигурации.
04Как описывать интеграцию с сайтом?
Указать событие, поля, источник, правила дублей, ответственного, задачу, UTM, обработку ошибки, повтор и способ проверить запись с обеих сторон.
05Что вынести в отдельный этап?
Редкие отчеты, процессы других отделов, полный исторический архив и сложные автоматизации, которые нельзя проверить до появления чистых данных и устойчивой работы команды.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Соберем ТЗ на первый CRM-контур
Покажите текущую таблицу, воронку и интеграции. Зафиксируем процесс, роли, данные и критерии приемки без лишней бюрократии.