«Заявки с сайта иногда не доходят до CRM. Разберитесь, почему» — задача, которую нам ставят примерно раз в месяц. И почти всегда выясняется, что руководитель не знает, как работает интеграция сайта с CRM изнутри: для него это чёрный ящик, в который заявка входит и иногда не выходит.
Разберём механику без кода: что физически происходит между нажатием кнопки и появлением карточки, где на этом пути заявка может потеряться, как понять, что интеграцию сделали нормально, и что спросить у подрядчика. Про то, что связка даёт бизнесу и какие бывают способы, мы писали отдельно — здесь смотрим под капот.
Что происходит за те две секунды
Человек нажал «Отправить». Дальше события идут в таком порядке.
Браузер отправляет заполненные поля на ваш сайт. Не в CRM — сайт и CRM напрямую между собой не разговаривают, посредником всегда выступает код на стороне сайта.
Обработчик на сайте принимает данные и проверяет их: заполнены ли обязательные поля, похоже ли содержимое на телефон, не робот ли это. Здесь же к заявке добавляется то, чего человек не вводил: адрес страницы, рекламная метка, время обращения.
Дальше обработчик обращается к CRM через её программный интерфейс — API. Это набор адресов, по которым внешняя программа может попросить систему что-то сделать: «создай лид с такими полями». Запрос уходит с ключом доступа, по которому CRM понимает, кто к ней обращается и что этому кому-то разрешено.
CRM создаёт запись и отвечает: «принял, номер такой-то» либо «ошибка, поле заполнено неверно». Ответ — самая важная часть, и именно её чаще всего игнорируют в дешёвых интеграциях: код отправил запрос и не посмотрел, что вернулось.
Сайт показывает посетителю «спасибо». В нормальной схеме это происходит после успешного ответа CRM, а не вместо него.
Внутри CRM дальше включается автоматика: назначается ответственный, ставится задача, уходит подтверждение клиенту. Это уже другая история — роботы и триггеры, которые к сайту отношения не имеют.
Три слова, которые вам скажет подрядчик
Их достаточно, чтобы понимать разговор и задавать правильные вопросы.
API — способ, которым одна программа просит другую что-то сделать. Бытовая аналогия: окно выдачи заказов. Вы не заходите на кухню и не готовите сами, вы называете заказ в окно и получаете ответ. У окна свои правила: что можно заказать, в каком виде и как часто.
Вебхук — персональный адрес с ключом внутри, по которому ваш сайт стучится в CRM. Простой и быстрый способ: получил адрес, вставил в настройки, работает. Подробности того, как настраивается и обрабатывается вебхук, мы разбирали для разработчиков; руководителю важно другое — у вебхука есть владелец. Он создаётся от имени конкретного сотрудника и работает с его правами. Уволился сотрудник, отключили его учётную запись — интеграция встала.
Приложение — способ посерьёзнее: связка живёт от имени системы, а не человека, и права выдаются явным списком. Настраивается дольше, зато переживает кадровые перемены. Как устроена регистрация и авторизация приложения, тоже разбирали отдельно.
Практический вывод для руководителя: если вам сделали интеграцию на вебхуке от учётной записи менеджера, который через полгода уволится, — это мина замедленного действия. Спросите, от чьего имени работает связка, и попросите перевести её на служебную учётную запись или на приложение. Заодно проверьте права доступа: ключ интеграции не должен уметь больше, чем нужно для создания заявки.
Где заявка теряется
Шесть мест, и у каждого свой симптом. Знать их полезно, чтобы разговор с подрядчиком начинался не с «у нас всё сломалось», а с описания того, что видно.
Форму переделали, обработчик забыли. Дизайнер поменял вёрстку, поля переименовались, код продолжает искать старые названия. Симптом резкий: заявки прекращаются одномоментно, обычно после обновления сайта.
Ключ отозван или истёк. Сотрудник уволен, вебхук пересоздан, тариф CRM понизили. Симптом такой же резкий, но без связи с работами по сайту.
CRM была недоступна в момент отправки. Обновление, авария у вендора, сеть. Симптом точечный: пропали заявки за конкретный час, остальные на месте.
Заявка не прошла проверку на стороне CRM. Обязательное поле пустое, телефон в неожиданном формате, сработала защита от дублей. Симптом выборочный: теряется часть заявок, обычно с определённой формы.
Упёрлись в ограничение по числу запросов. У любого API есть лимит, и при всплеске обращений часть запросов отклоняется. Симптом сезонный: заявки теряются в часы пик и в дни рекламных кампаний.
Заявку принял антиспам сайта. Форма отработала, но защита сочла отправку роботом. Симптом коварный: посетитель видит «спасибо», а заявки нет.
Первые два случая закрываются регулярной проверкой, остальные четыре разбираются по логам — и здесь мы подходим к главному.
Лог: единственное место, где видно правду
Лог — журнал, в который интеграция записывает каждую попытку: во сколько, с какими данными, что ответила CRM. Звучит скучно, но именно от его наличия зависит, будет разбор занимать двадцать минут или три дня.
Без лога любой инцидент превращается в гадание. Клиент утверждает, что оставлял заявку; в CRM её нет; проверить нечего, потому что событие нигде не зафиксировано. С логом видно: запрос ушёл в 14:32, CRM ответила «поле "телефон" заполнено неверно», заявка не создана — и дальше понятно, что чинить.
Второй механизм, который отличает нормальную интеграцию от дешёвой, — повторная отправка. Если CRM не ответила, заявка не выбрасывается, а откладывается и отправляется снова через минуту, потом через пять. Это закрывает самый обидный сценарий: система была недоступна две минуты, а компания потеряла заявки за это время безвозвратно.
Третий механизм — уведомление о сбое. Если заявка не ушла даже после повторов, кто-то должен об этом узнать: письмо администратору, сообщение в чат. Без этого поломка обнаруживается по тишине, а тишину легко списать на сезон.
Эти три вещи — лог, повторы и уведомление — стоят примерно один рабочий день на этапе разработки и почти не стоят ничего потом. Без них любая поломка обходится дороже.
Как система понимает, что это тот же человек
Отдельный вопрос, который всплывает через месяц после запуска: клиент оставил три заявки за неделю, и в CRM появилось три карточки.
Дедупликация — сопоставление новой заявки с уже существующими. Обычно ключом служит телефон, реже почта. Логика простая: если контакт с таким телефоном уже есть, новая заявка прикрепляется к нему, а не создаёт двойника.
Тонкость, о которой стоит договориться заранее: что делать, если у человека уже есть открытая сделка. Прикрепить обращение к ней или завести новую. Для ремонта квартиры правильный ответ один, для интернет-магазина — другой, и решает это бизнес, а не разработчик.
Второй нюанс — формат телефона. Если сайт отправляет номер как «8 (999) 123-45-67», а в CRM он хранится как «+79991234567», система считает их разными номерами и дубли появляются несмотря на настройку. Приведение к единому формату делается на стороне сайта и занимает полчаса, но про него забывают регулярно — та же история, что и при переносе базы из Excel.
Обратное направление: когда CRM пишет на сайт
Всё описанное выше — движение в одну сторону: сайт отдаёт, CRM принимает. Рано или поздно возникает вопрос про обратное направление, и стоит понимать, что это другая задача с другой ценой.
Обратный обмен нужен, когда сайт должен показывать то, что живёт в CRM или в учётной системе: статус заказа в личном кабинете, историю обращений, актуальные цены и остатки, свободные окна записи. Технически направление меняется на противоположное — теперь уже сайт спрашивает, а CRM отвечает.
Сложность здесь не в самом запросе, а в трёх вещах, которые в одностороннем обмене не возникают. Первая — скорость: если сайт при каждом открытии страницы лезет в CRM, страница начинает грузиться со скоростью CRM, а это заметно медленнее. Лечится кэшированием, то есть сайт хранит копию данных и обновляет её по расписанию, — и сразу появляется вопрос, насколько свежими должны быть цифры.
Вторая — безопасность. Односторонняя связка отдаёт данные внутрь, обратная достаёт их наружу, в публичный интернет. Права ключа здесь нужно резать жёстко: доступ строго к тем полям, которые показываются, и ничего сверх.
Третья — что показывать, когда CRM недоступна. У страницы должен быть запасной вариант: последние известные данные с пометкой времени либо честное «информация временно недоступна». Пустой экран здесь худший исход.
Практический ориентир: односторонняя связка форм — работа на дни, двусторонний обмен с личным кабинетом — на недели. Поэтому личный кабинет почти никогда не делают в первой очереди, и это правильно.
Как это выглядит по шагам
Карта работ, чтобы понимать, во что ввязываетесь.
| Шаг | Кто участвует со стороны компании | Сколько занимает | Чем заканчивается |
|---|---|---|---|
| Опись форм и решений | Владелец или маркетолог | 1–2 часа | Список форм: какая куда попадает и кто ответственный |
| Доступы и права | Администратор CRM | 1 час, если доступы есть | Служебная учётная запись и ключ с минимальными правами |
| Разработка обработчика | Ничего | 1–3 дня для типовой задачи | Заявки уходят в CRM с полями, метками и страницей |
| Лог, повторы, уведомление о сбое | Ничего | ещё около дня | Каждая попытка записана, сбой не остаётся незамеченным |
| Проверка сценариев | Тот, кто принимает работу | 2–3 часа | Проверены дубль, ночная заявка, недоступность CRM, все формы |
| Передача и инструкция | Администратор CRM | 1 час | Понятно, где смотреть лог и к кому идти при сбое |
Типовая связка на готовом модуле укладывается в несколько дней. Разработка под нестандартную логику — распределение по регионам, проверка клиента по базе, объединение с данными другой системы — считается отдельно и идёт неделями. Что важно прописать заранее, разбирали в статье про техническое задание.
Пять проверок, которые владелец делает сам
Ни одна не требует технических знаний.
Оставьте заявку с телефона как обычный посетитель и засеките, за сколько секунд она появилась в CRM. Больше пяти секунд — повод спросить почему.
Откройте карточку и посмотрите, что в ней кроме имени и телефона. Если нет страницы и рекламной метки, интеграция сделана наполовину: заявки не теряются, но посчитать рекламу вы не сможете.
Отправьте форму дважды с одним телефоном. Должна получиться одна карточка с двумя обращениями.
Спросите, где лежит лог, и попросите показать вашу тестовую заявку в нём. Если лога нет — это главный технический долг связки, и починить его стоит дешевле, чем разбирать первый серьёзный инцидент.
Спросите, от чьего имени работает интеграция. Ответ «от учётной записи Марины из отдела продаж» означает, что связка сломается при её увольнении.
Что спросить у подрядчика
Пять вопросов, которые отсеивают половину предложений.
«Что происходит, если CRM недоступна в момент отправки?» Правильный ответ описывает механизм: заявка откладывается и отправляется повторно. Ответ «такого не бывает» означает, что об этом не думали.
«Где будет лог и сколько он хранится?» Нужны конкретное место и срок. Месяца обычно достаточно.
«Кто узнает о сбое и как?» Должен быть адресат: письмо, сообщение в чат. Отчёт, который никто не читает, сбоем не считается.
«От чьего имени работает связка и что будет при увольнении этого человека?» Служебная учётная запись или приложение — хороший ответ.
«Что вы НЕ делаете в этом проекте?» Честный список исключений — доработки внутри CRM, изменение форм, настройка рекламы — экономит спор на приёмке.
Когда это избыточно
Если у вас одна форма и три заявки в неделю, полноценная связка с логами и повторами не окупится: письмо на почту плюс ручное заведение карточки обойдётся дешевле. Порог, за которым интеграция начинает себя оправдывать, — примерно десяток заявок в неделю или несколько источников сразу.
Если в компании ещё не решено, кто отвечает за заявку и за какое время, интеграция просто быстрее донесёт беспорядок до менеджеров. Сначала процесс, потом автоматизация — этот порядок работает и в остальных задачах.
И если сайт живёт на устаревшей платформе без поддержки, иногда дешевле сделать новый сайт, чем встраивать интеграцию в старый. Что вообще должно быть на сайте небольшой компании, собрано отдельно.
Сколько это стоит
Три части, которые считают отдельно.
Разработка обработчика: от подключения готового модуля с настройкой полей до написания связки под нестандартную логику. Разброс здесь кратный: от 3000 рублей при использовании готового модуля (только настройка) и до сотен тысяч рублей (при нестандартных интеграциях сложных самописных систем).
Обвязка — лог, повторные отправки, уведомление о сбое. Примерно день работы, и это лучшая инвестиция во всей задаче.
Поддержка. Сайт живёт: меняются формы, добавляются страницы, обновляется платформа. Каждое изменение — риск, что связка отвалится. Либо это входит в договор на обслуживание, либо вы платите за каждый ремонт отдельно.
Частые вопросы
Чем вебхук отличается от приложения простыми словами?
Вебхук — ключ от имени конкретного сотрудника: быстро настроить, но привязан к человеку и его правам. Приложение работает от имени системы, права выдаются явным списком, настройка дольше. Для одной формы на сайте хватает вебхука на служебной учётной записи; для связки, от которой зависит поток заявок, надёжнее приложение.
Можно ли передавать заявки без программиста?
Для популярных платформ есть готовые модули и сервисы-посредники, где связка собирается настройкой. Программист нужен, когда логика нестандартная: распределение по регионам, проверка по базе, объединение данных из нескольких систем.
Почему заявка появляется в CRM с задержкой?
Чаще всего дело в очереди: заявка принята, поставлена в обработку и отправляется следующим циклом. Задержка в секунды нормальна, в минуты — повод спросить, как устроена отправка. Если задержка появилась внезапно, посмотрите лог: вероятно, идут повторные попытки.
Что делать, если заявки перестали приходить?
Сначала оставьте тестовую заявку и посмотрите лог. Если запроса в логе нет — сломалось на стороне сайта, скорее всего после правок формы. Если запрос есть, а ответ с ошибкой — дело в CRM: ключ, права или проверка полей. Это разные исполнители, и такое разделение экономит день переписки.
Нужно ли что-то делать с персональными данными?
Форма должна собирать согласие на обработку, а сам факт согласия — сохраняться вместе с заявкой. Отдельно стоит проверить, что в логи не попадает лишнее: журнал с полными данными клиентов, лежащий в открытом доступе на сервере, — это утечка.
Как понять, что интеграция сделана качественно, если я не технарь?
По трём признакам: есть лог, который вам показали; есть повторная отправка при недоступности CRM; есть адресат уведомления о сбое. Если все три на месте, остальное почти наверняка сделано аккуратно. Если нет ни одного — связку писали по принципу «работает и ладно».
Итог
Интеграция сайта с CRM — это код на стороне сайта, который принимает форму, добавляет к ней контекст и передаёт в CRM через API с ключом доступа. Ломается она в шести предсказуемых местах, и пять из них разбираются по логу за двадцать минут.
Поэтому единственный технический вопрос, который стоит задать подрядчику до начала работ: что произойдёт, если CRM окажется недоступна в момент отправки заявки. Ответ на него отделяет связку, которая переживёт первый сбой, от той, которая молча потеряет дневной поток заявок.