Telegram-бот для техподдержки: очередь, приоритеты и история обращения

Лид: Сбор контекста, создание обращения, назначение оператора, статусы и сохранение истории переписки.

Дата проверки продуктовых сведений: 2026-10-03

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

Зачем строить техподдержку в боте

Telegram-бот даёт точку входа, где пользователь описывает проблему естественным языком без необходимости переходить на сайт или заполнять веб-форму. Сообщения приходят в чат с ботом, а бот сразу фиксирует текст, вложения и метаданные — user_id, время, язык интерфейса. Это позволяет создать запись обращения и передать её оператору без потери контекста.

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

Архитектура бота для очереди обращений

Типичная схема состоит из трёх компонентов: приёмник обновлений, база данных состояний и обращений, логика назначения оператора.

Приёмник обновлений получает объекты Update через официальный Bot API. Каждое обновление содержит объект Message с полями message_id, from, chat, text, date и опциональными вложениями. Бот извлекает chat.id и from.id, чтобы идентифицировать пользователя, и сохраняет текст сообщения.

База данных хранит таблицу обращений (tickets) с полями ID, user_id, status, priority, operator_id, created_at, updated_at и таблицу сообщений (messages) с ticket_id, sender_type (user или operator), text, attachments, timestamp. Связь один-ко-многим: одно обращение содержит множество сообщений.

Логика назначения оператора выбирает свободного сотрудника из списка, проверяя его текущую нагрузку или флаг доступности, и записывает operator_id в строку обращения. Если все операторы заняты, обращение попадает в очередь со статусом «ожидает».

Webhook или long polling

Бот может получать обновления двумя способами. Long polling вызывает метод getUpdates с интервалом и забирает массив новых объектов Update. Webhook регистрирует HTTPS-адрес методом setWebhook, и Telegram отправляет POST-запрос с телом Update при каждом событии. Официальный FAQ рекомендует webhook для production, поскольку он снижает задержку и нагрузку на API.

Создание обращения и сбор контекста

Когда пользователь первый раз пишет боту команду /start или свободное сообщение, бот проверяет наличие активного обращения для этого chat.id. Если активного обращения нет, бот создаёт новую запись в таблице tickets со статусом «новое» и генерирует уникальный номер — например, префикс T плюс timestamp или автоинкрементный ID.

Бот отвечает подтверждением: «Создано обращение T12345. Опишите проблему подробнее». Следующие сообщения пользователя добавляются в таблицу messages с привязкой к ticket_id. Это позволяет собрать весь контекст до момента, когда оператор начнёт отвечать.

Если пользователь прикрепляет фото, документ или голосовое сообщение, бот извлекает file_id из соответствующего поля объекта Message и сохраняет его в колонку attachments. Позже оператор может запросить файл методом getFile и скачать его через прямую ссылку.

Сбор дополнительных полей

Для структурирования контекста можно запросить категорию проблемы, номер заказа или email. Бот переключает состояние диалога — например, записывает в промежуточную таблицу user_state поле step со значением «awaiting_category». При получении следующего сообщения бот проверяет step, записывает категорию в поле ticket и переводит step в «awaiting_order_id». Такая машина состояний реализуется через условные блоки или библиотеку finite state machine.

Очередь и назначение оператора

Когда обращение создано и контекст собран, бот запускает функцию assign_operator. Она выбирает оператора по одному из алгоритмов:

• Round-robin: операторы перебираются по кругу, каждому достаётся следующее обращение.
• Наименьшая нагрузка: выбирается оператор с минимальным числом активных обращений в данный момент.
• Статус доступности: оператор сам помечает себя online/offline, и обращение назначается только доступным.

После выбора оператора бот обновляет поле operator_id и status на «назначено», отправляет пользователю сообщение «Обращение T12345 принято оператором, ожидайте ответа» и уведомляет оператора в отдельный чат или группу с кнопкой «Принять обращение T12345».

Если ни один оператор не доступен, обращение остаётся в статусе «в очереди», а бот периодически проверяет доступность операторов — например, раз в минуту запускает задачу cron, которая вызывает assign_operator для всех необработанных обращений.

Приоритеты обращений

Таблица tickets может содержать поле priority с числовыми значениями 1 — низкий, 2 — средний, 3 — высокий, 4 — критический. Приоритет назначается автоматически по ключевым словам в тексте («не работает оплата», «потерял доступ») или вручную оператором после первичного просмотра.

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

Статусы обращения и переходы

Жизненный цикл обращения включает несколько статусов:

1. Новое (new): обращение создано, контекст собирается.
2. В очереди (queued): контекст собран, ожидает назначения оператора.
3. Назначено (assigned): оператор выбран, но ещё не ответил.
4. В работе (in_progress): оператор отправил первое сообщение.
5. Ожидание ответа клиента (awaiting_user): оператор задал вопрос, ждёт уточнения.
6. Решено (resolved): оператор закрыл обращение.
7. Закрыто (closed): пользователь подтвердил решение или прошёл таймаут автозакрытия.

Переходы выполняются событиями: назначение оператора переводит из queued в assigned, первый ответ оператора — в in_progress, команда /resolve от оператора — в resolved. Если пользователь не отвечает 24 часа после resolved, обращение автоматически переходит в closed.

Реализация переходов

Каждое изменение status сопровождается записью в таблицу status_history с полями ticket_id, old_status, new_status, changed_by, timestamp. Это позволяет строить отчёты по времени в каждом статусе и анализировать узкие места — например, сколько обращений застревает в очереди дольше часа.

Интерфейс оператора

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

Когда оператор нажимает «Взять», бот обновляет operator_id и status, открывает диалог, где оператор видит всю историю сообщений пользователя и может отвечать. Ответ оператора дублируется в чат с пользователем и сохраняется в таблицу messages с sender_type = 'operator'.

Для закрытия обращения оператор отправляет команду /resolve T12345. Бот переводит статус в resolved, отправляет пользователю сообщение «Ваше обращение решено. Если проблема осталась, напишите ещё раз» и запускает таймер автозакрытия.

Передача между операторами

Если оператор не может решить проблему, он вызывает команду /transfer T12345 @colleague. Бот меняет operator_id, добавляет запись в status_history, уведомляет нового оператора и информирует пользователя: «Обращение передано специалисту по данному вопросу».

История переписки и поиск

Все сообщения хранятся в таблице messages с полным текстом, timestamp и ticket_id. Для быстрого поиска можно добавить полнотекстовый индекс на колонку text (например, с помощью PostgreSQL tsvector) или подключить внешний поисковый движок.

Оператор может найти прошлые обращения пользователя командой /history USER_ID. Бот возвращает список номеров обращений, даты создания, статусы и краткое резюме первого сообщения. Это помогает понять, повторяется ли проблема или пользователь обращается впервые.

Для аналитики полезна таблица ticket_metrics с агрегированными полями: среднее время первого ответа, время до решения, количество сообщений в диалоге. Эти метрики обновляются триггерами при изменении статуса или добавлении сообщения.

Типичные ошибки при построении очереди

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

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

Неправильная обработка вложений приводит к тому, что file_id сохраняется, но бот не проверяет срок жизни ссылки. Telegram хранит файлы ограниченное время, поэтому критичные документы нужно скачивать сразу методом getFile и сохранять на собственном хранилище.

Игнорирование изменений в API также создаёт проблемы. Telegram регулярно добавляет новые поля и типы сообщений; если бот ожидает только текст, он может падать при получении голосового сообщения или стикера. Используйте обработчик по умолчанию, который логирует неизвестные типы и возвращает вежливое сообщение пользователю.

Безопасность и конфиденциальность

Telegram Bot API передаёт идентификаторы чатов и пользователей, но не раскрывает номера телефонов без явного согласия пользователя. Сохраняйте в базе только минимально необходимые данные: user_id, username, текст сообщений и метаданные. Не записывайте IP-адреса и технические заголовки, если это не требуется для расследования инцидентов.

Webhook должен работать только через HTTPS с валидным сертификатом. Официальный FAQ требует TLS 1.2 или выше и отклоняет самоподписанные сертификаты без цепочки доверия. Разместите webhook на домене с сертификатом Let's Encrypt или коммерческого центра сертификации.

Контролируйте доступ операторов к истории обращений. Таблица operators может содержать роли: администратор видит все обращения, оператор — только назначенные ему и свободные в очереди. Проверяйте роль перед выполнением команд /history, /transfer, /reassign.

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

Чек-лист внедрения бота техподдержки

• Зарегистрировать бота через BotFather и получить токен.
• Создать таблицы tickets, messages, operators, user_state, status_history в базе данных.
• Настроить webhook или long polling для получения обновлений.
• Реализовать машину состояний для сбора контекста (категория, описание, вложения).
• Написать функцию assign_operator с выбранным алгоритмом распределения.
• Добавить поле priority и логику сортировки очереди.
• Создать команды для оператора: /take, /resolve, /transfer, /history.
• Настроить автоматические переходы статусов и таймер автозакрытия.
• Подключить полнотекстовый поиск или индексацию сообщений.
• Настроить алерты на превышение размера очереди и время ожидания.
• Проверить обработку всех типов сообщений: текст, фото, документ, голос, стикер.
• Настроить логирование ошибок и мониторинг доступности webhook.
• Провести нагрузочное тестирование с несколькими одновременными обращениями.
• Документировать процедуры для операторов и администраторов.

Интеграция с внешними системами

Бот может создавать обращения не только в собственной базе, но и отправлять их в CRM, трекер задач или helpdesk-систему через API. Это позволяет операторам работать в привычном интерфейсе, а пользователю — получать обновления статуса в Telegram.

При создании обращения бот вызывает POST-запрос к API внешней системы, передаёт поля subject, description, priority, customer_id и получает в ответе внешний идентификатор тикета. Этот идентификатор сохраняется в поле external_id таблицы tickets. Дальнейшие обновления синхронизируются вебхуком из внешней системы: когда оператор меняет статус в CRM, система отправляет уведомление боту, и бот пересылает сообщение пользователю.

Проверка результата

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

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

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

FAQ

Как узнать, сколько обращений в очереди?

Выполните SQL-запрос SELECT COUNT(*) FROM tickets WHERE status = 'queued'; или добавьте команду /queue_size для операторов, которая возвращает текущее число обращений в ожидании.

Можно ли назначить несколько операторов на одно обращение?

Да, если изменить поле operator_id на связь многие-ко-многим через промежуточную таблицу ticket_operators. Тогда несколько операторов увидят обращение и смогут отвечать, но потребуется координация, чтобы избежать дублирования ответов.

Как обрабатывать обращения на разных языках?

Telegram передаёт язык интерфейса пользователя в поле from.language_code. Сохраните его в таблицу tickets и выбирайте шаблоны сообщений бота на соответствующем языке. Операторов можно фильтровать по знанию языка, добавив поле languages в таблицу operators.

Что делать, если пользователь создал новое обращение, не закрыв старое?

Бот может проверить наличие активных обращений при команде /start или первом сообщении и предложить пользователю продолжить диалог в существующем обращении или явно закрыть его перед созданием нового. Альтернатива — разрешить несколько активных обращений на одного пользователя и различать их по номеру.

Как оценить нагрузку на операторов?

Считайте количество активных обращений (статусы assigned, in_progress, awaiting_user) для каждого operator_id. Добавьте метрику average_response_time — среднее время между сообщением пользователя и первым ответом оператора. Постройте дашборд с этими показателями, чтобы балансировать нагрузку.

Нужно ли хранить удалённые сообщения?

Telegram Bot API не уведомляет бота об удалении сообщения пользователем. Если требуется фиксировать такие события, используйте Telegram Client API (MTProto), но это усложняет архитектуру. Для техподдержки обычно достаточно хранить сообщения, полученные на момент отправки.

Как защититься от спама и флуда?

Ограничьте количество новых обращений от одного user_id в единицу времени — например, не более трёх в час. Если лимит превышен, бот отвечает: «Вы создали слишком много обращений, подождите перед следующим». Храните счётчик в таблице rate_limits с полями user_id, action, count, window_start.

Практический вывод

Telegram-бот для техподдержки объединяет удобство мессенджера и структуру CRM: пользователь описывает проблему в чате, бот создаёт обращение с уникальным номером, распределяет его по операторам с учётом приоритета и нагрузки, сохраняет всю переписку и позволяет анализировать метрики. Основа такой системы — корректная обработка объектов Message из Bot API, машина состояний для сбора контекста, алгоритм назначения оператора и таблицы для хранения обращений, сообщений и истории статусов. Проверка race conditions, настройка таймаутов и алертов, защита webhook и контроль доступа операторов обеспечивают стабильную работу под нагрузкой. Результат — асинхронная служба поддержки, доступная пользователю в привычном интерфейсе и операторам в структурированном виде.