Telegram давно стал для нас основным каналом общения с клиентами. Это быстро, привычно и не требует создания отдельных порталов, заполнения логинов-паролей и форм. Клиенты пишут нам так же легко, как друзьям, а инженеры отвечают скринами, логами и командами из терминала.
Но у этого удобства есть обратная сторона. Когда чатов становится не десятки, а сотни и тысячи, начинает побеждать хаос. В какой-то момент мы поняли: либо мы научим Telegram жить по правилам SLA, либо сами перестанем в эти правила укладываться.
В статье расскажем, как мы поддерживаем пилотных и VIP-клиентов прямо в Telegram — без классического Service Desk, но с измеримым и контролируемым SLA.
Откуда появилась задача
За несколько лет у нас накопилось больше тысячи групповых Telegram-чатов с пилотными и VIP-клиентами. Вместе с ними проявились три системные боли.
Сообщения теряются
Когда одновременно идут обсуждения в десятках чатов, легко не заметить, что в одном из них два дня никто не отвечает.
SLA в 60 минут невозможно посчитать
Telegram не знает, что такое «тикет», «первый ответ» и «просрочка». Попытки вести учёт в Excel ломаются уже на сотне чатов и паре дежурных смен.
Менеджерам нужны цифры
Фраза «кажется, всё нормально» не работает на квартальном совете директоров. Нужны факты: проценты, среднее время реакции, динамика по месяцам.
При этом отказываться от Telegram мы не хотели, потому что клиенты его любят. Значит, нужно было добавить дисциплину поверх привычного интерфейса.
Антидот: Python-бот, который превращает чат в тикет
Мы написали небольшой микросервис — Telegram-бота, который смотрит на каждый чат как на отдельную задачу и автоматически измеряет время реакции.
Логика получилась простой.
Как бот реагирует на новое сообщение
Получает апдейт через Bot API.
Проверяет автора сообщения. В системе есть группы пользователей support и sales — туда добавлены Telegram ID сотрудников компании МУЛЬТИФАКТОР. Если сообщение отправил пользователь не из этих групп, бот считает его клиентским обращением.
Если пишет клиент — создаётся задача и запускается SLA (до первого ответа).
Если отвечает саппорт или администратор — таймер останавливается, задача считается закрытой.
В PostgreSQL сохраняется запись: chat_id, момент создания, статус, метки времени.
Планируются напоминания:
Через 45 минут — жёлтый уровень и эмодзи ⚡ в дежурный чат
Через 55 минут — оранжевый уровень и эмодзи ❗
При достижении 60 минут — красный уровень, эмодзи ⚠️ и отметка SLA MISS
Бот никогда не замолкает из-за ограничений Telegram: мы учитываем Retry-After/флуд-контроль и делаем ретраи, чтобы переживать 429 Too Many Requests.
В итоге каждое новое обращение клиента (когда нет открытой задачи) становится тикетом, даже если оно написано в обычной группе.
Учёт рабочего времени, а не минут
Следующий подводный камень — рабочие часы. Если считать SLA по календарю, ночные сообщения мгновенно портят статистику.
Мы заложили расписание поддержки:
Понедельник – пятница: 03:00–23:00 (UTC+3)
Суббота – воскресенье: 10:00–19:00
Если сообщение пришло ночью, таймер стартует в первую минуту рабочего окна.
Если 60-минутный лимит «проваливается» через конец дня, остаток переносится на завтра.
Праздники бот берёт из публичного .ics-календаря, кеширует его на сутки и учитывает так же, как выходные.
В результате SLA отражает реальную работу команды, а не случайное время отправки сообщений.
Из чего состоит сервисный стек
Архитектура получилась компактной, без тяжёлых ITSM-систем.
Listener
Принимает апдейты Telegram. Используем чистый long polling (getUpdates), но при необходимости легко переключаемся на webhook.
SLA Engine
Считает рабочие минуты. Асинхронный коллектор таймеров, все состояния задач хранятся в таблице tasks.
Notifier
Отправляет ⚡❗⚠️-уведомления в дежурный чат на отметках 45, 55 и 60 минут.
Mailbox Watch
Следит за почтой. Если письмо висит без ответа больше 30 минут, бот пишет: «Проверьте, тикет не ушёл в Яндекс.Трекер».
Reporter
Отчётность прямо в Telegram:/slastat — сводка с первого числа месяца
/report <from> <to> — любой период
автоматическая выгрузка CSV раз в квартал
Сама отчётность выглядит вот так:
Role Manager
Управление «Ролями» сейчас реализовано через добавление с помощью InlineKeyboard и разрешено только администраторам бота.
DB Migrations
Для эволюции схемы без простоя. Используем Alembic: версия схемы хранится в alembic_version, alembic upgrade head запускается в CI перед деплоем и обеспечивает zero-downtime roll-out.
Как работает бот
Рассмотрим гипотетический сценарий, как будет работать бот, если команда саппорта не заметит сообщение от клиента.
12:00 — клиент пишет: «Не работает сервис».
12:00 — бот фиксирует задачу и ставит таймеры 45/55/60 минут.
12:45 — бот пишет в дежурный чат: ⚡ осталось 15 минут.
12:55 — бот: ❗ осталось 5 минут.
12:57 — саппорт отвечает клиенту.
12:57 — бот фиксирует закрытие задачи и факт, что SLA не нарушен.
Если ответа нет, чат помечается как 🔴 SLA MISS, а в базе растёт счётчик overdue=true. Без обсуждений и оправданий.
Права бота и privacy mode Telegram
Чтобы бот видел обычные сообщения в группах, мы отключили privacy mode и выдали необходимые права на чтение сообщений.
Кейс «анонимный админ» в группах
Мы учли режим «анонимный админ»: когда сообщение отправлено «от имени группы», бот всё равно распознаёт его как ответ саппорта и закрывает задачу.
Устойчивость к рестартам
После рестарта бот поднимает SLA-трекинг по всем открытым задачам из базы и продолжает отсчёт без потери состояния.
Честное уточнение про метрики (FRT vs MTTR)
Мы измеряем First Response Time — время до первого ответа. MTTR в классическом смысле не считаем, потому что «решение» может требовать нескольких итераций переписки.
Защита от дублей и гонок
Создание задачи реализовано идемпотентно: в одном чате не появятся две «открытые» задачи из-за гонок или параллельных апдейтов.
Важная особенность
Бот не отправляет сообщения в клиентские чаты — только в дежурные или служебные.
Отчётность без лишних BI-инструментов
Мы сознательно не прикручивали Grafana или отдельный BI.
Менеджеры получают цифры прямо в Telegram:
количество обращений
First Response Time
процент ответов в SLA
список «горячих» чатов
Финансистам раз в квартал прилетает CSV со строками: chat_id, created_at, first_reply_at, overdue. Этого хватает для расчёта KPI.
Что дала автоматизация
После внедрения бота цифры изменились быстро и наглядно:
98 % обращений укладываются в SLA 60 минут (раньше было около 70%)
Средний First Response Time снизился примерно на 40%
Саппорт перестал ставить ручные напоминания и будильники — бот делает это точнее и круглосуточно
Что в итоге
В какой-то момент мы перестали воспринимать Telegram как неформальный канал общения и признали очевидное: если в нём живёт поддержка, значит, в нём должны жить и метрики, и ответственность, и автоматизация. Мы не строили ещё один Service Desk и не заставляли клиентов менять привычки, а просто добавили слой логики, который превращает поток сообщений в управляемый процесс. В итоге инженеры продолжают общаться в знакомом интерфейсе, а менеджеры получают прозрачные цифры.
Главный вывод оказался простым: даже тысяча Telegram-чатов может работать предсказуемо, если у них есть понятные правила и автоматический контроль.
P.S. Эта статья готовилась до момента блокировки Telegram в России и описывает наш фактический опыт работы с этим каналом на тот момент. Разумеется, поддержка у нас не ограничивается одним мессенджером — у клиентов есть и другие способы связи с техподдержкой. О них и о том, как меняется архитектура коммуникаций, расскажем в следующих статьях.
