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

До начала разработки CRM заказчику и команде нужно договориться, как система будет работать на реальных сделках. Кто принимает заявку, какие сведения запрашивает, когда передаёт её коллеге и что происходит при ошибке. Эти договорённости составляют основу технического задания. Перечень экранов и пожеланий к интерфейсу без описания работы сотрудников оставляет слишком много решений на потом.

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

Сначала определите границы первой версии

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

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

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

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

Соберите рабочие материалы и назначьте владельцев решений

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

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

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

Опишите движение сделки, а не только набор разделов

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

Рассмотрим учебный пример для компании, которая продаёт оборудование. Он показывает способ описания требований и не относится к конкретному проекту Sibcode.

Пример процесса от обращения до предложения

• После отправки формы на сайте CRM получает обращение и сохраняет его источник, контактные данные и интересующий товар.
• Система ищет существующего клиента по согласованному правилу. При неоднозначном совпадении обращение поступает на ручную проверку, а карточки не объединяются автоматически.
• Новое обращение назначается менеджеру по правилам распределения. Если подходящего сотрудника нет, оно остаётся в очереди, за которую отвечает руководитель.
• Менеджер уточняет состав заказа и заполняет обязательные сведения. Без них перейти к подготовке предложения нельзя.
• Если требуется нестандартная скидка, предложение отправляется согласующему сотруднику. До его решения документ нельзя отметить как согласованный.
• После согласования менеджер отправляет предложение клиенту, а CRM сохраняет документ и время отправки.

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

Карточки, роли и отчёты

Для клиента, сделки, товара и других объектов перечислите поля, допустимые значения и связи. У каждого обязательного поля должен быть момент, когда его необходимо заполнить. Требовать все сведения при первом обращении неудобно, если часть из них становится известна только после разговора с клиентом.

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

Разделение ролей особенно заметно в системах с внешними пользователями. В CRM юридического сервиса «Мои Права» из портфолио Sibcode клиентам доступны их задачи и документы, а юристы работают с клиентской базой и внутренними процессами. Для такого проекта границы доступа нужно описывать отдельно для каждой группы пользователей.

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

По каждой интеграции согласуйте обмен в обе стороны

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

В задании на интеграцию CRM с другими системами предусмотрите следующие сведения.

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

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

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

Перенос данных и запуск тоже входят в задание

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

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

Также опишите переход сотрудников на новую систему. Будет ли период параллельной работы, кто отвечает на вопросы, в какой момент прекращается ввод данных в прежнюю CRM? Если запуск придётся остановить, должен быть понятен порядок возврата к работе и сохранения уже внесённых изменений.

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

Превратите требования в сценарии приёмки

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

Для учебного процесса с заявкой проверка может выглядеть так.

• В CRM ещё нет клиента с выбранными тестовыми контактами. После отправки формы появляется одно обращение с верным источником и ответственным.
• То же событие передаётся повторно. Новое обращение не создаётся, результат соответствует согласованному правилу обработки повторов.
• Менеджер пытается отправить предложение с несогласованной скидкой. Система запрещает действие и показывает, какое согласование требуется.
• Учётная система временно недоступна. Ошибка обмена сохраняется, ответственный видит её, а после восстановления доступен предусмотренный повтор.
• Сотрудник другого отдела открывает сделку без необходимых прав. Закрытые сведения и вложения ему недоступны.

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

Оставьте место для изменений, но сделайте их видимыми

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

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

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