Тикеты Поддержки vs. Запросы Функций: Чему Доверять?

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

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

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

Означает ли объём тикетов для отсутствующей функции то же самое, что счёт голосов за неё?

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

Что значит, когда у функции есть тикеты поддержки, но почти нет голосов на доске?

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

Доска читается как низкий приоритет:
"Export to CSV": 4 голоса за 6 месяцев

Поддержка рассказывает другую историю:
"Export to CSV": 31 тикет за тот же период, каждый с
другого аккаунта, каждый закрыт с «сейчас не
поддерживается, передадим обратную связь»

Всегда ли всплеск тикетов поддержки означает, что лежащая в основе проблема — отсутствующая функция?

Нет, и здесь два канала могут вводить в заблуждение в противоположную сторону. Всплеск тикетов так же часто вызван запутанным интерфейсом вокруг уже существующей функции, багом, или изменением, вышедшим без адекватного объяснения, ничто из которого не решается постройкой чего-то нового. Чтение каждого всплеска тикетов как «пользователи хотят функцию, которой у нас нет» производит roadmap, забитую вещами, на самом деле бывшими пробелами документации или замаскированными проблемами юзабилити. Тикет поддержки говорит вам, где трение; он сам по себе не говорит вам, является ли решением новая функция, изменение интерфейса, или лучшая статья помощи, и путаница этого тратит инженерное время на неверное решение.

Как два сигнала реально должны комбинироваться при решении, что строить?

Используйте тикеты, чтобы найти, где трение, и используйте доску запросов, плюс прямой контакт там, где доска скудна, чтобы подтвердить, как реально выглядит желаемый результат. Кластер тикетов идентифицирует реальную, ощущаемую проблему; он редко специфицирует решение достаточно точно, чтобы строить против него, потому что фрустрированный пользователь в разговоре с поддержкой описывает симптомы, не спецификации. Доска запросов, когда у неё достаточно голосов по одной и той же лежащей в основе проблеме, обычно несёт больше детали «что реально удовлетворило бы это», потому что написание запроса уже является актом спецификации желаемого, а не просто сообщением о том, что не так.

Должны ли агенты поддержки сами регистрировать тикеты как запросы на функции?

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

FAQ

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

Стоит ли строить функцию, сильно представленную в тикетах, но почти без голосов? Часто да, при условии, что объём тикетов реально идёт с отдельных аккаунтов, а лежащая в основе потребность подтверждена, а не предположена; относитесь к низкому счёту голосов как к артефакту измерения стоимости активации доски, не как к доказательству, что спрос нереален.

Как отличить с первого взгляда тикет о путанице интерфейса от подлинного тикета об отсутствующей функции? Смотрите, состоит ли решение в объяснении существующей возможности или извинении за отсутствующую. Паттерн решений «о, это на самом деле прямо там» указывает на проблему интерфейса или обнаруживаемости; паттерн «мы это ещё не поддерживаем» указывает на реальный разрыв.

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

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

По теме на changeloop: Документация для разработчиков, Сравнение инструментов changelog