Думки про форуми підтримки на основі спільноти

Минулого тижня – і цих вихідних – я читав коментарі до публікацій Піпіна Вільямсона про рішення його компанії скоригувати ціни на Easy Digital Downloads (і для тих, кому цікаво, я це вітаю).

Це розмова сама по собі, і є довга тема коментарів, яку, на мою думку, варто прочитати всім, хто бере участь у розробці продуктів WordPess, але я відволікаюся, оскільки це суть цієї публікації.

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

1. Раніше EDD пропонував форуми підтримки на основі спільноти (на додаток до іншої підтримки),
2. Я створював і працював над продуктами, які мали форуми підтримки на основі спільноти

І, оглядаючись назад, я абсолютно не вважаю, що це мудре рішення для магазину продуктів на основі WordPress пропонувати їх. У мене є свої причини, я розповім детальніше, але я хочу чітко пояснити, що я обмежую це суворо для WordPress, оскільки це те, що я знаю.

Я не можу говорити про інші сегменти нашої галузі.

Форуми підтримки на основі спільноти

Багато років тому я працював із чудовою командою, і ми створили надійний продукт, і я досі пишаюся нашою роботою. У той час однією з речей, які ми спочатку пропонували, були форуми підтримки на основі спільноти.

Спочатку здавалося, що це мало сенс: коли ми не відповідали на запити служби підтримки (що траплялося частіше, ніж ні – просто запитайте Кріса чи Майкла ), інші допомагали один одному на форумах.

Перші форуми підтримки на основі спільноти, які ми використовували.

Здається, безпрограшний варіант, чи не так? У вас є клієнти, які допомагають іншим клієнтам, і ваша команда допомагає клієнтам із серйознішими проблемами.

В ідеальній ситуації це може скластися саме так. Але світ не ідеальний, і, отже, не ідеальна природа форумів підтримки на основі спільнот.

Тож, звичайно, виникає запитання: що не так із форумами підтримки на основі спільнот?

Що насправді відбувається на форумах

Коли у вас є люди, які допомагають людям намагатися вирішити проблему за допомогою платного продукту, який надає підтримку, і підтримка надходить від когось іншого, а не від постачальника, тоді ви дивитесь на людей, які:

• не знаю, як був створений продукт,
• може надавати рішення з місця з меншим досвідом, ніж ви чи ваша команда розробників,
• можуть бути надані просто неправильні відповіді через брак досвіду.

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

Тоді хтось стикається з проблемою чи помилкою. Вони придбали підтримку, тож подають заявку, яка ставить у чергу невизначеної довжини. Вони не отримують відповіді так швидко, як їм хочеться, тому запитують когось на форумах. Вони отримують відповідь, змінюють код ядра, він працює, тому вони щасливі.

Потім ви або ваша команда повертаєтеся до свого початкового запитання служби підтримки, і вони знайшли дійсну помилку. Це чудово, тому що це дозволяє підвищити якість вашого програмного забезпечення.

Але вони змінили код ядра, тож будь-яке рішення, яке ви запропонуєте, швидше за все, зустрінеться словами «Дякую, але я вирішив це питання».

Але вирішено все не так.

І залежно від характеру того, що ви продаєте, це може спричинити помилки безпеки чи інші проблеми, про які ви просто не знаєте, доки не зможете діагностувати проблему.

Тепер, однак, ви повинні запитати користувача, що він зробив, щоб вирішити свою проблему, перевірити цей код, а потім перевірити свій код.

Зрештою, що це робить?

• Користувачі, які допомагають користувачам, можуть створювати неправильні рішення,
• Користувачі, які допомагають користувачам, можуть створювати більше або довші запити на підтримку, ніж це необхідно,
• Підприємство потенційно обтяжується більшою роботою, ніж потрібно, щоб виправити помилку чи додати функцію.
• І більше.

Тепер я не з тих, хто намагається скласти макет проблеми, а потім не надати рішення; однак я не можу надати рішення для всіх компаній. Хто може? модель не знаю; Я не знаю режиму роботи, я не знаю структуру, я багато чого не знаю.

Один із способів вирішити цю проблему

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

Проте перебування по той бік цього може змінити цю точку зору.

Отже, я б підійшов до цієї проблеми таким чином:

1. Підтримка здійснюється індивідуально. Клієнти надсилають свої запити в службу підтримки проблемній групі за допомогою програми, як-от HelpScout, а потім отримують підтримку 1-на-1 від команди.
2. Відповідь негайно (начебто). Повідомте клієнта, що його квиток стоїть у черзі, але є відставання, і ви працюєте над тим, щоб отримати його якомога швидше.
3. Сортування та визначення пріоритетів. Іноді, однак, необхідно сортувати квитки за важливістю. Не бійтеся робити це залежно від характеру квитка.
4. Поділіться проблемою. Це необов’язково, але якщо ви не збираєтеся створювати форуми підтримки на основі спільноти, запропонуйте ділитися виправленнями, оновленнями тощо через блог.

Знову ж таки, це те, як я б вирішив це на основі свого досвіду, але це не обов’язково спосіб.

Однак, якщо ви вирішуєте не використовувати форуми підтримки на основі спільноти, це потенційний спосіб впоратися з вибором не використовувати їх.

Тож використовувати їх чи ні?

Сподіваюся, для тих, кого ця ідея може зацікавити, ця публікація надасть достатньо інформації, щоб дати вам паузу щодо їх представлення.

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