Автоматическое закрытие тикетов по истечению
Когда тикет «зависает»: проблема нерешённых обращений
Представьте: клиент задал вопрос, оператор дал ответ, но диалог не закрыт — ни клиент не подтвердил решение, ни агент не перевёл тикет в статус «закрыт». Через неделю в топик-группе Telegram накапливаются десятки «висящих» обращений. Очередь растёт, агенты теряют фокус, а SLA-метрики — особенно время первого ответа (FRT) и время разрешения (TTR) — начинают показывать искажённую картину. Автоматическое закрытие тикетов по истечению — это не прихоть, а инструмент управления потоком обращений, который предотвращает хаос в очереди.
Как работает автоматическое закрытие: базовый механизм
В Telegram-CRM для службы поддержки механизм автоматического закрытия строится на триггерах автоматизации. Вы задаёте условие: если тикет находится в определённом статусе (например, «Ожидает ответа клиента» или «Решение предложено») дольше заданного времени — система переводит его в статус «Закрыт». Дополнительно можно настроить отправку уведомления клиенту через бота: «Ваше обращение будет автоматически закрыто через 24 часа, если не поступит ответ».
Типичные сценарии использования:
| Статус тикета перед закрытием | Таймер (пример) | Действие после срабатывания |
|---|---|---|
| Ожидает ответа клиента | 72 часа | Закрыть тикет, отправить уведомление |
| Решение предложено | 48 часов | Закрыть тикет, записать в историю |
| Отложен (snoozed) | 7 дней | Закрыть тикет, вернуть в очередь при повторном обращении |
Важно: автоматическое закрытие не удаляет историю переписки — тикет остаётся в архиве, и клиент может открыть его повторно, отправив новое сообщение в тот же топик.
Пошаговая настройка триггера автоматического закрытия
Шаг 1. Определите статусы-кандидаты
Проанализируйте текущий поток обращений. Какие статусы накапливают «зависшие» тикеты? Обычно это:
- «Ожидание ответа клиента» — клиент не реагирует после предложенного решения.
- «Дополнительный запрос» — вы запросили уточняющие данные, но клиент молчит.
- «Решение предложено» — агент написал ответ, но клиент не подтвердил закрытие.
Шаг 2. Установите разумные таймеры
Не копируйте чужие настройки SLA без адаптации. Время зависит от специфики вашей поддержки:
- Для технической поддержки SaaS: 48–72 часа.
- Для финансовых или юридических запросов: 5–7 дней.
- Для срочных обращений (критические баги): автоматическое закрытие не применяется — используйте эскалацию обращения.
Шаг 3. Настройте триггер в Telegram-CRM
В интерфейсе тикет-системы перейдите в раздел «Триггеры автоматизации». Создайте новое правило:
- Условие: Статус тикета равен «Ожидает ответа клиента» И время в этом статусе превышает 72 часа.
- Действие: Изменить статус на «Закрыт автоматически», отправить уведомление клиенту через Telegram Bot API, записать событие в историю тикета.
Шаг 4. Протестируйте на небольшой группе
Перед включением на всех обращениях выберите тестовый канал или отдел. Проверьте:
- Уведомления приходят клиентам?
- Тикеты корректно закрываются?
- Не закрываются ли обращения, где клиент уже написал ответ, но агент не обновил статус?
Когда автоматическое закрытие вредит: частые ошибки
Ошибка 1. Слишком короткий таймер. Если закрывать тикет через 24 часа, клиент, который проверяет почту/Telegram раз в день, может не успеть отреагировать. Результат — повторное обращение с негативным оттенком.
Ошибка 2. Закрытие без уведомления. Клиент видит, что его вопрос «исчез» без объяснения. Это подрывает доверие. Всегда настраивайте хотя бы одно предупреждение за 12–24 часа до закрытия.
Ошибка 3. Применение ко всем типам обращений. Для эскалированных или критических тикетов автоматическое закрытие должно быть отключено. Используйте отдельные триггеры для разных категорий.
Проблемы, которые решает автоматическое закрытие
Проблема 1: Раздутая очередь и потеря фокуса агентами
Когда агент видит очередь из 50 тикетов, из которых 30 уже решены, но не закрыты, он теряет мотивацию. Автоматическое закрытие очищает очередь, оставляя только активные обращения. Это улучшает метрику времени разрешения (TTR) — она перестаёт искажаться «зависшими» тикетами.
Проблема 2: Искажение SLA-отчётов
Руководитель смены смотрит отчёт: среднее время разрешения — 5 дней. На деле 3 дня из 5 — это «мёртвый» период, когда клиент не отвечал. Автоматическое закрытие позволяет корректно измерять чистое время работы агента.
Проблема 3: Нарушение соглашения об уровне обслуживания (SLA)
Если SLA требует закрывать 90% тикетов за 24 часа, а 20% обращений «висят» неделями, статистика становится неуправляемой. Автоматическое закрытие по истечению таймера (с учётом исключений) помогает соблюдать SLA-метрики.
Когда требуется вмешательство специалиста
Автоматическое закрытие — мощный, но не универсальный инструмент. Обратитесь к администратору Telegram-CRM или разработчику, если:
- Нужна интеграция с внешней базой знаний. Например, при автоматическом закрытии тикета система должна проверить, есть ли в базе знаний подходящая статья, и отправить её клиенту.
- Требуется сложная логика эскалации. Если тикет не закрыт после 3-го уведомления — передать супервизору.
- Необходима миграция данных из Excel. При переходе на новую тикет-систему старые «висящие» обращения нужно корректно закрыть или перенести. Подробнее — в статье миграция данных в Telegram-CRM из Excel.
- Настройка отложенных тикетов. Если вы используете функцию отсрочки (snooze), автоматическое закрытие должно учитывать этот статус отдельно. Читайте работа с отложенными тикетами.
Резюме: как внедрить без последствий
- Начните с аудита. Проанализируйте текущую очередь: сколько тикетов «зависло» и на каких статусах.
- Установите таймеры индивидуально. Для разных типов обращений — разные сроки.
- Настройте уведомления. Минимум одно предупреждение перед закрытием.
- Тестируйте на пилотной группе. Не включайте сразу на всех отделах.
- Документируйте исключения. Критические и эскалированные тикеты не должны закрываться автоматически.