Карта каналов AiHummer: не список логотипов, а набор текущих контрактов

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

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

Telegram: токен — только начало

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

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

MAX: собственный коннектор и собственная приёмка

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

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

Bitrix24: внутренний мессенджер сотрудников

В текущем контракте Bitrix24 используется как внутренний чат для сотрудников, а не как клиентский омниканал. Коннектор забирает из Bitrix24 входящие события — текст, медиа и голос — и передаёт их в шлюз AiHummer; среди них могут быть изображения, аудио, голосовые сообщения и файлы. Исходящие ответы агента отправляются обратно в Bitrix24; медиа в них поддерживаются. Интерактивные клавиатуры, кнопки и треды не поддерживаются. Формулировка «Моделируемый сценарий: коллега пишет агенту» соответствует назначению лучше, чем обещание очереди клиентской поддержки.

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

Приложение — не ещё один канальный коннектор

Мобильный и настольный клиент обслуживает os-client: QR-привязка, обмен в реальном времени, медиа и уведомления имеют собственный жизненный цикл. В карте укажите его отдельно, вместе с сетевой доступностью и тарифным правом. Так поддержка не будет искать проблему приложения в настройках Telegram.

Маршрутизация и доступ

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

Как поддерживать карту живой

У каждой строки укажите владельца и дату проверки. Обновляйте её при релизе коннектора, смене тарифа, отзыве учётных данных, изменении внешнего API или выводе поверхности. Статусы лучше формулировать как «проверено», «не настроено», «недоступно по тарифу» и «состояние неизвестно», а не одним словом «есть».

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

Поля рабочей матрицы

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

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

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

Для медиа создайте отдельную таблицу форматов. На входящем пути коннектор получает из Bitrix24 текст, медиа и голос и направляет их в шлюз AiHummer. На исходящем пути отдельно проверяйте ответы агента и медиа, которые отправляются обратно в Bitrix24. Интерактивные клавиатуры, кнопки и треды не поддерживаются; Telegram и MAX тоже различаются по интерактивным элементам, опросам и файлам. Если бизнес-процесс требует конкретный тип, подтвердите его на всём сквозном пути, включая размер, преобразование и повтор после ошибки.

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

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

Минимальный паспорт канала

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

Раз в месяц выбирайте один канал и повторяйте пользовательский путь с нуля. Такая ротация ловит истёкшие учётные данные, изменение внешнего API и забытый маршрут раньше реального обращения. Результат датируется; старый протокол остаётся историей, а не подтверждением текущей доступности.

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

Актуальные особенности смотрите на страницах Telegram, MAX и Bitrix24. Составьте собственную матрицу из нужных сценариев и подтвердите каждую строку на тестовом аккаунте перед обещанием пользователям.