Автоматизация передачи заявок с сайта в amoCRM: разбор схемы

Автоматизация передачи заявок с сайта в amoCRM экономит менеджеру 3-4 часа в день на ручном переносе контактов и закрывает главную дыру любого отдела продаж - потерянные лиды. Я собираю такие связки под ключ не первый год: от простой отправки формы Tilda в воронку до цепочек, где заявка успевает обогатиться данными об оплате из T‑Bank и трек-номером СДЭК ещё до того, как ей займётся человек. Разберу схему по слоям - что за чем идёт, где всё обычно ломается и как это чинить.

Из чего состоит цепочка от формы до сделки

Любая связка сайта с amoCRM раскладывается на четыре слоя, и путаница между ними - причина 80% багов, которые я разбираю на чужих проектах.

• Источник. Форма на Tilda, WooCommerce-заказ, чат-бот на aiogram, звонок через телефонию. У каждого свой формат данных и свой способ отдать их наружу.
• Транспорт. Webhook, серверный скрипт или посредник вроде n8n, который принимает данные источника и решает, что с ними делать.
• Обработка. Тут заявка чистится, проверяется на дубли, размечается по источнику (UTM-метки, referer) и при необходимости дополняется - например, подтягивается статус оплаты.
• Приёмник. Метод /api/v4/leads/complex в amoCRM, который создаёт сделку, контакт и связывает их в одном запросе.

Когда я рисую схему клиенту, я всегда развожу эти слои визуально. Иначе через полгода никто не вспомнит, почему заявки с посадочной страницы падают в одну воронку, а из корзины WooCommerce - в другую.

Минимальный полезный контракт данных, который я гоняю между слоями, выглядит так:

{
  "name": "Заявка с лендинга",
  "contact": {
    "name": "Иван",
    "phone": "+79001234567",
    "email": "ivan@example.com"
  },
  "source": "tilda",
  "utm": { "source": "yandex", "campaign": "remont-kvartir" },
  "price": 0,
  "comment": "Хочу расчёт под ключ"
}

Если этот объект собирается корректно на входе, дальше связка работает предсказуемо независимо от того, откуда пришла заявка.

Способы интеграции форм с amoCRM: что беру под задачу

Выбор транспорта - не вопрос вкуса, а вопрос того, сколько логики нужно навесить на заявку. Вот как я обычно решаю, сравнивая четыре рабочих варианта.

Встроенная форма и штатный коннектор Tilda закрывают процентов сорок задач. Проблема начинается, когда клиент хочет разметить заявку по UTM, отсечь спам-ботов и не плодить дубли контактов - стандартная интеграция форм с amoCRM тут упирается в потолок, и я перехожу на webhook с посредником.

Отдельно про Tilda: её Zero-блок умеет слать данные на произвольный webhook через настройку «Данные форм → Webhook». Я вешаю на форму такой перехватчик, чтобы дотащить UTM-метки, которые Tilda сама в CRM не передаёт:

document.addEventListener('DOMContentLoaded', function () {
  document.querySelectorAll('.t-form').forEach(function (form) {
    form.addEventListener('submit', function () {
      var params = new URLSearchParams(location.search);
      ['utm_source', 'utm_medium', 'utm_campaign'].forEach(function (key) {
        var input = document.createElement('input');
        input.type = 'hidden';
        input.name = key;
        input.value = params.get(key) || 'direct';
        form.appendChild(input);
      });
    });
  });
});

Часть логики я не собираю с нуля на каждом проекте, а беру из готовых модулей для приёма заявок и допиливаю под конкретную воронку - так связка выходит дешевле и предсказуемее, чем свежий код под каждого клиента.

Настройка транспорта: webhook и n8n как связующее звено

n8n я ставлю почти на каждый проект, где отправка лидов в amoCRM обрастает условиями. Это визуальный движок сценариев, который принимает webhook, крутит данные через ноды и стучится в API amoCRM. Разворачивается на VPS за 20 минут в Docker, дальше вся логика собирается мышкой плюс пара нод с кодом.

Типовой сценарий у меня состоит из пяти нод:

1. Webhook - точка входа, куда форма или бот шлёт POST-запрос.
2. Function - нормализация телефона в формат +7XXXXXXXXXX и валидация email.
3. HTTP Request к amoCRM - поиск контакта по телефону, чтобы не создавать дубль.
4. IF - ветвление: контакт есть → добавляем сделку к нему; нет → создаём заявку целиком.
5. HTTP Request - финальный вызов /api/v4/leads/complex.

Сам вызов на создание сделки с контактом выглядит так - один запрос вместо трёх:

curl -X POST 'https://ваш-домен.amocrm.ru/api/v4/leads/complex' 
  -H 'Authorization: Bearer ТОКЕН' 
  -H 'Content-Type: application/json' 
  -d '[{
    "name": "Заявка с лендинга",
    "price": 0,
    "_embedded": {
      "contacts": [{
        "name": "Иван",
        "custom_fields_values": [{
          "field_code": "PHONE",
          "values": [{ "value": "+79001234567" }]
        }]
      }]
    }
  }]'

Метод complex создаёт сделку, контакт и связку между ними атомарно. Если делать это тремя отдельными запросами, при обрыве на середине в CRM остаётся сделка без контакта - грязь, которую потом руками разгребает менеджер.

Где взять токен и как он живёт

amoCRM работает по OAuth 2.0: долгоживущий refresh-токен и access-токен на 24 часа. Я никогда не зашиваю access-токен в код - вместо этого храню refresh-токен и обновляю доступ автоматически перед запросом. Отдельная нода в n8n с расписанием раз в 12 часов дёргает /oauth2/access_token и складывает свежий токен в переменную. Забудешь про это - и через сутки связка молча перестанет слать заявки, а узнаешь ты об этом от разъярённого клиента.

Обработка ошибок и дедупликация лидов

Связка сайта с amoCRM без обработки ошибок живёт ровно до первого сбоя на стороне CRM. amoCRM отдаёт 429 при превышении лимита в 7 запросов в секунду и периодически ловит 504 под нагрузкой. Заявка, которая упёрлась в такой ответ, просто исчезает, если её некуда положить.

Я закрываю это тремя приёмами:

• Ретраи с задержкой. На ошибках 429 и 5xx - три повтора с паузой 2, 5 и 15 секунд. Больше 90% временных сбоев рассасываются уже на втором повторе.
• Очередь-буфер. Если после ретраев заявка так и не ушла, она падает в резервное хранилище - Google-таблицу или базу - откуда её можно долить вручную. Ни один лид не теряется.
• Уведомление в Telegram. Бот на aiogram пишет мне и клиенту, что заявка застряла. Реакция получается за минуты, а не когда кто-то заметит тишину в воронке.

Дедупликация - вторая по частоте боль. Клиент оставляет заявку с лендинга, через час пишет в бота, а вечером оформляет заказ в WooCommerce. Без проверки в CRM появляется три контакта на одного человека, и менеджеры звонят ему по очереди. Я всегда ищу контакт по нормализованному телефону перед созданием, и если он есть - цепляю новую сделку к существующему контакту, а не пложу клона.

На одном интернет-магазине после включения дедупликации по телефону число дублей контактов упало с 600+ в месяц почти до нуля, а конверсия в звонок выросла, потому что менеджеры перестали тратить время на разбор одинаковых карточек.

Нормализацию телефона держу максимально тупой и надёжной - приводлю всё к +7 и десяти цифрам:

def normalize_phone(raw: str) -> str:
    digits = ''.join(c for c in raw if c.isdigit())
    if digits.startswith('8') and len(digits) == 11:
        digits = '7' + digits[1:]
    if len(digits) == 10:
        digits = '7' + digits
    return '+' + digits

Проверка связки перед запуском в бой

Прежде чем отдать приём заявок в CRM клиенту, я прогоняю чек-лист - он ловит те грабли, на которые иначе наступишь уже на живом трафике.

• Отправить тестовую заявку с каждого источника: лендинг, WooCommerce, бот. Проверить, что все три долетели в нужную воронку.
• Отправить заявку с одним и тем же телефоном дважды - убедиться, что дубль контакта не создался.
• Оборвать сеть на середине и посмотреть, ушла ли заявка в буфер, а не в никуда.
• Проверить UTM-метки в карточке сделки - маркетологи первым делом смотрят именно на источник.
• Дождаться истечения access-токена и убедиться, что автообновление отработало.

Мониторинг я не оставляю на глаз человека. Раз в час сценарий проверяет, приходили ли заявки, и если за рабочий день их ноль при живом трафике на сайте - падает алерт. Молчание в воронке опаснее ошибки: ошибку видно сразу, а тихо оборвавшуюся интеграцию замечают через неделю, когда уже потеряны десятки обращений.

По срокам: типовую связку «форма Tilda → n8n → amoCRM» с дедупликацией и буфером я собираю за 1-2 рабочих дня. Проект с WooCommerce, обогащением данными об оплате из T‑Bank и трек-номерами СДЭК растягивается на неделю - там больше состояний и больше сценариев, которые надо проверить.

Частые вопросы

Нужен ли сервер для интеграции формы с amoCRM?

Для простой отправки через штатный коннектор Tilda или встроенную форму - нет, всё работает без своей инфраструктуры. Как только появляется обработка, дедупликация или обогащение данных, я поднимаю n8n на VPS. Самый дешёвый вариант - сервер за 200-300 рублей в месяц, этого хватает на поток в несколько тысяч заявок в сутки.

Что будет с заявкой, если amoCRM недоступна в момент отправки?

В грамотно собранной связке заявка не теряется. Сначала срабатывают ретраи с нарастающей паузой, и большинство временных сбоев закрываются на втором повторе. Если CRM не отвечает дольше, заявка уходит в резервное хранилище, а мне и клиенту прилетает уведомление в Telegram, чтобы долить её вручную.

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

Да, и это частый сценарий. Бот на aiogram и формы сайта шлют заявки в один и тот же webhook, а дальше n8n по нормализованному телефону решает, создавать новый контакт или цепляться к существующему. Клиент, который написал в бота и оставил заявку на сайте, окажется одной карточкой, а не двумя.

Как размечать источник заявки, чтобы это видел маркетолог?

UTM-метки я снимаю на стороне сайта в момент отправки формы и прокидываю их в кастомные поля сделки. В amoCRM заводятся поля вроде utm_source и utm_campaign, и по ним строится отчёт «сколько сделок принёс каждый канал». Для звонков источник подтягивается из телефонии по номеру, на который позвонил клиент.