- «У нас CRM уже есть. Почему тогда менеджеры все равно вручную пишут в WhatsApp, а заявки теряются?»
- «Потому что CRM хранит контакты, но не запускает действия по событиям».
Слышу это регулярно. Формально система стоит, карточки заполняются, сделки двигаются. По деньгам картина выглядит хуже: сайт живет отдельно, мессенджеры отдельно, бронирование отдельно, и в паузах между заявкой, первым ответом и повторным касанием теряется то, за что бизнес уже заплатил рекламой.
Рост начинается там, где у клиента есть события, а не просто карточка
Во многих компаниях CRM остается учетной базой. Для контроля это уже неплохо. Для продаж и маркетинга - недостаточно, потому что сама по себе карточка клиента никого дальше по воронке не двигает.
Обычно мы начинаем с карты событий: новая заявка, не дозвонились, начал запись и бросил, пришел на визит, давно не возвращался. После этого настраиваем статусы, поля и действия. Я когда-то сам делал наоборот и сначала проектировал «идеальную» карточку. На практике это удлиняет запуск на недели.
У сервисной компании сайт был на Laravel 11, дальше amoCRM, телефония и отдельная система бронирования. Менеджеры жаловались на плохие лиды. Цифры показали другое: часть заявок лежала без ответа 18-25 минут, по незавершенной записи не писал никто. Мы внедрили 3 сценария - «новая заявка», «не дозвонились», «не завершил бронирование» - и за 6 недель доля обработанных лидов выросла с 61% до 84% без найма.
Рабочая последовательность почти всегда одна: 5-7 событий клиента, потом статусы и поля, потом автоматические действия.
Сегменты по поведению приносят деньги быстрее, чем сегменты по профилю
Бизнес часто просит деление по полу, возрасту, району. Для рекламы это бывает полезно. В продажах чаще важнее другое: что человек сделал вчера или час назад.
Для малого бизнеса обычно хватает таких групп:
- новый лид;
- не завершил бронь;
- давно не возвращался;
- покупает только по акции;
- часто берет дорогую услугу.
У нас был проект с онлайн-записью, где база годами жила одной рассылкой «для всех». Разделили клиентов всего на 4 группы и привязали сообщения к стадии: кому напомнить, кого вернуть, кому показать премиум-слот. Повторные бронирования выросли на 18%, отписки снизились на 27%. Цифры говорят просто: не текст стал лучше, сообщение пришло в нужный момент.
Частая ошибка - делать десятки мелких сегментов и потом не успевать их обслуживать. Правильнее начать с 3-5 рабочих групп, где для каждой понятны событие, сообщение и ожидаемое действие.
Триггеры окупаются быстрее массовых рассылок
Массовая рассылка дает охват. Триггер приводит к следующему шагу в воронке. Поэтому я почти всегда советую сначала запускать 3-5 сценариев, которые срабатывают по событию в реальном времени.
Базовый набор, который обычно начинает окупаться первым:
- welcome после первой заявки;
- незавершенная форма или бронь;
- follow-up после звонка или встречи;
- реактивация через X дней без покупки;
- напоминание перед визитом.
В B2B-проекте на Node.js 20 + NestJS мы сделали простой follow-up через 2 часа после демо: короткий кейс, письмо и ссылка на следующий шаг. Конверсия в повторный контакт оказалась на 22% выше, чем при ручной отправке менеджерами. Персональный подход хорош, но менеджер отвлекается, а система отправляет вовремя.
{
"event": "booking_abandoned",
"client_id": "12345",
"service": "consultation",
"source": "site_form",
"utm_campaign": "search_brand",
"timestamp": "2026-03-14T12:45:00Z"
}
Если такое событие прилетает сразу с сайта или из booking-системы, CRM начинает работать как механизм продаж. Если данные приезжают CSV-файлом по пятницам, автоматизация остается декорацией.
Самые дорогие месяцы - когда автоматизируют хаос
Здесь чаще всего и теряются сроки. Слово «автоматизация» быстро тянет за собой email, SMS, Telegram, WhatsApp, скоринг, BI, несколько воронок. Но если в CRM дубли, статусы размыты, а согласия на коммуникации не хранятся, вы просто ускоряете хаос.
У нас был неудачный кейс в прошлом году. Клиент захотел 14 сценариев на старте. Сайт был на WordPress, CRM отдельно, система бронирования передавала данные с задержкой до 20 минут, менеджеры ставили статусы как придется. Проект завис почти на 4 месяца. После перезапуска мы сократили объем до 4 сценариев, почистили базу, ввели единые статусы и нормальную событийную схему на PostgreSQL 16. Запуск занял 5 недель, первый измеримый ROI появился на втором месяце.
CTO логистической платформы однажды точно сформулировал это на созвоне: «Пока событие не стало данными, любая автоматизация - это просто обещание». Формулировка грубоватая, но по сути верная.
Проверять нужно не функции CRM, а связку сайта, каналов и бронирования
Я бы мерил успех такой системы по четырем вещам: скорость реакции на лид, конверсия в следующий этап, доходимость до визита и снижение ручных действий менеджеров. Все это упирается в качество связки между CRM и остальными точками контакта.
| Проверка | Если все в порядке | Если плохо |
|---|---|---|
| События | есть API и webhooks | ручной импорт |
| История | видно источник и UTM | лид без источника |
| Сегменты | деление по поведению | только по полям |
| Аналитика | понятен вклад сценария | выручка не связана с сообщением |
У сети услуг, где мы связали сайт, CRM и booking-модуль, среднее время реакции на заявку упало с 23 минут до 3 минут. На бумаге разница выглядит скромно. В выручке это уже совсем другой разговор: подтвержденных записей стало больше, потому что клиенту отвечали в тот момент, когда он еще был готов купить.
В ближайшие 6-12 месяцев сильнее всего вырастут компании, у которых CRM станет центром событий, а не местом хранения контактов. Самый полезный вопрос для собственника сейчас простой: что у вас происходит автоматически в первые 10 минут после заявки - и сколько денег молчит в эти десять минут.
