Eelmisel nädalal – ja sel nädalavahetusel – olen lugenud Pippin Williamsoni postituste kommentaare tema ettevõtte otsuse kohta kohandada Easy Digital Downloadsi hindu (ja neile, kes on uudishimulikud, kiidan seda).
See on vestlus omaette ja seal on pikk kommentaarilõng, mida minu arvates tasub lugeda kõigil, kes on WordPessi tootearendusega seotud, kuid kaldun kõrvale, kuna see on selle postituse mõte.
Mõned lugejad on jätnud kogu kommentaarivoo jooksul kommentaare, arutades kogukonnapõhiste tugifoorumite kontseptsiooni. Kogu teema on lugemist väärt, kuid:
- EDD pakkus varem kogukonnapõhiseid tugifoorumeid (lisaks muule toele),
- Olen loonud tooteid, millel olid kogukonnapõhised tugifoorumid, ja töötanud nende kallal
Ja tagantjärele mõeldes ei pea ma absoluutselt mõistlikuks otsuseks, kui WordPressil põhinev tootepood neid pakuks. Mul on oma põhjused, ma täpsustan, kuid ma tahan olla selge, et ma piiran seda ranget WordPressi, sest see on see, mida ma tean.
Ma ei saa rääkida ühegi teise meie tööstuse segmendi eest.
Kogukonnapõhised tugifoorumid
Aastaid tagasi töötasin suurepärase meeskonnaga ja ehitasime tugeva toote ning olen siiani tehtud töö üle uhke. Selle aja jooksul oli üks asi, mida me esialgu pakkusime, kogukonnapõhised tugifoorumid.
Alguses tundus see olevat loogiline: kui me ei vastanud tugipiletitele (mis juhtus sagedamini kui mitte – küsige lihtsalt Chrisilt või Michaelilt ), aitasid teised foorumites üksteist.
Esimesed kogukonnapõhised tugifoorumid, mida kasutasime.
Tundub, et kõik võidavad, eks? Teie kliendid aitavad teisi kliente ja teie meeskond aitab kliente suuremate probleemide korral.
Ideaalses olukorras võib see nii välja kukkuda. Kuid maailm ei ole ideaalne olukord ja seega pole seda ka kogukonnapõhiste tugifoorumite olemus.
Seega tekitab see loomulikult küsimuse: mis on kogukonnapõhistel tugifoorumitel viga?
Mis foorumites tegelikult toimub
Kui teil on inimesi, kes aitavad inimestel proovida probleemi lahendada tasulise tootega, mis pakub tuge, ja tugi tuleb kelleltki teiselt peale müüja, siis vaatate inimesi, kes:
- ei tea, kuidas toode on ehitatud,
- võib pakkuda lahendusi kohast, kus on vähem kogemusi kui teie või teie ja teie arendajate meeskond,
- kogemuste puudumise tõttu võidakse anda lihtsalt valesid vastuseid.
Nii et vaadake seda järgmiselt: teil on toode, mille olete ise või teie ja meeskond loonud. Seda on testitud, hinnatud, testitud, hinnatud, kasutusele võetud ja müük jätkub.
Siis tekib kellelgi probleem või viga. Nad on ostnud toetuse, seega esitavad nad pileti, mis paneb määramatu pikkusega järjekorda. Nad ei kuule tagasi nii kiiresti, kui neile meeldib, seega küsivad nad foorumites kellegi käest. Nad saavad vastuse, muudavad põhikoodi, see töötab, nii et nad on rahul.
Seejärel pöördute teie või teie meeskond tagasi oma algse tugiküsimuse juurde ja nad on leidnud õigustatud vea. See on suurepärane, sest see võimaldab teil oma tarkvara kvaliteeti tõsta.
Kuid nad on muutnud põhikoodi, nii et ükskõik millisele teie pakutavale lahendusele vastatakse tõenäoliselt "Tänan, aga ma sain selle lahendatud."
Kuid kõik on valesti lahendatud.
Ja olenevalt müüdava kauba olemusest võib see põhjustada turvavigu või muid probleeme, millest te lihtsalt ei tea enne, kui suudate probleemi diagnoosida.
Nüüd peate aga küsima kasutajalt, mida ta oma probleemi lahendamiseks tegi, seda koodi auditeerima ja seejärel oma koodi auditeerima.
Lõpuks, mida see teeb?
- Kasutajad, kes aitavad kasutajatel luua valesid lahendusi,
- Kasutajad, kes abistavad kasutajaid, saavad genereerida rohkem või pikemaid tugitaotlusi kui vaja,
- Võimalik, et ettevõttele tuleb teha rohkem tööd, kui vea parandamiseks või funktsiooni lisamiseks vaja läheb.
- Ja veel.
Nüüd ma pole see, kes üritab probleemi paika panna ja seejärel lahendust ei paku. aga ma ei saa pakkuda lahendust kõikidele ettevõtetele. Kes saab? Ma ei tea mudelit; Ma ei tea töörežiimi, ma ei tea ülesehitust, ma ei tea paljusid asju.
Üks viis selle lahendamiseks
Kuid ma tean, et kogukonnapõhised tugifoorumid võivad tekitada rohkem probleeme kui mitte, kuigi see kõlab algusest peale eelise ja müügiargumendina.
Selle teisel poolel olemine võib seda perspektiivi siiski muuta.
Nii et viis, kuidas ma sellele probleemile läheneksin, on järgmine:
- Toetamine toimub üks-ühele põhimõttel. Kliendid esitavad oma tugipiletid probleemimeeskonnale sellise rakenduse kaudu nagu HelpScout ja saavad seejärel meeskonnalt individuaalset tuge.
- Vastake kohe (omamoodi). Andke kliendile teada, et tema pilet on pooleli, kuid teil on mahajäämus ja te töötate selle nimel, et see võimalikult kiiresti kätte saada.
- Triaaž ja prioriteedid. Mõnikord on siiski vaja pileteid tähtsuse alusel eristada. Ärge kartke seda teha sõltuvalt pileti olemusest.
- Jagage probleemi. See on valikuline, kuid kui te ei kavatse luua kogukonnapõhiseid tugifoorumeid, pakkuge ajaveebi kaudu paranduste, värskenduste jms jagamist.
Jällegi, see on just see, kuidas ma seda oma kogemuse põhjal käsitleksin, kuid see ei pruugi olla viis seda teha.
Kui aga otsustate kogukonnapõhiseid tugifoorumeid mitte kasutada, on see potentsiaalne viis nende mittekasutamise otsustamiseks.
Nii et kasutada neid või mitte?
Loodan, et neile, kellele see idee võib meeldida, annab see postitus piisavalt teadmisi, et nende tutvustamisel peatada.
Ma ei ütle, et need on alati halb mõte, kuid ma ütlen, et tuleb tõsiselt kaaluda, sest lõpuks võite tekitada teile ja teie meeskonnale rohkem toetuspileteid kui vaja.