In vier Schritten zum aussagekräftigen Kundenfeedback!

Von Protonet Team. Veröffentlicht 17. April 2015.

17. April 2015

Um sicherzustellen, dass unsere Server die perfekte Lösung für die alltäglichen Probleme unserer Kunden darstellen, ist ein enger Kontakt zu diesen das A und O.

Wie vor einigen Wochen im Blog bereits erwähnt, verzichten wir bewusst auf das branchenübliche Tracking der Nutzung unserer Server. Deshalb können wir nicht auf direkte Daten zurückgreifen, um SOUL zu verbessern. Um unsere Product Roadmap so gut wie möglich an die Bedürfnisse unserer Kunden anzupassen, suchen wir also den Austausch mit ihnen.
Ende 2014 haben wir eine Umfrage erstellt, welche uns einen groben Überblick darüber verschafft hat, in welchen Bereichen unsere Boxen zum Einsatz kommen und welche Aspekte an SOUL noch verbesserungsfähig sind. Detailliertere Einblicke kann uns eine quantitative Umfrage aber leider nicht bieten.

Louis führt Feedbackgespräche mit Protonet Kunden

Louis führt Feedbackgespräche mit Protonet Kunden

Um genau herauszufinden, was SOUL noch fehlt, hat Louis, unser Haus und Hof Psychologe und Werkstudent, explorative Telefongespräche mit einigen Benutzern geführt, welche in verschiedenen Bereichen die genaue Benutzung beleuchten. Diese teilen sich in 4 Arbeitsschritte auf.

1. Vorbereitung & Leitfaden

Das persönliche Gespräch am Telefon gibt den Benutzern die Möglichkeit, ihre Antworten frei zu formulieren. Dadurch lässt sich das Feedback nicht ganz so leicht messbar machen, wie bei beispielsweise einem Multiple-Choice-Test.
Um dennoch eine gewisse Vergleichbarkeit zu gewährleisten, ist ein Leitfaden nötig. Dieser muss gewisse Kriterien erfüllen, um eine hohe Test-Güte zu garantieren.

Objektivität

Zuallererst muss die Objektivität des Tests gegeben sein, das heißt die Unabhängigkeit der Ergebnisse von situationsspezifischen Faktoren wie, zum Beispiel der Formulierung der Fragen durch unseren Mitarbeiter. Dies wird gewährleistet, indem die Interviews immer nach einem klar festgelegten Schema durchgeführt werden.

Reliabilität

Die Reliabilität eines Tests gibt an, wie genau ein Test die Ausprägung einer erhobenen Eigenschaft misst. In unserem Fall bestimmt die Reliabilität, wie genau das Interview die tatsächliche Zufriedenheit der Benutzer in Bezug auf die einzelnen Features von SOUL misst. Eine hohe Reliabilität wäre zum Beispiel gegeben, wenn der Benutzer an zwei verschiedenen Zeitpunkten jeweils die gleichen Antworten gibt. Natürlich führen wir nicht zweimal die gleiche Befragung durch, sondern garantieren hohe Reliabilität durch bestimmte Techniken, zum Beispiel die Wiederholung einer Frage in umformulierter Form.

Validität

Eine hohe Validität eines Tests besagt, dass der Test auch genau das misst, was er zu messen vorgibt. Die Frage nach der Farbe der Kaffeemaschine hat zum Beispiel nichts in einem Interview bezüglich der Zufriedenheit mit unserem Produkt zu suchen, daher verringert sie die Validität des Interviews.
Diese drei von Gustav Lienert 1989 formulierten Hauptgütekriterien sind die Stützpfeiler, wenn es darum geht, ein Testergebnis aussagekräftig zu machen. Und Aussagekraft ist zwingend notwendig, da wir von einer kleinen Stichprobe – ca. 15 Kommunikationsagenturen, welche unsere Box benutzen – auf die Grundgesamtheit aller Kommunikationsagenturen schließen möchten.

2. Kontaktaufnahme

Nach abgeschlossener Vorbereitung geht es in die heiße Phase. Dank des ausgiebigen Kontaktes zwischen unserem Support, dem Projektmanagement-Team und unseren Kunden stehen wir zum Glück nicht ganz ohne Vorwissen da, was es uns um einiges leichter macht, den Kontakt zu euch herzustellen.
Bei der Durchführung von Feedback-Interviews ist es wichtig, sich potenzielle Störvariablen bewusst zu machen und sie gezielt zu umgehen. Hier gibt es verschiedene Bereiche, in denen diese sogenannten „BIAS‘“ auftreten können.
Eine der häufigsten Quellen beeinflussender Variablen findet sich im Verhalten des Interviewers. Um Vergleichbarkeit herzustellen, ist es wichtig, dass unser Mitarbeiter sich in jedem Telefonat gleich verhält. Das wird zum Teil durch den Leitfaden garantiert, zum Teil muss hier aber vom Interviewer selbst auf bestimmte Verhaltensweisen, zum Beispiel das Stellen von Suggestivfragen wie: „Ihr habt doch bestimmt auch schon die neue Backup-Funktion bemerkt, oder?“, geachtet werden.
Die Durchführung unserer Interviews dauerte im Schnitt 30 Minuten und war sehr erfolgreich. Wir haben unglaublich viel über die Nutzung unserer Server in Agenturen herausgefunden. Wir haben natürlich immer direkt mitgeschrieben, was uns berichtet wurde. Sicher ist sicher.

3. Auswertung

Mit der Durchführung der Interviews ist das Projekt natürlich noch nicht abgeschlossen. Es müssen Handlungen folgen. Um herauszufinden, was getan werden sollte, wird der Input analysiert und anschließend das Ergebnis interpretiert.
Bei der Auswertung der Interviews muss man sehr aufmerksam vorgehen. Hier helfen die Mitschriften ungemein. Unsere Produkte sollen Effizienz im Team steigern, gerade deshalb ist es wichtig, genau zu erkennen, welche Probleme sie bereits lösen und wo es noch hapert.
Wir haben zwar viele konkrete Verbesserungswünsche in den Interviews mitgeteilt bekommen, manchmal muss man diese aber auch zwischen den Zeilen lesen. Ist ein Benutzer nicht zufrieden mit der Finder-Einbindung, muss man nachhaken oder direkt im Gespräch konkrete Lösungsvorschläge machen, um genau herauszufinden, was wir verbessern können – ein allgemeines „Einbindung verbessern“ tut es hier nicht.
Hat man nun eine Liste von Verbesserungswünschen herausgefiltert, ist diese bei 15 Interviews wahrscheinlich ein bisschen länger. Um herauszufinden, welche dieser Probleme am dringendsten nach einer Lösung verlangen, vergleicht man also die geführten Interviews. Die am häufigsten aufgeführten Wünsche sind erst einmal die wichtigsten. Allerdings sollte man diese natürlich in Hinblick auf die Agenturen betrachten – die Größe der Firma hat zum Beispiel einen großen Einfluss darauf, wie wichtig der integrierte Kalender für die Mitarbeiter ist. Um solche Störvariablen auszuschließen, zieht man normalerweise aus der Grundgesamtheit der Agenturen, welche unseren Server benutzen, eine sogenannte Zufallsstichprobe, um zu gewährleisten, dass die Stichprobe generalisierbar ist. Da wir aber noch eine recht junge Firma sind und unsere Grundgesamtheit der Agenturen, welche unsere Server benutzen, überschaubar ist, stellt sich das als schwierig dar. Dementsprechend ist bei der Auswertung darauf zu achten, dass man zwar bestimmte Probleme erkennt, diese aber nicht zwingend in jeder Agentur auftreten werden. Die Ziehung einer Stichprobe und ihre Generalisierbarkeit werden einfacher, je größer unser Kundenpool wird.

4. Interpretation der Daten

Der letzte Schritt unseres Projektes beinhaltet die Interpretation der Daten. Dabei gehen wir in 3 Schritten vor:

➔ Zuerst schauen wir uns die Auswertung an und überlegen uns, auf welche Weise die dargestellten Probleme im Alltag unserer Kunden am besten gelöst werden können. Das geschieht im Team, denn nur mit Input aus jedem Bereich können langfristige Lösungen erarbeitet werden.
➔ Haben wir so die Kernprobleme erkannt und uns Lösungen dafür überlegt, geht es an die Umsetzung. Sobald die Lösungsvorschläge umgesetzt sind, werden sie in das nächste Server-Update integriert und gehen auf Reisen, um eure Server auf den neuesten Stand zu bringen.
➔ Nach dem Shipping des Updates könnte man denken, das Projekt ist beendet. Ein wichtiger Punkt fehlt allerdings noch. Auch wenn wir von unseren Lösungen vollends überzeugt sind, kann es immer sein, dass wir etwas vergessen, nicht verstanden oder schlichtweg nicht richtig gelöst haben. Der enge Kontakt zu unseren Kunden bricht hier also nicht ab. Wir bleiben weiter dran und sammeln regelmäßig Feedback, um unsere Server zu den perfektionisierten Lösungen für euren Alltag zu machen, die uns allen vorschweben.

Falls wir uns noch nicht bei euch gemeldet haben, euch aber etwas aufgefallen ist, was ihr gerne verbessert hättet, schreibt uns einfach! Am besten direkt eine E-Mail an jan@protonet.info, wir freuen uns immer über Input.