ТЗ на автоматизацию продаж: события, правила и восстановление

Автоматизируйте следующий шаг продажи

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

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

Восстановите фактическую работу

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

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

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

Паспорт автоматического правила

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

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

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

Согласия и качество данных

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

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

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

Напоминание, эскалация и завершение

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

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

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

Интеграции и восстановление после сбоя

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

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

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

Метрики без выдуманного эффекта

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

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

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

Приёмочный сценарий с остановкой CRM

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

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

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