Согласование скидки в CRM: как связать решение с версией предложения

Согласование скидки в CRM - это проверка конкретного предложения: его состава, цены, условий оплаты и срока действия. Решение руководителя должно относиться к определённой версии этих условий. Иначе отметка «согласовано» остаётся в карточке, а клиент получает уже другое предложение.

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

Почему одного поля со статусом недостаточно

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

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

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

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

Что включить в запрос на скидку

Хороший запрос позволяет руководителю принять решение без дополнительного сбора информации. Начните с короткого набора обязательных сведений:

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

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

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

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

Как развести полномочия и маршрут решения

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

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

Для каждого решения определите:

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

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

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

Когда прежнее согласование перестаёт действовать

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

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

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

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

Как перенести порядок в amoCRM или Битрикс24

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

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

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

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

Как проверить настройку перед рабочим запуском

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

1. Обычный запрос: согласующий получает полный состав условий, а решение связано с нужной версией.
2. Возврат на уточнение: менеджер видит, чего не хватает; исправленный запрос не теряется среди прежних.
3. Изменение после одобрения: новый состав или порядок оплаты требует повторной проверки по правилу компании.
4. Отказ: предложение не помечается как согласованное после закрытия задачи.
5. Отсутствие руководителя: срабатывает согласованный порядок замещения, без самовольного расширения прав.
6. Техническая правка: изменение, признанное несущественным, сохраняет понятную историю.

Результаты фиксируйте как «ожидалось - получилось - кто проверил». Если один сценарий проходит только благодаря подсказке администратора, доработайте текст задания или маршрут. Управляемость проявляется в одинаковых действиях разных сотрудников.

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

Частые вопросы

Нужно ли согласовывать любую скидку

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

Достаточно ли комментария руководителя в карточке

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

Можно ли сразу настроить сложный маршрут

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

Источники

• Справка amoCRM: создание новой задачи.
• Справка Битрикс24: запуск бизнес-процесса в карточке CRM.
• Справка Битрикс24: события бизнес-процессов в карточке CRM.