Форма на сайте и Telegram: путь заявки, сбои и журнал отправок

Что соединяет интеграция сайта с Telegram

Интеграция сайта с Telegram — это связка из двух частей: страница с формой и обработчик на сервере. Клиент заполняет поля и нажимает «Отправить», страница передаёт данные обработчику, а тот формирует запрос к Bot API методом sendMessage и указывает, в какой чат положить сообщение. Сам Telegram о вашем сайте ничего не знает: он принимает готовый текст и доставляет его туда, где сидят ответственные.

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

Стоит разделить две задачи, которые часто смешивают. Доставить сообщение о заявке людям — здесь нужен только исходящий HTTPS-запрос. Принимать сообщения от клиентов ботом и отвечать — это уже другой сценарий: ему нужны webhook, домен и сертификат.

Два способа собрать связку

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

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

Путь заявки: шесть шагов

Четвёртый шаг — точка, где заканчивается ваша система и начинается чужая. До него заявка существует в ваших файлах, после — только как сообщение в чужом интерфейсе. Ошибка здесь не видна ни клиенту, ни менеджеру: клиент получил «спасибо, заявка принята», менеджер ничего не увидел. Поэтому подтверждение показывайте после ответа Bot API, а не после нажатия кнопки: в ответе есть поле ok, а при ошибке — description с причиной.

Лимиты, из-за которых заявки не доходят

Telegram прямо описывает ограничения в справке для разработчиков: в один чат не стоит отправлять больше одного сообщения в секунду, в группе бот не может отправить больше 20 сообщений в минуту, а на весь бот приходится около 30 сообщений в секунду. При превышении приходит ошибка 429, и в ответе бывает параметр с задержкой, после которой попытку имеет смысл повторить.

Для потока заявок этих лимитов хватает с запасом: 20 сообщений в минуту — это 1200 в час. Ловушка в другом: одно обращение часто отправляют трижды — менеджеру, в общий чат отдела, руководителю. Три копии уменьшают пропускную способность группы втрое, а в пик — после рассылки или вечером — лимит выбирается мгновенно, и копии отваливаются с ошибкой 429. Надёжнее слать одну копию в один чат, а остальным показывать заявку из своей системы.

Журнал отправок: минимальный набор полей

Журнал — единственный способ доказать, что заявка была, и одновременно ответ на вопрос «что именно сломалось»: форма, обработчик или доставка в чат. Держать его можно в базе, в таблице или в файле, важно не место, а набор полей.

• Номер заявки и время отправки формы — по ним ищут обращение и считают срок ответа.
• Все поля, которые ввёл клиент, включая комментарий целиком: в чат уходит сокращённый вариант.
• Адрес страницы, с которой пришла заявка, и источник перехода — без этого не понять, какая форма работает.
• Статус: принята, отправлена, доставлена, ошибка. Три состояния вместо двух нужны, чтобы отличать «ушло» от «дошло».
• Код ответа и текст ошибки от Bot API, номер попытки и время следующей.
• Идентификатор сообщения в чате, если он вернулся в ответе — тогда по заявке можно найти конкретное сообщение.

Отдельно заведите ключ отправки — свой номер заявки, который не меняется при повторах. Он нужен затем, чтобы повтор после таймаута не создал второе сообщение: таймаут не означает «не дошло», запрос мог дойти, а ответ потеряться. В Bot API для похожей задачи есть update_id — по нему отсеивают повторно присланные обновления при работе через webhook. И держите в голове срок: недоставленные обновления Telegram хранит не дольше 24 часов, так что вычитать накопившееся за неделю простоя не получится.

Что делать при сбое

Порядок разбора сбоя стоит зафиксировать заранее, иначе в момент инцидента все ищут виноватого вместо причины. Ниже — типовые отказы связки «сайт — Telegram» и что с каждым делать.

Повторы — отдельная дисциплина, и в ней легко сделать хуже. Amazon в AWS Builders' Library описывает три инструмента: таймаут на каждый удалённый вызов, ограниченное число повторов и паузу, растущую после каждой попытки, с добавкой случайного разброса, чтобы клиенты не повторяли синхронно. Там же предупреждение про каскад: если повторы включены на каждом из пяти уровней стека по три раза, нагрузка на нижний уровень вырастает в 243 раза. Для нашей связки вывод простой — повторять отправку должен один участник, обработчик формы, а не три звена по очереди.

И обязательный второй канал. Если отправка не удалась за отведённое число попыток, заявка уходит письмом на дежурный адрес, а в чат — строка «заявка № такой-то не доставлена». Сбой виден до того, как клиент позвонит. Проверять второй канал стоит заранее: раз в месяц — тестовая заявка при выключенном основном.

Пять проверок перед запуском

1. Отправьте тестовую заявку с телефона в мобильной сети, а не только с рабочего компьютера: половина проблем видна лишь на реальном устройстве.
2. Отключите на минуту доступ в интернет у обработчика и убедитесь, что заявка сохранилась, а после восстановления дошла сама.
3. Отправьте 30 заявок подряд: в чат должно прийти 30 сообщений, в журнале — 30 записей без дублей.
4. Заблокируйте бота в тестовом чате и проверьте, что сработали резервный канал и предупреждение.
5. Прочитайте, что именно приходит в сообщении: номер заявки, контакт, суть, время и страница. Без номера разбор инцидента превращается в переписку «а помнишь, вчера звонили».

Что остаётся человеку

Интеграция убирает ручное копирование: заявка появляется в чате сама, с номером и полным текстом. Она не отменяет ответа человеку, не выбирает, что отвечать, и не решает, брать ли заказ. Автоматизация отвечает за доставку и след, человек — за решение и за разговор. Где проходит эта граница и почему её нельзя размывать, мы разбирали в материале про уровни автономии ИИ-агента.

С чего начать

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

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