Wie ihr das Beste aus eurem Kundendienst herausholt

Die Kolleginnen und Kollegen aus dem Kundendienst sind immer eine gute Quelle für Nutzerfeedback, neue Ideen, Anforderungen und auch Probleme, sprechen sie doch jeden Tag stundenlang mit den Nutzern. Allerdings sind Mitarbeiter im Kundendienst in den seltensten Fällen ausgebildete Anforderungsanalysten, sodass die Informationen, die beim Produktmanager ankommen, häufig nur bedingt für die Weiterentwicklung herangezogen werden können.

Das dies sehr schade ist, liegt auf der Hand. Im Folgenden möchten wir euch daher vorstellen, wie wir eine Schulung mit unseren Kolleginnen und Kollegen im Kundendienst durchgeführt haben, um an bessere Informationen über die Ziele und Bedürfnisse unserer Nutzer zu kommen.

Das Problem

Ihr kennt sicherlich die Cartoons von projectcartoon.com, in denen gezeigt wird, was bei der Erhebung von Nutzeranforderungen alles schief gehen kann. In etwas modifizierter Form sieht das Problem für unseren konkreten Fall wie folgt aus:

Der Cartoon zeigt die drei Schwachstellen im Prozess:

  1. Der Nutzer kann nicht richtig artikulieren, was er wirklich benötigt
  2. Der Supportmitarbeiter hält das fest, was er vom Nutzer verstanden hat
  3. Der PO wiederum muss die Informationen aus dem Support interpretieren und versuchen herauszufinden, was der Nutzer wirklich möchte

Dass bei diesem Stille-Post-Spiel etwas ganz anderes herauskommt, als das was der Nutzer wirklich benötigt, ist nachvollziehbar. Aus diesem Grund beschlossen wir, einen Workshop mit unseren Kolleginnen und Kollegen aus dem Kundendienst durchzuführen. Ziel des Workshops war es herauszufinden, wo man ansetzen, damit Nutzeranforderungen künftig besser aufgenommen und an den PO kommuniziert werden.

Gründe für die Probleme

Wir begannen den Workshop mit ein paar einleitenden Worten und der Wertschätzung unserer Kolleginnen und Kollegen. Denn sie sind nun mal das Ohr am Nutzer und leisten jeden Tag einen fantastischen Job, sich die Probleme (und manchmal auch Beleidigungen) der Nutzer anzuhören, darauf einzugehen und Lösungen für die Probleme zu finden.

Als nächstes kamen wir auf die Probleme aus unserer Sicht zu sprechen:

  1. Immer wieder kommen die Informationen nicht oder nicht in geeigneter Form beim PO an, was zur Folge hat, dass Probleme, Anforderungen und Wünsche nicht ihren Weg in den Backlog und die Umsetzung finden
  2. Hierdurch gelangen mögliche Verbesserungen nicht in die Produkte – und im Zweifel bekommen wir so unzufriedene Nutzer, die sich im Support melden oder die im schlimmsten Fall unseren Produkten irgendwann ganz den Rücken zukehren

Da die Probleme auch unseren Kolleginnen und Kollegen bekannt waren und sie natürlich ebenfalls an einer Verbesserung der Situation interessiert waren, gab es auch keine große Diskussion über den Sachverhalt. Stattdessen konnten wir uns ganz den Hintergründen widmen, die für den Sachverhalt verantwortlich waren.

Aus unserer Sicht waren dies folgende Gründe:

  • Wichtige Hintergrundinformationen über die Nutzer und deren Ziele fehlten häufig in den Tickets.
  • Die Tickets waren teilweise nicht verständlich beschrieben. Beispielsweise wurden immer wieder in Ticket-Beschreibungen nur die E-Mails oder sonstige Korrespondenz mit den Nutzern 1:1 kopiert und nicht weiter aufbereitet.
  • Oft war schwer abzuschätzen, wie groß der Anteil an Nutzern wirklich ist, die ein Problem bzw. einen Wunsch haben.
  • Teilweise wurden Themen mehrfach in Tickets aufgenommen, was zu einem unüberschaubaren Backlog führte.
  • Zu manchen Problem gab es auf der anderen Seite gar keine Tickets.

Die Folge dessen war klar: Als PO muss man viel interpretieren oder nachfragen um überhaupt den Sinn eines Tickets zu verstehen und dann dessen Relevanz einschätzen zu können. Diesen Aufwand scheuen die POs häufig, weil sie sowieso chronisch zu viel zu tun haben.

Im Gespräch mit den Kolleginnen und Kollegen kamen jedoch weitere spannende Gründe ans Licht, die wir so überhaupt nicht auf dem Schirm hatten:

  • Man hatte sich an die Probleme „gewöhnt“ und einfache Workarounds entwickelt, weshalb die Probleme gar nicht mehr gemeldet wurden.
  • Es gab viele „historische“ Probleme, zu denen in der Vergangenheit es Entscheidungen gab, die nicht mehr hinterfragt oder neu priorisiert wurden.
  • Teilweise gab es auch schlichtweg zu wenig direkte Kommunikation zwischen den POs und dem Support, weshalb Tickets ohne Rückfragen geschlossen und nicht weiter bearbeitet wurden.

Der Dialog mit den Kolleginnen und Kollegen war wie gesagt sehr erhellend, wurden doch Themen benannt, an die wir so nicht gedacht hätten.

Nutzer-Ziele verstehen

Teil 2 unseres Workshops setzte sich dann damit auseinander, wie die Kolleginnen und Kollegen im Kundendienst besser verstehen und aufnehmen können, was die tatsächlichen Ziele und Bedürfnisse der Nutzer sind. Wie gesagt, als Mitarbeiter im Kundendienst ist man in der Regel kein ausgebildeter Anforderungsanalyst oder ähnliches. Trotzdem ist es wichtig, dass auch hier ein besseres Verständnis über den Unterschied zwischen Wünschen und Bedürfnissen der Nutzer hergestellt wird.

Der Unterschied zwischen Zielen, Anforderungen und Wünschen

Wir fingen also an mit dem uns wohlbekannten (angeblichen) Zitat von Henry Ford:

So sehr einem dieses Zitat in Produkt- und UX-Kreisen vielleicht auch zum Halse raushängt: unsere Kolleginnen und Kollegen hatten es noch nie gehört! Und egal, ob Ford es wirklich so gesagt hat oder nicht, das Zitat ist schön plakativ, und so schmunzelten auch unsere Kolleginnen und Kollegen und verstanden, worauf wir hinaus wollten.

Als nächstes besprachen wir ein tatsächliches Ticket aus unserem Backlog mit einer „Nutzeranforderung“, die so im Kundendienst aufgenommen wurde und anhand derer man schön sehen konnte, wie Wunsch und tatsächliches Ziel auseinander klaffen können.

Auch wenn ihr ohne Kontext jetzt inhaltlich vielleicht nicht ganz so viel mit der Anforderung anfangen könnt, seht ihr vielleicht schon anhand der Beschreibung was unser Problem damit gewesen sein könnte. Die Anforderung lautete wie folgt:

„Der Nutzer möchte die angezeigten Konten im Container ‚Kontoliste‘ auf der Übersicht selber konfigurieren können.“

Man erkennt klar, dass hier ein Nutzer einen Wunsch geäußert hatte, der so ohne zu hinterfragen 1:1 aufgenommen wurde. Wir diskutierten in der Folge also, was der Nutzer durch Äußerung des Wunsches erreichen wollte. Heraus kam dabei ein ganz anderes Thema:

„Nutzer, die eine Urlaubsvertretung für einen Kollegen machen müssen, möchten sich gezielt die Konten des Kollegen anschauen können, damit sie mit diesen Konten arbeiten können.“

Aha, kein Wunsch mehr nach Konfiguration, sondern nach einer Anzeige relevanter Informationen!

Im Folgenden erklärten wir den Kolleginnen und Kollegen den Unterschied zwischen den folgenden Begriffen (u.a. auf Basis der ISO-Norm 9241):

  • Nutzer-Ziele: Was der Nutzer eigentlich erreichen möchte, das angestrebte Arbeitsergebnis
  • Aufgabe: Die Menge an Aktivitäten, die zur Erreichung eines Ziels unternommen werden
  • Probleme: Hindernisse, mit denen sich der Nutzer auf dem Weg zur Erreichung seiner Ziele konfrontiert sieht
  • Wünsche und Idee: Lösungen zum Erledigen der Aufgaben oder zum Lösen der Probleme, basierend auf dem Erfahrungsschatz und der Vorstellungskraft des Nutzers
  • Erfordernisse: Voraussetzungen, die für den Nutzer notwendig sind, seine Ziel zu erreichen
  • Nutzungsanforderungen: Ergeben sich aus dem Ziel, den Problemen und den Erfordernissen. Die Lösung sollte die Anforderungen erfüllen.
  • Mögliche Lösungen: Der Lösungsraum mit vielen verschiedenen Lösungen. Unser Job ist es, die beste Lösung für das Ziel zu identifizieren.

Auf das konkrete Beispiel bezogen könnte es also wie folgt aussehen:

  • Nutzer-Ziel: Urlaubsvertretung für den Kollegen machen.
  • Aufgabe: Die Konten des Kollegen verwalten
  • Problem: In der Kontenliste sind zu viele Konten gemischt enthalten, sodass schwer zu erkennen ist, welches die für die Vertretung relevanten Konten sind
  • Wunsch: Der Nutzer wünscht sich eine Konfigurationsmöglichkeit für die Kontenliste
  • Erfordernis: Der Nutzer muss während der Abwesenheit des Kollegen in der Lage sein, dessen Konten einzusehen.
  • Nutzungsanforderung: Die Anwendung soll es einer Urlaubsvertretung ermöglichen, während der Abwesenheit eines Kollegen, eine separate Liste mit den Konten des zu vertretenden Kollegen einzusehen.
  • Mögliche Lösungen:
    • Eine Kontenliste, die ich mir gezielt konfigurieren kann
    • Eine Urlaubsvertretungs-Funktion
    • Etc.

Anhand des Beispiels konnten wir unseren Kolleginnen und Kollegen also schön aufzeigen, dass der Wunsch des Nutzers vielleicht nicht die einzige mögliche Lösung für dessen Ziel und Problem ist, sondern dass die erweiterten Informationen stattdessen dabei helfen, ganz neue (und vielleicht bessere) Lösungen zu erdenken und entdecken. Wichtig ist es dafür, dass schon im Kundendienst versucht wird, die Ziele und Erfordernisse der Nutzer bestmöglich zu klären und zu dokumentieren, damit sie anschließend für die Lösungsfindung genutzt werden können.

Doch wie klärt man im Kundendienst die Ziele und Erfordernisse der Nutzer am besten? Das war der nächste Teil unseres Workshops.

Wie man aus Nutzern die richtigen Informationen herausbekommt

Vielen von euch, die häufiger User Interviews selbst durchführen oder zumindest dabei zuschauen, ist vermutlich bekannt, wie man richtig nachfragt. Doch unseren Kolleginnen und Kollegen im Kundendienst hatten nie eine Ausbildung zu diesem Thema bekommen, weshalb wir den nächsten Teil des Workshops ganz dem Thema „Fragen stellen“ widmeten.

Zunächst sprachen wir über Fragetechniken und wie man Fragen nicht formulieren sollte (Suggestiv-Fragen, geschlossene Fragen), sondern was man stattdessen fragen sollte (offene Fragen mit „W“, neutrale Fragen).

Anschließend kamen wir auf eine spezielle Fragemethode zu sprechen, welche die meisten von euch sicherlich kennen und hoffentlich auch selber nutzen: den „5 Why“ von Taiichi Ohno von Toyota. Diese Methode übten wir dann ein paar Mal anhand realer Beispiele, die bei uns im Kundendienst aufgekommen waren – mit sehr erhellenden Erkenntnissen.

Nutzer-Ziele dokumentieren

Nachdem wir mehrmals mit der „5 Why“ Methode geübt hatten und den Kolleginnen und Kollegen die Macht dieser Vorgehensweise klar geworden war, widmeten wir uns abschließend noch der Frage, wie und wo die Nutzer-Ziele eigentlich idealerweise dokumentiert werden sollten. Wie anfänglich beschrieben war ein Problem, dass die Art der Erfassung optimiert werden konnte.

Dokumentieren, aber wo?

Doch ein weiteres Problem war die Frage nach dem „Wo“. Denn jeder PO kennt vermutlich das Problem eines immer länger werdenden Product Backlogs, wenn jede Idee, jeder Wunsch und jede Anforderung gleich im Backlog aufgenommen wird. Bei älteren Produkten ist dann ein Backlog mit mehreren hundert Items keine Seltenheit mehr – was jedoch zur Folge hat, dass der Backlog nicht mehr zu pflegen ist.

Aus diesem Grund schlugen wir den Kolleginnen und Kollegen vor, dass wir ein eigenes Support-Board in Jira anlegen könnten, in dem alle neuen Themen gesammelt werden könnten. Wichtig ist hierbei natürlich, dass dieses Support-Board regelmäßig besprochen und gepflegt wird, damit hier nicht dasselbe Problem auftritt. Wir verabredeten also, dass sich der PO mit den Kundendienst-Kollegen regelmäßig (ca. 1x pro Monat) zusammensetzt und die neuen Themen durchgeht, bespricht und falls möglich direkt priorisiert (oder ggf. auch entfernt).

So lösten wir gleichzeitig das von den Kolleginnen und Kollegen genannte Kommunikations-Problem, denn die Kommunikation zwischen PO und Kundendienst erfolgt so automatisch auf eine anderen Basis.

Dokumentieren, aber wie?

Nachdem die Frage nach dem „Wo“ geklärt war, sprachen wir nochmals über das „Wie“. Wir schauten uns an, ob und wenn ja welche Ticket-Vorlagen bisher genutzt wurden und wie wir diese optimieren können. Schließlich einigten wir uns auf zwei verschiedene Vorlagen.

Die Vorlagen für Anforderungen und Ziele soll den Kolleginnen und Kollegen aus dem Kundendienst helfen, die durch Nachfragen erfassten Informationen so zu transportieren, dass der PO verstehen kann, welcher Nutzer die Anforderung hat, was konkret das Ziel ist und wie relevant das Thema ist. Hierfür definierten wir die folgende Vorlage:

  • Nutzer-Typ: Um welche(n) Nutzer(-Typ) geht es?
  • Nutzer-Ziel: Was ist das Ziel der Nutzer, was möchten sie erreichen?
  • Erfordernisse: Was benötigen die Nutzer, um das Ziel zu erreichen?
  • Barrieren: Welche Hindernisse stehen den Nutzern aktuell bei der Zielerreichung im Weg?
  • Relevanz: Wie viele Nutzer haben dasselbe oder ähnliche Probleme beim gleichen Ziel genannt?
  • Quelle: Wo bzw. in welchem Kontext wurde der Wunsch des Kunden bzw. die Anforderung gemeldet?
  • Ideen: Welche Lösungsideen haben die Nutzer ggf. geäußert?

Auch für Fehler und Bugs verständigten wir uns auf eine Vorlage, die insbesondere dabei helfen soll, das Problem zu verstehen und zu reproduzieren und die dabei unterstützen soll, die Relevanz des Bugs einzuschätzen:

  • IST-Zustand / Problem: Eine verständliche Beschreibung des aktuellen (fehlerhaften) Zustandes bzw. des Problems
  • Schweregrad / Relevanz: Informationen zum Schweregrad (z.B. Kritisch, Hoch, Mittel, Niedrig, Kosmetisch) und zur Auftrittswahrscheinlichkeit, bzw. wie viele Nutzer vom Problem betroffen sind
  • Quelle: Worüber wurde der Fehler / das Problem gemeldet? Z.B. Support-Ticket
  • Systemumgebung: Tritt der Fehler generell auf, oder nur unter einer bestimmten Konfiguration (z.B. Windows 8, Auflösung 1024×768)
  • Schritte zur Reproduktion: Kann der Fehler reproduziert werden? Wenn ja, wie?
  • SOLL-Zustand: Was ist das wünschenswerte Verhalten?

Diese beiden Vorlagen haben wir anschließend in Jira als Beschreibungsvorlagen angelegt, sodass beim Anlegen eines neuen Tickets gleich die benötigten Informationen angezeigt werden.

Neben den Vorlagen besprachen wir noch weitere Themen, die aus unserer Sicht nötig waren, um die Tickets so hilfreich und verständlich wie möglich zu machen:

  • Der Titel der Tickets sollte kurz und prägnant sein, damit man schon beim Überfliegen des Support-Boards versteht, worum es geht.
  • Kunden-E-Mails, Texte aus Support-Tickets können in den Kommentaren dokumentiert werden, aber nicht in der Beschreibung.
  • Wenn möglich sollen alle Anfragen (schriftlich wie telefonisch), Foren-Beiträge o.ä. bei den jeweiligen Tickets gesammelt werden, damit man die Themen hierüber ein besseres quantifizieren und außerdem bei Bedarf Details besser nachvollziehen kann.
  • Das Anlegen von mehreren Tickets zu einem Thema sollte vermieden werden. Stattdessen sollte immer erst im Support-Board geprüft werden, ob es schon ein (ähnliches) Ticket zum selben Sachverhalt gibt.

Quantifizierung der Anforderungen

Das letzte Thema, welches wir in unserem Workshop besprachen, war die Frage wie man die Relevanz von Anforderungen und Bugs am besten einschätzen kann.

Denn ihr kennt das Problem: jedes Team hat nur begrenzte Ressourcen für die Weiterentwicklung der Produkte, aber es gibt immer viele Ideen, was man machen kann. Das Ziel eines jeden Produkt-Teams ist es daher, möglichst große Mehrwerte für möglichst viele Nutzer zu erzeugen. Dazu ist es wichtig zu wissen, wie relevant eine Anforderung ist oder wie schwer ein Fehler wiegt.

Zur Bewertung von Anforderungen, Ideen und Wünschen definierten wir daher die folgende Kriterien, die zur Bewertung der Relevanz herangezogen werden können:

  • Wie viele Nutzer-Anfragen gibt es zu dem Thema? Handelt es sich um eine einzelne Anfrage, oder kommt das Thema immer wieder in E-Mails, Telefonaten oder im Forum hoch?
  • Wie groß wäre die Auswirkung / der Mehrwert des Themas? Wie viele Nutzer würden von der Änderung profitieren? Alle oder nur spezielle Zielgruppen? Welche Zielgruppe / Persona würde von den Änderungen profitieren? Wäre der Nutzen für die Zielgruppe hoch, mittel, klein?
  • Welcher Art wäre der Mehrwert? Zeit sparen, Geld sparen, Bequemlichkeit, Kontrolle behalten, Fehlervermeidung, etc.

Für Fehler und Bugs einigten wir uns auf die folgenden Kriterien:

  • Wie ist der Schweregrad des Fehlers?
    • Kritisch – Der Fehler kann zu einem Totalausfall oder Teilausfall des Systems führen. Es kommt zu Datenverlust / Datenzerstörung. Es gibt keinen Weg, dies zu vermeiden.
    • Hoch – Die Folgen entsprechen im Wesentlichen den unter „Kritisch“ beschriebenen Folgen, aber es gibt einen Workaround.
    • Mittel – Das System produziert fehlerhafte Ergebnisse. Es kommt aber nicht zum Ausfall oder Datenverlust.
    • Niedrig – Das System liefert teilweise fehlerhafte Ergebnisse. Es kommt nicht zum Ausfall oder Datenverlust. Es gibt eine Möglichkeit, die Fehler zu umgehen.
    • Kosmetisch – Das Aussehen bzw. das Verhalten der Software sollte verbessert werden
  • Wie ist die Auftrittswahrscheinlichkeit? z.B. Bei jeder Nutzung, häufig, immer wieder, selten
  • Wie hoch ist die Anzahl betroffener Nutzer? z.B. Alle, viele, einige, wenige? Hilfreich ist hier auch die Nennung von Rahmenbedingungen, in welchen Fällen Nutzer betroffen sind

Die Kolleginnen und Kollegen aus dem Kundendienst haben in der Regel ein gutes Gefühl dafür, wie häufig eine Anfrage ankommt oder wie schwerwiegend Fehler sind. Die oben genannten Anhaltspunkte sollen ihnen helfen, besser zu artikulieren und festzuhalten, wie relevant die Themen sind.

Fazit

Der Workshop und der damit verbundene Austausch mit unseren Kolleginnen und Kollegen aus dem Kundendienst hat uns allen viel Spaß gemacht und ein besseres gegenseitiges Verständnis der Bereiche geschaffen. Wir konnten uns auf ein gemeinsames Vorgehen verständigen, mit dem die Anforderungen, Wünsche, Ideen und Probleme unserer Nutzer künftig schneller, effizienter und auch besser bedient und gelöst werden können.

Denn letztlich wollen wir alle doch eines erreichen: unsere Nutzer zufriedenstellen und ihnen Produkte und Lösungen anbieten, die einen Mehrwert schaffen.

Eure Erfahrungen?

Zum Schluss würde uns noch interessieren, wie ihr mit eurem Kundendienst / Customer Support zusammenarbeitet. Habt ihr ein gemeinsames Vorgehen definiert, mit dem Anforderungen und Wünsche oder Probleme erfasst, dokumentiert und bearbeitet werden?

Wenn ja, lasst uns gerne an euren Erfahrungen teilhaben und schreibt einen Kommentar zu diesem Artikel!

Über Rainer Gibbert

Rainer ist Produktmanager mit großer Begeisterung für gute, Kunden-orientierte und wirtschaftlich erfolgreiche Produkte. Derzeit leitet er bei der Star Finanz GmbH in Hamburg den StarMoney Bereich und verantwortet dort die Produktentwicklung. Zuvor war Rainer u.a. bei REBELLE als Head of Product, bei Fielmann Ventures als Senior Produktmanager sowie bei OTTO als Produktmanager im E-Commerce Innovation Center tätig und leitete das User Insights Team bei der XING AG.

Über Sebastian Feige

Sebastian ist überzeugt davon, dass erstklassige Produkte genau dort entstehen können, wo eine methodische Herangehensweise zum Verstehen der Zielgruppe, ihrer Eigenschaften und Bedürfnisse einen integralen Bestandteil der Arbeitsabläufe darstellt. Derzeit kümmert er sich als UX Researcher um Anforderungsanalyse, Evaluation und strategische Ausrichtung der UX-Aktivitäten im Bereich Privatkundengeschäft der Star Finanz GmbH in Hamburg. Zuvor war Sebastian in Hamburg u.a. als UX-Consultant und Product Owner tätig.

5 Kommentare

  1. Robert B.

    Super spannendes und – für mich – mehr als aktuelles Thema.
    Habe tatsächlich dazu in 10min. meinen ersten Austausch mit unserem Kundenservice.

    Da hilft eure “Vorarbeit” als Richtlinie auf jeden Fall weiter. Danke!

    Eine Frage hätte ich aber tatsächlich noch:
    Bzgl. der Einschätzung wie viele Nutzer das Problem betrifft, hatten wir auch schon häufiger Diskussionen; meist ohne große Verbesserungsideen des bisherigen Prozesses.
    Wie geht ihr damit genau um? Wenn ein Supportticket angelegt wird, ist ja nicht sofort klar wie häufig dieses Problem im Kundenservice auftritt. Genauso stellt sich mir die Frage ob die Kollegen im Service die Tickets im Lauf der Zeit aktualisieren falls sich die Häufigkeit der Anfragen dazu geändert hat.


  2. Frank B.

    Als Customer Support Mitarbeiter sage ich tausend Dank für diesen Artikel! Zum vorherigen Kommentar: wir haben unser E-Mailsystem mit JIRA verbunden. E-Mails können dadurch mit JIRA-Tickets verknüpft werden. Die entsprechende JIRA Ticketnummer in einem extra dafür vorgesehenen Feld eingetragen und nach dem Absenden bzw. Abschließen der Mail zählt dann ein Counter in JIRA automatisch die verknüpften E-Mails. So wird automatisch quantifiziert. Auch in Textbausteinen für häufig gestellte Fragen können wir eine Ticketnummer fest hinterlegen. Über einen Link in JIRA können die POs dann andersherum mit entsprechendem Zugang zum E-Mailprogramm auch die verknüpften E-Mails inhaltlich einsehen. Einziger Nachteil: jede verknüpfte E-Mail erzeugt eine Benachrichtigung über ein Update im Ticket für alle Follower.


  3. Rainer Gibbert Artikelautor

    Hallo Robert, hallo Frank,

    schön, dass euch der Artikel gefällt und wir ein paar Denkanstöße geben konnten!

    Wir halten die Mitarbeiter im Support dazu an, dass sie die Tickets in Jira mit den entsprechenden Anfragen in unserem Helpdesk-Tool verknüpfen, sodass man pro Bug oder Idee sehen kann, wie viele und welche Anfragen dazu rein kommen. Dadurch bekommt man einerseits ein besseres Gefühl für die Relevanz und andererseits kann man bei Bedarf das “ungefilterte” Feedback nachlesen.

    Das Thema mit der Aktualisierung der Tickets ist natürlich ein guter Punkt. Bisher funktioniert das bei uns auch noch nicht ideal, da müssen wir noch ran. Aber ja, sinnvoll wäre es auf jeden Fall, dass die Tickets aktualisiert werden, wenn neue Erkenntnisse bzw. Anfragen dazu vorliegen.

    Viele Grüße
    Rainer


  4. Sven Bucher

    Ich denke, dass fehlende Infos in den Tickets ein häufiges Problem im technischen Kundendienst sind. Diese gilt es zu optimieren und die Probleme zu vermeiden. Wir haben bei der Auswahl des technischen Kundendienst darauf geachtet und haben seit jeher kein Problem damit. Vielen Dank für Ihren Beitrag!


  5. Paul Trabb

    Meine Frau fängt demnächst bei einem Telefonservice an. Ich werde ihr diesen Artikel zeigen, damit sie sehen kann, wie und wo die Nutzer-Ziele eigentlich idealerweise dokumentiert werden sollen. Vielen Dank für diesen hilfreichen Beitrag.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →