Как отправлять заявки с сайта в Telegram и MAX

Человек оставил заявку на сайте в 19:40. Письмо ушло на почту, почту смотрят утром, перезвонили в 11 следующего дня. За это время он написал ещё в две компании, и в одной ему ответили через десять минут.

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

Почему почта проигрывает

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

Почту открывают сессиями — утром, после обеда, вечером. Между сессиями заявка просто лежит. Ещё она попадает в общий ящик, где перемешана с рассылками, счетами и уведомлениями сервисов, и глазами не выделяется. А если ящиком пользуются двое, начинается «я думал, ты ответил».

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

Что понадобится

Бот. Не аккаунт человека, а именно бот: он создаётся за минуту, ему не нужен телефон, его не заблокируют за рассылку и он не уйдёт вместе с сотрудником.

Место, куда слать. Три варианта, и выбор важнее, чем кажется:

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

Мы берём группу. В ней сразу видно, кто ответил, и не нужно пересылать заявку коллеге отдельным сообщением.

Сервер, который отправит. Форма на сайте не должна слать сообщение сама — об этом дальше отдельно, это важнее всего остального.

Форма на сайте с отправкой в Telegram: как это устроено

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

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

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

На отправке заявок из России мы потеряли полдня, поэтому расскажу подробно.

Всё было написано и проверено на машине разработки — сообщения уходили. Выкатили на боевой сервер, нажали кнопку: тишина. Никакой ошибки на экране, заявка сохранена, сообщение не пришло.

Оказалось: с сервера, стоящего в России, обращение к Telegram просто не проходит — соединение висит и отваливается по таймауту. Двенадцать секунд ожидания и обрыв.

Коварство в том, что на разработке всё работает. Локальная машина ходит в интернет иначе, и проверка проходит успешно. А на боевом отправка молча не срабатывает: пользователь видит «заявка принята», в мессенджер ничего не приходит, ошибка оседает в журнале, который никто не читает.

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

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

При этом выбирают такой узел не только за цену: не менее важно, что он делает с ключами и с данными человека. Об этом дальше.

Где лежат ключи и что с персональными данными

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

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

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

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

И это же закрывает вопрос с персональными данными. Через узел проходят имя и телефон человека. Закон требует, чтобы такие данные записывались и хранились в базах на территории России — у нас так и есть, хранение идёт в своей системе. Узел ничего не записывает, он только передаёт: это транзит, а не второе место хранения. Поэтому «ничего не пишет» — пункт не про экономию места, а про соблюдение 152-ФЗ.

⚠️ И одно из своего опыта: не записывайте в журнал текст ошибки внешнего запроса целиком — в него попадает адрес вместе с токеном. Мы на этом обожглись — разбор случая есть в статье про единое окно для обращений.

MAX: что там иначе

MAX устроен похоже: бот, чат, отправка сообщения запросом. Основные отличия — практические.

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

Аудитория другая: если ваши клиенты живут в MAX, заявка там уместнее. Мы отправляем в оба мессенджера — стоит это ровно одного дополнительного вызова, а закрывает обе привычки.

⚠️ Не превращайте это в рассылку по всем каналам сразу. Дублирование одной заявки в четыре места означает, что её обработают дважды или не обработает никто.

Что важнее техники

Настройка занимает день. Дальше начинается то, из-за чего затея обычно и не срабатывает.

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

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

Что делать с историей. Мессенджер — плохое хранилище: искать в переписке за прошлый месяц невозможно. Заявка должна оставаться в системе, а сообщение — быть уведомлением, а не единственным следом. Мы сохраняем заявку до отправки, поэтому уведомление можно потерять без последствий.

Согласие на обработку данных. В форме — обязательно, до отправки, с сохранением отметки: кто, когда, какую редакцию документа принял. Как мы это сделали в каждом канале — разбирали отдельно.

На что смотреть, если делаете сами

• Заявка сохраняется до отправки, а не вместо неё.
• Ошибка отправки видна вам, а не только журналу: письмо, отдельное уведомление, отметка в интерфейсе.
• Есть повторная отправка — кнопкой, руками, без разработчика.
• Токен не лежит на сервере приложения и тем более не уходит в браузер.
• Сообщения об ошибках чистятся от секретов.
• В сообщении есть страница, с которой пришла заявка: без неё непонятно, на что человек откликнулся.

Что в итоге

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

Но техника здесь — меньшая часть. Отправку можно настроить за день, а вот договориться, кто отвечает вечером в пятницу, — это уже про то, как устроена работа. Без второго первое даёт только более быстрое уведомление о потерянном клиенте.

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

Хотите разобрать свой случай — расскажите о задаче.