Тип бота
Оповещения, которые кто-то обязан принять, а не ещё один заглушённый чат
Telegram-бот диспетчеризации отправляет заявку или аварийное оповещение конкретному человеку, требует подтверждения приёма и эскалирует дальше, если подтверждение не пришло за отведённое время. Он заменяет групповой чат, в котором каждый считает, что этим уже занимается кто-то другой. Расставлять приоритеты за вас он не будет.
Боты оповещений и диспетчеризации: цена, сроки и ограничения
- Фиксированная цена
- $3,400 USD
- Срок
- 16 календарных дней с момента старта
- Потолок рассылки
- ~30 сообщений/сек на бота, ~20/мин в одну группу
- Холодные рассылки
- Невозможны — получатель должен написать боту первым
- Подтверждение доставки
- Только факт отправки: ни доставки, ни прочтения
- Заблокировавшие бота
- Отправка падает с явной ошибкой
As of 2025-10-01, Telegram Bot API 13.4
Какую задачу это решает
Операционные команды почти всегда начинают с группового чата, и какое-то время это работает. Поломка приходит тихо: группа растёт, сообщения идут непрерывно, люди отключают в ней звук. С этого момента канал, по которому идёт ваша срочная работа, — это канал, который никто не читает вовремя, и никто этого не замечает, потому что сообщения по-прежнему исправно доставляются.
Конкретный дефект в том, что у сообщения в группе нет адресата и нет состояния. Оно либо прочитано, либо нет, и между заявкой, которую все считают взятой, и заявкой, которую не тронул никто, нет никакой разницы. Самые дорогие происшествия в обслуживании оборудования, выездном сервисе и эксплуатации зданий почти никогда не вызваны пропавшим оповещением. Их вызывает оповещение, которое видели все и каждый решил, что оно адресовано соседу.
Исход меняют две вещи: адресность и подтверждение приёма. Заявка уходит названному человеку, этот человек обязан нажать «принял», и если он не сделал этого в окне, заявка уходит следующему. Звучит тривиально и меняет поведение сразу же, потому что исчезает та двусмысленность, из-за которой игнорировать было комфортно.
Как идёт разработка
Событие приходит из той системы, которая его обнаружила
Срабатывание мониторинга, тикет, порог на датчике, отправленная форма. Сам бот ничего не обнаруживает — он слой доставки и ответственности поверх систем, которые и так знают, что что-то произошло.
webhookМаршрутизация выбирает человека, а не группу
Кто получит заявку, решают текущий график дежурств, нужная квалификация и зона. Сообщение, адресованное одному человеку, ведёт себя совершенно иначе, чем то же сообщение в канале на тридцать человек, и продукт состоит именно в этой разнице.
chat-member-updatesПолучатель обязан принять или отказаться
Две кнопки и видимый обратный отсчёт. Отказ — это полноценный ответ, который сразу двигает заявку дальше; из системы убирают не отказ, а молчание.
inline-keyboardБез подтверждения срабатывает таймер эскалации
Окно задаёт приоритет: две минуты на критическую аварию, тридцать на рутинную заявку. Эскалация идёт к следующему в цепочке, затем к руководителю, и каждый шаг фиксируется.
broadcastУ принятой работы есть состояние, видимое всем
Принято, на месте, выполнено или заблокировано с указанием причины. Диспетчер видит доску, ничего не спрашивая, — и это убирает вторичные отвлечения, когда людей дёргают ради статуса.
inline-keyboardВсё пишется в журнал ради разбора, который будет потом
Кого известили, во сколько, кто принял, сколько заняло принятие. Это важнее всего на разборе после того, как что-то пошло плохо: память подводит, а запись — нет.
webhook
Что Telegram разрешает, а что нет
Бот отправляет порядка 30 сообщений в секунду суммарно и около 20 в минуту в одну группу.
Личные сообщения — быстрый путь, публикации в группу — медленный. Схема, которая раздаёт всё веером через один общий чат, упрётся в лимит ровно тогда, когда инцидент сделает этот чат оживлённым.
Бот не может написать пользователю, который сам ни разу ему не писал.
Каждый человек из графика дежурств обязан один раз открыть бота, прежде чем на него можно будет назначить заявку. Это реальный шаг внедрения, и ему место в плане запуска, а не в моменте первой эскалации.
Telegram не сообщает о доставке сообщения — только о том, что отправка принята.
Вы знаете, что сообщение ушло; вы не знаете, что его увидели. Ровно поэтому подтверждение приёма — это кнопка, а не предположение, и ровно поэтому эскалация идёт по таймеру.
Если пользователь заблокировал бота, отправка падает с явной ошибкой.
Эта ошибка трактуется как операционный сбой и показывается руководителю. Заблокировавший бота дежурный инженер — проблема графика, и узнавать о ней посреди инцидента поздно.
Поведение уведомлений Telegram определяют настройки на устройстве самого пользователя.
Протолкнуть критическое оповещение сквозь телефон в режиме «не беспокоить» нельзя. Там, где человека действительно нужно разбудить, цепочка эскалации обязана заканчиваться каналом, которым Telegram не управляет, — например телефонным звонком.
Когда это не нужно строить
- Вам нужен гарантированный подъём по тревоге там, где на кону жизнь и здоровье. Telegram не перебьёт беззвучный режим телефона, и правильный инструмент здесь — пейджер или служба обзвона.
- В команде меньше пяти человек, и все сидят в одной комнате. Сказать вслух быстрее, а дисциплина подтверждений будет ощущаться бюрократией — потому что ею и будет.
- Нет графика дежурств и нет договорённости о том, кто за что отвечает. Бот начнёт маршрутизировать работу по структуре, которой не существует, и покажет это, а не починит.
- Ваши оповещения уже настолько шумные, что их игнорируют. Сделать их труднее для игнорирования, не убрав шум, — это сначала раздражение, потом отключённый звук, потом исходная проблема.
На чём это работает
| Компонент | Версия | Зачем |
|---|---|---|
| grammY | 1.45 | Фреймворк бота; состояние диалога хранится на каждого пользователя ради подтверждений. |
| Cloudflare Workers | current | Среда исполнения; таймеры эскалации крутят cron-триггеры. |
| Cloudflare D1 | current | График дежурств, заявки, состояние подтверждений и журнал аудита. |
| Zod | 4.4 | Валидация входящих webhook-вызовов от систем мониторинга и тикетов. |
| TypeScript | 5.9 | Строгий режим. Эскалация — конечный автомат, и типы здесь окупаются сразу. |
О чём спрашивают перед стартом
Чем это отличается от группы в Telegram с упоминаниями?
Упоминание — это просьба обратить внимание, у которой нет состояния. Здесь система знает, принял ли заявку конкретный человек, и действует сама, если не принял. Разница вылезает в ту ночь, когда упомянутый спал.
Что будет, если заявку не примет никто во всей цепочке?
Эскалация дойдёт до конца цепочки и поднимет отдельное оповещение руководителю с прямой формулировкой, что цепочка исчерпана. Молча система не сдаётся никогда: диспетчеризация, тихо теряющая работу, опаснее, чем её отсутствие.
Можно ли задать разные окна эскалации под разные приоритеты?
Да, и нужно. Критическая авария с окном в тридцать минут — это театр, а рутинная заявка с окном в две минуты приучает людей нажимать «принял», не читая. Окна настраиваются для каждого уровня приоритета отдельно.
Учитывает ли он передачу смены?
Да. График знает, кто сейчас на дежурстве, и эскалация идёт по нему, а не по фиксированному списку. Передача смены — момент, на котором ручная диспетчеризация рассыпается чаще всего, потому что список в чьей-то голове отстаёт на сутки.
Может ли он забирать заявки из нашей тикет-системы?
Да: через webhook там, где ваша система это умеет, и опросом там, где не умеет. Тикет-система остаётся источником истины о содержании заявки, а бот отвечает за то, кому сказали и ответил ли он.
Что именно попадает в журнал аудита?
Каждое отправленное уведомление, кому и в какую минуту, каждое подтверждение или отказ, каждый шаг эскалации и итоговое состояние. Журнал выгружается, потому что его основное применение — разбор после происшествия, а не дашборд.