Контроль просроченных согласований цен в индивидуальных коммерческих предложениях

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

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

Где возникает сбой

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

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

Основа системы

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

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

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

Сроки

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

Смысл матрицы не в бюрократии, а в снятии споров. Менеджер заранее понимает, кому направлять запрос. Руководитель продаж не решает каждый раз с нуля, чей это уровень. Финансовый блок не тратить время на заявки без исходных данных. Собственник видит единый стандарт, а не набор исключений.

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

Ответственность

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

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

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

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

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

Без такого разделения ролей бизнес снова скатывается в обсуждение, кто «не увидел сообщение».

Единый реестр

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

Хороший реестр отвечает на пять вопросов без ручного поиска:

Если реестр не дает этих ответов, он превращается в архив, а не в инструмент управления.

Эскалация

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

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

Критерии полной заявки

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

Я ввожу короткий чек-лист полноты. В нем только то, без чего решение невозможно: составь предложения, базовая цена, запрашиваемая цена, маржа или валовая прибыль, причина скидки, цель уступки, срок действия предложения, условияловия оплаты, особые обязательства перед клиентом. Пока чек-лист не закрыт, заявка не попадает в очередь согласования. Это резко уменьшает число «зависаний», которые на деле были сырой подготовкой.

Показатели

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

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

Практика внедрения

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

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

Ежедневный ритм

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

При таком ритме проблема не копится. Просрочка перестает быть старой привычкой и становится отклонением с именем, сроком и ценой.

Ошибки собственника

Самая дорогая ошибка — лично согласовывать слишком многое. Когда любое нестандартное предложение тянется к собственнику, компания создает бутылочное горлышко. Люди привыкают ждать верхнего решения даже там, где хватило бы лимита руководителя отдела. предсказуем: зависшие заявки, нервные менеджеры, клиенты без ответа.

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

Третья ошибка — терпеть устные исключения. Как только в системе появляются договоренности «я уже согласовал голосом», реестр теряет силу. Любое исключение заносится в карточку заявки, иначе бизнес снова остается без фактовв.

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

Что меняется после запуска

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

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