Как описать бизнес-процессы перед разработкой CRM

Наблюдайте работу, а не только обсуждайте идеал

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

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

Определите границы процесса

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

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

Карточка процесса

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

Опишите переходы, а не только статусы

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

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

Разведите полномочия

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

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

Определите качество данных

Назначьте идентификаторы контакта, компании и сделки, правила обязательности и поиска дублей. Телефон может измениться или принадлежать нескольким представителям; название компании может быть записано по-разному. Нельзя без обсуждения считать любое совпадение одной строкой доказательством одинаковой сущности.

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

Как превратить описание в задание

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

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

Пример разбора перехода воронки

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

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

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

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

Как описать изменение предложения в CRM

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

В примере сделка D-14 содержит предложения P-1 и P-2. Первое остаётся в истории, но действующим для дальнейшего оформления считается согласованное P-2. Две версии не превращаются в две продажи. При отказе от дополнительных работ фиксируется решение вернуться к прежнему составу; оно не должно возникать из-за случайного восстановления старого значения поля.

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

На обследовании попросите участников назвать документ, который подтверждает каждый переход. Если подтверждение хранится в почте, определите, как сотрудник найдёт его из CRM. Таблица описывает возможный проектный процесс; она не является заявлением о готовых функциях собственного продукта Webexlab.