Согласование скидки: полномочия, условия сделки и фиксация решения

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

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

Какую задачу решает этот процесс

Представим рабочую ситуацию. Руководитель продаж разрешил менеджеру дать клиенту скидку 10%. Затем менеджер изменил скидку на 15%, но в CRM по-прежнему отображается прежнее одобрение. Формально решение есть, однако оно относится к другим условиям.

Процесс согласования должен дать руководителю три проверяемых ответа:

1. Какие условия видел согласующий.
2. Кто и когда принял решение.
3. Совпадают ли текущие условия сделки с одобренной версией.

Результат — не абстрактное разрешение «дать скидку», а запись вида: «версия v1 с ценой 10 000 и скидкой 10% одобрена указанным сотрудником». Изменение влияющего на цену условия создаёт новую версию или переводит сделку на повторную проверку.

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

Какие данные и правила подготовить

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

Все значения в последнем столбце вымышлены для объяснения процесса и не относятся к клиенту Switch On AI.

Маржу нельзя подменять выручкой или ценой продажи. Если подтверждённой себестоимости нет, поле остаётся неизвестным. Когда заказчик предоставляет себестоимость C, маржу в деньгах можно определить как M = P − C, где P — цена после скидки. Маржинальность — другой показатель: R = (P − C) / P × 100%. Метод расчёта утверждает профильный специалист заказчика.

Какие правила скидок нужны до автоматизации

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

Основой служит матрица полномочий:

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

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

Как отправить на согласование нужную версию сделки

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

• ID сделки и номер версии;
• состав предложения;
• используемый прайс;
• цена до скидки;
• размер и сумма скидки;
• предлагаемая итоговая цена;
• роль или идентификатор согласующего;
• время запроса и срок решения.

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

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

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

Как исполнить и сохранить решение

Маршрут должен различать как минимум три результата:

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

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

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

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

Учебный пример: путь от входных данных до результата

Ниже — полностью синтетический пример. Числа, версии и название роли условны; это не файл, не клиентский кейс и не результат внедрения Switch On AI.

Исходная цена P0 = 10 000. Менеджер запрашивает скидку d1 = 10%.

• Сумма скидки: S1 = P0 × d1 = 10 000 × 0,10 = 1 000.
• Цена после скидки: P1 = P0 − S1 = 10 000 − 1 000 = 9 000.

Согласующий одобряет версию v1. Поэтому действующая цена становится равна 9 000 условных единиц.

После этого менеджер меняет скидку на d2 = 15%:

• Новая сумма скидки: S2 = 10 000 × 0,15 = 1 500.
• Новая предлагаемая цена: P2 = 10 000 − 1 500 = 8 500.

Но 8 500 ещё не становится действующей ценой. Одобрение v1 относилось к скидке 10%, поэтому для v2 нужен новый запрос.

Третья строка показывает возможный результат нового одобрения, а не автоматическое продолжение первого. Строку v1 сохраняют без изменений. Именно журнал версий позволяет доказать, почему до второго решения действовала цена 9 000, а после него — 8 500.

Как проверить результат перед запуском

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

Перед запуском команда должна подтвердить четыре критерия:

1. Расчёт 10 000 − 10% = 9 000 воспроизводится.
2. Роль согласующего обладает утверждёнными полномочиями.
3. Одобрение связано с номером версии, а не только со сделкой.
4. Изменение скидки не меняет действующую цену без нового решения.

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

Что согласовать для внедрения

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

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

Switch On AI может разработать ИИ-помощника, бота или интеграцию для этой операции после проверки данных, API и прав доступа. Цель настройки — обеспечить правило «согласованная скидка относится к конкретной версии условий сделки». Совместимость с конкретной CRM, тарифом или приложением проверяется отдельно; статья не подтверждает выполненное внедрение какого-либо вендора.

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

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