Корпоративный Telegram-бот: интеграции и доступы

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

Типовые задачи

• Заявки от сотрудников. Отпуск, закупка, доступ, техподдержка. Бот собирает данные и создаёт заявку в системе.
• Согласования. Уведомление ответственному, две кнопки, результат в системе. Самая частая и самая окупаемая задача.
• Справки по данным. Остаток, статус заказа, сводка. Без входа в учётную систему.
• Уведомления по событиям. Новая заявка, просроченная задача, отклонение от нормы.
• Отметки о выполнении. Для тех, кто работает не за компьютером.
• Дежурства и алерты. Сообщение уходит в группу, а действие фиксируется за конкретным человеком.

Общее у всех: короткое действие вместо длинного входа в интерфейс.

Интеграции

Здесь основная работа. Три сценария по возрастанию сложности:

Готовый API у системы. Лучший случай: бот вызывает методы, получает ответ. Работы немного.

Есть механизм публикации, но нет нужного метода. Типично для учётных систем: публикация есть, а операции под вашу задачу нет. Её приходится описывать на стороне системы - разбор такого случая в статье про MCP-сервер для 1С; принципы те же, независимо от протокола.

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

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

Роли и доступы

Ключевой момент, который часто делают неправильно.

Неправильно: считать, что раз бот не публичный, доступ ограничен. Адрес бота узнать легко, и написать ему может кто угодно.

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

Правильно:

• Список разрешённых на вашей стороне: в базе, с ролями.
• Проверка в каждом обработчике по идентификатору пользователя из события - см. chat id и user id.
• Общая проверка в мидлвари для административной части, чтобы не копировать её в каждый обработчик - см. aiogram.
• Отдельная учётная запись в целевой системе с минимальными правами.
• Ограничение объёма выдачи. Справка по одному заказу, а не выгрузка всех.

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

Аудит действий

Для внутреннего бота это не опция.

Логировать нужно:

• Кто - идентификатор пользователя, а не имя, которое можно сменить.
• Что - какое действие и над каким объектом.
• Когда.
• Результат - успех или ошибка.

Зачем: согласование, сделанное через бота, - это юридически значимое действие внутри компании. Через полгода понадобится ответить, кто именно согласовал, и «в переписке где-то было» - неудовлетворительный ответ.

Второй мотив: логи показывают, чем реально пользуются. Обычно выясняется, что из десяти функций работают три, и это повод упростить бота, а не добавлять одиннадцатую.

Как устроена разработка такого бота - процесс и приёмка. Обсудить задачу - услуги. Обзор - гид по Telegram-ботам.