Регламент отдела продаж: как написать с нуля и не забросить через месяц
Как составить рабочий регламент звонков по этапам сделки и сделать так, чтобы он не осел в папке, а реально контролировался.
Обычно всё начинается одинаково. Новый менеджер выходит на линию, и через неделю выясняется, что он здоровается по-своему, презентует продукт по-своему и вообще не спрашивает бюджет клиента, потому что "как-то неудобно". РОП садится и за вечер пишет регламент: как отвечать на звонок, что говорить на каждом этапе, какие возражения закрывать и как. Документ получается на восемь страниц, его рассылают в чат отдела, все ставят лайк — и через месяц никто, включая автора, не помнит, что там написано.
Дело не в том, что регламент был плохим. Дело в том, что регламент почти никогда не умирает от плохого текста — он умирает от того, что его невозможно проверить. Написать правила легко. Тяжело сделать так, чтобы они не разошлись с тем, что реально происходит на звонках уже через две недели.
Зачем регламент вообще, если менеджеры и так продают
У опытного продавца обычно есть свой стиль, и часто он неплохо работает. Проблема регламента не в том, чтобы заменить этот стиль, а в том, чтобы у отдела был единый минимум: что обязательно нужно узнать у клиента, какие возражения закрыты стандартным ответом, а не импровизацией, и на каком этапе звонок считается проваленным, а не просто "неудачным".
Без этого минимума РОП управляет отделом на ощупь. Один менеджер выясняет бюджет и сроки на первом звонке, другой — только на третьем, если вообще выясняет. Один проговаривает конкурентные преимущества по чек-листу, другой полагается на память. При этом все звонки выглядят одинаково живо и профессионально — если слушать выборочно, десять минут из ста звонков, различить систему от хаоса почти невозможно.
Регламент — это не сценарий, по которому нужно говорить слово в слово. Это список вещей, которые обязаны произойти на звонке, независимо от того, кто его ведёт.
Структура: пишите по этапам звонка, а не по темам
Самая частая ошибка в первой версии регламента — писать его по темам ("как работать с возражениями", "как презентовать цену"), а не по хронологии разговора. Из-за этого документ читается как справочник, а не как инструкция к действию, и менеджер, который открыл его перед звонком, не понимает, с чего начинать.
Рабочая структура строится вокруг этапов конкретного звонка:
Открытие. Что обязательно произносится в первые 30 секунд: представление, название компании, повод для звонка. Здесь же — что делать, если клиент сразу говорит "нам неинтересно" на автомате, не выслушав предложение.
Выявление потребности. Список вопросов, которые должны прозвучать до презентации продукта: бюджет, сроки, кто принимает решение, что клиент уже пробовал. Это тот этап, который менеджеры пропускают чаще всего, потому что хочется скорее перейти к рассказу о продукте.
Презентация. Какие выгоды озвучивать в зависимости от того, что ответил клиент на предыдущем этапе — не единый монолог для всех, а развилки.
Работа с возражениями. Три-пять типовых возражений с эталонным ответом на каждое. Не "дорого — объясните ценность", а конкретная формулировка, которую менеджер может произнести почти дословно.
Закрытие. Что считается результативным завершением звонка: договорённость о следующем шаге с датой, а не расплывчатое "созвонимся на неделе".
Такая структура важна ещё по одной причине: именно по этапам звонка проще всего потом проверять, что реально происходит в разговорах, а не только читать документ.
Ошибка "написали и забыли"
Регламент на восемь страниц, который живёт в закреплённом сообщении Telegram-чата, обречён. Не потому что он плохо написан, а потому что у него нет механизма обратной связи. РОП физически не может каждый день слушать по десять-пятнадцать звонков на менеджера и сверять их с документом — а если регламент не проверяется, он быстро становится необязательным к прочтению.
Дальше события развиваются по одному и тому же сценарию. Новый менеджер регламент не читает вообще, потому что его никто не спрашивает. Опытный менеджер отклоняется от него всё сильнее, потому что за отклонение не следует никакой реакции. Через два-три месяца регламент существует только на бумаге, а отдел продаёт так, как получается у каждого конкретного человека — то есть без него.
Ручной контроль здесь не масштабируется в принципе: даже дисциплинированный РОП физически прослушивает выборочно — часть звонков, часть менеджеров, вручную выписывая своё мнение. При таком объёме проверка регламента превращается в вопрос удачи: какие звонки попались на прослушку в этом месяце.
Единственный способ, при котором регламент реально доживает до контроля, — сделать так, чтобы проверялся не выборочный кусок, а каждый звонок, и чтобы вывод по каждому пункту был не оценкой на глаз, а опирался на то, что менеджер реально сказал.
Как регламент превращается в чек-лист, который проверяется каждый день
Здесь регламент отдела продаж и инструмент контроля должны совпадать буквально — иначе документ и практика снова разойдутся. В CANAL это устроено так: вы загружаете уже написанный регламент или скрипт продаж, и система сама строит из него чек-лист критериев — не абстрактную "оценку общения", а конкретные пункты вроде "выяснил бюджет", "закрыл возражение по цене эталонным ответом", "договорился о дате следующего звонка".
Дальше каждый звонок разбирается по этим критериям автоматически, и под каждым вердиктом — точная цитата из разговора с таймкодом, а не голая оценка "выполнено/не выполнено". Это меняет саму природу разбора звонков с РОПом: вместо "мне кажется, ты плохо отработал возражение" — конкретная фраза клиента и конкретная (или отсутствующая) реакция менеджера на неё. Регламент из документа в чате становится тем, с чем реально сверяют звонки каждый день, а не раз в квартал перед аттестацией.
Посмотреть, как выглядит такой разбор на реальном примере, можно на демо-звонке без регистрации — там видно и структуру чек-листа, и формат цитат с таймкодами.
Как внедрить регламент так, чтобы он прижился
Три вещи, которые определяют, приживётся регламент или нет.
Во-первых, регламент нужно тестировать на реальных звонках, а не писать в вакууме. Возьмите десять-пятнадцать уже записанных разговоров, разных по исходу, и проверьте черновик регламента на них: понятно ли, что должно было произойти на каждом этапе, и легко ли определить, произошло это или нет.
Во-вторых, регламент нуждается в постоянной обратной связи, а не в разовом внедрении. Если у РОПа нет способа систематически видеть, где отдел от него отклоняется, регламент неизбежно устареет и перестанет соответствовать тому, что реально работает с текущими клиентами. Подключить CRM и телефонию под такой регулярный контроль можно самостоятельно: Bitrix24, amoCRM и Chatwoot заводятся за 10 минут без звонка менеджеру и без внедренцев, регистрация — на странице входа. Для остальных систем звонок инженеру всё равно не понадобится — подключение включено в стоимость.
В-третьих, регламент должен быть проверяемым по каждому звонку, а не по выборке. Если контроль охватывает пять звонков из ста, отклонения от регламента копятся именно в тех девяноста пяти, которые никто не слышал. Как именно устроена автоматическая проверка ста процентов звонков и куда уходят результаты, подробно разобрано на странице как это работает.
Частые вопросы
Регламент должен быть скриптом слово в слово или можно оставить менеджеру свободу? Свобода в формулировках — это нормально, если обязательные пункты (что выяснить, что закрыть, чем завершить разговор) остаются одинаковыми для всех. Жёсткий скрипт слово в слово обычно работает хуже: звонок звучит неестественно, и клиент это чувствует.
С чего начинать регламент, если в отделе никогда его не было? С разбора десяти-двадцати реальных звонков — лучших и худших. Разница между ними почти всегда даёт готовую структуру: что делают сильные менеджеры и не делают слабые. Регламент, написанный "из головы" без опоры на реальные разговоры, обычно расходится с практикой в первую же неделю.
Нужно ли отдельно хранить и защищать записи звонков, если по ним строится регламент? Да, и это отдельный вопрос безопасности, а не только методологии. Записи и разборы должны храниться с разграничением доступа по ролям, желательно на серверах в РФ и с соответствием 152-ФЗ — подробности на странице безопасности.
Как часто нужно пересматривать регламент? Ориентир — раз в квартал или после заметного изменения продукта/цен. Но это осмысленно только если у вас есть постоянный поток данных о том, где реальные звонки расходятся с текущей версией регламента — иначе пересмотр снова превращается в работу вслепую.
Регламент не работает сам по себе — он работает, пока кто-то регулярно сверяет с ним реальные звонки. Как только эта сверка становится систематической, а не выборочной, документ из формальности превращается в инструмент, который действительно меняет то, как отдел продаёт.