SupportCandy Reports - Плагин WordPress

Руководство по SupportCandy Reports: как читать отчёты службы поддержки и превращать их в решения

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

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

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

Какую задачу решает расширение Reports в SupportCandy

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

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

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

Какие вопросы можно закрыть с помощью отчётов

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

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

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

Кому подойдёт SupportCandy Reports и когда он может быть лишним

Расширение лучше всего раскрывается на сайтах, где SupportCandy уже стал рабочим центром поддержки. Это могут быть магазины с WooCommerce, сайты с цифровыми продуктами, обучающие платформы, SaaS-сервисы на WordPress, агентства, которые обслуживают клиентов через тикеты, или внутренний портал для заявок. В каждом таком случае отчёты помогают не просто считать обращения, а понимать, что именно тормозит поддержку.

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

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

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

Reports также полезен для сайтов, где тикеты содержат дополнительные поля. Документация указывает, что отчёты можно генерировать для некоторых типов custom fields: single select, multiple select, checkbox и radio button, а также для категории, приоритета, рейтинга и SLA. Это особенно важно, если поле "Тип проблемы", "Продукт", "Тариф", "Регион" или "Источник обращения" помогает принимать управленческие решения.

Когда лучше начать не с отчётов

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

Практическое правило: если команда не договорилась, когда тикет считается закрытым, отчёт по Ticket Closing Delay нельзя использовать как показатель эффективности. Сначала фиксируется процесс, потом читается график.

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

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

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

• Основной плагин SupportCandy установлен, активирован и обновлён вместе с используемыми расширениями.
• Страница поддержки создана через [supportcandy] или отдельные страницы настроены через [wpsc_create_ticket] и [wpsc_open_ticket].
• В Support настроены агенты и роли, чтобы было понятно, кто отвечает за какие тикеты.
• Категории, приоритеты, статусы и пользовательские поля не дублируют друг друга и имеют понятные названия.
• Закрытые статусы отделены от незавершённых, иначе отчёт по закрытию будет вводить в заблуждение.
• Для страниц SupportCandy отключено агрессивное кеширование, если оно мешает формам, спискам тикетов или динамическим данным.
• Есть резервная копия сайта и возможность проверить обновление на копии, особенно если база тикетов большая.

Если поддержка работает через email piping, WooCommerce, EDD, Gravity Forms, SLA, Satisfaction Survey или Workflow/Automations, учитывайте эти расширения при проверке отчётов. Reports может дать полезный срез по данным, но он не исправит ошибочные правила маршрутизации, невалидные уведомления или форму, которая собирает слишком общие категории.

Какие данные нужны для осмысленного первого отчёта

Новому сайту с пустой базой тикетов не стоит ожидать полезной аналитики сразу после включения Reports. Минимально нужен набор обращений за период, в котором есть созданные, закрытые и отвеченные тикеты. Для отчётов по rating должен быть настроен и реально использован механизм оценки. Для отчётов по custom fields поля должны быть не просто созданы, но и заполнены в тикетах.

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

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

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

Первый маршрут в админ-панели

После активации проверьте путь Support -> Settings -> Reports. В документации этот экран описан как место для общих настроек отчётов. Там указывается default duration и выбор custom fields, по которым нужно генерировать отчёты. Затем перейдите в Support -> Reports и откройте несколько базовых отчётов: Ticket Statistics, Response Delay, Ticket Closing Delay и Communication Gap.

Что должно считаться успешной установкой

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

1. Откройте Support -> Reports и выберите период, где точно есть тикеты.
2. Сравните количество созданных тикетов с фильтром в Support -> Tickets за тот же период.
3. Откройте тикеты, которые должны быть закрыты, и убедитесь, что их статус относится к закрытым.
4. Проверьте один отчёт без фильтра и один отчёт с фильтром по категории или приоритету.
5. Если используете custom fields, добавьте только 1-2 самых важных поля и посмотрите, появились ли они в Reports.

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

Как настроить Reports, чтобы графики отвечали на реальные вопросы

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

Default Duration: зачем нужен период по умолчанию

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

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

Generate reports for custom fields: выбирать только поля с управленческим смыслом

Документация указывает, что отчёты можно генерировать для custom fields некоторых типов, включая single select, multiple select, checkbox и radio button. Это разумное ограничение: такие поля дают конечный набор вариантов, который можно агрегировать. Текстовые поля, длинные описания и произвольные комментарии хуже подходят для отчётности, потому что их нельзя аккуратно сложить в понятный график без отдельной обработки.

Лучшие кандидаты для отчётов по полям - те, где ответ пользователя влияет на процесс: продукт, категория проблемы, тариф, отдел, приоритет, тип клиента, источник обращения. Худшие кандидаты - поля, которые редко заполняются, постоянно переименовываются или собирают почти одинаковые варианты вроде "ошибка", "проблема", "не работает" и "сломалось".

Как безопасно добавить новое поле в отчёты

1. Проверьте, что поле уже используется в форме или в тикетах и имеет предсказуемые варианты.
2. Добавьте его в Support -> Settings -> Reports -> Generate reports for custom fields.
3. Откройте Support -> Reports и выберите период, где это поле точно заполнено.
4. Сравните график с несколькими реальными тикетами, чтобы убедиться, что смысл поля читается правильно.
5. Если поле не помогает принять решение, уберите его из отчётов и оставьте в форме только как справочную информацию.

Фильтры: не смешивайте все тикеты в один показатель

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

Фильтр должен быть достаточно узким, чтобы отвечать на вопрос, но не настолько узким, чтобы оставалось 2 тикета и вывод терял смысл. Например, фильтр "Category equals Pre-sale Questions" полезен, если эта категория действительно заполнена. Фильтр "Category equals Pre-sale Questions + Priority equals High + Agent equals Иван" может быть слишком узким для регулярной аналитики, если данных мало.

Как читать основные отчёты без ложных выводов

Reports показывает несколько разных показателей, и каждый из них отвечает на свой вопрос. Ошибка новичка - сравнивать их как одно и то же. Количество созданных тикетов говорит о входящем потоке. Количество закрытых - о завершении. First Response Delay показывает скорость первой реакции. Average Response Delay ближе к ритму всей переписки. Ticket Closing Delay показывает, сколько времени уходит до закрытия. Communication Gap описывает среднее число сообщений в цепочке до закрытия.

Ticket Statistics: входящий поток и закрытие

Ticket Statistics показывает тренд созданных и закрытых тикетов за выбранный период. Это базовый отчёт для ответа на вопрос: "Очередь растёт или команда успевает закрывать обращения?". Если созданных тикетов больше, чем закрытых, это может быть тревожным сигналом, но не всегда. Иногда часть тикетов ожидает ответ клиента, часть относится к долгим задачам, а часть намеренно не закрывается до завершения проекта.

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

Response Delay: первая реакция и средний ответ

Документация выделяет First Response Delay и Average Response Delay. Первое измеряет время до первого ответа агента, второе - среднее время ответа в переписке. Эти показатели нельзя смешивать. Первая реакция важна для ощущения клиента: его не игнорируют. Средний ответ важен для реального движения тикета к решению.

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

Ticket Closing Delay: скорость завершения, а не только скорость ответа

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

Не используйте Ticket Closing Delay как единственный показатель качества агента. У одного сотрудника могут быть сложные категории, у другого простые обращения. Сначала фильтруйте по категории, приоритету, продукту или типу запроса, а уже потом сравнивайте выводы.

Communication Gap: сколько сообщений нужно до решения

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

Если Communication Gap вырос в одной категории, откройте 5-10 тикетов из этого среза и посмотрите, где именно появляются дополнительные сообщения. Частые причины: отсутствует обязательное поле, клиент не прикладывает скриншот, агент просит данные по одному за раз, нет готового шаблона диагностики или товарная документация устарела.

Ratings и custom fields: качество глазами клиента и разрез по бизнесу

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

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

Практический сценарий: найти причину задержки ответа после запуска новой функции

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

Цель

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

Подготовка

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

Шаги анализа

1. Откройте Support -> Reports -> Ticket Statistics и выберите период после запуска функции.
2. Сравните количество созданных и закрытых тикетов без фильтра, чтобы понять общий поток.
3. Добавьте фильтр по категории или custom field, связанному с новой функцией.
4. Откройте Response Delay и отдельно посмотрите First Response Delay и Average Response Delay.
5. Проверьте Communication Gap для того же фильтра: выросло ли количество сообщений до закрытия.
6. Откройте несколько реальных тикетов из этого среза и выпишите, какие данные агент просит повторно.

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

Если First Response Delay вырос только в новой категории, причина может быть в маршрутизации: тикеты не назначаются нужному агенту или уведомления не доходят. Если Average Response Delay и Communication Gap растут вместе, проблема чаще в качестве входных данных или сложности инструкции. Если Ticket Closing Delay вырос, но ответы идут быстро, тикеты могут зависать в статусе ожидания клиента или не закрываться после решения.

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

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

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

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

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

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

Для Response Delay возьмите 3-5 тикетов и вручную посмотрите время создания и первый ответ агента. Для Communication Gap откройте цепочку переписки и оцените, действительно ли много сообщений уходит на уточнения. Для custom fields проверьте, что выбранные значения заполнены в самих тикетах, а не только добавлены в форму после факта.

Печать и передача отчёта

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

Мини-итог после настройки

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

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

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

Сохранённые фильтры как рабочие представления

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

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

Связка с настройками ticket list

Документация SupportCandy по списку тикетов описывает default filters, filter items и saved filters. Это важно для Reports, потому что отчёты и список тикетов должны говорить на одном языке. Если в списке тикетов агент привык фильтровать по категории и приоритету, в Reports стоит использовать похожие условия. Так команда быстрее связывает график с конкретными обращениями.

Что делать с найденной проблемой

Каждый отчёт должен завершаться действием или решением "ничего не менять". Если вырос Communication Gap, можно улучшить форму и добавить обязательное поле. Если вырос First Response Delay, проверить уведомления и дежурства. Если вырос Ticket Closing Delay, уточнить правила статусов и автоматического закрытия. Если отчёт по custom field показывает перегрузку одной категории, добавить документацию или отдельного ответственного агента.

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

Продуктовые сценарии: какие решения принимать по разным отчётам

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

Когда созданных тикетов стало больше, но закрытие не просело

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

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

Какой вывод считать рабочим

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

Когда первая реакция быстрая, но закрытие долгое

Такой сценарий особенно важен для SupportCandy Reports, потому что он показывает различие между Response Delay и Ticket Closing Delay. Быстрый первый ответ может скрывать медленное решение. Агент видит тикет, отвечает клиенту, но дальше переписка растягивается. Причина может быть в сложной категории, недостатке прав у агента, ожидании разработчика, отсутствии шаблона диагностики или в том, что клиенту приходится по частям присылать данные.

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

Когда Communication Gap растёт только у одной категории

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

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

Когда отчёты по custom fields спорят с ощущениями команды

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

Хорошая практика - сделать короткую ревизию значений поля. Уберите дубли, переименуйте непонятные варианты, не смешивайте технические и коммерческие категории в одном поле. Для отчёта лучше 6-8 ясных вариантов, чем 30 вариантов, которыми никто последовательно не пользуется. Reports не исправит плохую таксономию, но быстро покажет, где она мешает принимать решения.

Как использовать отчёты на командной встрече

Регулярный разбор поддержки не должен превращаться в чтение всех графиков подряд. Выберите 2-3 показателя, которые соответствуют текущей цели. Например, если команда улучшает скорость первой реакции, смотрите First Response Delay по важным категориям. Если цель - уменьшить количество повторных уточнений, смотрите Communication Gap. Если цель - разгрузить сложную категорию, смотрите Ticket Statistics и custom field report по этой категории.

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

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

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

Отчёт пустой, хотя тикеты есть

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

Что проверить: снимите фильтр, выберите период шире, откройте несколько тикетов вручную, проверьте их даты, статусы и заполненные поля. Если речь о custom fields, убедитесь, что поле относится к поддерживаемому типу и добавлено в настройках Reports. Если после этого отчёт не появляется, обновите основной SupportCandy и все расширения на тестовой копии.

Фильтр отчёта даёт странный результат

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

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

График загрузился, но цифры не совпадают с ожиданием команды

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

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

Страница отчётов тормозит или не строит крупный период

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

Что делать: проверяйте отчёт по меньшему периоду, сужайте фильтр, не включайте лишние custom fields, обновляйте расширения на staging-копии и не запускайте тяжёлые проверки в часы пик. Если сайт имеет очень большую базу, обсудите с разработчиком или хостингом индексы, cron, объектный кеш и общую нагрузку WordPress. Не удаляйте старые тикеты только ради ускорения, если они нужны для истории или обязательств перед клиентами.

После обновления часть интерфейса Reports выглядит неправильно

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

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

Показатель Response Delay выглядит хуже после изменения уведомлений

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

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

Безопасные улучшения процесса без правки кода плагина

Для SupportCandy Reports не стоит придумывать PHP-хуки или JavaScript-правки без прямого подтверждения в документации. Надёжнее улучшать процесс через настройки SupportCandy, структуру полей, правила команды и исключения кеша. Это безопаснее, обратимо и не ломает обновления.

Улучшите форму, если Communication Gap слишком высокий

Если отчёт показывает много сообщений до закрытия, проверьте не график, а форму создания тикета. Возможно, клиент не указывает продукт, версию, URL, скриншот, шаги воспроизведения или срочность. Добавьте одно обязательное поле с выбором из фиксированных вариантов вместо длинного текстового объяснения. Через следующий период сравните Communication Gap по той же категории.

Настройте статусы, если Ticket Closing Delay искажён

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

Исключите страницы поддержки из агрессивного кеша

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

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

Когда стоит использовать SupportCandy Reports

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

Перед внедрением не пытайтесь решить всё графиками. Сначала проверьте базовый SupportCandy: страницы, короткие коды, роли, уведомления, статусы, категории, поля, кеш и тестовый тикет. Затем включите Reports, задайте default duration, добавьте только важные custom fields, сохраните несколько рабочих фильтров и договоритесь, как команда будет читать показатели.

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

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