Автоматизация обновления статусов тикетов

Введение: проблема ручного управления статусами

В службе поддержки, работающей через Telegram-CRM, статус тикета — это индикатор того, на какой стадии находится обращение: поступило ли оно, взято ли в работу, ожидает ли ответа клиента или уже решено. Однако на практике многие команды сталкиваются с ситуацией, когда статусы обновляются вручную, с опозданием или не обновляются вовсе. Это может приводить к путанице в очереди обращений, нарушению соглашений об уровне обслуживания (SLA) и, как следствие, к снижению качества поддержки.

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

Типичные проблемы при автоматизации статусов

1. Статус не обновляется после отправки ответа

Описание проблемы. Агент поддержки отвечает клиенту в топик-группе Telegram, но статус тикета остаётся прежним — например, «В работе» или «Ожидание ответа оператора». Это дезориентирует супервизора и может привести к тому, что обращение не будет закрыто вовремя.

Причины.

• Отсутствие настроенного триггера, который переводит статус при отправке сообщения агентом.
• Конфликт правил: другое условие (например, по времени) переопределяет статус обратно.
• Ошибка в webhook-интеграции: внешняя система не получает сигнал о новом сообщении.

Пошаговое решение.

1. Проверьте настройки триггеров автоматизации. Убедитесь, что создано правило вида: «Если агент отправил сообщение в тикет, то изменить статус на "Ожидание ответа клиента"».
2. Проверьте приоритет правил. Если несколько триггеров могут сработать одновременно, настройте порядок их выполнения. Обычно более конкретные правила (по действию агента) должны иметь более высокий приоритет.
3. Протестируйте webhook-интеграцию. Отправьте тестовое сообщение и проверьте, приходит ли событие во внешнюю систему (если она используется). При отсутствии сигнала обратитесь к документации Telegram Bot API и настройкам webhook в вашей CRM.

Когда требуется специалист. Если проблема сохраняется после проверки всех настроек, возможно, требуется анализ логов интеграции или помощь разработчика для отладки webhook-соединения.

2. Автоматический перевод в статус «Закрыт» при отсутствии ответа клиента

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

Причины.

• Некорректно настроен таймер автоматического закрытия. Например, условие «Если от клиента нет ответа более 24 часов» срабатывает, но не учитывает, что последнее сообщение было от агента.
• Отсутствует правило, которое отменяет закрытие, если клиент написал после истечения таймера.

Пошаговое решение.

1. Проверьте условие триггера. Убедитесь, что он срабатывает только при отсутствии ответа клиента, а не при простое тикета в целом. Например, условие: «Если последнее сообщение в тикете от агента И прошло более 24 часов с момента этого сообщения».
2. Добавьте правило-исключение. Создайте триггер, который при получении нового сообщения от клиента в уже закрытом тикете переводит его обратно в статус «Открыт» или «В работе».
3. Настройте уведомление супервизору. Если тикет автоматически переводится в статус «Ожидание подтверждения закрытия», пусть руководитель смены получает оповещение и может отменить закрытие вручную.

Когда требуется специалист. Если логика закрытия сложная (например, зависит от типа обращения или SLA), а настройки триггеров не позволяют её реализовать, потребуется помощь разработчика для создания кастомного скрипта.

3. Статус не обновляется при эскалации обращения

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

Причины.

• Действие эскалации не связано с изменением статуса в настройках триггера.
• Используется отдельный канал для эскалаций (например, другой топик), и статус не синхронизируется между ними.

Пошаговое решение.

1. Создайте триггер, который при эскалации (например, при назначении тикета агенту из другой группы) меняет статус на «Эскалировано» или «Передано на уровень 2».
2. Если эскалация происходит в другой топик-группе, убедитесь, что тикет-система поддерживает сквозную нумерацию и статусы. Настройте webhook так, чтобы при создании тикета в новом топике он получал статус из исходного обращения.
3. Проверьте права доступа. Убедитесь, что у агента, который выполняет эскалацию, есть разрешение на изменение статуса.

Когда требуется специалист. Если эскалация включает несколько уровней и требует сложной логики (например, автоматическое уведомление супервизора при превышении времени на уровне 1), рекомендуется обратиться к разработчику для настройки сценария.

4. Ошибки в синхронизации статусов между системами

Описание проблемы. Если вы используете Telegram-CRM в связке с внешней системой (например, HelpDesk или CRM), статусы могут расходиться. Тикет в Telegram-CRM помечен как «Закрыт», а во внешней системе — как «В работе», или наоборот.

Причины.

• Задержка в webhook-интеграции или её отсутствие для определённых событий.
• Конфликт идентификаторов: внешняя система не может сопоставить тикет в Telegram-CRM со своей записью.
• Ошибка в маппинге статусов: разные названия статусов в системах не сопоставлены корректно.

Пошаговое решение.

1. Проверьте настройки webhook. Убедитесь, что при каждом изменении статуса в Telegram-CRM отправляется событие во внешнюю систему. Обычно это настраивается в разделе «Интеграции» или «Webhook».
2. Сопоставьте статусы. Создайте таблицу соответствия: например, «Закрыт» (Telegram-CRM) = «Resolved» (внешняя система), «В работе» = «In Progress».
3. Проверьте уникальный идентификатор тикета. Убедитесь, что при создании тикета во внешнюю систему передаётся ID из Telegram-CRM, и наоборот. Это может быть номер тикета или внешний ID.
4. Протестируйте синхронизацию. Измените статус в Telegram-CRM и проверьте, обновился ли он во внешней системе через 1-2 минуты.

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

5. Автоматическое обновление статуса при превышении SLA

Описание проблемы. Система должна автоматически повышать приоритет или менять статус тикета, если время первого ответа (FRT) или время разрешения (TTR) превышено. Однако этого не происходит.

Причины.

• Не настроены правила SLA в системе.
• Триггер, основанный на времени, не срабатывает из-за неправильной конфигурации часового пояса.
• Таймер запускается не с того события (например, с момента создания тикета, а не с момента его назначения агенту).

Пошаговое решение.

1. Настройте SLA-метрики. Определите, с какого момента начинается отсчёт времени (создание тикета, назначение агенту) и какое время считается критическим.
2. Создайте триггер, который при превышении времени (например, FRT > 30 минут) меняет статус на «Просрочено» или повышает приоритет.
3. Проверьте часовой пояс. Убедитесь, что в настройках системы указан правильный часовой пояс, иначе таймер может срабатывать в нерабочее время.
4. Настройте уведомление супервизора. При срабатывании триггера пусть руководитель смены получает оповещение в Telegram или по электронной почте.

Когда требуется специалист. Если SLA-метрики сложные (например, зависят от типа клиента или времени суток), а встроенные триггеры не позволяют их реализовать, потребуется кастомная разработка.

Когда проблема требует обращения к специалисту

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

• Сложная логика автоматизации. Если требуется реализовать цепочку действий (например, при эскалации на второй уровень автоматически создаётся подтикет, меняется статус и отправляется уведомление), а встроенные триггеры не поддерживают такой сценарий.
• Интеграция с внешними системами. Если webhook-интеграция не работает или даёт сбои, а документация не помогает, лучше привлечь специалиста.
• Массовые ошибки. Если статусы не обновляются для всех тикетов или для определённой группы, это может указывать на системную проблему, требующую анализа кода или конфигурации.
• Безопасность. Если автоматизация затрагивает конфиденциальные данные (например, статусы, связанные с платежами), настройку лучше доверить профессионалу.

Заключение: резюме

Автоматизация обновления статусов тикетов в Telegram-CRM — это инструмент, который помогает снизить нагрузку на агентов и супервизоров, а также соблюдать SLA. Однако, как и любая автоматизация, она требует тщательной настройки и тестирования. Мы рассмотрели пять типичных проблем: отсутствие обновления после ответа, преждевременное закрытие, ошибки при эскалации, расхождение статусов между системами и проблемы с SLA. Для каждой из них предложены пошаговые решения, а также указано, когда стоит обратиться к специалисту.

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

Для более глубокого понимания возможностей автоматизации рекомендуем ознакомиться с нашими статьями: шаблоны и автоматизация ответов в Telegram-CRM, автоматическая отправка ответов по тригерам и автоматизация создания тикетов из сообщений.