Автоматизация продаж проваливается не из-за плохих систем. В подавляющем большинстве случаев CRM работает ровно так, как её настроили, интеграции передают данные, боты отвечают — и при этом через полгода отдел возвращается к таблицам, а руководитель считает проект потраченными деньгами. Причина почти всегда управленческая: не описан порядок работы, не назначен ответственный, не снят замер до старта, запущено слишком много сразу.
Хорошая новость в том, что все восемь ошибок из этого разбора видны рано — в первые три недели после старта проекта, когда деньги ещё не потрачены целиком и всё можно развернуть. Плохая — что признаки выглядят безобидно: лишний вопрос подрядчика, отложенное согласование, «давайте сразу всё настроим, чтобы потом не возвращаться».
Дальше — восемь ошибок с ранним признаком, ценой в рублях на модельной компании и профилактикой. Модель одна и та же: отдел продаж из шести менеджеров, 400 заявок в месяц, средний чек 60 000 ₽, конверсия в сделку 15 %, валовая маржинальность 30 %. Отсюда валовая прибыль со сделки — 18 000 ₽, а цена одной заявки — 2 700 ₽. Как считается цена заявки на своих цифрах, разобрано в опорной статье про автоматизацию отдела продаж.
Восемь ошибок: ранние признаки и цена
Проект внедрения устроен так, что первые три недели уходят на разбор процесса и согласования, а не на код. Именно в этот период компания предъявляет подрядчику свою реальную организацию работы — и все восемь ошибок проявляются как бытовые мелочи. Ни одна из них в этот момент не выглядит как риск на миллион рублей, поэтому их пропускают.
| Когда | Что происходит | Как это выглядит на самом деле |
|---|---|---|
| Неделя 1 | Подрядчик спрашивает, как обрабатывается заявка. Три менеджера отвечают по-разному, руководитель — четвёртым способом | Процесса нет. Настраивать будут чью-то версию, и остальные её обойдут |
| Неделя 2 | В карточку добавляют поля «на всякий случай», список растёт до 25–40 обязательных | Никто не спросил, какой отчёт читает каждое поле. Половина не читает никакой |
| Неделя 2 | На вопрос «какие цифры сейчас» отвечают «примерно» и «в районе» | Замера до старта нет. Эффект проекта будет спором мнений |
| Неделя 3 | У подрядчика 15 вопросов, ответы на которые ждут дольше трёх дней | Владельца процесса нет. Срок поедет на 3–6 недель, поддержка пойдёт вхолостую |
| Неделя 3 | В план запуска попали шесть модулей, обучение назначено на один день | Через две недели менеджеры будут пользоваться двумя из шести |
Горизонтальная лента времени на три недели. На неделе 1 отметка «три разных ответа на вопрос, как обрабатывается заявка». На неделе 2 две отметки: «25–40 обязательных полей» и «нет цифр до старта». На неделе 3 две отметки: «15 вопросов подрядчика без ответа дольше трёх дней» и «шесть модулей в плане запуска, обучение за один день». Под каждой отметкой — короткое последствие. Справа от ленты вертикальная граница с подписью «дальше начинается разработка: разворачивать дорого».
Таблица ниже — свод по всем восьми. Цены модельные, на компании из вводных выше; в вашей они изменятся пропорционально потоку заявок и среднему чеку, но порядок величин сохранится.
| Ошибка | Ранний признак | Цена в модели |
|---|---|---|
| 1. Автоматизировали беспорядок | Три сотрудника описывают путь заявки тремя способами | Переделка воронки и правил: 60 000–120 000 ₽ и 2–4 недели |
| 2. Поля ради полей | Больше 25 обязательных полей, в карточках прочерки и «уточнить» | 40 часов отдела в месяц — 36 000 ₽ — плюс недостоверные отчёты |
| 3. Нет владельца процесса | Вопросы подрядчика висят дольше трёх дней | Срок плюс 3–6 недель, поддержка 25 000 ₽/мес вхолостую |
| 4. Внедрили всё сразу | Шесть модулей в плане, обучение за один день | Около 340 000 ₽ из 520 000 ₽ приходится на модули, которыми не пользуются |
| 5. Нет замера до старта | На вопрос «сколько было» отвечают «примерно» | Второй этап не финансируется: эффект нечем доказать |
| 6. Робот вместо продавца | Больше 25 % диалогов, где клиент просит человека | 44 обращения в месяц не доходят до менеджера — 118 800 ₽ валовой прибыли |
| 7. Сквозные права доступа | Каждый менеджер видит все сделки и может выгрузить их в файл | База 1 200 клиентов уходит вместе с уволенным сотрудником |
| 8. Подрядчик исчез после сдачи | В договоре нет сроков ответа и передачи доступов, ответы идут на третий день | Перенастройка у нового исполнителя: 160 000–260 000 ₽ |
Ошибка первая: автоматизировали беспорядок
Самая дорогая и самая частая. Компания заказывает настройку CRM, надеясь, что система принесёт порядок вместе с собой. Система приносит только то, что в неё заложили: если у трёх менеджеров три разных способа работы с заявкой, подрядчик выберет один — обычно тот, который описал самый разговорчивый участник встречи, — и настроит воронку под него. Остальные продолжат работать по-своему в обход системы, и уже через месяц в отчётах появятся сделки, которых нет, и не появятся те, которые есть.
Регламент обязан появиться до настройки, а не после неё, и он не обязан быть толстым. Рабочая версия помещается на страницу: канал, норматив первого ответа, ответственный, обязательные вопросы клиенту, что фиксируется в системе, что происходит при просрочке. Как собрать такой документ за день и на чём обосновать нормативы, разобрано в материале про регламент обработки заявки.
После запуска регламент писать поздно по простой причине: он уже написан — настройками системы, и переписать его теперь стоит денег и недель, а не одного совещания. Разворачивать настроенную воронку на пятой неделе проекта в модели обходится в 60 000–120 000 ₽ и 2–4 недели сверху. Ровно та же работа до начала настройки стоит нескольких часов руководителя.
Ошибка вторая: поля ради полей
На второй неделе кто-нибудь обязательно говорит: «раз уж настраиваем, давайте добавим поле — вдруг пригодится». К запуску обязательных полей в карточке становится 25–40. Дальше происходит предсказуемое: менеджер, у которого клиент на линии, не может сохранить сделку, пока не заполнит все, — и заполняет прочерками, «уточнить» и «нет данных». Через месяц отчёт по источникам заявок показывает, что 40 % пришли из источника «нет данных».
В модели каждое лишнее поле стоит секунд, а вместе они дают около шести минут на заявку. На 400 заявках это 40 часов в месяц, или 36 000 ₽ по ставке 900 ₽/час полной стоимости менеджера. Но главные потери не здесь, а в достоверности: решения принимаются по данным, которые набивали лишь бы сохранить карточку.
Формулировка «менеджеры не хотят вести CRM» почти всегда неверна. Менеджер отлично ведёт то, что возвращается ему в тот же день: расчёт, который подставляется в КП, историю разговора, которая избавляет от «напомните, о чём мы договаривались». И перестаёт вести то, что уходит в никуда. Правило простое: каждое обязательное поле обязано либо попадать в живой отчёт, либо возвращаться менеджеру пользой в тот же день. Поля, не проходящие эту проверку, удаляются — подробный разбор в материале почему менеджеры не ведут CRM.
Ошибка третья: нет владельца процесса
Владелец процесса — не спонсор проекта и не системный администратор. Это человек, который отвечает на вопросы подрядчика в течение суток, принимает решения о спорных местах и имеет право сказать «в нашей компании будет так». Признак его отсутствия ловится на третьей неделе: у подрядчика накопилось полтора десятка вопросов, ответы висят дольше трёх дней, а проект стоит, продолжая расходовать оплаченное время.
В компании из 15 человек отдельной должности под это нет и быть не должно. Владельцем становится один из троих.
- Руководитель отдела продаж — если он есть и реально управляет очередью заявок, а не продаёт сам на 80 % времени. Это лучший вариант: он же будет читать отчёты.
- Собственник — в компаниях до 20 человек часто единственный, кто может решать спорные вопросы. Тогда проект надо резать по объёму: ему хватит времени на два модуля, но не на шесть.
- Сильный менеджер с частичной разгрузкой — рабочий вариант, если снять с него часть плана на время проекта. Без разгрузки он выберет продажи, и это правильный выбор с его стороны.
Схема из четырёх блоков и стрелок между ними. Слева «Подрядчик: вопросы по процессу». В центре крупный блок «Владелец процесса: ответ в течение суток, право решать спорные места». Справа два блока: «Собственник: бюджет и приоритеты» и «Отдел продаж: работает по решению». Пунктирная ветка мимо центрального блока подписана «вопрос уходит всем сразу — ответа нет 3+ дня, срок +3–6 недель». Под центральным блоком подпись «в компании из 15 человек это РОП, собственник или разгруженный менеджер».
Ошибка четвёртая: внедрили всё сразу
Пакетный запуск выглядит экономным: подрядчик один раз погружается в процесс, один раз выезжает на обучение, скидка за объём. На практике шесть модулей — единое окно заявок, автораспределение, скоринг, автогенерация КП, бот квалификации и дашборд — это шесть новых привычек, которые отделу предлагают освоить за один день обучения. Через две недели в живых остаются две: те, что снимают ежедневную боль. Остальные обходят.
В модели из 520 000 ₽ настройки на четыре неиспользуемых модуля приходится около 340 000 ₽. Деньги не пропали физически — модули существуют и даже работают, — но они не изменили ни одной цифры и продолжают требовать поддержки. Работающий порядок другой: две волны по два модуля с интервалом в 4–6 недель, и вторая волна планируется только после того, как по первой снята цифра.
| Пакетный запуск шести модулей | Две волны по два модуля | |
|---|---|---|
| Обучение | Один день на шесть новых привычек | Полдня на два модуля, через 4–6 недель ещё полдня |
| Что используется через месяц | Два модуля из шести | Оба модуля первой волны |
| Когда виден эффект | Не разделить: изменилось всё сразу | По каждой волне отдельно, есть с чем сравнить |
| Цена ошибки в выборе | Оплачены все шесть | Вторая волна отменяется без потерь |
| Настройка в модели | 520 000 ₽, из них ~340 000 ₽ вхолостую | 210 000 ₽ за первую волну |
Ошибка пятая: нет замера до старта
Без цифр «до» разговор об эффекте превращается в спор мнений: подрядчик считает проект успешным, руководитель отдела — бесполезным, собственник видит только счета. Проверить нельзя ни одну из позиций, и в этом споре всегда выигрывает тот, кто громче. Практическое последствие даже хуже отсутствия аргументов: второй этап не финансируется, потому что первый нечем защитить.
Замер занимает неделю и делается вручную, без всяких систем: выборка заявок за месяц, секундомер, выгрузка из телефонии и почты. Достаточно пяти цифр — поток обращений по каналам, доля необработанных, время первого ответа, конверсия по этапам и время на ведение одной сделки. Как их снять, если ещё ничего не внедрено, подробно разобрано в опорной статье кластера; здесь важно одно: цифры фиксируются письменно и датируются до подписания договора, а не восстанавливаются задним числом.
Часть менеджеров или часть потока заявок, которая в первый месяц работает по-старому. Нужна, чтобы отделить эффект системы от сезонности, смены рекламы и общего внимания руководства к теме. Двух менеджеров из шести достаточно; без такого сравнения любой рост будет приписан проекту, а любое падение — рынку.
Ещё три ошибки: робот, права и исчезнувший подрядчик
- 1Робот вместо продавца
Бот, которому поручили отвечать на всё, вежливо и быстро уводит клиента от сделки. Признак — доля диалогов, где клиент пишет «оператор» или «человек», выше 25 %. В модели бот не доводит до менеджера 44 обращения в месяц: при конверсии 15 % это 6,6 сделки и около 118 800 ₽ валовой прибыли — больше, чем стоила вся его настройка. Профилактика: стоп-темы, по которым бот молча передаёт диалог человеку, и жёсткий предел длины сценария. Чем ограничивается квалификация лида ботом, мы описали отдельно.
- 2Сквозные права доступа
Единственная в списке техническая ошибка. По умолчанию в большинстве систем каждый менеджер видит все сделки и может выгрузить базу в файл. Обнаруживается это обычно в день увольнения — вместе с базой на 1 200 клиентов. Профилактика делается за пару часов на этапе настройки: видимость только своих сделок, отдельное право на выгрузку, журнал экспортов, отзыв доступов в день ухода сотрудника.
- 3Подрядчик исчез после сдачи
Признак виден ещё до подписания: в договоре нет срока ответа на обращение, не описана передача доступов и исходных материалов, поддержка сформулирована как «сопровождение по мере необходимости». После сдачи ответы приходят на третий день, потом не приходят. Перенастройка у нового исполнителя стоит 30–50 % первоначального бюджета — в модели 160 000–260 000 ₽. Что должно быть в договоре и что входит в поддержку, разобрано в материалах про договор на разработку и состав поддержки.
Сравнение в две колонки. Левая «Шесть модулей сразу»: обучение один день, используются 2 из 6, эффект не разделить, настройка 520 000 ₽, из них около 340 000 ₽ вхолостую. Правая «Две волны по два модуля»: обучение полдня и ещё полдня через 4–6 недель, используются оба модуля первой волны, эффект считается по каждой волне, первая волна 210 000 ₽. Под колонками общая подпись «вторая волна планируется только после того, как по первой снята цифра».
Что стоит один перезапуск
Ошибки редко приходят по одной: беспорядок в процессе почти всегда идёт вместе с пакетным запуском и отсутствием владельца. Ниже — сложенная стоимость типового сценария, в котором компания запустила шесть модулей без регламента, три месяца прожила с ними и вернулась к перезапуску с двух.
Самая обидная строка здесь — не 520 000 ₽ за неиспользуемые модули, а 162 000 ₽ потерянных заявок. Пока отдел живёт в двух системах, заявки теряются чаще, чем до автоматизации: часть приходит в новое окно, часть в старое, и ни за одним из них нет полноценного дежурного. Это регулярный побочный эффект длинного параллельного периода, и он единственный в списке продолжает расти каждый месяц, пока проект не закончен.
Две составные колонки, ось Y — рубли. Левая колонка «Перезапуск, 1 080 400 ₽» из пяти сегментов с подписями: настройка шести модулей 520 000 ₽, поддержка 75 000 ₽, работа в двух системах 113 400 ₽, потерянные заявки 162 000 ₽, перезапуск 210 000 ₽. Правая колонка «Верный порядок сразу, 246 000 ₽» из двух сегментов: два модуля 210 000 ₽ и поддержка 36 000 ₽. Между колонками фигурная скобка с подписью «834 400 ₽ и около четырёх месяцев».
Если признаки уже появились, разворачивать проект целиком обычно не нужно. Достаточно четырёх действий, каждое из которых занимает от нескольких часов до недели.
- 1Остановить настройку на 3–5 дней и написать регламент на одну страницу. Это дешевле любого другого шага и снимает ошибку номер один целиком.
- 2Сократить состав первой волны до двух модулей, остальные перенести письменно, с датой пересмотра. Не отменить — именно перенести: отменённое возвращается спорами, перенесённое возвращается по плану.
- 3Назначить владельца процесса поимённо и с нормативом ответа — сутки. Если такого человека нет, объём проекта надо резать до того, что помещается в доступное внимание.
- 4Снять пять цифр «до» задним числом, насколько это возможно: выгрузки из телефонии, почты и CRM за прошлый месяц дают четыре из пяти. Даже неполный замер лучше, чем спор мнений на приёмке.
Когда автоматизацию продаж лучше не начинать
Отдельный класс ошибок — не в исполнении, а в самом решении начать. В четырёх ситуациях честный ответ подрядчика звучит как «сейчас не надо», и это тот случай, когда стоит его услышать.
- Меньше 60–80 обращений в месяц. Эксплуатация системы съедает больше, чем приносят возвращённые заявки. Здесь работают регламент, общий ящик и дежурный, а не проект за 400 000 ₽.
- Процесс меняется каждый месяц. Пока продукт, прайс и способ продажи перебираются на ходу, любая настройка устаревает быстрее, чем окупается. Сначала стабилизация, потом автоматизация.
- Некому владеть проектом. Если ни у кого в компании нет суток в неделю на решения по проекту, он превратится в вялотекущую переписку с оплатой поддержки.
- Проблема в продукте или цене. Автоматизация ускоряет обработку заявок и не влияет на то, почему клиенты отказываются. Если конверсия падает на этапе «узнал цену», система покажет это красивее, но не изменит.
- Задача сформулирована как «чтобы менеджеры работали». Дисциплина настройками не чинится. Систему обойдут, а вы получите ещё и счёт за поддержку.
Автоматизация не создаёт порядок — она делает существующий порядок быстрее. В том числе беспорядок.
