SupportCandy Workflows - Плагин WordPress

Руководство по настройке и применению SupportCandy Workflows

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

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

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

Какую задачу решает автоматизация заявок в SupportCandy

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

SupportCandy Workflows закрывает именно эту прослойку между поступлением заявки и человеческим решением. По официальной документации рабочий сценарий может состоять из условий и действий, а автоматический вариант запускается по событиям жизненного цикла заявки. Для пользователя это означает, что часть рутины можно превратить в предсказуемое правило: новая заявка с высоким приоритетом получает ответственного, обращение из категории "Billing" попадает к нужной группе, внутренняя заметка создается при смене статуса, а агент видит ручной сценарий только тогда, когда заявка соответствует заданным условиям.

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

Где Workflows особенно полезен

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

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

Когда автоматизацию лучше отложить

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

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

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

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

Базовый SupportCandy и страницы поддержки

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

Проверьте страницу, где вы используете основной короткий код [supportcandy]. Создайте тестовую заявку, откройте ее от имени агента и убедитесь, что видны статус, категория, приоритет, поля заявки, история сообщений и внутренние заметки. Если основной портал не работает, переходить к Workflows рано.

Статусы, категории и приоритеты

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

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

Агенты, роли и право запускать сценарии

Официальная документация SupportCandy описывает отдельное право Trigger Workflow в настройках ролей агентов. Это важный элемент безопасности. Ручные рабочие сценарии не должны быть видны всем подряд: агент с базовой ролью может отвечать на заявки, но не обязательно должен запускать эскалацию, менять внутренние поля или переназначать обращения между командами.

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

Почта, уведомления и кеш

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

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

Установка расширения и первичная проверка в WordPress

Установка SupportCandy Workflows не должна превращаться в эксперимент на рабочем потоке заявок. Лучший порядок - подготовить резервную копию, проверить базовый SupportCandy, поставить расширение, создать один безопасный тестовый сценарий и только после этого переносить реальные правила. На сайте, где поддержка уже принимает обращения, желательно делать настройку в период низкой нагрузки или сначала на копии сайта.

Общий порядок установки

Если расширение уже получено как ZIP-файл, используйте стандартный механизм WordPress: Plugins, затем Add New, затем Upload Plugin. После загрузки активируйте расширение и вернитесь в раздел SupportCandy. В документации по автоматическим сценариям указан путь Support - Settings - Workflow. Именно там ожидается настройка автоматических рабочих сценариев.

1. Проверьте, что базовый SupportCandy активен и открывается без ошибок.
2. Загрузите ZIP-файл расширения через стандартный экран установки плагинов WordPress.
3. Активируйте расширение и обновите страницу админ-панели.
4. Откройте настройки SupportCandy и найдите раздел Workflow.
5. Создайте тестовую заявку с нейтральной категорией и низким приоритетом.
6. Убедитесь, что существующие заявки не изменились после активации расширения.

На этом этапе не создавайте правило, которое закрывает, удаляет или массово меняет заявки. Даже если в списке действий доступно изменение статуса или удаление, первый тест должен быть обратимым. Например, можно добавить приватную заметку к тестовой заявке или изменить тестовое поле, созданное специально для проверки.

Первый безопасный тест

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

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

Логика "триггер - условие - действие" без лишней магии

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

Триггеры: что запускает автоматический сценарий

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

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

Условия: фильтр от случайных срабатываний

Условия определяют, к каким заявкам применится сценарий. В документации упоминаются поля заявки, пользовательские поля, агентские поля и операторы вроде Equal to, Matches, Has word. Чем точнее условие, тем меньше риск. Если вы используете только статус "Open", правило может затронуть слишком много заявок. Если добавить категорию, приоритет и служебное поле, сценарий станет заметно безопаснее.

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

Действия: что меняется в заявке

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

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

Автоматические рабочие сценарии для повторяемых событий

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

Маршрутизация новой заявки

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

Хорошая структура автоматического правила выглядит так:

1. Триггер: создана новая заявка.
2. Условия: категория техническая, приоритет высокий, поле "тип клиента" соответствует нужному уровню обслуживания.
3. Действие: назначить старшую группу или конкретного агента.
4. Действие: добавить приватную заметку с причиной назначения.
5. Проверка: тестовая заявка получила правильного исполнителя и не ушла в другую очередь.

Реакция на смену статуса

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

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

Автоответы без раздражения клиента

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

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

Ручные рабочие сценарии и виджет на странице заявки

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

Когда ручной сценарий лучше автоматического

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

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

Виджет Workflows и порядок на экране заявки

SupportCandy позволяет управлять виджетами индивидуальной заявки в разделе Support - Settings - Ticket Widgets. В списке виджетов документация упоминает Workflows, а также возможность включать, выключать, переименовывать и менять порядок виджетов. Для команды поддержки это не косметика, а часть рабочего процесса.

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

Права запуска и минимизация ошибок

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

Практический пример: эскалация срочной технической заявки

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

Цель сценария

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

Подготовка

Перед настройкой убедитесь, что в SupportCandy уже есть категория для технических вопросов, приоритет "High" или его локальный аналог, агентская роль для старшей поддержки и право Trigger Workflow у тех агентов, которые будут запускать ручной сценарий. Если используется отдельное поле "тип проблемы", подготовьте варианты значений заранее.

Автоматическая часть

1. Откройте Support - Settings - Workflow - Automatic.
2. Создайте сценарий с понятным названием, например "Пометка срочной технической заявки".
3. Выберите триггер создания новой заявки.
4. Добавьте условия: категория техническая, приоритет высокий, при необходимости дополнительное поле совпадает с нужным типом проблемы.
5. Добавьте действие приватной заметки: агенту нужно проверить срочность и решить, нужна ли эскалация.
6. При необходимости добавьте действие назначения первичной группы, но не старшего специалиста, если нужна человеческая проверка.
7. Сохраните сценарий и проверьте его только на тестовой заявке.

Ручная часть

1. Создайте ручной сценарий "Эскалация в старшую поддержку".
2. Добавьте условия, при которых он будет отображаться: приоритет высокий, категория техническая, статус не закрыт.
3. Добавьте действия: назначить старшую группу, сменить статус на "в работе", добавить приватную заметку с причиной эскалации.
4. Проверьте, что сценарий появляется в виджете только у агентов с правом запуска.
5. Создайте вторую тестовую заявку, которая не соответствует условиям, и убедитесь, что сценарий не отображается.

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

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

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

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

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

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

Тестовая матрица

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

Проверка уведомлений

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

Проверка прав

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

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

Связка Workflows с полями, виджетами и соседними расширениями

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

Поля заявки как основа условий

В документации по полям заявки указано, что ticket fields могут быть системными или пользовательскими, выводиться в форме новой заявки и в виджете индивидуальной заявки, а редактирование после создания зависит от возможностей агента. Для Workflows это значит, что пользовательские поля можно использовать как более точные условия: тип продукта, источник проблемы, уровень клиента, необходимость доступа, согласие на диагностику.

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

Виджеты заявки как рабочее место агента

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

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

Соседние расширения и риск пересечения правил

В экосистеме SupportCandy есть расширения для автоматического назначения, SLA, автоматического закрытия, таймера, отчетов, WooCommerce, EDD, LMS, Slack, Webhooks и других задач. Они могут дополнять Workflows, но иногда пересекаются по смыслу. Например, одно расширение может считать сроки обслуживания, другое закрывать неактивные заявки, а Workflows менять статус или исполнителя.

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

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

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

Не автоматизируйте удаление и закрытие без отдельной проверки

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

Ведите журнал правил на человеческом языке

Названия сценариев должны объяснять цель, а не только технический триггер. Плохо: "Rule 1", "High", "Auto status". Лучше: "Пометка срочной технической заявки", "Ручная эскалация в старшую поддержку", "Приватная заметка при переводе в ожидание клиента". Когда сценариев станет больше, такие имена помогут быстро понять, какое правило можно отключить.

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

Почему в этом руководстве нет PHP-сниппета

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

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

Практичные сценарии применения без перегруза правилами

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

Первичная сортировка по категории и приоритету

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

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

Служебные заметки для единых стандартов обработки

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

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

Ручная эскалация без хаоса в назначениях

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

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

Маршруты для WooCommerce, EDD или LMS-заявок

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

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

Рабочая карта для команды

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

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

Частые проблемы при настройке Workflows и способы диагностики

Большинство проблем с SupportCandy Workflows связаны не с установкой как таковой, а с несовпадением условий, прав, виджетов и ожиданий. Ниже - диагностика, которую стоит пройти до обращения в поддержку или отката расширения.

Сценарий не срабатывает после создания заявки

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

Что проверить

• Создайте заявку с точно теми значениями, которые указаны в условиях.
• Проверьте, что категория, приоритет и пользовательские поля совпадают не по смыслу, а по конкретному значению.
• Временно сузьте сценарий до одного действия приватной заметки, чтобы увидеть сам факт срабатывания.
• Убедитесь, что проверяете новую заявку, если триггер настроен на создание новой заявки.

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

Ручной сценарий не виден агенту в виджете

Симптом: сценарий создан, но на странице заявки агент не видит его в виджете Workflows. Здесь возможны три причины: условия не совпали, виджет выключен или роль агента не имеет права Trigger Workflow.

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

Правило срабатывает слишком широко

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

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

Письма приходят несколько раз или не приходят ожидаемым людям

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

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

Сценарий конфликтует с SLA, назначением или автоматическим закрытием

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

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

После обновления изменилось поведение действия или интерфейса

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

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

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

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

Не стоит ждать от него самостоятельного "умного" управления поддержкой. Лучший результат появляется, когда у вас уже есть понятная структура статусов, категорий, ролей и полей. Тогда Workflows превращает эту структуру в автоматические и ручные сценарии, а не подменяет собой управленческое решение.

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

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