tinowa
(Kulturkapital)
1
rstockm
(Ralf Stockmann)
2
Anatomie von problematischen Support-Situationen
- Unklare Fehlerbeschreibungen
- bei klaren Fehlern (gut reproduzierbar)
- bei unklaren Fehlern (nicht reproduzierbar)
-
Strategie:
- Formulare für Bugs erstellen
- im direkten Dialog klären
- Support-Konferenz (öffentlich, Google Hangout)
- Fehlermeldungen aussagekräftig machen
- Anfrage, danach tot stellen -
- auch wenn eine Lösung angeboten wurde. War die erfolgreich?
- nicht reagieren auf notwendige Nachfragen
- Fragen auf Direktkanälen, nicht auf den dafür vorgesehenen…
- andere lernen nichts davon
- schwerer systematische Fehlerbilder bei mehreren Usern zu finden
- gleich an mehrere Supporter geschickt
-
Strategie:
- darauf drängen public zu machen
- Posting anonymisiert publizieren
- Fehler 42
- Doku nicht gelesen
- nicht verstanden / falsch angewandt
- Weitestgehendes Desintresse an Beta-Tests
- oder schnell abflachende Motivationskurve
- Feature Request
- Feature gibt es schon, ist aber schlecht dokumentiert oder schlecht zu finden
- Keine Reaktion der Entwickler
- Fehler werden gar nicht gemeldet
- es wird versucht selbst das “Problem” zu lösen
- oder an falschen Ansprechpartner
-
Strategien:
- Menschen, denen man gar nicht so gerne helfen möchte
- Tonfall, Erwartungshaltung, Ansprache
- Egoistisch (kommerziell) oder weltanschaulich problematisch
- Dokumentation
- wie ist die zu finden
- wie adressatengerecht ist die formuliert
- welche Dokumentation ist die richtige?
- Screencast (veraltet schnell)
- DokuWiki (wenig hilfreich bei komplexen Abläufen)
- Blog mit sehr eng gefassten Themen
- Animated Gifs
- Tooltips (in html nachgebaut?)
- Splash-Screen beim ersten Start
- Qualitätsstandards für den Support
- Reaktionszeiten
- Klassifizierung von Bug, Featurerequest etc.
- Gründe geben, warum man kein Feedback bekommt
- die falschen Leute geben (fehlerhaften Support)
- Voting-System für hilfreichste Antwort
1 „Gefällt mir“