SupportCandy Usergroup - Плагин WordPress

Руководство по настройке SupportCandy Usergroup для командной поддержки клиентов

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

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

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

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

Какую задачу решает группа пользователей в системе тикетов

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

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

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

Где такая модель особенно полезна

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

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

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

Когда надстройка может быть лишней

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

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

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

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

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

Базовые страницы SupportCandy

SupportCandy может выводить общий портал поддержки через шорткод [supportcandy]. Отдельно документация описывает страницы для создания нового тикета через [wpsc_create_ticket] и открытия тикета через [wpsc_open_ticket]. Для Usergroup чаще удобен полноценный портал, потому что пользователю нужно не только создать обращение, но и вернуться к списку или открыть конкретный тикет.

Проверьте:

• Страница поддержки создана и выбрана в Support -> Settings -> General Settings -> Page Settings.
• На странице нет лишних скриптов конструктора, которые перекрывают форму или кнопки.
• Клиент без прав администратора может открыть портал, создать тикет и увидеть свой список.
• Агент или администратор видит тикет в админ-панели и может ответить.

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

Права, роли и тестовые пользователи

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

1. Участник группы, который создает обращение.
2. Супервизор этой же группы, который должен видеть обращения участников.
3. Пользователь вне группы, который не должен видеть эти обращения.

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

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

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

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

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

SupportCandy Usergroup является надстройкой к SupportCandy. Поэтому порядок включения обычно такой: сначала установлен и активен основной SupportCandy, затем добавляется надстройка Usergroup, после чего в настройках появляется раздел для групп пользователей. Официальная документация по базовому SupportCandy описывает установку из каталога WordPress и ручную установку через загрузку ZIP-архива. Для самой надстройки не нужно описывать покупку или получение файла, но логика WordPress остается той же: плагин устанавливается через Plugins -> Add New или через загрузку архива в админ-панели.

После активации не начинайте сразу переносить всех клиентов. Сначала выполните короткую первичную проверку:

1. Откройте Support -> Settings и проверьте, появился ли раздел Usergroups или близкий пункт в структуре настроек.
2. Откройте страницу документации или интерфейс настроек и сравните доступные пункты с ожидаемыми: общие настройки, список групп, поля группы.
3. Создайте одну тестовую группу с понятным названием, например Acme Test, но не добавляйте туда реальных клиентов.
4. Добавьте одного тестового участника и одного тестового супервизора.
5. Создайте тестовый тикет от участника и проверьте, какую группу получил тикет.

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

Минимальная проверка после включения

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

Минимальный результат считается успешным, если:

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

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

Настройка Usergroup: автоназначение, выбор группы и права супервизора

Главный раздел настроек находится по пути Support -> Settings -> Usergroup -> General. Именно здесь определяется, будет ли тикет автоматически получать группу автора, сможет ли клиент выбрать группу при создании обращения, будет ли поле группы заполняться автоматически и сможет ли супервизор закрывать тикеты участников.

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

Автоматическое назначение группы новым тикетам

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

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

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

Разрешение клиенту менять группу тикета

Параметр Allow customers to modify usergroups of tickets позволяет пользователю выбрать группу при создании тикета и менять или удалять группу на странице конкретного обращения, если в форме добавлено поле usergroup. Этот режим удобен для аккаунт-менеджеров и подрядчиков, которые создают обращения по разным организациям.

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

Как проверить ручной выбор

1. Убедитесь, что тестовый пользователь состоит минимум в двух группах.
2. Добавьте поле usergroup в форму создания тикета.
3. Включите разрешение клиенту менять группу тикета.
4. Создайте тикет от имени тестового пользователя и выберите одну из групп.
5. Откройте тикет как супервизор выбранной группы и как супервизор другой группы.

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

Автозаполнение поля группы в форме

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

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

Категория тикета и право пользователя менять категорию

При создании Usergroup можно заранее выбрать категорию для новых тикетов участников группы. Это удобно, если разные организации всегда обращаются по разным линиям поддержки: например, один клиент идет в категорию Corporate Support, а другой - в Training. Параметр Allow user to change category in ticket form определяет, может ли пользователь изменить категорию при создании обращения.

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

Может ли супервизор закрывать тикеты

Настройка Allow supervisor to close ticket отвечает за важную границу ответственности. Если она включена, супервизор может закрывать тикеты, созданные другими участниками группы. Если выключена, он может просматривать и отвечать, но не закрывать обращение.

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

Создание групп: участники, супервизоры и категория по умолчанию

Сама группа создается в разделе Support -> Settings -> Usergroups -> Usergroups. Документация выделяет три ключевых блока: участники, супервизоры и категория. Каждая группа должна иметь понятное название и логическую границу: компания, филиал, отдел, проект или учебная группа. Не называйте группы слишком общо, например Clients или VIP, если в системе будет много разных клиентов. Через несколько месяцев такая структура станет неуправляемой.

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

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

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

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

Категория группы как способ направить тикеты

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

Но не перегружайте категории ролью доступа. Если вам нужно отделить видимость по компаниям, используйте Usergroup. Если нужно разделить темы обращений, используйте категории. Если нужно распределить работу между агентами, смотрите в сторону агентских ролей, назначений или Agentgroups. Разделение этих понятий делает систему понятнее и снижает число спорных тикетов.

Проверка группы после создания

После создания группы выполните короткую проверку:

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

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

Поля Usergroup: какие данные хранить о компании или отделе

Одна из сильных возможностей SupportCandy Usergroup - пользовательские поля самой группы. Они настраиваются в Support -> Custom Fields -> Usergroup Fields и относятся не к отдельному тикету, а к группе как объекту. Документация приводит примеры вроде местоположения, количества сотрудников и выручки. В практическом руководстве важнее не сами примеры, а принцип: поле группы хранит стабильный контекст организации, который пригодится при обработке тикетов.

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

Полезные поля для B2B-поддержки

Для компании или отдела обычно полезны такие поля:

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

У каждого поля есть параметры вроде метки, порядка, типа поля, дополнительной информации, лимита символов, placeholder и настроек дат. Не делайте длинные поля без ограничения, если агентам нужна короткая подсказка. Чем проще поле, тем выше шанс, что команда будет его заполнять и читать.

Где эти данные появляются

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

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

Виджет в тикете, уведомления и фильтр списка

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

Виджет Usergroup на странице тикета

Виджет нужен для контекста и, если разрешено, для изменения группы тикета. Настраивается он через Support -> Settings -> Ticket Widgets -> Usergroup. В общих настройках виджетов SupportCandy можно включать или отключать виджеты, переименовывать их, менять порядок и назначать права просмотра или изменения.

Практический подход такой:

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

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

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

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

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

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

Фильтрация тикетов по группам

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

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

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

Разберем сценарий, который хорошо показывает смысл SupportCandy Usergroup. Есть WordPress-сайт с клиентским порталом поддержки. Один корпоративный клиент Acme Store имеет трех сотрудников, которые создают обращения, и менеджера, который должен видеть все тикеты этой компании. Агентам поддержки нужно фильтровать обращения по компании и видеть дополнительный контекст: регион, договор и основной контакт.

Цель

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

Подготовка

Перед началом должны быть выполнены четыре условия:

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

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

1. Откройте Support -> Custom Fields -> Usergroup Fields и создайте поля Contract ID, Region и Main Contact, если эти данные нужны агентам.
2. Откройте Support -> Settings -> Usergroups -> Usergroups и создайте группу Acme Store.
3. Добавьте двух сотрудников в участники группы.
4. Добавьте менеджера компании в участники и назначьте его супервизором.
5. Заполните поля группы: код договора, регион и основной контакт.
6. Выберите категорию по умолчанию, если все обращения этой компании должны идти в одну линию поддержки.
7. В Support -> Settings -> Usergroup -> General включите автоназначение группы, если сотрудники состоят только в этой группе.
8. В Ticket Widgets включите виджет Usergroup для агентов и проверьте, нужно ли показывать его клиентам.
9. В шаблонах уведомлений добавьте супервизоров группы к тем событиям, где это оправдано.

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

Теперь создайте тикет от имени сотрудника Acme Store. Откройте этот тикет как агент и проверьте, что видна группа и заполненные поля. Затем зайдите как супервизор и убедитесь, что тикет участника доступен. После этого зайдите как внешний пользователь, который не входит в группу. Он не должен видеть тикет Acme Store.

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

Нюанс с несколькими группами

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

Практичные идеи применения групп на разных сайтах

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

Поддержка клиентов агентства

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

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

Филиальная сеть или франшиза

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

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

Учебная платформа или клуб

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

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

Внутренний сервисный отдел

Если WordPress используется как внутренний портал, Usergroup можно настроить по департаментам: бухгалтерия, продажи, склад, IT, маркетинг. Руководитель департамента видит заявки сотрудников своего отдела, а агенты поддержки фильтруют очередь по подразделению. Категория при этом остается темой обращения: доступ, оборудование, сайт, документы или интеграции.

Для внутреннего портала полезно включить уведомления супервизорам только по ключевым событиям, иначе руководители быстро начнут игнорировать письма. Если отделов много, дополнительно продумайте единый формат названий групп, например Department - Sales и Department - Finance.

Проверка результата: как понять, что группы работают правильно

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

Матрица тестов перед запуском

Для запуска подготовьте небольшую матрицу. Она помогает не забыть отрицательные проверки:

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

Что проверять после изменения настроек

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

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

Ограничения и аккуратные настройки безопасности

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

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

Что не стоит делать

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

Безопасный откат спорной настройки

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

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

Диагностика частых проблем с группами и тикетами

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

Супервизор не видит тикеты участников

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

Сначала проверьте, что супервизор добавлен в ту же группу не только как supervisor, но и как member. Документация прямо указывает, что супервизоры должны быть частью списка участников. Затем проверьте, получил ли сам тикет нужную группу. Если тикет не связан с группой, супервизору нечего видеть в рамках этой модели.

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

Клиент не видит поле выбора группы в форме

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

В официальных настройках указано условие: чтобы пользователь выбирал группу при создании тикета, нужно добавить custom field usergroup в форму тикета и включить разрешение клиенту изменять группы тикетов. Поэтому проверьте не только общий переключатель, но и состав полей формы в Support -> Custom Fields -> Ticket Form Fields.

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

Тикет получает не ту категорию

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

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

Письма приходят не тем людям или не приходят супервизору

Симптом: тикет виден в интерфейсе, но супервизор не получает письмо, или письмо получает слишком широкий круг людей.

Проверьте шаблон события в Support -> Email Notifications -> Ticket notifications. Документация Usergroup говорит, что в получатели можно добавлять участников или супервизоров группы, но это нужно настроить в шаблонах. Затем проверьте общие почтовые настройки: From Email, Reply-To Email, лимит писем за cron-задание и вложения. Если письма не уходят вообще, проблема может быть в доставке почты WordPress, а не в Usergroup.

В админ-панели пропали кнопки или элементы настроек

Симптом: не видно кнопок добавления, часть настроек не открывается или интерфейс ведет себя странно.

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

Пользователь вне группы видит чужой тикет

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

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

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

SupportCandy Usergroup стоит использовать, если вы уже работаете с SupportCandy или планируете строить поддержку внутри WordPress и вам нужна не просто очередь тикетов, а организационная модель клиентов. Надстройка особенно полезна там, где обращение одного сотрудника должно быть видно ответственному лицу компании, отдела, филиала или учебной группы.

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

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