Кейс · Таллинн
Как компания в Таллинне перестала терять заявки: с 23 часов до 15 секунд
Заявки жили в почте и личных чатах. Собрали один контур: сайт → n8n → CRM → Telegram. Реакция сжалась до 15 секунд, на входе лиды больше не пропадают.
- Клиент
- [НАЗВАНИЕ КЛИЕНТА]
- Город
- Таллинн, Эстония
- Сфера
- [СФЕРА КЛИЕНТА]
- Обновлено
- 2 сентября 2026 г.
8 мин
Контекст
[НАЗВАНИЕ КЛИЕНТА] приводит спрос с сайта и платных каналов. Отдел небольшой: собственник и менеджеры, которые одновременно ведут сделки, отвечают клиентам и смотрят рекламу.
Форма на сайте отправляла письмо на общий ящик. Параллельно люди писали в личные мессенджеры. CRM существовала, но в неё попадало то, что кто-то успел перенести руками вечером.
Рекламный кабинет показывал заявки. Продажи видели другую картину. Сверять эти два списка было некому, поэтому бюджет выглядел «рабочим», пока не начинали искать конкретное обращение.
Где ломалось
Медиана до того, как живой человек замечал заявку, составляла 23 часа. Ночные и субботние обращения ждали ближайшего рабочего утра, а часть так и оставалась письмом без хозяина.
Один и тот же человек иногда оставлял заявку дважды. В почте это были два письма, в переписке — третье сообщение. В CRM карточка либо не появлялась, либо появлялась дважды и без источника.
Потеря была не драматической «поломкой сайта». Она была тихой: письмо уехало в рассылку, менеджер решил, что ответит коллега, UTM стёрлись при пересылке. Деньги на клик уже были потрачены.
До и после
Было
- Заявка падает письмом на общую почту и часто дублируется в личном мессенджере.
- Ночью и в выходные обращение никто не фиксирует.
- Менеджер видит лид в среднем через 23 часа.
- Источник и UTM теряются при пересылке.
- Часть оплаченного спроса не доходит до разговора.
Стало
- Заявка сразу уходит в webhook n8n, минуя ящик.
- В CRM появляется карточка с источником, страницей и UTM.
- Telegram-бот пишет ответственному за 15 секунд.
- Повтор с тем же контактом дополняет карточку, а не плодит дубль.
- Конверсия в сделку выросла: первый контакт происходит, пока человек ещё на линии.
Решение
Не меняли стек на платформу «всё в одном». Собрали короткий контур, который компания может объяснить редактору и новому менеджеру на одной схеме.
Форма сайта отправляет JSON в webhook n8n. Сценарий проверяет дубль по контакту, создаёт или обновляет карточку в CRM и пишет ответственному в Telegram. Клиент сразу видит, что обращение принято.
Почта осталась запасным каналом на первую неделю, потом её убрали из основного пути. Если заявка не попала в CRM, это инцидент, а не «ну, письмо где-то есть».
Ход одной заявки. Наведите или выберите узел — справа от схемы будет, что именно происходит на этом шаге.
Шаг 1 из 5
Форма короткая: имя и контакт обязательны, ссылка на сайт — нет. До отправки проверяются поля. В JSON уходят страница, UTM и время. Человек не ждёт, пока «письмо дойдёт».
Стек
- Сайт
- Форма с проверкой полей, скрытые UTM и страница входа
- Webhook
- Одна точка приёма JSON, без почты в основном пути
- n8n
- Маршрут, дедупликация, назначение ответственного
- [НАЗВАНИЕ CRM]
- Карточка лида, статус, источник, следующий шаг
- Telegram Bot API
- Уведомление тому, кто реально отвечает клиенту
Этапы внедрения
01
Разобрали путь заявки
1–2 дня
Выписали все места, куда человек может постучаться: форма, почта, директ, звонок. Для каждого места — кто видит обращение и через сколько. На этом шаге стало видно, что CRM не была системой учёта, она была архивом.
02
Зафиксировали поля и статусы
1 день
Оставили минимум, без которого сделку нельзя начать: имя, контакт, страница, UTM, комментарий. Статус «новый» получил хозяина и срок первого ответа. Всё остальное — после разговора, не до него.
03
Собрали сценарий n8n
2–3 дня
Webhook, проверка, поиск дубля, запись в CRM, сообщение в Telegram, ответ форме. Отдельно прогнали ошибку CRM: заявка не должна тихо исчезнуть, если один шаг не ответил.
04
Подключили CRM и бота
1 день
Бота добавили в рабочий чат, не в личные «сохранённые». Сообщение короче экрана: имя, контакт, страница, ссылка на карточку. Длинные письма в Telegram никто не дочитывает.
05
Прогнали боевые сценарии
1 день
Новая заявка, повтор, заявка без UTM, заявка ночью, обрыв webhook. Засекали время до сообщения в чате. Пока цифра плавала, контур не считался запущенным.
06
Убрали обход через почту
неделя наблюдения
Семь дней почта работала копией. Когда расхождения с CRM закончились, копию выключили. Иначе команда возвращается в ящик в первую же нервную неделю.
Цифры
- Время реакции сократилось на 99 процентов: с 23 часов до 15 секунд
- Потеря лидов на этапе приёма — 0 процентов
- 15 секунд до первого контакта с ответственным
−99% на витрине — это читаемая форма той же цифры. 23 часа равны 82 800 секундам. 15 секунд от этого срока — около 0,02%, то есть сокращение примерно 99,98%. В кейс для редакции ставим исходные величины: 23 часа → 15 секунд. Округление до −99% не меняет вывод.
Конверсия из обращения в сделку выросла, потому что первый контакт случается в ту же сессию, а не на следующие сутки. Точный прирост в пунктах — [РОСТ КОНВЕРСИИ] после выгрузки из CRM. В публичный текст не ставится цифра, которую нельзя показать редакции.
«Мы не купили ещё одну платформу. Мы убрали место, где заявка могла тихо умереть. Утром больше не нужно спрашивать, кто видел письмо.»
Факты для редакции
Блок можно переносить в материал. Плейсхолдеры в квадратных скобках заменяются после согласования с клиентом.
- Клиент
- [НАЗВАНИЕ КЛИЕНТА]
- Рынок
- Таллинн, Эстония
- Сфера
- [СФЕРА КЛИЕНТА]
- Контур
- Сайт → n8n → CRM → Telegram
- Было
- 23 часа до реакции
- Стало
- 15 секунд до уведомления
- Потери на входе
- 0%
- Период наблюдения
- [ПЕРИОД]
Если заявки всё ещё проверяют по почте утром
Это считается в часах. Контур из кейса собирается вокруг текущего сайта и текущей CRM.