Bitrix24 как рабочее место ИИ-коллеги: правильная модель канала

Когда говорят «агент в Bitrix24», легко представить клиентского чат-бота с меню, кнопками и очередью операторов. В AiHummer коннектор устроен иначе: Bitrix24 — внутренний мессенджер сотрудников, а агент представлен человекоподобной пользовательской учётной записью. Ему пишут в личном диалоге или упоминают в группе, как коллеге. Эта разница определяет сценарии, права, интерфейс и критерии готовности.

Документация канала Bitrix24 описывает двусторонний маршрут: коннектор забирает входящие события и передаёт их в шлюз, а ответы возвращает через контракт Deliver. Отдельная страница плагина покрывает установку и настройку OAuth. Но наличие канала не означает, что агент автоматически умеет создавать задачу, менять CRM или отвечать каждому сотруднику. Эти полномочия проектируются отдельно.

Почему «коллега», а не «бот-витрина»

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

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

Как приходит сообщение

Производственный коннектор использует OAuth-контексты агентов и опрашивает события. Официальная документация Bitrix24 для im.v2.Event.get описывает получение событий текущего пользователя, подписку и позицию чтения событий (offset) для подтверждения обработки. Она также предупреждает об эксклюзивности: несколько приложений, забирающих очередь одного пользователя, могут конкурировать за события. Это надо учитывать при пилоте и миграции со старой интеграции.

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

Доступ начинается с организационной карты

Составьте список агентских учётных записей, отделов и разрешённых направлений. Правила доступа отделов (ACL) отвечают на вопрос, чьи сообщения обслуживает конкретный агент. В группе добавляется условие упоминания. На стороне AiHummer остаются привязки канала к агенту и пользовательский доступ. Один уровень не заменяет другой: OAuth-пользователь в Bitrix24, отдел, маршрут разговора и полномочия инструмента — разные сущности.

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

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

Модельный процесс первой линии

Сотрудник пишет: «Где инструкция по VPN для нового ноутбука?» Агент ищет в базе знаний, возвращает краткий порядок и ссылку на актуальный документ. Если инструкции нет или она просрочена, он не импровизирует, а создаёт запрос владельцу знаний — только если такой инструмент настроен.

Второй сценарий: «Создай заявку на доступ». Агент уточняет систему, роль и основание, показывает итоговые поля и вызывает инструмент. У заявки есть идемпотентный ключ, чтобы повторное событие не создало дубликат. Если у пользователя нет права или отдел не разрешён, запрос не исполняется.

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

Что измерять

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

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

Ограничения

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

Нельзя гарантировать время ответа, отсутствие лимитов Bitrix24 или доставку при недоступности внешней системы. Официальный API возвращает 429/503 и имеет собственные ограничения, поэтому очередь, лимит запросов и повтор должны быть частью эксплуатации.

Чек-лист пилота

Зафиксировать внутренний сценарий и не смешивать его с клиентской поддержкой.
Выделить Bitrix24-пользователя для каждого агентского контекста.
Проверить OAuth, обновление токена и отзыв доступа.
Настроить отделы, личные чаты, групповые упоминания и AiHummer-привязки.
Начать со справочных знаний и актуальных источников.
Добавлять действия отдельными инструментами с минимальными правами.
Проверить дубли, позицию чтения событий, перезапуск, медиа и ошибки доставки.
Не строить интерфейс на кнопках и неподдерживаемых возможностях.
Измерять не только ответы, но и решённые задачи и ошибки маршрутизации.
Назначить владельца канала и процедуру отключения.

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