Входящие заявки: чеклист контура от формы до учёта

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

Рядом в выдаче висят обещания «собрать систему автоматизации заявок за вечер» и статьи про CRM без шага «кто взял в работу». Я отделяю три темы. Уведомления о заявках - первый измеримый сигнал ответственному после формы: одно сообщение с полями и ссылкой. Автоматизация заявок - весь контур «вход → учёт → сигнал → ответственный» на любой платформе. Здесь фокус на входящих заявках как на цепочке от формы до строки учёта, где видно статус и ответственный.

Три формулировки, которые путают на старте:

На одном разборе у сервисной компании заявки приходили в Tilda, копировались в WhatsApp владельцем, а «учёт» жил в заметках на телефоне. Реклама шла, в ленте формы копились ответы, половина обращений не получала контакт в тот же день. Я предложил один канал приёма, имя ответственного и таблицу с пятью колонками. Через неделю стало видно, сколько заявок реально «зависло» без звонка - не из-за рекламы, а из-за разорванного контура.

Минимальный контур входящих заявок для меня - не стек из пяти сервисов, а четыре шага с проверяемым результатом на каждом. Форма (сайт, Яндекс.Формы, мессенджер, квиз) принимает ответ. Приём фиксирует факт поступления в одном согласованном месте - лента формы, webhook, бот или почта с правилом «не терять». Ответ - живой человек связывается с клиентом в согласованные N минут. Учёт - одна строка с полями, статусом и именем того, кто взял в работу.

Схема inline для пилота:

форма на сайте / Яндекс.Форма / бот в Telegram
        ↓
   приём (один primary-канал + резерв)
        ↓
   ответ ответственного (имя в чеклисте)
        ↓
   строка учёта (таблица или CRM - одна точка write)

Рабочий порядок на пилоте:

1. 01

   Выбрать одну форму с наибольшим потоком или с самой болезненной потерей ответов.

2. 02

   Согласовать 3-5 полей письменно до подключения второго канала или CRM.

3. 03

   Назначить одного ответственного и резервного - оба должны получить тест-заявку.

4. 04

   Выбрать один канал приёма: Telegram, webhook в чат, лента конструктора или почта ответственного.

5. 05

   Прогнать тест-заявку с публичной страницы, не из редактора.

Минимум полей, который я фиксирую в ТЗ:

1. 01

   Имя - как представился клиент или «не указано».

2. 02

   Контакт - телефон или email, что реально оставили.

3. 03

   Суть - услуга, вопрос, желаемая дата (одно текстовое поле).

4. 04

   Источник - UTM, название лендинга или скрытое поле «форма главная / акция».

5. 05

   Статус - new / в работе / закрыто; меняет только ответственный после контакта.

Входящие заявки с сайта на пилоте я не смешиваю с «временной» Google Form без согласования: разные поля, разные webhook, менеджер путает источники. Одна форма, один шаблон приёма, один ответственный, одна таблица write.

Пример минимальной строки учёта, которую я прошу видеть после тест-заявки:

{
  "id": "req_7f3a9c",
  "source": "landing-main",
  "contact": "+79001234567",
  "message": "Нужен расчёт на пятницу",
  "status": "new",
  "assigned_to": "Анна",
  "created_at": "2026-09-15T10:15:00+03:00"
}

SLA на пилоте я формулирую не как «100% доставка», а как согласованные N минут до первого контакта с клиентом после тест-заявки. Обычно 15-60 минут в рабочее время - достаточно, чтобы понять, доходит ли контур. Ночные заявки на пилоте либо уходят в утренний дайджест с пометкой, либо в отдельный чат дежурного - но это отдельное правило, не смешиваю с дневным контуром.

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

Приём входящей заявки - не «все каналы сразу», а один primary-канал, где ответственный точно видит новое обращение в рабочее время, и резерв, если основной молчит. Отвечать на входящие заявки в согласованный срок может только человек с именем в чеклисте, не «отдел продаж» и не «кто свободен».

Кто отвечает и за сколько минут

Я фиксирую письменно:

• имя ответственного и резервного (владелец, старший менеджер);
• primary-канал: рабочий Telegram-чат, webhook в тот же чат, лента Tilda или почта личного ящика;
• резерв: второй канал из списка, если primary не сработал в тесте;
• N минут до первого контакта с клиентом в рабочее время.

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

Каналы приёма: что сравниваю

Для Telegram Bot API webhook шлёт HTTPS POST с JSON Update; при ответе не 2xx платформа повторяет доставку (документация Telegram). Яндекс.Формы отправляют HTTP асинхронно с повторами при 5XX и заголовком x-delivery-id (send-request) - на приёмнике нужен дедуп, иначе дубли в чате и таблице.

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

Эпизод из практики: владелец интернет-магазина принимал заявки через пересылку из почты в личный Telegram. Менеджер не был в цепочке, клиентам отвечали с задержкой в сутки. Достаточно было назначить одного ответственного, завести рабочий чат и таблицу с колонкой «кто ответил» - без новой CRM.

Система входящих заявок в полном смысле появляется, когда форма, приём, ответ и учёт уже неделю совпадают с лентой ответов. До этого я не раздуваю стек: ни amoCRM со всеми полями, ни пять сценариев в n8n, ни «роя агентов» поверх хаоса.

Таблица как первая система учёта

Google Forms связывается с Google Sheets - каждая заявка становится строкой (справка Google). Яндекс.Формы дают почту, HTTP и при необходимости строку в Вики - паттерн описан в гайде по Яндекс.Формам. Для пилота я чаще начинаю с одной таблицы: те же 3-5 полей формы → колонки, статус меняет только ответственный. Прозрачно, дёшево, видно «кто ответил».

Критерий готовности таблицы: тест-заявка = новая строка с timestamp, контактом, источником и статусом new. Если строка не появляется - проблема в приёме, не в «не той CRM».

CRM - второй слой, не замена контура

Битрикс24 CRM-формы сохраняют заявки в CRM (справка); amoCRM принимает события через webhooks на destination URL (API). Интеграция сайта с CRM имеет смысл, когда контур форма → ответ → строка уже держится 3-7 дней без потерь. CRM до контура даёт карточки без SLA: менеджер не видит push, владелец смотрит отчёты по пустым этапам.

Типовой порядок подключения CRM:

1. 01

   Те же поля, что на пилоте в таблице → поля сделки или лида.

2. 02

   Один write-контур; дедуп по id ответа формы.

3. 03

   Ответственный в CRM совпадает с именем в чеклисте.

4. 04

   Неделя без расхождений «лента формы vs карточка» - потом второй лендинг с отдельным тегом источника.

n8n и iPaaS - когда не на первый день

n8n Form Trigger и Webhook запускают workflow; production URL появляется только после publish (документация n8n). На разборах слышу «соберём за десять минут» - риск не в скорости клика, а в трёх параллельных сценариях без пилота: дубли, тихие 500 на приёмнике, менеджер не знает, какой канал главный. Сначала ручной контур с тест-заявкой, потом один сценарий write в таблицу или CRM.

Пример тела POST от формы на webhook (упрощённо, без секретов):

{
  "form_id": "form_48291",
  "answer_id": "ans_7f3a9c",
  "submitted_at": "2026-09-15T10:15:00+03:00",
  "fields": {
    "name": "Анна",
    "phone": "+79001234567",
    "message": "Нужен расчёт на пятницу",
    "utm_source": "yandex_direct"
  },
  "headers": {
    "x-delivery-id": "dlv_9e2b1a"
  }
}

На приёмнике я сверяю answer_id или x-delivery-id перед записью в строку - иначе одна заявка трижды окажется в чате и таблице.

Ниже не общие советы «планируйте заранее», а симптомы с фиксом из разборов по входящим заявкам и обработке входящих без выдуманных ROI.

Отдельно про возражение «Albato или n8n соберут систему входящих заявок за вечер». Без пилота я фиксирую риск: параллельные сценарии дают дубли и тихие ошибки webhook, а не «больше лидов». Сначала один контур, потом iPaaS с теми же полями.

Смена домена, перенос формы в другой аккаунт или смена URL webhook - частый сбой: старый адрес в настройках, в логе 403 или таймаут. После любого переноса - новая тест-заявка и скрин успешной строки учёта с верным временем.

Перед масштабированием на вторую форму, CRM или ночной сценарий я прогоняю восемь пунктов приёмки. Это минимум для запроса «настроить входящие заявки» без хаоса в учёте.

1. Выбрана одна форма и один primary-канал приёма (Telegram, webhook в чат, лента формы или почта ответственного) - второй канал только как резерв.
2. Согласованы 3-5 полей: имя, контакт, суть, источник/UTM, статус - письменно до второй интеграции.
3. Назначен ответственный по имени и резервный получатель - оба подтвердили тест-заявку.
4. Тест-заявка отправлена с публичной страницы формы, не из режима предпросмотра редактора.
5. Приём сработал в согласованные N минут в рабочее время; при webhook проверен дедуп по x-delivery-id или answer_id.
6. Ответственный связался с клиентом; статус в строке учёта сменился с new на «в работе» или «закрыто».
7. Строка учёта: одна запись с верным временем, контактом и источником - таблица или CRM, но одна точка write.
8. Приёмка 3-7 дней: число ответов в форме совпадает с числом обработанных строк; ни одна заявка не «зависла» без контакта.

Если пункт 8 не выполняется - проблема почти всегда в двух параллельных учётах (чат без статуса + почта без строки) или в ответе без фиксации в таблице. Ещё один виджет из выдачи редко лечит это быстрее, чем один честный тест с экрана формы.

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

Признаки, что пора расширять

• Чеклист из восьми пунктов закрыт 3-7 дней подряд, расхождений лента/приём/строка нет.
• Ответственный не копирует заявки из почты вручную в чат.
• Нужен второй лендинг - тот же шаблон полей, отдельный тег источника, не смешивая до стабильного потока первой формы.
• Нужна интеграция сайта с CRM - поля копируют пилот, один write-контур.

Признаки, что рано

• Тест-заявка не будит ответственного.
• Webhook в логе с ошибками на каждой второй отправке.
• Подключили CRM, бота или iPaaS до первого успешного прохода «форма → ответ → строка».

Автоматизация обработки заявок на втором слое для меня - напоминание о просроченных статусах, дедуп между двумя формами, черновик ответа клиенту. Не замена живому приёму и не оправдание пропуска строки учёта.

В сентябре 2026 Cursor выкатил Projects в beta: координатор планирует и делегирует subagents, сам код не пишет, контекст общий для долгих задач (блог Cursor). Для входящих заявок я не плодю Projects и агентов до стабильного контура заявка → учёт → человек. Swarm уместен для кодовой базы и миграций, не для приёма лидов с лендинга. Метрики merge из поста Cursor не переношу на заявки - это другой процесс.

Автоматизация заявок в блоге - про весь контур; уведомления о заявках - про сигнал ответственному как первый измеримый шаг поверх того же контура.

Когда контур держится без потерь, на созвоне я разбираю не «какую CRM купить», а что мешало раньше и что добавить вторым шагом: второй лендинг с тегом, CRM вместо таблицы, webhook в Cursor /automate для черновика ответа - не вместо ping менеджеру. Если нужен разбор вашей схемы - разбор процесса. Внедрение под ключ, когда форма уже на трафике - разработка проектов.

Если нужен слой сигнала после формы - читайте уведомления о заявках. Если точка входа именно Яндекс.Форма - Яндекс.Формы в заявки. Карта шире, чем один канал - автоматизация заявок. Когда форма на сайте и нужен контур в CRM - интеграция сайта с CRM.

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