Мысли о форумах поддержки сообщества
На прошлой неделе — и в эти выходные — я читал комментарии к сообщениям Пиппина Уильямсона о решении его компании скорректировать цены на Easy Digital Downloads (и тем, кому любопытно, я приветствую это).
Это разговор сам по себе, и есть длинная ветка комментариев, которую, я думаю, стоит прочитать всем, кто занимается разработкой продуктов WordPess, но я отвлекся, поскольку в этом смысл этого поста.
Некоторые читатели оставляли комментарии в ленте комментариев, обсуждая идею форумов поддержки на базе сообщества. Всю ветку стоит прочитать, но:
- EDD раньше предлагал форумы поддержки на базе сообщества (в дополнение к их другой поддержке),
- Я создавал и работал над продуктами, для которых были форумы поддержки сообщества.
И, оглядываясь назад, я абсолютно не думаю, что это мудрое решение для магазина продуктов на основе WordPress предлагать их. У меня есть свои причины, я уточню, но я хочу прояснить, что я ограничиваю это строго WordPress, потому что это то, что я знаю.
Я не могу говорить о каких-либо других сегментах нашей отрасли.
Форумы поддержки сообщества
Много лет назад я работал с отличной командой, и мы создали надежный продукт, и я до сих пор горжусь проделанной нами работой. В то время одной из вещей, которые мы изначально предлагали, были форумы поддержки на базе сообщества.
Поначалу это казалось логичным: когда мы не отвечали на запросы в службу поддержки (что случалось чаще всего — просто спросите Криса или Майкла ), другие помогали друг другу на форумах.
Первые форумы поддержки сообщества, которые мы использовали.
Это кажется беспроигрышным, верно? У вас есть клиенты, помогающие другим клиентам, и ваша команда помогает клиентам с более серьезными проблемами.
В идеальной ситуации может получиться так. Но ситуация в мире не идеальна, и, следовательно, природа форумов поддержки на уровне сообщества тоже не идеальна.
Поэтому, естественно, возникает вопрос: что не так с форумами поддержки сообщества?
Что на самом деле происходит на форумах
Когда у вас есть люди, помогающие людям решить проблему с платным продуктом, который обеспечивает поддержку, и поддержка исходит от кого-то другого, а не от поставщика, вы ищете людей, которые:
- не знаю, как продукт был построен,
- может предоставлять решения из места с меньшим опытом, чем у вас или у вас и вашей команды разработчиков,
- могут быть даны просто неправильные ответы от отсутствия опыта.
Итак, посмотрите на это так: у вас есть продукт, созданный вами или вашей командой. Его протестировали, оценили, протестировали, оценили, развернули, и продажи идут полным ходом.
Затем кто-то сталкивается с проблемой или ошибкой. Они купили поддержку, поэтому они отправляют заявку, которая ставит в очередь неопределенной длины. Они не отвечают так быстро, как им хотелось бы, поэтому спрашивают кого-нибудь на форумах. Они получают ответ, они модифицируют основной код, он работает, так что они довольны.
Затем вы или ваша команда возвращаетесь к исходному вопросу службы поддержки и обнаруживаете законную ошибку. Это здорово, потому что позволяет повысить качество вашего программного обеспечения.
Но они изменили основной код, поэтому любое предлагаемое вами решение, скорее всего, будет встречено словами «Спасибо, но я решил проблему».
Но все решено неправильно.
И в зависимости от характера того, что вы продаете, это может привести к ошибкам безопасности или другим проблемам, о которых вы просто не знаете, пока не диагностируете проблему.
Однако теперь вы должны спросить пользователя, что он сделал, чтобы решить свою проблему, проверить этот код, а затем проверить свой код.
В конце концов, что это дает?
- Пользователи, помогающие пользователям, могут давать неверные решения,
- Пользователи, помогающие пользователям, могут создавать больше или более длинные запросы в службу поддержки, чем необходимо,
- Бизнес потенциально облагается большим объемом работы, чем необходимо для исправления ошибки или добавления функции.
- И более.
Теперь я не из тех, кто пытается сформулировать проблему, а затем не предлагает решения; однако я не могу предоставить решение для всех предприятий. Кто может? я не знаю модель; Я не знаю режима работы, я не знаю структуры, я не знаю многого.
Один из способов решить эту проблему
Но я точно знаю, что форумы поддержки сообщества могут создавать больше проблем, чем нет, хотя с самого начала это звучит как преимущество и аргумент в пользу продажи.
Однако нахождение по другую сторону этого может изменить эту точку зрения.
Итак, я бы подошел к этой проблеме так:
- Поддержка осуществляется в индивидуальном порядке. Клиенты отправляют свои запросы в службу поддержки проблемной команде через приложение, такое как HelpScout, а затем получают поддержку один на один от команды.
- Отвечать немедленно (вроде). Сообщите клиенту, что его заявка находится в очереди на рассмотрение, но есть невыполненная работа, и вы работаете над ее выполнением как можно скорее.
- Сортировка и расстановка приоритетов. Однако иногда необходимо сортировать заявки по важности. Не бойтесь делать это в зависимости от характера билета.
- Поделитесь проблемой. Это необязательно, но если вы не собираетесь создавать форумы поддержки сообщества, предложите делиться исправлениями, обновлениями и т. д. через блог.
Опять же, это именно то, как я бы решил это, основываясь на своем опыте, но это не обязательно способ сделать это.
Однако, если вы предпочитаете не использовать форумы поддержки сообщества, это потенциальный способ справиться с отказом от их использования.
Так использовать их или нет?
Для тех, кому может быть интересна эта идея, я надеюсь, что этот пост даст вам достаточно информации, чтобы вы задумались о том, чтобы представить их.
Я не говорю, что это всегда плохая идея, но я говорю, что есть некоторые серьезные соображения, потому что в конечном итоге вы можете вызвать у себя и своей команды больше запросов в службу поддержки, чем необходимо.