Один процесс для Max и Telegram: как объединить заявки и не плодить копии ботов

В колонке для Cossa Айнюков разбирает обычную онлайн-запись в салон, клинику или студию. Клиент выбирает услугу и время, оставляет контакт, а администратор проверяет детали и подтверждает запись. Но что произойдёт, если человек напишет сначала в Telegram, а затем в Max? При простом копировании бота компания получит две переписки и, возможно, две заявки. Сотрудникам придётся разбираться, кто отвечает клиенту и на каком этапе находится его обращение.

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

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

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

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

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

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