Telegram-бот для согласования внутренних заявок: кто решил, что одобрено и что дальше

MAATRIX · 17 октября 2026 · 8 мин чтения

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

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

Что должно быть видно до кнопки

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

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

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

Роли появляются раньше маршрута

Свяжите Telegram ID с действующей учётной записью сотрудника через корпоративный вход или подтверждение администратора. Username и отображаемое имя не являются основанием для полномочий. Сотрудник с именем «Финансовый директор» может оказаться очень убедительным дизайнером интерфейсов.

Для каждой категории заявки задайте маршрут. Например, непосредственный руководитель подтверждает необходимость, а ответственный за бюджет — сумму выше согласованного порога. Эти правила относятся к вашей организации; бот не должен выводить их из названия должности по догадке.

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

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

Состояния, которые не спорят между собой

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

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

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

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

Как устроить данные

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

Для истории сохраняйте предыдущую и новую версии, участника, действие, время и комментарий. Содержимое одобренной версии должно оставаться доступным для проверки. Если все поля постоянно перезаписываются, журнал «одобрено вчера» не объяснит, что именно вчера одобрили.

Не помещайте всю заявку в данные кнопки. В callback_data передайте короткий идентификатор действия или непрозрачный токен, а подробности получите из базы. Telegram описывает callback-кнопки и ответы на них в Bot API. Размер, формат и наличие кнопки не являются проверкой полномочий.

Для Python-проекта aiogram предоставляет Callback Data Factory и фильтры. Они помогают упаковывать и разбирать значения, но бизнес-проверки всё равно остаются в вашем обработчике. Библиотека не знает, разрешено ли конкретному сотруднику согласовывать покупку за эту сумму.

Что происходит после нажатия

Обработчик получает пользователя из проверенного обновления Telegram, извлекает действие и находит заявку. Затем проверяет активность сотрудника, назначение на текущий этап, версию карточки и допустимость перехода. Только после этого меняет состояние.

Ниже показана идея условного обновления для собственной таблицы approval_requests в PostgreSQL. Это учебный фрагмент для одного согласующего и одного этапа. Параметры поступают из серверного обработчика, а не напрямую из непроверенного текста. Предварительная проверка активной учётной записи остаётся обязательной.

UPDATE approval_requests
SET state = 'approved',
    decided_by = $3,
    decided_at = now(),
    version = version + 1
WHERE id = $1
  AND version = $2
  AND state = 'pending'
  AND approver_id = $3
RETURNING id, version, state;

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

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

После обработки ответьте на callback, чтобы клиент Telegram завершил ожидание. Уберите устаревшие кнопки или обновите карточку. Если редактирование сообщения не удалось, состояние базы всё равно остаётся источником истины: повторное нажатие должно получить ответ «решение уже принято», а не выполнить действие снова.

Возврат на доработку — полноценный результат

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

Отклонение тоже должно иметь объяснение. Короткое «не предусмотрено бюджетом» полезнее красной надписи без следующего шага. При этом комментарий не должен содержать сведения, которые нельзя показывать автору; для внутренних заметок предусмотрите отдельное поле и права.

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

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

Напоминания без превращения в будильник

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

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

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

Приёмка на трёх сотрудниках

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

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

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

Для бота, небольшой PostgreSQL и фоновых напоминаний можно начать с VPS MAATRIX Uab Start с 4 GB RAM на поддерживаемой Ubuntu или Debian. При росте числа интеграций и вложений измерьте ресурсы и рассмотрите Heka Standard с 8 GB. Резервируйте базу, храните токен отдельно и настройте постоянный запуск приложения.

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