Заявка с сайта падает в 21:40. Форма отправляет письмо на общую почту, письмо лежит до утра, утром его открывает администратор - а клиент уже задал тот же вопрос конкуренту в 21:52. Всё это время заявка существовала: она лежала в почте, целая и с телефоном. Проблема не в том, что заявку потеряли, а в том, что о её появлении никто не узнал в момент, когда она появилась.
Этот материал - о механизме, который решает ровно эту проблему и называется вебхуком. Слово техническое, но за ним стоит идея, понятная любому человеку: узнавать о событии сразу, а не проверять, случилось ли оно. План такой: сначала аналогия из обычной жизни, потом - что происходит без магии, потом - когда вебхук нужен, а когда хватает расписания или рук, и в конце - как собрать типовую связку «заявка с сайта → CRM → уведомление» без программиста. Заодно закроем вопросы надёжности и безопасности - они у вебхуков есть, и о них лучше знать заранее.
Консьерж, обходчик и собственные ноги
Представьте дом, в котором вам важно узнавать о посылках. Первый вариант: вы сами спускаетесь к стойке и спрашиваете, нет ли чего на ваше имя - раз в день, когда вспомните. Это ручная проверка: пока вы не пришли, посылка ждёт; если забыли - ждёт вчерашняя тоже. Второй вариант: сотрудник дома обходит все стойки каждый час и приносит всё накопившееся. Это расписание: задержка меньше, но всё равно до часа тишины, и посылка часа в два дня просто ждёт обхода.
Третий вариант: консьерж, который знает вас в лицо и поднимается к вам ровно в момент, когда курьер вручил посылку. Не через час, не после обхода - сразу. Ему не надо ничего проверять: событие само его толкнуло. Это и есть вебхук - «крючок», на который сервис-источник вешает уведомление. Не вы ходите смотреть и не кто-то ходит смотреть за вас: факт появления посылки сам приходит к вам.
Вся разница между тремя вариантами - во времени реакции и в усилии. Руками - максимум усилия и максимум задержки. Расписание - усилие нулевое, задержка средняя. Вебхук - усилие нулевое, задержка минимальная. Ни один вариант не «лучше» вообще: приходят ситуации, где нужен каждый. Об этом - через раздел.
Что происходит под капотом - если без магии
Теперь то же самое чуть техничнее, но всё ещё на человеческом языке. У любого вебхука три части.
Источник. Сервис, в котором случается событие: форма на сайте, платёжная система, календарь записи, CRM, мессенджер. В настройках большинства таких сервисов есть раздел вроде «уведомления» или «интеграции» - там источник умеет сообщать о событиях.
Адрес-крючок. Особый URL - длинная ссылка вроде номерка из гардероба. Когда событие происходит, источник заходит по этому адресу и оставляет сообщение: «только что была заявка, вот имя, вот телефон, вот текст». Адрес выдаёт та система, которая будет принимать события. Важное свойство: адрес уникален и секретен - кто знает адрес, тому источник готов оставлять сообщения. Позже о последствиях.
Обработчик. Получатель разбирает сообщение и делает полезное: создаёт карточку в CRM, пишет менеджеру в мессенджер, включает сценарий ответа. Обработчик - это и есть ваша автоматизация; в Growo его роль играет триггер-вебхук, с которого начинается сценарий в конструкторе.
Собранные вместе, три части дают картину: клиент нажал «Отправить» на форме → форма зашла на адрес-крючок и оставила данные → обработчик в ту же секунду начал работать. Никто ничего не проверял - событие само принесло себя. Отсюда и скорость, ради которой всё затевается: реакция измеряется секундами, потому что между событием и обработкой нет ни одного «когда посмотрим».
Когда событие должно сообщать о себе само
Вебхук нужен не всегда - и полезно понимать, когда именно он обязателен. Два признака. Первый: событие редкое и важное - заявка, оплата, отмена записи, сообщение клиента, новый отзыв. Их мало, каждое дорого, пропуск каждого заметен. Второй: задержка стоит денег или лояльности - клиент, задавший вопрос, через десять минут уже холоднее, чем минуту назад; о том, как дорого обходится именно первый контакт, у нас есть разбор «Первый контакт за секунды».
Если оба признака на месте - расписание здесь враг: оно гарантирует среднюю задержку в половину интервала. Проверка почты раз в час - до тридцати минут молчания на каждой заявке. Вебхук убирает эту задержку целиком.
Когда достаточно расписания
У расписания своя территория: события, где важно не «сразу», а «регулярно». Синхронизация остатков, утренняя сводка новых лидов, вечерний отчёт по диалогам, еженедельная выгрузка. Здесь гонять мгновенные уведомления бессмысленно - вам всё равно нужен момент «начало дня», чтобы получить всё разом. Расписание проще настраивать, проще проверять и легче чинить: сломался утренний отчёт - вы это заметите завтра утром, и это нормально.
Практическое правило: если событие можно описать словами «каждое утро», «раз в час», «по понедельникам» - это расписание. Если словами «когда клиент», «в момент оплаты», «как только пришло» - это вебхук.
Когда лучше оставить руками
И третья, непопулярная опция: ничего не автоматизировать. События, требующие человеческого суждения в каждом случае - разбор конфликта, оценка сложной заявки, решение о скидке, - не становятся лучше от того, что о них узнали на двенадцать секунд раньше. Автоматизация доставки события человеку? Да, полезно. Автоматизация самого решения? Пока нет. Честная граница «что можно отдать машине» разобрана в материале CRM или ИИ-сотрудник - и она проходит не там, где кажется.
Триггер и его работа: шпаргалка
Сводная таблица: какое событие источника и для чего годится. Правая колонка отвечает на вопрос «что делает обработчик» - это и есть сценарий, который вы собираете в конструкторе.
| Триггер (событие) | Для чего подходит |
|---|---|
| Новая заявка с формы сайта | Мгновенная передача в CRM и уведомление ответственному |
| Сообщение в мессенджер | Первый ответ и маршрутизация диалога нужному человеку |
| Оплата или новый заказ | Выдача доступа, письмо с деталями, передача в доставку |
| Отмена или перенос записи | Пересчёт свободных слотов и предложение времени другому клиенту |
| Появление отзыва | Быстрая реакция и постановка задачи менеджеру |
| Изменение статуса сделки в CRM | Следующий шаг процесса без напоминаний |
| Окончание рабочего дня | Вечерняя сводка диалогов и заявок ответственному |
| Каждое утро в фиксированный час | Дайджест ночных лидов и плана на день |
Обратите внимание на две нижние строки: расписание здесь живёт рядом с вебхуками в одной таблице - это не конкуренция, а разделение труда по типу события. О том, сколько именно часов съедает ручная доставка таких событий, если её не разделить, - в материале «Сколько часов уходит на ручную обработку».
Что нужно, чтобы вебхук заработал
Минимальный чек-лист из трёх пунктов - один к одному частям из раздела про «капот».
- Получить адрес-крючок. В Growo адрес выдаёт триггер-вебхук: добавляете триггер в начало сценария - платформа даёт ссылку.
- Вписать адрес в источник. В настройках формы, платёжки или CRM указываете этот URL как адрес уведомлений и выбираете события, о которых сообщать.
- Собрать обработчик. Сценарий после триггера: что сделать с данными - завести карточку, уведомить, ответить.
После сборки - обязательный шаг, который пропускают чаще всего: тестовое событие. В большинстве источников есть кнопка «отправить тест» - нажимаете и смотрите, пришло ли событие в обработчик и что он сделал. Тридцать секунд проверки экономят вечер отладки наугад: если тестовое событие не дошло, проблема в настройке источника, и это видно сразу, а не по молчанию первых живых заявок.
Типовая связка: заявка с сайта → CRM → уведомление
Самый частый сценарий - тот, ради которого большинство и знакомится с вебхуками, - выглядит так.
Клиент заполняет форму на сайте: имя, телефон, «хочу записаться на просмотр». Форма по настроенному адресу-крючку отправляет событие с данными. Сценарий в обработчике принимает его и делает три вещи: создаёт карточку клиента в CRM с источником «сайт», находит ответственного по правилу (дежурный, район, тип объекта) и отправляет ему уведомление с телефоном и текстом заявки. Дополнительно сценарий может отправить клиенту подтверждение - «заявку получили, ответим в течение часа» - про ценность такого первого касания и способы его не потерять написано в «Виджет на сайт за 30 секунд».
Результат: между нажатием «Отправить» и уведомлением менеджеру проходят секунды; карточка в CRM существует, даже если менеджер был в дороге; ничего не лежит в почте. Разница с «письмом на общую почту» не в скорости как таковой - в гарантиях: у события есть получатель, адресат и след в журнале.
Другие связки, которые собираются так же
Конструкция «источник → адрес → обработчик» одинакова везде, меняются только роли.
Оплата → доступ. Платёжная система сообщает о успешном платеже - сценарий выдаёт доступ к курсу или кабинету и отправляет письмо с деталями. Клиент не ждёт, пока администратор утром сверит выписку.
Отмена записи → пересборка расписания. Календарь сообщает об отмене - сценарий освобождает слот и предлагает это время следующему в листе ожидания. Пустой час перестаёт быть неизбежностью; о том, как запись без телефона меняет поток клиентов, - в «Онлайн-запись вместо телефона».
Отзыв → задача. Площадка отзывов сообщает о новом отзыве - сценарий ставит задачу ответственному с текстом и ссылкой. Реакция приходит пока отзыв горячий.
Заметьте общее: ни в одной связке нет программирования в привычном смысле - есть события и действия над ними. Именно поэтому связки собираются в визуальном конструкторе: шаги ложатся в схему, которую можно прочитать глазами.
Надёжность: что если вебхук потерялся
У мгновенных сообщений есть цена: они летят по сети, а сеть иногда молчит. Что нужно знать о надёжности.
Повторные попытки. Хорошие источники при недоступности обработчика повторяют отправку несколько раз. Планируйте сценарий так, чтобы повторное событие не создавало дубль: получив заявку с тем же идентификатором, обработчик должен обновить существующую карточку, а не заводить вторую. Это свойство называется идемпотентностью, но помнить надо само правило: одному событию - одно действие.
Дубли. Обратная ситуация: одно событие может прийти дважды даже без сбоев. Правило то же - сверьте идентификатор перед созданием чего-либо нового.
Журнал. Каждое пришедшее событие должно оставлять след: когда, от кого, с какими данными, что сделал обработчик. Без журнала разбор «заявка была, а карточки нет» превращается в гадание; с журналом - в чтение. В конструкторе Growo журнал ведётся со сценарием по умолчанию, включая пробные прогоны и окно песочницы.
Молчание источника. Если событий нет долго - убедитесь, что это пауза, а не отвалившаяся настройка. Тестовое событие из источника - быстрая проверка живости связки.
Безопасность: адрес - это ключ
Адрес-крючок работает как пароль: кто его знает, тому источник будет оставлять сообщения. Отсюда три правила гигиены. Не публикуйте адрес в открытых местах - инструкциях, чатах, скриншотах. Используйте секрет из источника, если он поддерживается: обработчик проверяет подпись события и игнорирует чужие. Если адрес утёк - перегенерируйте его и впишите в источник новый; старый мгновенно перестаёт работать.
Звучит как забота параноика, пока не встретишь практику: вебхук с правом создавать заявки, случайно попавший в публичную документацию, - это приглашение заваливать вашу CRM мусором. Гигиена здесь такая же обычная, как замок на входной двери.
Частые ошибки самодельных связок
Пока связки собирает человек без опыта, одни и те же грабли повторяются из раза в раз.
- Проверка «раз в день» вместо события. Форма шлёт письма на почту, почту открывают утром - вебхук не при чём, задержка встроена в сам процесс.
- Двойные заявки. Событие приходит дважды, обработчик честно создаёт две карточки - и два менеджера звонят одному клиенту.
- Событие есть, обработчика нет. Источник настроен и шлёт данные «в никуда» - адрес был, сценарий пересобрали, старый адрес умер.
- Нет журнала. Связка работала, потом тихо сломалась - и никто не заметил, потому что смотреть нечего.
- Адрес в публичном доступе. См. раздел о безопасности.
Общий корень всех пяти - связка собиралась как «настроил и забыл», а такой режим у интеграций не работает: они живые, им нужен след и проверка.
Как это выглядит в Growo
Теперь о том, как то же самое устроено у нас, - без прикрас. В конструкторе сценарий начинается с триггера, и вебхук - один из типов триггера: добавляете его, платформа выдаёт адрес, вы вписываете адрес в источник, шлёте тестовое событие и видите его в сценарии. Дальше собираете обработчик из шагов - условия, переменные, HTTP-запросы, отправка - и прогоняете сценарий на тестовых данных до подключения живого потока. Включение в бой идёт через окно песочницы на 72 часа - устройство этого окна разобрано в материале о пробном запуске без риска.
Если заявки у вас уже завязаны на другой конструктор сценариев - их можно перевезти: у нас есть импорт сценариев из n8n, описанный в пошаговом гайде по переезду. Готовые связки под частые задачи - формы, записи, уведомления - собраны в шаблонах: быстрее начать с проверенной схемы и поправить под себя, чем строить с белого листа.
Что делать сейчас
- Выпишите три события в своём бизнесе, о которых вы узнаёте позже, чем хотелось бы.
- По каждому решите: вебхук, расписание или человек - по правилу «когда клиент» против «каждое утро».
- Для одного события соберите связку: адрес-крючок, источник, обработчик.
- Отправьте тестовое событие и убедитесь, что след появился в журнале.
- Прогоните сценарий на тестовых данных, затем - песочница 72 часа и решение о бое.
Вебхук - не технология ради технологии, а способ убрать из бизнеса ожидание: событие произошло - об нём узнали в тот же момент. Если хотите увидеть, как такие связки ложатся на вашу нишу, начните с разведки рынка и своих данных в Growo: там видно, какие события у конкурентов уже автоматизированы и что это даёт.