Интеграция сайта с amoCRM: как не терять заявки

Заявка с сайта, которая не долетела до CRM, — это не «технический сбой», а прямой убыток: деньги на рекламу потрачены, лид пришёл, но менеджер его не увидел и не перезвонил. По нашему опыту в таких потерях виноват не «плохой сайт», а разрыв между сайтом и amoCRM: письма на почту, которые никто не читает, формы, отправляющие данные «в никуда», звонки без карточки сделки. Ниже — как устроена рабочая интеграция, что именно связывают, где чаще всего рвётся цепочка и когда стоит делать синхронизацию в обе стороны.

Как заявки теряются без интеграции

Пока сайт и CRM живут отдельно, лид проходит через цепочку ручных пересечений — и на каждом что-то отваливается.

• Форма шлёт письмо на почту. Письмо попадает в спам, тонет в потоке, приходит ночью и теряется к утру. Никакого учёта: сколько заявок реально было — неизвестно.
• Заявки лежат в Google-таблице или в админке сайта. Менеджер должен сам туда заходить и переносить данные руками. По выходным и в пик — не заходит.
• Звонок идёт мимо CRM. Клиент позвонил, трубку не взяли, номер нигде не зафиксировался — перезвонить некому.
• Мессенджеры разбросаны. Написали в Telegram-бота, в директ, в чат на сайте — три разных окна, ни одной карточки.
• Дубли и путаница. Один и тот же человек оставил заявку дважды, на него завели две сделки, звонят оба менеджера — клиент раздражён.

Симптом всегда один: расхождение между числом обращений в аналитике рекламы и числом сделок в CRM. Если реклама показывает 200 кликов по цели, а в amoCRM за тот же период 60 сделок — часть разницы это не «плохие лиды», а потерянные заявки. Интеграция закрывает разрыв: каждое обращение автоматически становится сделкой в нужной воронке с зафиксированным источником.

Что именно связывают с amoCRM

Интеграция — это не одна «кнопка», а набор каналов, каждый со своим способом передачи данных.

Веб-формы. Заявки с лендинга, формы обратного звонка, калькулятора, квиза. Отправляются в amoCRM либо через встроенные веб-хуки форм, либо через ваш бэкенд, который принимает POST и создаёт сделку. Второй вариант надёжнее: вы контролируете валидацию, ретраи и логирование. Как мы делаем формы и бэкенд под них — в разделе услуг студии.

Телефония. Виртуальная АТС (Mango, UIS, Sipuni и др.) через готовую интеграцию из маркетплейса amoCRM: входящий звонок открывает карточку, пропущенный создаёт сделку и задачу «перезвонить», разговоры пишутся и подшиваются.

Мессенджеры и боты. Telegram, WhatsApp, MAX, чат на сайте. Диалог из бота или чата привязывается к сделке, а не остаётся в отдельном приложении. Для сложных сценариев — бот с квалификацией лида, который передаёт в amoCRM уже заполненные поля (бюджет, услуга, город).

Формы-агрегаторы и внешние площадки. Заявки с Авито, маркетплейсов, партнёрских лендингов сводятся в одну воронку.

Ключевой принцип: у каждого канала — свой тег или поле «источник», чтобы потом отличить лид с контекстной рекламы от лида из Telegram. Пример такой сборки нескольких каналов в одну воронку мы показывали в кейсе по синхронизации с amoCRM.

Webhooks или API: чем передавать данные

Это два разных инструмента для двух разных задач, и на практике обычно нужны оба.

API (REST) — вы пишете в amoCRM. Ваш бэкенд вызывает методы amoCRM (создать контакт, создать сделку, добавить примечание) через официальный REST API с авторизацией по OAuth 2.0. Это основной путь передачи заявок с сайта. Плюсы: полный контроль, можно отправлять сразу заполненные поля, можно повторить запрос при сбое.

Webhooks — amoCRM сообщает вам о событиях. amoCRM дёргает ваш URL, когда что-то поменялось: сделка сменила статус, добавили примечание, создали контакт. Это нужно для обратной связи — например, чтобы при переходе сделки в «Оплачено» сайт открыл клиенту доступ или отправил письмо.

Практические требования к обеим сторонам:

• Идемпотентность. Один и тот же вебхук amoCRM может прислать дважды. Обработчик должен по внешнему ID понять, что событие уже применено, и не создавать дубль.
• Ретраи с очередью. Если amoCRM недоступна в момент отправки заявки, запрос нельзя терять — он уходит в очередь и повторяется. Иначе при любом кратком сбое заявка исчезает молча.
• Валидация на границе. Данные формы и тело вебхука — это внешний ввод. Проверяйте формат телефона и email, отсекайте ботов и мусор до создания сделки.
• Логи каждой заявки. Должна быть возможность ответить на вопрос «куда делась заявка от Иванова в 14:32» — по логу, а не по догадкам.

Рекомендуем не тянуть токены и запросы напрямую из фронтенда: ключи amoCRM живут только на бэкенде, фронт общается со своим сервером. Это и безопасность, и единая точка для валидации и ретраев.

Поля, воронки и дедупликация

Мало «создать сделку» — важно создать её правильно, иначе CRM превращается в свалку.

Маппинг полей. Каждое поле формы должно попасть в конкретное поле сделки/контакта: имя → контакт, телефон → контакт, услуга → кастомное поле сделки, UTM-метки → поля источника. Договоритесь заранее, куда что кладётся, иначе данные разъедутся по разным полям в зависимости от канала.

Правильная воронка и этап. Заявка с сайта должна падать в нужную воронку (например, «Входящие лиды») на первый этап, а не в общую кучу. У разных каналов могут быть разные воронки — холодная заявка с квиза и горячий звонок не одно и то же.

Дедупликация. amoCRM умеет искать существующий контакт по телефону и email. Логика такая: перед созданием ищем контакт по нормализованному телефону; нашли — привязываем новую сделку к нему, не нашли — создаём новый контакт. Нормализация обязательна: +7 (999) 123-45-67 и 89991234567 — это один номер. Без этого один человек размножается на несколько карточек, и статистика по клиентам врёт.

Как это выглядит в цифрах и дашбордах — в кейсе по аналитике заявок в amoCRM.

Аналитика по источникам заявок

Интеграция окупается не только тем, что заявки не теряются, но и тем, что становится видно, откуда они приходят.

Передавайте вместе с заявкой UTM-метки и client_id веб-аналитики (Метрика/GA). Тогда в amoCRM у каждой сделки видно: рекламная кампания, ключевое слово, канал. Дальше это связывается со стадией сделки и суммой — и вы считаете не «стоимость клика», а стоимость сделки и стоимость продажи по каждому источнику.

Что это даёт на практике:

• Видно, какая реклама приносит сделки, а какая — только клики.
• Видно конверсию по каналам: из формы в продажу может конвертить лучше, чем из звонка, или наоборот.
• Отваливается спор «маркетинг привёл плохие лиды / продажи их слили» — по этапам воронки видно, где именно теряются деньги.

Без передачи меток вся эта аналитика недоступна: сделки есть, а откуда они — загадка. Метки стоит фиксировать при первом касании и не терять при последующих переходах по сайту.

Типичные ошибки и когда нужен синк в обе стороны

Частые грабли, которые мы разбираем на внедрениях:

• Токены OAuth протухают, и отправка молча ломается. Access-токен живёт ограниченное время; если не обновлять refresh-токеном автоматически — в один день заявки просто перестают доходить. Нужен мониторинг и алерт.
• Нет обработки ошибок. amoCRM ответила 4xx/5xx — а код это проглотил. Заявка «отправлена», но её нет. Обязательны ретраи и уведомление при провале.
• Дубли из-за отсутствия дедупликации. Разобрали выше — самая частая причина хаоса в базе.
• Всё пишется в одну воронку. Невозможно построить процесс: горячее и холодное вперемешку.
• Секреты в открытом виде. Ключи amoCRM в коде фронтенда или в репозитории — прямая утечка.

Когда достаточно односторонней передачи (сайт → CRM): если сайт только собирает заявки, а вся дальнейшая работа идёт в amoCRM. Это большинство лендингов и корпоративных сайтов.

Когда нужен двусторонний синк (сайт ⇄ CRM):

• Личный кабинет / SaaS. Статус сделки в amoCRM должен отражаться в кабинете клиента: оплатил — открылся доступ, сменился этап — обновился статус заказа.
• Каталог и остатки. Если менеджер меняет что-то в CRM, а это должно быть видно на сайте.
• Сквозные сценарии. Например, при переходе сделки в «Оплачено» сайт автоматически выдаёт продукт или запускает онбординг.

Двусторонний синк строится на связке «API для записи + вебхуки для чтения событий» и требует аккуратной обработки конфликтов и идемпотентности — иначе два источника правды начнут спорить. Такие сценарии, как и односторонние, мы собираем под ключ: подборка внедрений — в разделе кейсов. Ориентиры по трудоёмкости зависят от числа каналов и глубины синка: простая передача форм — это дни, полноценный двусторонний обмен с личным кабинетом — недели; точная вилка считается по вашему набору каналов.

Официальную документацию по методам и авторизации имеет смысл держать под рукой — developers.amocrm.ru.

FAQ

Можно ли интегрировать сайт с amoCRM без программиста?

Для типовых форм и телефонии — частично да: в маркетплейсе amoCRM есть готовые виджеты и коннекторы для популярных конструкторов и АТС. Но как только нужны валидация, дедупликация, ретраи при сбоях, кастомные поля и передача UTM — без бэкенда и разработчика вы упрётесь в потолок готовых решений и продолжите терять часть заявок на пограничных случаях.

Что надёжнее для передачи заявок — webhooks или API?

Для отправки заявки с сайта в amoCRM используется REST API: ваш сервер сам создаёт сделку и контролирует результат. Webhooks идут в обратную сторону — amoCRM уведомляет ваш сайт о событиях (смена этапа, оплата). Для полноценного сценария с личным кабинетом нужны оба.

Как избежать дублей контактов в amoCRM?

Перед созданием контакта искать существующий по нормализованному телефону и email (приводить номера к единому формату). Нашли — привязывать сделку к найденному контакту, не нашли — создавать новый. Плюс включить встроенную проверку дублей в самой amoCRM как второй рубеж.

Почему заявки доходят не все, хотя интеграция «есть»?

Обычно причина одна из трёх: протухший OAuth-токен без автообновления, отсутствие ретраев при временной недоступности amoCRM, или проглоченная ошибка ответа API. Все три лечатся мониторингом отправки, очередью с повторами и логированием каждой заявки — чтобы любую потерю можно было отследить.

Нужна ли двусторонняя синхронизация, если у меня обычный лендинг?

Как правило, нет. Лендингу достаточно односторонней передачи «сайт → amoCRM»: собрали заявку, отдали в CRM, дальше работа идёт в CRM. Двусторонний синк нужен, когда сайт показывает клиенту статус его сделки или заказа — то есть в личных кабинетах, SaaS и e-commerce со сквозными сценариями.