SupportCandy SLA - Плагин WordPress

Руководство по настройке SupportCandy SLA для службы поддержки в WordPress

SupportCandy SLA нужен не для красивой метки в списке тикетов, а для управляемого контроля сроков ответа и закрытия обращений. В этом руководстве разберём, как подготовить базовый SupportCandy, где включается логика SLA, как составить политики без конфликтов, как вывести срок в тикет-лист, настроить уведомления о нарушении срока и проверить результат на тестовом обращении.

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

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

Какую задачу решает SLA в тикет-системе WordPress

В обычной очереди поддержки тикеты легко сортировать по дате обновления, статусу или приоритету, но этого недостаточно для обещаний клиентам. Если команда отвечает "быстро", каждый агент понимает это по-своему. Один берёт новые обращения сначала, другой открывает самые сложные, третий работает только по назначенным тикетам. В итоге реальная срочность теряется, а спор начинается уже после жалобы клиента.

SupportCandy SLA добавляет к этой очереди измеримый срок. Администратор описывает набор условий - например, статус, категорию или приоритет - и задаёт время, за которое команда должна выполнить действие. Когда тикет подходит под условия политики, плагин рассчитывает целевой момент и показывает, остаётся ли обращение within SLA или уже out of SLA. В русскоязычной работе это удобнее воспринимать как "в сроке" и "срок нарушен", но в интерфейсе реальные английские метки лучше узнавать и не переводить в уме каждый раз.

Главное отличие от простого приоритета в том, что SLA связан не только с важностью тикета, но и с моментом отсчёта. Для первичного ответа логично считать срок от создания обращения. Для повторного ответа после сообщения клиента часто важнее считать срок от последнего обновления. Для закрытия задачи можно использовать другой интервал и другие условия. Такая модель позволяет не смешивать разные обещания в одну колонку "High".

Правильная настройка SLA начинается не с кнопки "Add New", а с описания правил поддержки. Нужно заранее решить, какие обращения считаются срочными, какие статусы означают ожидание агента, когда срок должен сбрасываться, кто получает уведомление и что делать после нарушения. Без этой карты плагин будет формально работать, но команда всё равно не поймёт, почему один тикет горит красным, а другой спокойно ждёт.

Когда срок нужен, а когда он только создаёт шум

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

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

Какие обещания лучше не автоматизировать сразу

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

Кому подойдёт SupportCandy SLA и где лучше выбрать другой подход

SupportCandy SLA логично использовать, если основная поддержка уже построена внутри WordPress на SupportCandy. Администратору не нужно переносить обращения в отдельный SaaS-сервис, агентам не нужно держать ещё одну вкладку с внешней системой, а владелец сайта сохраняет контроль над данными тикетов в собственной установке WordPress. Для небольших и средних команд это часто практичнее, чем внедрять отдельный корпоративный сервис только ради SLA.

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

Если SupportCandy пока используется как простая форма "напишите нам", а все ответы идут хаотично через почту, внедрение SLA лучше отложить. Сначала настройте страницы поддержки, роли агентов, базовые уведомления, статусы после ответа агента и клиента, список тикетов и тестовый процесс. Иначе SLA будет считать сроки по плохо размеченным обращениям, а нарушения будут говорить не о скорости поддержки, а о неготовой модели данных.

Подходящие сценарии

• Команда отвечает на тикеты по категориям и должна видеть, какие обращения скоро выйдут за срок.
• На сайте есть разные уровни срочности: обычный вопрос, техническая проблема, критичный сбой, запрос по заказу.
• Нужно отправлять уведомление менеджеру или группе агентов, когда обращение нарушило срок.
• Поддержка работает в WordPress и хочет не переносить тикеты во внешний сервис без необходимости.
• Руководителю важно видеть не только количество открытых обращений, но и дисциплину реакции команды.

Сценарии, где стоит быть осторожнее

SupportCandy SLA не заменяет полноценное планирование смен, обучение агентов и описание правил приоритета. Если пользователи сами могут выставлять максимальную срочность каждому обращению, SLA быстро превратится в красную ленту из "самых важных" тикетов. Лучше оставить клиенту понятную форму выбора темы и влияния проблемы, а итоговый приоритет для SLA подтверждать на стороне команды.

Также не стоит ожидать, что SLA сам исправит доставку писем. Если на сайте плохо настроена отправка почты, уведомления о нарушении срока могут не дойти. Для серьёзной поддержки нужно проверить почтовый транспорт, шаблоны уведомлений, получателей и спам-фильтры. Это не слабость SLA, а обычное ограничение WordPress-сайтов, где письма зависят от окружения.

Что проверить перед установкой и включением SLA

Перед добавлением SLA-политик полезно пройти короткий аудит текущей поддержки. Это скучный этап, но именно он снижает количество ложных нарушений. Плагин не знает бизнес-контекст сам по себе: он смотрит на поля, статусы и события тикета. Если эти поля заполняются нерегулярно, итоговый срок будет выглядеть случайным.

Сначала убедитесь, что базовый SupportCandy установлен, активирован и создаёт тикеты через нужную страницу поддержки. В официальной документации описаны два обычных пути установки основного плагина: через каталог плагинов WordPress или загрузкой ZIP-архива в админ-панели. Для SLA-расширения важно, чтобы основной плагин уже работал: без него политики не к чему применять.

Базовый чек перед настройкой

• Создайте тестовый тикет от имени клиента и проверьте, что он появляется в Support > Ticket List.
• Проверьте, что у команды есть агенты в Support > Support Agents, а роли не дают лишних прав случайным пользователям.
• Опишите 3-5 рабочих статусов, например новый тикет, ожидание ответа агента, ожидание клиента, решено, закрыто.
• Проверьте категории и приоритеты. SLA-политикам нужны стабильные условия, а не случайные названия.
• Убедитесь, что уведомления SupportCandy уже уходят и не попадают в спам.
• Проверьте, какие поля нужно вывести в тикет-лист для агентов, чтобы срок был виден без открытия каждого обращения.

Почему статусы важнее, чем кажется

Большинство ошибок с SLA возникает не из-за самого таймера, а из-за неудачных статусов. Например, команда хочет считать срок повторного ответа от момента, когда клиент написал новое сообщение. Тогда должен быть статус, который явно означает ожидание реакции агента. Если все ответы клиента оставляют тикет в общем статусе "Open", политика будет срабатывать слишком широко и смешает новые обращения с уже обработанными.

В SupportCandy есть настройка автоматического изменения статуса после ответа агента или клиента. Её нужно сверить с будущими SLA-политиками. Если после ответа клиента тикет получает статус "Awaiting agent reply", именно этот статус удобно использовать в условиях политики для повторного ответа. Если у вас другая терминология, оставьте её, но смысл должен быть таким же: по статусу должно быть понятно, чья очередь действовать.

Проверка перед установкой: откройте один тестовый тикет, ответьте как агент, затем ответьте как клиент и посмотрите, как меняются статус, дата обновления и видимость тикета в списке. Если этот простой цикл неясен, SLA лучше пока не включать.

Установка расширения и первая проверка в админ-панели

Для работы SupportCandy SLA нужен установленный SupportCandy. Само SLA-расширение добавляет отдельный раздел настроек в админ-панель SupportCandy. В документации путь к политике указан как Support > Settings > SLA > SLA Policies, а общие цвета меток находятся в Support > Settings > SLA > General settings. Если после активации вы не видите этот раздел, проверяйте не политику, а базовые условия: активен ли основной плагин, активировано ли расширение, есть ли у текущего пользователя права администратора.

Не нужно начинать с десятка политик. Сделайте одну простую: например, для новых тикетов с высоким приоритетом задать первый ответ в течение нескольких часов от даты создания. Цель первой проверки - убедиться, что тикет подходит под условия, срок появляется в интерфейсе и статус "в сроке" меняется предсказуемо. Только после этого можно добавлять отдельные правила для категорий, повторных ответов и закрытия.

Порядок безопасного первого включения

1. Убедитесь, что базовый SupportCandy создаёт и открывает тестовые тикеты.
2. Активируйте SLA-расширение обычным способом через админ-панель WordPress.
3. Откройте Support > Settings > SLA > General settings и задайте читаемые цвета для меток Within SLA и Out of SLA.
4. Перейдите в SLA Policies и создайте одну тестовую политику с минимальным набором условий.
5. Создайте новый тикет, который точно подходит под условия политики.
6. Откройте список тикетов и сам тикет, чтобы проверить отображение срока и метки.

Как понять, что расширение действительно работает

Первые признаки работы - появление SLA-логики в настройках, возможность создать политику и отображение статуса срока в списке или в виджете тикета. На странице WordPress.org для SupportCandy отдельно указано, что оставшееся время может показываться в списке тикетов, если поле SLA добавлено в элементы списка, и в отдельном тикете. Это важная деталь: если срок рассчитан, но не выведен в нужную колонку, агент может его просто не увидеть.

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

Политики SLA: время, точка отсчёта и условия

Политика SLA в SupportCandy состоит из трёх смысловых частей: времени, точки отсчёта и условий. Время отвечает на вопрос "сколько есть на действие". Точка отсчёта отвечает на вопрос "от какого события считать". Условия отвечают на вопрос "к каким тикетам это правило применимо". Ошибка в любой части даёт неправильный результат, поэтому настройки нужно читать не как форму, а как маленькое правило поддержки.

Официальная документация описывает два ключевых варианта расчёта: Date Created и Date Updated. Первый подходит для обещаний от момента создания тикета: первый ответ, первичная сортировка, закрытие в течение определённого срока с даты обращения. Второй подходит для ситуаций, когда срок должен начинаться после изменения: клиент ответил, агент уточнил данные, статус изменился, тикет получил новую информацию.

Как выбирать Calculate From

Date Created используйте для обязательств, которые привязаны к рождению обращения. Например, новый критичный тикет должен быть взят в работу в короткий срок. Если агент ответил клиенту и перевёл обращение в ожидание, первичная политика уже выполнила свою роль. Для повторных ответов она обычно не подходит, потому что дата создания остаётся прежней.

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

Как условия влияют на точность

Условия можно воспринимать как фильтр, который выбирает подходящие тикеты. Документация показывает пример с отношением AND, статусом ожидания ответа агента и категорией технического запроса. Такой подход хорош тем, что политика сработает только тогда, когда совпали оба признака. Если использовать слишком широкие условия, например только категорию без статуса, правило начнёт применяться к тикетам, которые уже ждут клиента или почти закрыты.

Чем точнее условия, тем меньше ложных "нарушений". Но слишком дробить правила тоже опасно. Если создать отдельную политику на каждую мелкую комбинацию, администратор быстро потеряет картину. Начинайте с крупных сценариев: первый ответ, повторный ответ, закрытие или эскалация для критичных тикетов. Потом добавляйте категории, если они действительно требуют разных сроков.

Пример логики для повторного ответа

Допустим, вы используете статус Awaiting agent reply, который назначается после ответа клиента. Политика повторного ответа может быть такой: время - рабочий интервал, точка отсчёта - Date Updated, условия - статус равен Awaiting agent reply и категория равна технической. Так агент видит только те обращения, где клиент уже сделал следующий шаг, а команда должна вернуться с ответом.

Пример логики для закрытия

Для закрытия тикета точка отсчёта часто зависит от внутреннего процесса. Если договорённость звучит как "мы решаем типовые обращения за несколько дней после создания", используйте Date Created. Если закрытие должно считаться после получения всех данных от клиента, одного SLA может быть недостаточно: лучше отделить первичный ответ, ожидание клиента и финальное решение разными статусами, чтобы срок не шёл против команды, пока она ждёт информацию.

Как вывести SLA в список тикетов и сделать срок заметным для агента

Настроенная политика бесполезна, если агент не видит срок в ежедневной очереди. В SupportCandy список тикетов настраивается отдельно для агентского и клиентского вида. Документация по элементам списка указывает, что в тикет-лист можно добавлять поля из ticket fields, agent-only fields и customer fields, а ширину колонки можно задать при редактировании поля. Для SLA это значит, что видимость нужно планировать отдельно от самой политики.

Для агента колонка SLA должна отвечать на вопрос "что открыть первым". Если она спрятана в конце широкой таблицы, слишком узкая или доступна только после открытия тикета, команда продолжит работать по привычке. Лучше сделать колонку рядом со статусом, приоритетом, датой обновления или назначенным агентом. Так срок становится частью обычного просмотра очереди, а не отдельной проверкой.

Минимальный набор колонок для SLA-очереди

• Номер или тема тикета, чтобы быстро открыть обращение.
• Статус, чтобы понять, кто должен действовать дальше.
• Приоритет или категория, если они участвуют в условиях SLA.
• Назначенный агент или группа, если команда делит ответственность.
• SLA-метка или оставшееся время, чтобы видеть срок без входа в каждый тикет.
• Дата обновления, чтобы сверить логику Date Updated.

Не выводите клиенту больше информации, чем ему действительно нужно. Внутренняя SLA-дисциплина может быть полезна команде, но клиентский интерфейс должен оставаться понятным. Если вы показываете клиенту статусы, убедитесь, что они не создают ложных ожиданий. Например, метка Out of SLA в клиентском виде может усилить конфликт, если поддержка использует SLA только как внутренний ориентир.

Цвета меток и риск визуального шума

В общих настройках SLA можно изменить цвета тегов Within SLA и Out of SLA. Не выбирайте слишком много агрессивных цветов одновременно. Если статус, приоритет и SLA все красные, агент перестанет понимать, какой сигнал главный. Хорошая практика - сделать нормальный срок спокойным, а нарушение заметным, но не превращать весь список в аварийную панель.

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

Уведомления о нарушении срока и работа с получателями

SupportCandy SLA умеет запускать уведомления по событию Out of SLA. В документации путь описан как Support > Email Notifications > Ticket Notifications > Add New, где в качестве триггера выбирается Out of SLA. Условия для такого уведомления необязательны, но их можно использовать, чтобы разделить разные категории или команды.

Это важный момент для практики: одно общее письмо "срок нарушен" быстро становится шумом. Если поддержка делится на техническую, маркетинговую и клиентскую команды, лучше сделать отдельные уведомления с условиями. Тогда технические нарушения уходят техническому лидеру, вопросы по заказам - менеджеру магазина, а общие обращения - ответственному агенту или группе.

Что включить в письмо

Текст уведомления должен помогать действовать, а не просто сообщать о проблеме. В шаблоне можно использовать макросы SupportCandy для данных тикета: номер, имя клиента, письмо клиента, последний ответ, историю и другие поля, доступные в редакторе уведомлений. Не перегружайте письмо полной историей, если агент всё равно откроет тикет. Лучше дать минимум: идентификатор, тему, текущий статус, категорию, последний ответ и ссылку на тикет, если такой макрос доступен в вашей настройке.

• Тема письма: коротко укажите, что тикет вышел за срок, и добавьте номер тикета.
• Получатели: отправляйте письмо тому, кто может принять действие, а не всей компании.
• Условия: используйте категорию, статус или приоритет, если разные команды отвечают за разные очереди.
• Текст: добавьте один явный призыв: открыть тикет, назначить агента, ответить клиенту или пересмотреть статус.

Как не создать почтовую лавину

Если уведомление отправляется всем агентам без условий, команда быстро перестанет реагировать. Начните с одного письма руководителю поддержки или ответственному агенту. Затем добавляйте условия по категориям. Если тикетов много, лучше сделать рабочий фильтр в списке тикетов и использовать письмо как резервный сигнал, а не как основной способ управления очередью.

Проверьте доставку на отдельном тестовом тикете. Искусственно задайте короткий срок, дождитесь нарушения и убедитесь, что письмо пришло нужному получателю. Если письмо не приходит, не меняйте сразу SLA-политику. Сначала проверьте общие уведомления SupportCandy, почтовый сервис WordPress, адрес получателя, спам и условия уведомления.

Практический сценарий: срок повторного ответа для технических тикетов

Разберём предметный пример, который хорошо показывает смысл SupportCandy SLA. Допустим, сайт продаёт цифровой продукт или оказывает поддержку по технической услуге. Клиент пишет в тикет, агент отвечает и просит уточнение. Клиент возвращается с логом ошибки или скриншотом. С этого момента команда обещает дать следующий ответ быстрее, чем по обычным общим вопросам, потому что обращение уже в работе и клиент ждёт продолжения.

Цель

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

Подготовка

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

Шаги настройки

1. Откройте Support > Settings > SLA > SLA Policies.
2. Создайте новую политику для повторного ответа по техническим тикетам.
3. Задайте время, которое команда реально может выдержать в рабочем процессе.
4. В поле расчёта выберите Date Updated, потому что срок начинается после нового сообщения или изменения тикета.
5. В условиях выберите отношение AND, чтобы совпадали сразу статус ожидания агента и техническая категория.
6. Сохраните политику и проверьте, что в списке нет другой более близкой политики, которая случайно перехватит тот же тикет.
7. Настройте уведомление Out of SLA с условием той же категории, если разные команды получают разные письма.

Ожидаемый результат

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

Нюанс, который часто мешает проверке

Если статус после ответа клиента не меняется, политика может не сработать. Тогда проблема не в SLA, а в связке статусов и условий. Проверьте настройку статуса после ответа клиента в общих настройках SupportCandy или вручную измените статус тестового тикета. После этого снова посмотрите, применился ли срок.

Мини-итог: практический сценарий должен проверяться как цепочка "клиент ответил - статус изменился - политика совпала - срок появился - агент увидел - уведомление сработало при нарушении". Если выпал один элемент, исправляйте именно его.

Как проектировать несколько политик без конфликтов

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

Начинайте с матрицы, а не со списка случайных правил. В строках удобно держать тип действия: первый ответ, повторный ответ, закрытие. В столбцах - срочность или категория. Так видно, какие правила пересекаются. Если пересечение намеренное, ближайший срок логичен. Если пересечение случайное, условия нужно сузить.

После переноса матрицы в админ-панель делайте тесты по одному сценарию. Не меняйте сразу пять политик, если один тикет получает неожиданный срок. Откройте его поля, посмотрите статус, категорию, приоритет и дату обновления. Затем сравните с условиями каждой политики. В большинстве случаев причина становится очевидной: слишком широкое условие, неправильная точка отсчёта или статус, который не меняется в нужный момент.

Как документировать правила для команды

Даже если вся логика настроена в плагине, сделайте короткий внутренний документ. В нём достаточно описать, какие статусы запускают SLA, какие категории считаются техническими, кто получает уведомления и что агент должен сделать при нарушении. Это снижает споры и помогает новым сотрудникам не ломать процесс случайными изменениями статусов.

Проверка результата после настройки

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

Тестовый сценарий для первичного ответа

1. Создайте новый тикет, который подходит под политику первого ответа.
2. Откройте список тикетов и убедитесь, что SLA-поле видно агенту.
3. Сравните статус, категорию и приоритет с условиями политики.
4. Ответьте как агент и проверьте, меняется ли статус тикета так, как задумано.
5. Если срок должен перестать быть актуальным после ответа, убедитесь, что другая политика не продолжает ошибочно считать его как новый тикет.

Тестовый сценарий для повторного ответа

1. После ответа агента отправьте новое сообщение от клиента.
2. Проверьте, что тикет получил статус ожидания агента.
3. Убедитесь, что SLA-срок считается от последнего обновления.
4. Посмотрите, видит ли агент срок в списке без открытия тикета.
5. Если нужно проверить уведомление, временно задайте короткий тестовый интервал и дождитесь события Out of SLA.

Как фиксировать результаты проверки

Запишите итог в простой таблице: сценарий, ожидаемая политика, фактическая политика, отображение в списке, письмо о нарушении, решение. Это особенно полезно, если поддержку настраивает не тот человек, который потом будет ей пользоваться. Через несколько недель такие записи помогают понять, почему политика устроена именно так, а не "как получилось".

Если проверка показывает слишком много нарушений, не делайте вывод, что SLA "слишком строгий". Сначала отделите техническую ошибку от реальной нагрузки. Техническая ошибка - правило применяется к лишним тикетам, статус не меняется, письмо не уходит. Реальная нагрузка - правило применилось правильно, но команда не успевает. Это разные проблемы, и решаются они разными действиями.

Ограничения, безопасность и производительность

SupportCandy SLA работает внутри WordPress и опирается на данные тикет-системы. Поэтому ограничения здесь такие же практические, как у многих WordPress-плагинов: качество хостинга, корректная отправка писем, порядок в ролях пользователей, совместимость с другими расширениями, аккуратное обновление. Не обещайте клиентам абсолютные сроки, пока не проверили работу на своём окружении.

Для производительности важны не только SLA-политики, но и общий размер очереди. SupportCandy развивает базовый плагин и добавляет оптимизации, но любой сайт с большим количеством тикетов должен внимательно относиться к фильтрам, колонкам, почтовым событиям и лишним уведомлениям. Если вы выводите много полей в список тикетов, используете сложные фильтры и отправляете уведомления на каждое событие, админ-панель может стать менее удобной.

Что делать без кода

Для этого продукта безопаснее решать большинство задач настройками, а не фрагментами PHP. Документация подтверждает интерфейсные пути для политик, уведомлений, макросов, ролей, статусов, приоритетов и списка тикетов. Публичных хуков именно для изменения SLA-расчёта в найденных источниках недостаточно, поэтому выдумывать сниппеты не стоит. Если нужна глубокая доработка расчёта, лучше проверить официальную документацию, обратиться к разработчику или тестировать расширение на копии сайта.

• Используйте роли агентов вместо выдачи административного доступа всем сотрудникам поддержки.
• Не меняйте ядро WordPress, файлы SupportCandy или файлы SLA-расширения ради правки логики срока.
• Проверяйте обновления на тестовой копии, особенно если SLA влияет на публичные обещания клиентам.
• Не делайте уведомления всем пользователям сайта. Получатели должны быть ограничены рабочей ролью.
• Не показывайте клиенту внутренние SLA-метки, если команда использует их только для внутреннего контроля.

Совместимость с WooCommerce и другими расширениями

Базовый SupportCandy поддерживает интеграции и дополнительные поля, включая сценарии с WooCommerce, Easy Digital Downloads, Gravity Forms, рабочими процессами и другими расширениями. Для SLA это означает дополнительную ценность: условия могут опираться на хорошо заполненные поля тикета, а агент видит контекст обращения. Но не нужно автоматически добавлять в SLA всё, что есть на сайте. Чем больше условий участвует в политике, тем важнее тестировать крайние случаи.

Если тикеты создаются через интеграцию или почтовый канал, проверьте, какие статус, категория и приоритет получают такие обращения. Частая ошибка - вручную созданный тикет подходит под политику, а тикет из внешнего канала не подходит, потому что у него не заполнено нужное поле. Решение обычно не в SLA, а в настройке формы, маппинга или правил создания тикета.

Ответственность, рабочее расписание и эскалация внутри команды

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

Не делайте SLA только "сигналом администратора". Если срок видит один владелец сайта, а реальные ответы дают агенты, реакция будет запаздывать. Лучше, чтобы агент видел срок в своей очереди, руководитель получал уведомление при нарушении, а команда понимала, какие действия считаются правильными: ответить клиенту, назначить тикет специалисту, изменить статус, запросить данные, оставить внутреннюю заметку или пересмотреть категорию.

Как распределить ответственность

Для каждого типа SLA-политики полезно назначить владельца процесса. Первый ответ часто отвечает за сортировку и первичный контакт. Повторный ответ после клиента - за специалистом или группой, которая ведёт проблему. Контроль закрытия - за агентом, который взял тикет в работу, или за руководителем очереди. Если эти роли не описаны, нарушение срока превращается в спор "кто должен был ответить".

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

Рабочие часы как ожидание, а не магическая защита

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

Внутри статьи мы не утверждаем универсальное правило "таймер всегда останавливается вне рабочих часов", потому что такие детали нужно проверять в вашей версии и документации. Практический подход безопаснее: настройте тестовый тикет перед нерабочим интервалом, посмотрите расчёт срока, затем решите, как формулировать ожидание для клиента. Если срок считается календарно, делайте обещания с запасом или разделяйте внутренний SLA и публичное время ответа.

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

Эскалация без хаоса

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

Если вы используете агентские группы или отдельные роли, проверьте видимость тикета до включения уведомлений. Письмо руководителю бесполезно, если он не может открыть тикет или не видит нужные поля. То же касается младших агентов: не выдавайте им лишние административные права только ради просмотра SLA. Лучше настроить роль так, чтобы человек видел и обрабатывал свои тикеты, но не мог менять системные политики без необходимости.

Как вести внутреннюю мини-документацию

Создайте короткий документ на одну страницу. В нём должны быть названия SLA-политик, условия, точка отсчёта, владелец действия, получатель уведомления и критерий успешной проверки. Такой документ нужен не для бюрократии, а для стабильности. Когда администратор меняет статус или добавляет категорию, он сразу видит, какие SLA-правила могут сломаться.

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

Почему SLA может показываться неправильно и как искать причину

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

Политика не применяется к тестовому тикету

Симптом: тикет создан, но SLA-метка не появляется. Возможная причина - тикет не совпадает с условиями политики. Проверьте статус, категорию, приоритет и другие поля, которые вы указали. Особенно внимательно смотрите на автоматическое изменение статуса после ответа клиента или агента.

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

Применяется не та политика

Симптом: срок есть, но он короче или длиннее ожидаемого. Возможная причина - тикет подходит под несколько политик, а система выбирает ближайшее время среди совпавших правил. Это поведение нужно учитывать при проектировании, а не считать ошибкой.

Как исправить: составьте список всех политик, которые могут совпасть с этим тикетом. Сузьте общие правила дополнительным статусом или категорией. Если пересечение намеренное, запишите его во внутреннюю документацию, чтобы агент понимал, почему сработал более строгий срок.

SLA не видно в списке тикетов

Симптом: срок есть в индивидуальном тикете, но агент не видит его в очереди. Возможная причина - SLA-поле не добавлено в элементы тикет-листа или колонка слишком узкая. В SupportCandy элементы списка настраиваются отдельно, поэтому политика и видимость - разные этапы.

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

Уведомление Out of SLA не приходит

Симптом: тикет нарушил срок, но письма нет. Возможные причины - не создано уведомление с триггером Out of SLA, получатель не указан, условия уведомления не совпали, письма WordPress не доставляются или письмо ушло в спам.

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

Слишком много тикетов выходят за срок

Симптом: список быстро заполняется нарушениями, и команда перестаёт реагировать. Возможные причины - срок нереалистичен, политики применяются слишком широко, статусы не отделяют ожидание клиента от ожидания агента или команда фактически перегружена.

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

Когда SupportCandy SLA будет удачным выбором

SupportCandy SLA стоит использовать, когда поддержка уже работает в WordPress через SupportCandy и команде нужен понятный контроль сроков. Сильная сторона расширения - связь SLA с реальными полями тикета: статусами, категориями, приоритетами, датой создания и датой обновления. Благодаря этому можно настроить разные правила для первого ответа, повторного ответа и контроля закрытия, а затем вывести срок в очередь агента и добавить уведомление о нарушении.

Не пытайтесь включить всё сразу. Начните с одной политики, которая закрывает самый болезненный сценарий. Для большинства команд это либо первый ответ по срочным обращениям, либо повторный ответ после сообщения клиента. Проверьте тестовый тикет, список, индивидуальный экран и письмо Out of SLA. После этого расширяйте правила по категориям и приоритетам.

Если после проверки вы понимаете, что структура тикетов готова, а команда сможет работать по срокам, можно получить файл SupportCandy SLA и развернуть настройку на тестовой копии сайта. Лучший результат получается не там, где SLA просто включён, а там, где команда понимает, какой статус запускает таймер, кто отвечает за просрочку и как проверить, что обещание клиенту действительно выполняется.