W zeszłym tygodniu – i w ten weekend – czytałem komentarze pod postami Pippina Williamsona na temat decyzji jego firmy o dostosowaniu cen w Easy Digital Downloads (a dla ciekawskich, cieszę się z tego).
To rozmowa sama w sobie i jest długi wątek komentarzy, który moim zdaniem jest wart przeczytania dla każdego zaangażowanego w rozwój produktu WordPess, ale dygresję, ponieważ o to właśnie chodzi w tym poście.
Niektórzy czytelnicy pozostawili komentarze w kanale komentarzy, omawiając pojęcie społecznościowych forów wsparcia. Warto przeczytać cały wątek, ale:
- EDD używane do oferowania forów wsparcia opartych na społeczności (oprócz innego wsparcia),
- Stworzyłem i pracowałem nad produktami, które miały fora wsparcia oparte na społeczności
Patrząc wstecz, absolutnie nie sądzę, że oferowanie ich przez sklep z produktami opartymi na WordPressie jest mądrą decyzją. Mam swoje powody, rozwinę, ale chcę jasno powiedzieć, że ograniczam to ścisłe do WordPressa, ponieważ to jest to, co wiem.
Nie mogę wypowiadać się w imieniu innych segmentów naszej branży.
Fora wsparcia oparte na społeczności
Lata temu pracowałem ze świetnym zespołem i zbudowaliśmy solidny produkt i nadal jestem dumny z pracy, którą wykonaliśmy. W tym czasie jedną z rzeczy, które początkowo oferowaliśmy, były społecznościowe fora wsparcia.
Na początku wydawało się to mieć sens: kiedy nie odpowiadaliśmy na zgłoszenia do pomocy technicznej (co zdarzało się częściej niż nie – po prostu zapytaj Chrisa lub Michaela ), inni pomagali sobie nawzajem na forach.
Pierwsze fora wsparcia oparte na społeczności, z których korzystaliśmy.
Wygląda na wygraną, prawda? Twoi klienci pomagają innym klientom, a Twój zespół pomaga klientom z większymi problemami.
W idealnej sytuacji tak może się to potoczyć. Ale świat nie jest idealną sytuacją, a zatem nie ma też charakteru społecznościowych forów wsparcia.
Tak więc, naturalnie, rodzi się pytanie: co jest nie tak z forami wsparcia opartymi na społeczności?
Co tak naprawdę dzieje się na forach
Jeśli masz ludzi, którzy pomagają ludziom rozwiązać problem za pomocą płatnego produktu, który zapewnia wsparcie, a wsparcie pochodzi od kogoś innego niż dostawca, wtedy patrzysz na ludzi, którzy:
- nie wiem jak powstał produkt,
- możesz dostarczać rozwiązania z miejsca o mniejszym doświadczeniu niż Ty lub Twój zespół programistów,
- mogą być udzielane po prostu błędne odpowiedzi z braku doświadczenia.
Spójrz na to w ten sposób: Masz produkt, który zbudowałeś Ty lub Ty i zespół. Zostało przetestowane, ocenione, przetestowane, ocenione, wdrożone, a sprzedaż jest w toku.
Wtedy ktoś napotyka problem lub błąd. Kupili pomoc techniczną, więc przesyłają zgłoszenie, które umieszcza w kolejce o nieokreślonej długości. Nie odbierają odpowiedzi tak szybko, jak chcą, więc pytają kogoś na forach. Dostają odpowiedź, modyfikują podstawowy kod, działa, więc są szczęśliwi.
Następnie Ty lub Twój zespół wrócicie do pierwotnego pytania o pomoc i znaleźli uzasadniony błąd. To świetnie, ponieważ pozwala podnieść jakość oprogramowania.
Ale zmienili podstawowy kod, więc każde rozwiązanie, które oferujesz, prawdopodobnie spotka się z „Dzięki, ale udało mi się rozwiązać".
Ale to wszystko źle rozwiązane.
W zależności od charakteru sprzedawanego produktu może to spowodować błędy w zabezpieczeniach lub inne problemy, o których po prostu nie zdajesz sobie sprawy, dopóki nie zdiagnozujesz problemu.
Teraz jednak musisz zapytać użytkownika, co zrobił, aby naprawić swój problem, skontrolować ten kod, a następnie przeprowadzić audyt swojego kodu.
Ostatecznie, do czego to służy?
- Użytkownicy pomagający użytkownikom mogą tworzyć nieprawidłowe rozwiązania,
- Użytkownicy pomagający użytkownikom mogą generować więcej lub dłużej zgłoszeń serwisowych niż jest to konieczne,
- Firma jest potencjalnie opodatkowana większą ilością pracy, niż jest to konieczne, aby naprawić błąd lub dodać funkcję.
- I więcej.
Teraz nie jestem tym, który próbuje rozplanować problem, a potem nie dostarcza rozwiązania; jednak nie mogę zapewnić rozwiązania dla wszystkich firm. Kto może? Nie znam modelu; Nie znam sposobu działania, nie znam budowy, nie znam wielu rzeczy.
Jeden sposób na rozwiązanie tego?
Ale wiem, że fora wsparcia oparte na społeczności mogą generować więcej problemów niż nie, nawet jeśli od samego początku brzmi to jak zaleta i punkt sprzedaży.
Bycie po drugiej stronie może jednak zmienić tę perspektywę.
Więc sposób, w jaki podchodzę do tego problemu, jest taki:
- Wsparcie odbywa się na zasadzie „jeden do jednego”. Klienci przesyłają swoje zgłoszenia do zespołu zajmującego się problemami za pośrednictwem aplikacji takiej jak HelpScout, a następnie otrzymują wsparcie od zespołu.
- Odpowiedz natychmiast (tak jakby). Poinformuj klienta, że jest w kolejce do zgłoszenia, ale są zaległości i pracujesz, aby dostać się do niego JAK NAJSZYBCIEJ.
- Segregacja i ustalanie priorytetów. Czasami jednak konieczne jest sortowanie biletów według ważności. Nie bój się tego robić w zależności od charakteru biletu.
- Podziel się problemem. Jest to opcjonalne, ale jeśli nie będziesz mieć forów pomocy opartych na społeczności, zaproponuj udostępnianie poprawek, aktualizacji i tak dalej za pośrednictwem bloga.
Ponownie, tak właśnie bym to rozwiązał w oparciu o moje doświadczenie, ale niekoniecznie jest to sposób na zrobienie tego.
Jeśli jednak zdecydujesz się nie korzystać z forów wsparcia opartych na społeczności, jest to potencjalny sposób radzenia sobie z rezygnacją z korzystania z jednego z nich.
Więc używaj ich czy nie?
Dla tych, którzy mogą być zabawni, mam nadzieję, że ten post dostarczy wystarczająco dużo informacji, aby dać ci chwilę zastanowienia się nad ich wprowadzeniem.
Nie mówię, że zawsze są złym pomysłem, ale mówię, że należy wziąć pod uwagę kilka poważnych rozważań, ponieważ ostatecznie możesz sprawić, że ty i twój zespół będziecie otrzymywać więcej zgłoszeń do wsparcia niż to konieczne.