Как настроить правила возврата сделки на предыдущий этап и фиксировать причину

6 минут чтения

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

Что определить до настройки отката сделки

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

Выберите этапы, с которых разрешён возврат

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

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

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

Составьте справочник причин и подготовьте поле для фиксации

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

Что понадобится:

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

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

Настройте правило перехода на предыдущий этап

Перед изменениями зафиксируйте текущие настройки и согласуйте время внедрения с командой. Если система позволяет, сначала настройте и проверьте правило в тестовой воронке.

  • Уточните этапы, между которыми разрешён возврат.
  • Проверьте, что поле причины создано и доступно для заполнения сотрудникам.
  • Определите роли, которым можно менять этап на более ранний.
  • Убедитесь, что автоматизации, связанные с переходом, не запускают нежелательные действия повторно.
  1. Откройте настройки воронки.
    Найдите раздел, где задаются этапы сделки, переходы между ними и права сотрудников. В зависимости от системы правило может находиться в настройках воронки, роботов, бизнес-процессов или контроля переходов.
  2. Задайте допустимые направления возврата.
    Для каждого разрешённого сценария укажите исходный и целевой этап. Например, возврат с «Согласование условий» на «Подготовка предложения» разрешён, а переход с «Успешно завершено» обратно — только ответственному руководителю или запрещён.
  3. Ограничьте доступ по ролям.
    Разрешите возврат тем сотрудникам, которым он необходим для работы. Если платформа поддерживает отдельные права на смену этапа, не расширяйте их больше, чем требуется.
  4. Сохраните правило и проверьте его действие.
    Убедитесь, что разрешённый переход выполняется, а запрещённый блокируется или требует согласования. Не запускайте правило на всех рабочих сделках, пока не проверите оба сценария.

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

Сделайте указание причины обязательным при возврате

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

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

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

Проверьте откат на тестовых сделках

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

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

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

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

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

Отслеживайте возвраты и уточняйте правила

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

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

Разбор нестандартных случаев при возврате сделки

Можно ли разрешить возврат только руководителю?

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

Что делать, если для причины нужен комментарий?

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

Как поступить, если нужно вернуть сделку сразу на несколько этапов назад?

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

Можно ли сохранять несколько причин для одной сделки?

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

Что проверить, если переход заблокирован даже с заполненной причиной?

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

Нужно ли очищать причину при переходе сделки вперёд?

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

Как действовать, если в CRM нет условия для обязательного поля при возврате?

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

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх