ТЗ на внедрение CRM: процессы, данные, интеграции и приёмка

Что должно описывать ТЗ на внедрение CRM

CRM полезна, когда по обращению понятно, кто отвечает за следующий шаг, какие условия обсуждались и почему сделка остановилась. Если техническое задание ограничивается списком полей и просьбой «сделать воронку», эти вопросы остаются без ответа. До выбора системы нужно согласовать модель работы с клиентом, правила данных и доказательства, по которым компания примет внедрение.

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

Начните с трёх реальных обращений

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

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

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

Разделите клиента, контакт и сделку

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

Для дублей задайте правила поиска кандидатов и объединения записей. Совпадение телефона не всегда означает одного человека: номер бывает общим. Автоматическое объединение по слабому признаку способно смешать историю разных клиентов. Предусмотрите очередь спорных совпадений, сохранение ссылок на старые записи и проверку истории после объединения. Документация Microsoft описывает настраиваемые правила обнаружения дублей; их наличие не заменяет проверку поведения конкретной конфигурации.

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

Опишите передачу заявки и исключения

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

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

Опишите передачу работы при увольнении, болезни и смене территории. У клиента не должно исчезнуть следующее действие только потому, что аккаунт менеджера отключён. Проверьте переназначение открытых задач, доступ к переписке, сохранение авторства и уведомление нового владельца. Массовую передачу стоит принимать на небольшом контрольном наборе до применения ко всей базе.

Интеграции: договоритесь о значении каждого события

Для сайта, телефонии, почты, мессенджера и учётной системы составьте паспорт обмена. В нём нужны направление передачи, обязательные поля, идентификаторы, допустимая задержка, права сервисного пользователя и поведение при отказе. Фраза «интеграция с 1С» не объясняет, какие документы и статусы передаются и кто разрешает конфликт двух изменений.

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

Приёмка включает отключение внешней системы, повторную доставку и восстановление. Проверяется не только появление карточки: важно сохранение источника, связи с клиентом и следующего действия. Менеджер должен видеть честный статус синхронизации. Сообщение «обработано» недопустимо, если событие лишь поставлено в очередь и получатель его ещё не подтвердил.

Перенос истории и доступ сотрудников

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

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

Матрица доступа должна различать просмотр, изменение, экспорт и административные действия. Проверьте чужое направление, массовую выгрузку и отключённого сотрудника. Скрытая кнопка экспорта не является доказательством запрета: проверка выполняется и на стороне сервера. Журнал изменений должен помогать восстановить значимые действия, не превращаясь в бесконтрольное хранилище лишних персональных данных.

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

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

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

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

Как оценить объём и первую очередь

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

Для оценки передайте количество сущностей и интеграций, качество базы, объём истории, число ролей, примеры исключений и доступность тестового контура. Отдельно учтите обучение, исправление данных и сопровождение после запуска. Лицензия CRM не покрывает автоматически работы по процессу, переносу и адаптации команды; конкретный состав зависит от выбранной системы и договора.

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

Бриф для согласования с командой

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

Перед передачей на оценку проведите совместный разбор с продажами, руководителем, интегратором и ответственным за данные. Каждый должен объяснить один и тот же пример одинаково: откуда пришёл клиент, почему выбран менеджер, что происходит дальше и где зафиксирован результат. Если объяснения расходятся, уточняйте требования до настройки. Хорошее ТЗ заканчивается проверяемой моделью работы, а не длинным перечнем возможностей продукта.