Как собрать заявки из сайта, Telegram, почты и мессенджеров в одну очередь

Чтобы собрать заявки из сайта, Telegram, почты и мессенджеров в одну очередь, недостаточно пересылать сообщения в общий чат. Нужен единый входной контур: каждый канал создаёт событие, система подтверждает его приём, приводит данные к общей схеме, проверяет повтор, связывает обращение с клиентом, сохраняет исходный канал и только затем создаёт или обновляет запись в CRM и ставит её в очередь ответственному.

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

Что именно означает «одна очередь заявок»

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

Минимально готовый контур должен обеспечивать:

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

Если хотя бы один канал по-прежнему проверяется человеком отдельно, общая цифра «новых заявок» недостоверна. Поэтому начинать следует не с дашборда, а с карты событий и точек подтверждения.

Как устроен процесс от сообщения до ответственного

Надёжный маршрут состоит из коротких этапов, каждый из которых можно измерить и повторить:

1. Получить. Webhook, API, почтовая подписка или форма передают событие во входной endpoint.
2. Подтвердить. Endpoint быстро проверяет подлинность, сохраняет сырой конверт и отвечает каналу успешным кодом.
3. Нормализовать. Адаптер преобразует разные поля в общий объект заявки.
4. Проверить повтор. Система сравнивает технический ключ события и бизнес-признаки обращения.
5. Определить клиента. Подтверждённые телефон, email, канальный user ID и другие ключи сопоставляются с CRM.
6. Создать или обновить. В CRM появляется контакт, обращение или активность без потери предыдущей истории.
7. Маршрутизировать. Правила выбирают очередь, владельца, приоритет обслуживания и дедлайн.
8. Записать результат. Журнал связывает исходное событие, нормализованную версию, CRM ID и итог маршрутизации.

Внешний webhook не должен выполнять весь процесс синхронно. Например, Microsoft Graph рекомендует быстро подтвердить уведомление или поставить его в очередь; при ошибке либо таймауте доставка может повториться. Это нормальное свойство интеграции, поэтому получатель обязан быть готов к повторной обработке.

Единый контракт события заявки

Каналы передают разные объекты: форма — поля и UTM, Telegram — объект Update, почта — сообщение и thread, мессенджер — событие диалога. Внутри системы они должны стать одним объектом, условно LeadEvent. Это не карточка клиента, а зафиксированный факт поступления обращения.

Полезный ориентир даёт спецификация CloudEvents: сочетание source + id должно быть уникальным для отдельного события, а повторно отправленное событие может сохранить тот же ID. Не обязательно внедрять стандарт буквально, но принцип стоит перенести в собственный контракт.

Особенности подключения разных каналов

Форма сайта

Форма должна создавать серверное событие до отправки писем и уведомлений. Клиентский JavaScript не является единственной гарантией: запрос может повториться после таймаута, пользователь — нажать кнопку дважды, а антиспам — задержать обработку. Сервер выдаёт ID приёма, сохраняет согласованные поля и атрибуцию, после чего отдельный worker пишет данные в CRM.

Telegram

Telegram Bot API предлагает два взаимоисключающих способа получения обновлений: long polling и webhook. У объекта Update есть update_id, который помогает обнаруживать повторы и восстанавливать последовательность. При webhook следует проверять секретный токен, хранить технический ID и не считать повторную доставку новой заявкой.

Почта

Пересылка писем на ещё один ящик не создаёт надёжный контур. Gmail API использует watch, уведомления Pub/Sub и historyId, после чего приложение запрашивает изменения. Подписку нужно продлевать, а документация прямо рекомендует резервную синхронизацию, потому что уведомления могут задерживаться или теряться. Для Microsoft 365 аналогичную роль выполняют change notifications, lifecycle events и delta query.

Другие мессенджеры

Для каждого канала нужен собственный адаптер подлинности, подтверждения, rate limit, вложений и повторов. Но после адаптера все события обязаны соответствовать одному контракту. Бизнес-логика не должна знать, как именно Telegram или почта доставили сообщение.

Дедупликация: три разных вида совпадений

Ошибка — искать дубли только по телефону. В системе есть как минимум три разных задачи:

1. Технический дубль события. Один webhook или notification доставлен повторно. Его безопасно подавить по канальному ключу.
2. Тот же человек. Совпали подтверждённые идентификаторы. Контакт можно связать, но обращение не обязательно закрывать.
3. Та же потребность. Клиент написал в чат, а через пять минут отправил форму по тому же вопросу. Это может быть продолжение существующего обращения либо новая заявка — решение зависит от времени, темы и состояния сделки.

На уровне базы полезны уникальные ограничения и идемпотентная запись. PostgreSQL поддерживает INSERT ... ON CONFLICT, но upsert решает только заранее определённый конфликт ключей. Бизнес-решение «это то же обращение или новое» остаётся отдельным правилом. CRM также может поддерживать upsert по email или пользовательскому уникальному идентификатору, однако ключи и последствия обновления надо определить до интеграции.

Единый статус без потери канального состояния

Нельзя использовать статусы Telegram, почты и CRM как взаимозаменяемые. У системы должны быть два слоя:

• техническое состояние события: принято, проверено, нормализовано, записано, ошибка, повтор;
• бизнес-состояние обращения: новое, назначено, в работе, ожидает клиента, завершено, отклонено.

Техническая ошибка не должна переводить лид в «отказ», а прочитанное сообщение не означает «обработано». Каждый переход хранится как событие: старое состояние, новое, причина, инициатор и время. Тогда можно восстановить историю и корректно пересчитать очередь после сбоя.

Сохраняйте источник, даже если клиент сменил канал

Поле source = Telegram недостаточно. Нужно различать как минимум первый источник, источник текущего сообщения, marketing touchpoint и технический путь доставки. Клиент мог впервые прийти с рекламной страницы, написать в мессенджер, затем продолжить по почте. Перезаписывание одного поля уничтожит атрибуцию и усложнит анализ качества каналов.

Храните исходные метки неизменяемо, а вычисляемую атрибуцию — отдельно и с версией правила. Если UTM отсутствуют, это не повод придумывать источник: значение остаётся неизвестным. На форме фиксируйте только согласованные параметры; не переносите в CRM весь URL, если он может содержать персональные или секретные значения.

Очередь обработки и назначение ответственного

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

Правила маршрутизации лучше начинать с детерминированных условий: регион, продукт, язык, тип клиента, рабочее время и доступность группы. AI можно подключить позже для извлечения признаков, но отсутствие уверенности не должно оставлять заявку без владельца. Безопасный fallback — общая очередь с явным сроком и алертом.

Назначение считается завершённым только после фиксации ответственного в системе истины. Сообщение в чате — уведомление, а не подтверждение владения. Если сотрудник недоступен или не принял заявку, правило возврата должно снова поставить её в рабочую очередь.

Архитектура решения и движение данных

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

1. Адаптеры каналов проверяют подпись, токен и схему входа.
2. Ingress endpoint быстро сохраняет сырой конверт и подтверждает приём.
3. Event store и очередь дают повторяемость, retry и контроль порядка.
4. Нормализатор создаёт версионируемый LeadEvent.
5. Identity resolution ищет клиента и фиксирует силу совпадения.
6. CRM adapter идемпотентно создаёт контакт, обращение и активность.
7. Router и журнал назначают владельца, ставят дедлайн и сохраняют результат.

Сырые payload не должны бесконтрольно копироваться между сервисами. В рабочую запись попадает минимальный набор, необходимый для процесса; секреты, лишние заголовки и чувствительные вложения обрабатываются по отдельной политике. Подготовка такого контура данных описана в статье о готовности данных к внедрению AI.

Ошибки, ограничения и безопасный fallback

• CRM временно недоступна. Событие остаётся в durable-очереди, попытка повторяется, а возраст очереди контролируется.
• Webhook доставлен повторно. Идемпотентный ключ возвращает ранее созданный результат без второй заявки.
• Подписка истекла или уведомление потеряно. Плановая сверка API восстанавливает пропущенные изменения.
• Контакт определён неоднозначно. Создаётся задача разбора, а записи не объединяются автоматически.
• Вложение слишком большое или запрещённого типа. Заявка принимается без обработки файла, пользователь или менеджер получает понятный статус.
• Неверная подпись webhook. Событие отклоняется до очереди и фиксируется как инцидент.
• Правило маршрутизации не сработало. Заявка идёт в общую fallback-очередь, а не исчезает.

Системы доставки часто работают по модели at-least-once: сообщение может прийти больше одного раза или не по порядку. Даже режим exactly-once у конкретного брокера не устраняет дубли, созданные самим источником. Поэтому уникальность, журнал прогресса и идемпотентные действия нужны на стороне бизнес-приложения.

Права доступа и персональные данные

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

Токены каналов хранятся отдельно от payload, webhook проверяется до записи в бизнес-очередь, вложения проходят проверку и карантин. Менеджер видит только те обращения, которые нужны его роли. Конкретную схему обработки персональных данных следует сверять с применимым законодательством, договорами, безопасностью и профильным юристом.

Как измерить качество, эффект и стоимость

До внедрения зафиксируйте baseline по каждому каналу. Измеряйте не количество настроенных интеграций, а качество движения заявки:

• доля событий, подтверждённых каналом и записанных во входной журнал;
• доля заявок, дошедших до CRM без ручного копирования;
• число технических дублей и доля безопасно подавленных повторов;
• доля неоднозначных совпадений клиента;
• время от события до появления в рабочей очереди;
• доля заявок без владельца и с просроченным первым действием;
• расхождение между каналом, event store и CRM при сверке;
• стоимость обработки одного события и одной принятой заявки;
• возраст самой старой записи в retry и quarantine очередях.

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

Расчётный сценарий без выдуманного кейса

Это пример структуры расчёта, а не результат клиента. Допустим, заявки приходят из формы, Telegram и двух почтовых ящиков. Сначала команда неделю считает входы по журналам каналов и отдельно — записи в CRM. Расхождение становится baseline потерянных или продублированных событий.

В пилоте подключают один endpoint, общий контракт и две очереди: рабочую и карантин. Формула создаёт событие с собственным ID; Telegram сохраняет update_id; почтовые адаптеры хранят message ID и курсор синхронизации. В CRM запись выполняется по идемпотентному ключу события, а совпадение клиента оценивается отдельно.

Пилот считается технически готовым не после появления красивого списка, а после сверки контрольного периода: все подтверждённые события либо связаны с CRM, либо имеют объяснимый статус retry, duplicate или quarantine. Только затем к очереди можно подключать AI-классификацию и автоматические ответы.

Пошаговый план внедрения

1. Перечислите каналы, аккаунты, типы событий и владельцев доступа.
2. Соберите baseline: объём, пики, задержки, потери, дубли и ручные передачи.
3. Определите единый LeadEvent, обязательные поля и версию схемы.
4. Назначьте технический ключ идемпотентности для каждого канала.
5. Разделите правила повтора события, совпадения контакта и совпадения потребности.
6. Опишите технические и бизнес-статусы как две отдельные машины состояний.
7. Настройте ingress, event store, retry, quarantine и мониторинг возраста очереди.
8. Подключите CRM через идемпотентное создание или обновление и сохраните связь ID.
9. Добавьте детерминированную маршрутизацию и общую fallback-очередь.
10. Настройте резервную сверку каналов, журнал переходов и алерты.
11. Проверьте повторы, таймауты, недоступность CRM, истечение подписки и конфликты контактов.
12. После стабильной доставки подключайте квалификацию, ответы и аналитику продаж.

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

Нужно ли переносить все переписки в CRM?

Нет. В CRM достаточно хранить необходимые для процесса факты, связи и историю действий. Полный сырой payload можно держать в защищённом event store с ограниченным сроком и доступом, если это действительно нужно для аудита.

Можно ли использовать общий чат как единую очередь?

Чат полезен для уведомлений, но плохо подходит как система истины: в нём нет надёжной идемпотентности, формальной машины статусов, владельца записи и сверки с источником. Очередь должна существовать независимо от уведомления.

По какому полю искать дубли?

Технический повтор ищут по уникальному ключу канала. Контакт сопоставляют по подтверждённым идентификаторам, а повтор потребности — по совокупности клиента, темы, времени и состояния обращения. Одного универсального поля нет.

Что делать, если CRM недоступна?

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

Как не потерять письма?

Хранить курсор или history ID, продлевать подписки, подтверждать уведомления и выполнять периодическую сверку через API. Одного webhook недостаточно, если поставщик допускает пропущенные или задержанные уведомления.

Нужно ли сразу подключать AI?

Нет. Сначала докажите, что события стабильно поступают, не дублируются, связываются с CRM и получают владельца. После этого AI можно применять для извлечения полей, классификации и подсказок без маскировки проблем интеграции.

Как сохранить первичный источник при смене канала?

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

Что является критерием готовности пилота?

За контрольный период каждое подтверждённое событие имеет известный итог: записано в CRM, подавлено как технический дубль, ожидает повторной попытки либо находится в объяснимом карантине. Необъяснимо потерянных событий быть не должно.