Требование к CRM становится проверяемым, когда другой человек может выполнить описанные действия и однозначно оценить результат. Записывайте исходные условия, роль, событие, ожидаемое изменение и исключения. Такая формулировка связывает техническое задание с приёмкой и уменьшает число споров о том, что именно обещали сделать.
Разберите пожелание на наблюдаемые действия
Фраза «руководитель должен контролировать продажи» объединяет несколько задач. Ему могут понадобиться список сделок без следующего шага, причины отказов и прогноз по выбранному периоду. Разделите эти задачи. Для каждой укажите, какое решение руководитель принимает после просмотра данных.
Затем определите единицу проверки. Для списка просрочек это конкретные сделки и сроки задач, для прогноза — правила включения суммы и ожидаемой даты. Не записывайте «данные должны быть корректными» без способа сверки. Корректность подтверждается сравнением с согласованным набором исходных записей и заранее рассчитанным результатом.
Используйте форму «дано — действие — результат»
Условный пример: дано обращение нового клиента с выбранной услугой, действующим телефоном и источником. После отправки формы создаётся предусмотренная карточка, сохраняются значения, назначается доступный ответственный. Пользователь видит подтверждение только после принятия заявки выбранным контуром обработки.
Теперь добавьте негативную ветку. При недоступности CRM обращение сохраняется для повторной доставки, а ответственный получает сигнал по согласованному правилу. После восстановления создаётся одна карточка. Это проектируемое поведение интеграции, которое нужно реализовать и проверить; его нельзя считать автоматическим свойством любой формы или CRM.
Назовите допустимые исключения
У одного клиента может быть несколько запросов, один телефон может использоваться отделом закупок, а заявка может не содержать компанию. Для каждого случая решите, что считается нормальным результатом. Если допустимо ручное уточнение, укажите, кто получает задачу и какие данные доступны до завершения проверки.
Не делайте требование чрезмерно жёстким там, где бизнес не имеет однозначного правила. Например, обязательный бюджет до первого разговора провоцирует фиктивное заполнение. Лучше указать этап, на котором значение действительно необходимо, и отдельное состояние «ещё не выяснено». Пустое поле не должно молча превращаться в нулевую сумму.
Подготовьте данные для приёмки
Соберите небольшую таблицу: номер сценария, исходные карточки, роль исполнителя, шаги, ожидаемые значения, фактический результат и доказательство. Включите обычное выполнение, повтор, отмену, возврат на предыдущий этап и ограничение доступа. Количество проверок определяется риском процесса, а не желанием получить длинный документ.
Для условной заявки создайте тестовый контакт с узнаваемым идентификатором. Отправьте её дважды с одним идентификатором события, затем сформируйте отдельное новое обращение того же клиента. В первом случае ожидается отсутствие повторного эффекта, во втором — применение правила новой потребности. Эти проверки различают технический повтор и реальную повторную продажу.
Привяжите требования к изменениям
Каждому требованию присвойте стабильный номер. Если меняется бизнес-правило, обновите связанные тесты, описание полей и инструкцию сотрудника. В журнале укажите причину изменения и того, кто его согласовал. Переписка без связи с номером требования быстро теряет контекст.
Перед приёмкой проверьте: результаты измеримы; роли определены; тестовые данные доступны; исключения рассмотрены; критические сценарии проходят повторно после исправлений. Общую структуру документа можно взять из статьи о ТЗ на CRM. Здесь важно довести каждое значимое пожелание до воспроизводимого опыта, который одинаково понимают заказчик, исполнитель и будущая поддержка. Затем эти сценарии пригодятся и для проверки качества внедрения.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.