Tankar om gemenskapsbaserade supportforum
Förra veckan – och i helgen – har jag läst kommentarerna till Pippin Williamsons inlägg om hans företags beslut att justera priserna på Easy Digital Downloads (och för de som är nyfikna, jag applåderar det).
Det är en konversation i och för sig, och det finns en lång kommentarstråd som jag tycker är värd att läsa för alla som är inblandade i WordPess produktutveckling, men jag avviker eftersom det är meningen med det här inlägget.
Vissa läsare har lämnat kommentarer genom hela kommentarflödet och diskuterat begreppet community-baserade supportforum. Hela tråden är värd att läsa men:
- EDD brukade erbjuda community-baserade supportforum (utöver deras andra stöd),
- Jag har byggt och arbetat med produkter som hade community-baserade supportforum
Och i efterhand tycker jag absolut inte att det är ett klokt beslut av en WordPress-baserad produktbutik att erbjuda dem. Jag har mina skäl, jag ska utveckla det, men jag vill vara tydlig med att jag begränsar detta strikt till WordPress eftersom det är vad jag vet.
Jag kan inte tala för några andra segment av vår bransch.
Community-baserade supportforum
För år sedan arbetade jag med ett fantastiskt team och vi byggde en solid produkt, och jag är fortfarande stolt över det arbete vi gjorde. Under den tiden var en av de saker som vi initialt erbjuder community-baserade supportforum.
Först verkade det vara vettigt: När vi inte svarade på supportärenden (vilket var något som hände oftare än inte – fråga bara Chris eller Michael ), hjälpte andra varandra i forumen.
De första community-baserade supportforumen som vi använde.
Det verkar som en win-win, eller hur? Du har dina kunder som hjälper andra kunder, och du har ditt team som hjälper kunder med större problem.
I en idealisk situation kan det vara så här. Men världen är inte en idealisk situation och därför är det inte heller karaktären hos community-baserade supportforum.
Så, naturligtvis, väcker detta en fråga: Vad är det för fel med community-baserade supportforum?
Vad som verkligen händer i forumet
När du har människor som hjälper människor att försöka lösa ett problem med en betalprodukt som ger support, och supporten kommer från någon annan än leverantören, då tittar du på personer som:
- vet inte hur produkten byggdes,
- kanske tillhandahåller lösningar från en plats med mindre erfarenhet än du eller du och ditt team av utvecklare,
- kan få helt enkelt felaktiga svar på grund av bristande erfarenhet.
Så se på det så här: Du har en produkt som du eller du och ett team har byggt. Det har testats, utvärderats, testats, utvärderats, implementerats och försäljningen rullar på.
Då stöter någon på ett problem eller en bugg. De har köpt support, så de skickar in en biljett som sätter den i en kö av obestämbar längd. De hör inte tillbaka så snabbt som de vill, så de frågar någon i forumen. De får ett svar, de modifierar kärnkoden, det fungerar, så de är nöjda.
Sedan kommer du eller ditt team tillbaka till sin ursprungliga supportfråga och de har hittat en legitim bugg. Det är bra eftersom det låter dig öka kvaliteten på din programvara.
Men de har ändrat kärnkoden så vilken lösning du än erbjuder kommer sannolikt att mötas med "Tack, men jag har fått det löst."
Men det har löst sig helt fel.
Och beroende på arten av det du säljer kan detta introducera säkerhetsbuggar eller andra problem som du helt enkelt inte är medveten om förrän du kan diagnostisera problemet.
Nu måste du dock fråga användaren vad de gjorde för att fixa sitt problem, granska den koden, sedan måste du granska din kod.
I slutändan, vad gör detta?
- Användare som hjälper användare kan skapa felaktiga lösningar,
- Användare som hjälper användare kan generera fler eller längre supportförfrågningar än nödvändigt,
- Verksamheten beskattas potentiellt med mer arbete än nödvändigt för att fixa en bugg eller lägga till en funktion.
- Och mer.
Nu är jag inte en som försöker lägga upp ett problem och sedan inte ge en lösning; Jag kan dock inte tillhandahålla en lösning för alla företag. Vem kan? Jag kan inte modellen; Jag vet inte driftsättet, jag vet inte strukturen, jag kan inte många saker.
Ett sätt att ta itu med detta
Men vad jag vet är att community-baserade supportforum kan generera fler problem än inte även om det från början låter som en fördel och ett försäljningsargument.
Att vara på andra sidan av detta kan dock förändra det perspektivet.
Så sättet jag skulle närma mig det här problemet är så här:
- Supporten sker på en-till-en-basis. Kunder skickar in sina supportbiljetter till problemteamet via en applikation som HelpScout och får sedan 1-mot-1-support från teamet.
- Svara omedelbart (Sorts). Låt kunden veta att biljetten står i kö för att bli åtgärdad men det finns en eftersläpning och du arbetar för att få till det ASAP.
- Triage & Prioritera. Ibland är det dock nödvändigt att triage biljetter via betydelse. Var inte rädd för att göra detta beroende på vilken typ av biljett.
- Dela problemet. Detta är valfritt men om du inte ska ha community-baserade supportforum, erbjud dig att dela korrigeringar, uppdateringar och så vidare via en blogg.
Återigen, det här är bara hur jag skulle ta itu med det baserat på min erfarenhet, men det är inte nödvändigtvis så att göra det.
Om du väljer att inte använda community-baserade supportforum är det här ett potentiellt sätt att hantera att inte använda ett.
Så använda dem eller inte?
För dem som kanske är underhållande tanken på det, hoppas jag att det här inlägget ger tillräckligt med insikter för att ge dig en paus om att introducera dem.
Jag säger inte att de alltid är en dålig idé, men jag säger att det finns några allvarliga överväganden att göra eftersom du i slutändan kan orsaka fler supportbiljetter för dig och ditt team än nödvändigt.
