Система контроля просроченных согласований ценовых исключений

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

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

Что считать исключением

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

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

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

Маршрут согласования

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

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

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

Точка учета

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

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

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

Просрочка как сигнал

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

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

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

Правила эскалации

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

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

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

Ответственность и мотивация

Если просрочки ни на что не влияют, система останется декоративной. Я связываю дисциплину с ролями, а не с абстрактной коллективной ответственностью. Менеджер отвечает за полноту и качество запроса. Руководитель продаж — за первичный фильтр и срок реакции в своем лимите. Коммерческий руководитель — за решения вне стандартного коридора и за долю исключений в выручке. Финансы — за контроль маржи и условий оплаты. Администратор системы — за корректность маршрутов, справочников и отчетов.

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

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

Чистота причин

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

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

Запуск без шума

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

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

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

Что получает собственник

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

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