Согласование в компании обычно начинается как переписка. Менеджер пишет руководителю в мессенджер: «клиент просит 12 процентов, даём?». Руководитель отвечает через сорок минут, иногда голосовым, иногда «ок». Через месяц никто не помнит, кто именно разрешил ту скидку, а в отчёте по марже видно только результат.
Согласование скидки в Битрикс24 и согласование договоров в CRM решают ровно эту задачу: перевести устную договорённость в шаг, у которого есть автор, время и след в карточке. Ниже собрано, чем эти два процесса отличаются друг от друга, что нужно решить до настройки, где именно в портале живёт механика согласования и на какие грабли компании наступают чаще всего.
Два разных процесса под одним словом
В компаниях словом «согласование» называют две вещи, устроенные по-разному. Их полезно разделить до того, как что-то настраивать.
Первое, это разрешение отступить от правил. Менеджер хочет дать скидку больше стандартной, изменить срок оплаты, отгрузить без предоплаты. Здесь решение принимает один человек, обычно быстро, а вопрос звучит как «да или нет». Такое согласование должно занимать минуты, иначе оно превращается в тормоз сделки.
Второе, это проверка документа. Договор смотрят юрист, финансист, иногда руководитель направления. Каждый отвечает за свой кусок, и правки от одного меняют текст, который смотрит следующий. Здесь важнее не скорость, а версия документа и порядок прохождения.
Ошибка, которую мы видим регулярно: обе истории пытаются собрать одной и той же схемой. В итоге разрешение на скидку идёт через трёх человек и приходит на следующий день, а договор согласовывает один руководитель, который не читает третий пункт.
Сначала правила, потом кнопки
Настройка в портале занимает несколько часов. Договорённость о том, что именно согласуется, занимает больше времени и приносит больше пользы.
Начните с матрицы полномочий. Это таблица из трёх колонок: что менеджер решает сам, что согласует руководитель отдела, что уходит выше. Для скидок она выглядит примерно так: до 5 процентов менеджер даёт самостоятельно, от 5 до 15 согласует руководитель отдела, свыше 15 согласует коммерческий директор. Цифры у каждой компании свои, важна сама структура.
Дальше определите, что считается основанием. Без этого согласующий получает вопрос «дать скидку?» без контекста и вынужден переспрашивать, а переписка возвращается туда, откуда вы её забирали. Обычно достаточно трёх полей: размер скидки, причина, сумма сделки после скидки.
Третье решение касается сроков. Сколько времени есть у согласующего и что происходит, если он молчит. Вариантов два: заявка ждёт до победного или уходит выше по иерархии. Оба рабочие, но выбрать нужно заранее, иначе первая же командировка руководителя остановит продажи.
И последнее: что происходит при отказе. Сделка возвращается на предыдущую стадию, менеджер получает комментарий с причиной, клиенту уходит другое предложение. Отказ без указанной причины бесполезен, потому что менеджер пойдёт спрашивать в мессенджер, и круг замкнётся.
Где в Битрикс24 живёт механика согласования
Инструментов два, и выбор между ними определяется тарифом и сложностью процесса.
Бизнес-процессы. Это конструктор, в котором собирается цепочка шагов. Официальная документация прямо называет согласование договоров и утверждение отпусков типовой задачей для последовательного бизнес-процесса: шаги выполняются по порядку, каждый начинается после завершения предыдущего. Для более сложных сценариев с ветвлением есть бизнес-процесс со статусами, который представляет собой несколько связанных последовательных процессов и подходит, когда развитие зависит от результата каждого шага.
Роботы и триггеры в CRM. Более простой инструмент, привязанный к стадиям воронки: при переходе на стадию срабатывает действие. Роботами удобно ставить задачи, уведомлять руководителя, планировать дела и фиксировать записи в истории.
Здесь есть тарифная развилка, о которой лучше узнать до проектирования, а не после. Бизнес-процессы и дизайнер бизнес-процессов доступны на тарифах Профессиональный и Энтерпрайз, на Стандартном их нет. Роботы и триггеры в CRM работают уже на Стандартном. Поэтому компания на Стандартном тарифе собирает согласование стадиями воронки и роботами, а полноценную цепочку с ветвлением и параллельными согласующими получает только после перехода на старший тариф.
Практический вывод простой. Если процесс звучит как «одна стадия, один согласующий, два исхода», роботов достаточно. Если в схеме появляются слова «параллельно», «если сумма больше», «вернуть на доработку с сохранением истории», это территория бизнес-процессов.
Как согласование выглядит для сотрудника
Здесь важна деталь, которая определяет, приживётся инструмент или нет. Если бизнес-процесс или робот ждёт согласования сотрудника либо дополнительных данных, сотрудник видит это прямо в карточке элемента CRM: там же отображаются поля для ввода информации по задаче и кнопки согласования и отклонения.
Смысл в том, что руководителю не нужно уходить в отдельный раздел, искать список заявок и вспоминать, о какой сделке речь. Он открывает карточку, видит сумму, клиента, историю переписки и тут же принимает решение.
Из этого следует и требование к настройке: в момент запроса в карточке должны быть заполнены поля, на которые смотрит согласующий. Если размер скидки лежит в комментарии менеджера, а не в поле, согласующий будет открывать переписку, и минутная операция снова станет пятнадцатиминутной.
Согласование скидки: как собрать
Рабочая схема для типичного отдела продаж выглядит так. Приводим её как ориентир, а не как единственно верный вариант.
В карточке сделки заводятся поля: запрашиваемая скидка в процентах, причина запроса, итоговая сумма. Причина оформляется списком, а не текстом: удержание клиента, объём закупки, конкурентное предложение, повторная продажа. Список нужен для того, чтобы через полгода можно было посчитать, за что именно компания раздала маржу.
В воронке появляется стадия «Согласование скидки». Менеджер переводит сделку на неё после заполнения полей. Стадия делает две вещи сразу: запускает запрос согласования и физически показывает в канбане, сколько сделок стоит и ждёт решения. Второе часто оказывается полезнее первого, потому что очередь становится видимой.
Согласующий определяется по размеру скидки согласно матрице полномочий. Если запрос укладывается в порог руководителя отдела, он идёт к нему, если превышает, уходит выше.
При положительном решении сделка возвращается в рабочую стадию, скидка фиксируется в поле, а не в устной договорённости. При отказе сделка возвращается назад, а менеджер получает причину отказа. Причина обязательна, иначе схема снова выродится в переписку.
Отдельно предусмотрите поведение при молчании. Самый частый вариант: через определённое время согласующий получает напоминание, а после второго напоминания уведомление уходит его руководителю. Это не наказание, а способ не потерять сделку из-за отпуска.
Что подготовить в карточке до запуска
Согласование живёт не само по себе, а поверх данных сделки. Если данных нет, никакая схема не спасёт, поэтому перед настройкой стоит пройтись по четырём пунктам.
Поля. Всё, на что смотрит согласующий, должно быть отдельным полем карточки, а не строчкой в комментарии. Список полей короткий: размер скидки, причина, сумма после скидки, при необходимости срок оплаты. Чем меньше полей, тем выше шанс, что менеджеры будут их заполнять.
Обязательность. Поля запроса имеет смысл делать обязательными на той стадии, где запускается согласование, а не с самого начала. Обязательное поле скидки в первой стадии воронки будет мешать всем сделкам, включая те, где скидки не будет вовсе.
Права доступа. Согласующий должен видеть карточку целиком, включая сумму и историю. Здесь всплывает частая проблема: руководитель отдела не видит сделки соседнего направления, а согласовывать по матрице должен именно он. Права проверяются до запуска, иначе первое же согласование упрётся в пустой экран.
Связь с документами. Согласованная скидка должна попадать в счёт и в коммерческое предложение из поля, а не переноситься руками. Если шаблоны документов подтягивают цену из другого места, расхождение появится в первую же неделю, и доверие к процессу пропадёт быстрее, чем вы успеете его донастроить.
Эти четыре пункта занимают несколько часов работы и снимают большую часть претензий, которые обычно возникают через месяц после запуска.
Согласование договора: чем оно отличается
С договором всё иначе, и попытка использовать ту же схему обычно проваливается по трём причинам.
Первая: согласующих несколько, и у каждого свой предмет проверки. Юрист смотрит ответственность и подсудность, финансист отвечает за условия оплаты, руководитель направления за обязательства по срокам. Если пустить их последовательно, срок согласования складывается из всех очередей. Если параллельно, придётся решать, что делать с противоречащими правками.
Вторая: документ меняется по ходу. После правок юриста финансист смотрит уже другой текст. Поэтому в процессе должно быть явно указано, какая версия согласована, и правка после согласования обязана запускать круг заново хотя бы по затронутым разделам.
Третья: у договора есть срок, привязанный к обещанию клиенту. Менеджер сказал «пришлём завтра», и с этого момента согласование живёт в чужом графике. Поэтому в схеме нужен явный срок на каждого участника, а не общий призыв к оперативности.
Рабочий компромисс, который мы обычно предлагаем: типовой договор без изменений идёт по короткому маршруту с одним согласующим, а нетиповой или с правками клиента уходит на полный круг. Разделение по этому признаку сокращает средний срок сильнее, чем любые напоминания, потому что большая часть договоров в компании как раз типовые.
Пять ошибок, из-за которых согласование бросают
Инструмент чаще умирает не от технических проблем, а от организационных. Вот что встречается в аудитах чаще всего.
Согласуют всё подряд. Когда через процедуру проходит каждая сделка, включая те, где менеджер действовал строго по правилам, очередь растёт, а согласующие начинают штамповать «да» не глядя. Согласование имеет смысл только для отклонений от нормы.
Один согласующий без замены. Пока человек на месте, всё работает. Он уходит в отпуск, и отдел возвращается в мессенджер, потому что клиенты ждать не будут. Заместитель должен быть предусмотрен на этапе проектирования.
Нет причины отказа. Менеджер видит «отклонено» и идёт выяснять голосом. Формально процесс есть, фактически он добавил шаг и ничего не заменил.
Согласование не влияет на документы. Скидку разрешили, но в счёт и в коммерческое предложение она попадает руками. Появляется расхождение между тем, что согласовано, и тем, что ушло клиенту, а виноватого потом не найти.
Никто не смотрит статистику. Согласование накапливает ценные данные: сколько скидок запрошено, сколько одобрено, по каким причинам, у каких менеджеров. Если эти цифры не смотреть, компания получает бюрократию вместо управленческого инструмента.
Как это выглядит в жизни
Соберём сказанное в один сценарий. Пример собирательный, но узнаваемый для любой компании со средним чеком и торгом на входе.
Оптовая компания, семь менеджеров, стандартная скидка 5 процентов. Раньше запросы шли в общий чат, коммерческий директор отвечал по мере возможности, а в конце квартала выяснялось, что средняя скидка по отделу составила 11 процентов вместо плановых семи.
После настройки картина другая. Менеджер заполняет три поля и переводит сделку на стадию согласования. Запрос на 9 процентов уходит руководителю отдела, тот открывает карточку, видит сумму сделки, историю закупок клиента и указанную причину, нажимает согласование. Сделка возвращается в работу, скидка зафиксирована в поле и оттуда попадает в счёт.
Запрос на 18 процентов уходит выше. Коммерческий директор видит, что причина указана как конкурентное предложение, но история показывает третью покупку клиента за квартал, и отклоняет запрос с комментарием про допустимые 12 процентов. Менеджер получает конкретную цифру, а не «дорого, подумай ещё».
Через месяц руководитель смотрит статистику и обнаруживает, что 60 процентов запросов приходит от двух менеджеров, а средняя запрошенная скидка у них вдвое выше, чем у остальных. Это уже разговор про работу с возражениями, и он стал возможен только потому, что запросы перестали быть перепиской.
Отдельный побочный эффект: очередь в канбане показала, что запросы копятся по вторникам, когда у согласующего стоит блок совещаний. Проблему решили переносом совещаний, а не автоматизацией.
Что измерять после запуска
Через месяц работы имеет смысл посмотреть на четыре показателя. Они же покажут, нужна ли донастройка.
Среднее время от запроса до решения. Если оно больше нескольких часов по скидкам, схема мешает продажам, и порог самостоятельности менеджера стоит поднять.
Доля одобренных запросов. Если одобряется практически всё, значит, либо пороги занижены, либо согласующий не читает. И то и другое лечится: в первом случае правкой матрицы, во втором разговором.
Распределение причин. Когда 80 процентов скидок идёт по причине «конкурентное предложение», это вопрос не к менеджерам, а к прайсу и позиционированию.
Количество сделок, застрявших на стадии согласования дольше суток. Это прямой индикатор того, что механика напоминаний настроена плохо или согласующий перегружен.
Кто отвечает за схему после запуска
Настроенное согласование живёт до первой реорганизации. Появляется новое направление, меняется руководитель отдела, вводится новая линейка с другой маржой, и матрица полномочий перестаёт совпадать с реальностью. Через полгода менеджеры находят обходной путь, а портал показывает красивую, но неработающую схему.
Поэтому у процесса нужен владелец. Это не администратор портала и не подрядчик, а руководитель, который отвечает за коммерческие правила: обычно коммерческий директор или руководитель продаж. Его задача не настраивать, а решать, кто и что согласует, и сообщать об изменениях тому, кто настраивает.
Минимальный регламент выглядит так. При смене ответственного за направление проверяются согласующие и заместители. При запуске нового продукта проверяются пороги скидок. Раз в квартал руководитель смотрит статистику по запросам и решает, надо ли двигать пороги. Это полчаса работы в квартал, и они окупаются тем, что схема остаётся живой.
Отдельно стоит договориться, куда идти, если процесс сломался: у кого спрашивать, если согласующий недоступен, а сделка горит. Наличие такого ответа в явном виде почти всегда лучше, чем аварийный возврат всей команды в мессенджер.
Что мы делаем на таких проектах
Настройка согласований редко бывает изолированной задачей: она тянет за собой поля в карточке, стадии воронки, права доступа и шаблоны документов. Поэтому мы обычно начинаем с матрицы полномочий и списка исключений, а собираем схему уже под неё.
Если нужно, чтобы этим занялись специалисты, посмотрите наши услуги по Битрикс24: мы проектируем и настраиваем согласования, роботов и бизнес-процессы, а заодно проверяем, соответствует ли ваш тариф тому, что вы хотите автоматизировать. Последнее лучше выяснить до старта работ, чтобы не проектировать цепочку, которую портал на текущем тарифе не выполнит.
Отдельный частый запрос: перенести в портал согласования, которые годами жили в переписке и в головах. Здесь основная работа не техническая, а описательная, и без участия руководителя направления она не делается. Зато после неё портал перестаёт быть местом для хранения контактов и становится тем, где действительно принимаются решения.
Частые вопросы
Можно ли настроить согласование скидки на Стандартном тарифе?
Простое согласование собирается роботами и стадиями воронки, они доступны на Стандартном. Полноценные бизнес-процессы и дизайнер бизнес-процессов доступны на тарифах Профессиональный и Энтерпрайз, поэтому цепочка с ветвлением, параллельными согласующими и возвратом на доработку потребует перехода на старший тариф.
Где сотрудник видит запрос на согласование?
Прямо в карточке элемента CRM. Если бизнес-процесс или робот ждёт согласования либо дополнительных данных, в карточке отображаются поля для ввода информации и кнопки согласования и отклонения, так что искать заявку в отдельном разделе не нужно.
Чем последовательный бизнес-процесс отличается от процесса со статусами?
Последовательный выполняет действия по порядку: каждый этап начинается после завершения предыдущего, и этого достаточно для согласования договоров или заявлений. Процесс со статусами объединяет несколько связанных последовательных процессов и применяется, когда дальнейший ход зависит от результата предыдущего шага.
Что делать, если согласующий в отпуске?
Предусмотреть заместителя ещё при проектировании и задать поведение при молчании: напоминание через заданное время и передачу выше по иерархии. Схема с единственным согласующим без замены разваливается на первой же неделе его отсутствия.
Обязательно ли заводить отдельную стадию воронки под согласование?
Не обязательно, но полезно. Отдельная стадия делает очередь видимой в канбане и позволяет считать, сколько сделок и как долго ждут решения. Без неё запросы растворяются среди прочих задач, и оценить нагрузку на согласующих становится нечем.