Gedanken zu Community-basierten Support-Foren

Letzte Woche – und dieses Wochenende – habe ich die Kommentare zu Pippin Williamsons Beiträgen über die Entscheidung seines Unternehmens gelesen, die Preise für Easy Digital Downloads anzupassen (und für diejenigen, die neugierig sind, begrüße ich es).

Das ist eine Konversation an und für sich, und es gibt einen langen Kommentarthread, den ich für jeden lesenswert finde, der an der Produktentwicklung von WordPess beteiligt ist, aber ich schweife ab, da dies der Punkt dieses Beitrags ist.

Einige Leser haben im gesamten Kommentar-Feed Kommentare hinterlassen , in denen sie die Idee von Community-basierten Support-Foren diskutieren. Der ganze Thread ist lesenswert, aber:

1. EDD bot früher Community-basierte Support-Foren an (zusätzlich zu ihrem anderen Support).
2. Ich habe Produkte entwickelt und bearbeitet, die Community-basierte Support-Foren hatten

Und im Nachhinein halte ich es absolut nicht für eine kluge Entscheidung, dass ein WordPress-basierter Produktshop sie anbietet. Ich habe meine Gründe, ich werde näher darauf eingehen, aber ich möchte klarstellen, dass ich dies strikt auf WordPress beschränke, weil es das ist, was ich weiß.

Ich kann nicht für andere Segmente unserer Branche sprechen.

Community-basierte Support-Foren

Vor Jahren habe ich mit einem großartigen Team zusammengearbeitet, und wir haben ein solides Produkt entwickelt, und ich bin immer noch stolz auf unsere Arbeit. Während dieser Zeit war eines der Dinge, die wir ursprünglich anboten, Community-basierte Support-Foren.

Zunächst schien es sinnvoll: Wenn wir gerade keine Support-Tickets beantworteten (was öfter passierte – frag einfach Chris oder Michael ), halfen sich andere in den Foren aus.

Die ersten Community-basierten Support-Foren, die wir verwendet haben.

Es scheint wie eine Win-Win-Situation, oder? Sie haben Ihre Kunden, die anderen Kunden helfen, und Sie haben Ihr Team, das Kunden bei größeren Problemen hilft.

Im Idealfall kann es so aussehen. Aber die Welt ist keine ideale Situation und somit auch nicht die Natur von Community-basierten Support-Foren.

Das wirft natürlich eine Frage auf: Was ist falsch an Community-basierten Support-Foren?

Was wirklich in den Foren passiert

Wenn Sie Leute haben, die anderen helfen, ein Problem mit einem kostenpflichtigen Produkt zu lösen, das Support bietet, und der Support von jemand anderem als dem Anbieter kommt, dann suchen Sie nach Leuten, die:

• weiß nicht, wie das Produkt gebaut wurde,
• möglicherweise Lösungen von einem Ort aus bereitstellen, der weniger Erfahrung hat als Sie oder Sie und Ihr Entwicklerteam,
• können aus Mangel an Erfahrung einfach falsche Antworten gegeben werden.

Betrachten Sie es also so: Sie haben ein Produkt, das Sie oder Sie und ein Team gebaut haben. Es wurde getestet, bewertet, getestet, bewertet, bereitgestellt und der Verkauf läuft.

Dann stößt jemand auf ein Problem oder einen Fehler. Sie haben Support gekauft, also senden sie ein Ticket, das sie in eine Warteschlange von unbestimmter Länge bringt. Sie hören nicht so schnell zurück, wie sie möchten, also fragen sie jemanden in den Foren. Sie erhalten eine Antwort, sie ändern den Kerncode, es funktioniert, also sind sie glücklich.

Dann kehren Sie oder Ihr Team zu ihrer ursprünglichen Supportfrage zurück und sie haben einen legitimen Fehler gefunden. Das ist großartig, weil Sie damit die Qualität Ihrer Software steigern können.

Aber sie haben den Kerncode geändert, sodass jede Lösung, die Sie anbieten, wahrscheinlich mit „Danke, aber ich habe es gelöst bekommen“ beantwortet wird.

Aber es ist alles falsch gelöst.

Und je nach Art des Produkts, das Sie verkaufen, könnte dies zu Sicherheitslücken oder anderen Problemen führen, von denen Sie sich einfach nicht bewusst sind, bis Sie das Problem diagnostizieren können.

Jetzt müssen Sie den Benutzer jedoch fragen, was er getan hat, um sein Problem zu beheben, diesen Code zu prüfen, und dann Ihren Code zu prüfen.

Letztendlich, was bewirkt das?

• Benutzer, die Benutzern helfen, können falsche Lösungen produzieren,
• Benutzer, die Benutzern helfen, können mehr oder längere Supportanfragen als nötig generieren,
• Das Unternehmen wird möglicherweise mit mehr Arbeit als nötig belastet, um einen Fehler zu beheben oder eine Funktion hinzuzufügen.
• Und mehr.

Nun, ich bin niemand, der versucht, ein Problem zu entwerfen und dann keine Lösung anzubieten; Ich kann jedoch keine Lösung für alle Unternehmen anbieten. Wer kann? Ich kenne das Modell nicht; Ich kenne die Funktionsweise nicht, ich kenne die Struktur nicht, ich weiß vieles nicht.

Eine Möglichkeit, dies anzugehen

Aber was ich weiß, ist, dass Community-basierte Support-Foren mehr Probleme verursachen können als nicht, obwohl es von Anfang an nach einem Vorteil und einem Verkaufsargument klingt.

Auf der anderen Seite zu stehen, kann diese Perspektive jedoch ändern.

So würde ich dieses Problem angehen:

1. Der Support erfolgt auf einer Eins-zu-eins-Basis. Kunden senden ihre Support-Tickets über eine Anwendung wie HelpScout an das Problemteam und erhalten dann 1-zu-1-Support vom Team.
2. Reagieren Sie sofort (sozusagen). Lassen Sie den Kunden wissen, dass sein Ticket bearbeitet werden soll, aber es einen Rückstand gibt und Sie daran arbeiten, es so schnell wie möglich zu erledigen.
3. Sichtung & Priorisierung. Manchmal ist es jedoch notwendig, Tickets nach Wichtigkeit zu selektieren. Scheuen Sie sich nicht, dies abhängig von der Art eines Tickets zu tun.
4. Teilen Sie das Problem. Dies ist optional, aber wenn Sie keine Community-basierten Support-Foren haben möchten, bieten Sie an, Fixes, Updates usw. über einen Blog zu teilen.

Nochmals, so würde ich es aufgrund meiner Erfahrung ansprechen, aber es ist nicht unbedingt die Art und Weise, wie man es macht.

Wenn Sie sich jedoch gegen die Verwendung von Community-basierten Support-Foren entscheiden, ist dies eine mögliche Möglichkeit, mit der Entscheidung umzugehen, keine zu verwenden.

Also verwenden oder nicht?

Ich hoffe, dass dieser Beitrag für diejenigen, die die Idee davon haben, genügend Einblicke bietet, um Ihnen eine Pause bei der Einführung zu geben.

Ich sage nicht, dass sie immer eine schlechte Idee sind, aber ich sage, dass einige ernsthafte Überlegungen angestellt werden müssen, da Sie und Ihr Team letztendlich möglicherweise mehr Support-Tickets als nötig verursachen.