Best Practices

7. Juli 2021 | Michel Rienäcker

Eine Frage, die sich jeder im Kampf mit seiner IT-Software schon einmal gestellt und auf rettende Hilfe gehofft hat: Wie wird mein Support-Ticket und damit mein Problem am schnellsten bearbeitet? Das liegt ganz in Ihrer Hand. Je besser Sie das Problem für die Support-Abteilung Ihres IT-Dienstleisters darstellen, desto effizienter kann es bearbeitet und behoben werden. Unser Sellmore CRM Entwickler Michel Rienäcker gibt an einem praktischen CRM Beispiel Tipps, was es für das perfekte Support-Ticket benötigt, die Arbeit der Entwickler erleichtert und Sie schneller zur Lösung gelangen. 

Am Anfang stand das Problem. Und dessen Beschreibung.

Im Leben eines Software-Entwicklers kommt man nicht umhin, Support-Arbeit zu leisten. Seien es Probleme in eigenen Entwicklungen oder aber die Aushilfe in der entsprechenden Abteilung. Dabei tauchen in der Kommunikation mit den Kunden immer wieder Stolpersteine auf, die eigentlich vermeidbar sind. Dies geht los bei Problembeschreibungen, die große Fragezeichen hinterlassen bis hin zu Screenshots, die keinen Schluss darauf zulassen, wo im CRM der Fehler überhaupt aufgetreten ist. Diese Punkte sorgen dafür, dass sich die Bearbeitung eines Tickets unnötig verlängert.

Da ich mit diesen Problemen immer wieder konfrontiert werde, habe ich mir die Frage gestellt: Warum ist das so? Warum erhalten wir immer wieder Supportanfragen, die automatisch bei Betrachtung schon eine Rückfrage beinhalten? 

Eine Antwort darauf ist, dass Kunden oft nicht verstehen, wie unsere Sicht der Dinge aussieht und welche „Werkzeuge“ wir zur Verfügung haben. Um diese Wissenslücke zu schließen, will ich hier an einem einfachen Beispiel zeigen, warum Angaben zum Zeitpunkt, zum Benutzer und vor allem zur URL (also dem Link der Fehlerseite) wichtig sind.

Typische Fehlermeldung - ein Beispiel aus der Entwickler-Perspektive

Zum Verdeutlichen der Problematik habe ich dazu eine kleine Seite geschrieben, die innerhalb einer Firma eine neue Person anlegt. Zu dieser Seite kann durch einen Button in der Firmen-Zusammenfassung gesprungen werden. In der Seite habe ich nun bewusst einen Fehler eingebaut, sodass eine bestimmte Kombination von Sicherheitseinstellungen des CRM dazu führt, dass die Person nicht angelegt werden kann. 

Nun ein Beispiel, das so immer wieder auftritt: Der Kunde meldet sich sinngemäß mit folgender Problembeschreibung: 

„Das CRM geht nicht. (siehe Screenshot anbei)“. 

Der Screenshot zeigt folgendes:

Da es sich hier augenscheinlich um einen .net Fehler handelt, würde ich nun die Log-Files dazu erst einmal durchschauen. Diese bieten, je nach Einstellung, einen unterschiedlichen Informationsgehalt. In den meisten Fällen ist die Protokollierung aber relativ gering eingestellt, um die Festplatte des CRM-Servers nicht zu füllen. Dies ist auch in diesem Fall so, sodass sich mir nun folgendes Bild ergibt:

Wie man hier sehen kann, ist weder zu erkennen, wo der Fehler auftrat, noch welcher Nutzer betroffen war. Das Einzige, das hier tatsächlich herausgelesen werden kann, ist der Zeitpunkt des Fehlers. Da sich manchmal auch SQL-Fehler hinter oben gezeigter Fehlermeldung verbergen, habe ich zusätzlich noch das SQL-Log geprüft. Dieses war allerdings komplett leer. Hier bleibt nun keine andere Möglichkeit. Ich muss beim Kunden nachfragen, wo im CRM der Fehler aufgetreten ist. Da aber noch ca. 10 weitere Kunden auf ihre Problemlösung warten, schreibe ich dem Kunden eine E-Mail mit der entsprechenden Rückfrage. Bis der Kunde diese beantwortet hat, sind wieder 2-3 Tage vergangen. 

Vorteile einer guten Problembeschreibung

• Weniger Kommunikationsaufwand 
• Schnellere Bearbeitung Ihres Tickets
• Effiziente Problemlösung 
• Weniger Frust für alle Beteiligten

Wie Sie Software-Probleme besser darstellen können 

Was hätte der Kunde nun bei seiner Anfrage besser machen können, und wie wäre die Ticketbearbeitung dann abgelaufen?

1.     Screenshot des kompletten Bildschirms

In erster Linie wäre ein Screenshot gut gewesen, auf dem erkennbar ist, wo er entstanden ist. Das heißt, ein Screenshot vom kompletten Bildschirm inklusive Uhr. Wenn die Log-Dateien nämlich größer sind, ist auch hier schnell die Übersicht verloren und der Supporter freut sich über jede Zeitangabe. 

Tool-Tipp

Für alle Windows-Nutzer bietet sich die App „Snipping Tool“ an. Hiermit können Sie ganz einfach Screenshots erstellen, bearbeiten und speichern. Sie finden es am besten über die Windows Suchfunktion. 

Aber Achtung, in der Startmaske von Snipping Tool wird bereits darauf hingewiesen, dass das Tool „in einem zukünftigen Update auf eine andere Seite verschoben“ wird (Stand Juli 2021). Dann kann man aber noch wie gewohnt mit der Funktion „Ausschneiden und skizzieren“ seine Bildschirmausschnitte anfertigen. 

„Ausschneiden und skizzieren“: Windows-Logo-Taste + Umschalttaste + S 

Mac-Nutzer können unter OS X standardmäßig die Screenshot-Funktion "Bildschirmfoto" mit Hilfe folgender Tastenkombination nutzen: [CMD] + [Shift] + [4]

2.     URL der Fehlerseite

Weiterhin wäre es sehr wichtig gewesen, dass die aufgerufene Adresse mitgeschickt wird. Wird die URL näher untersucht, zeigt sich, dass hier verschiedene Informationen in Form von URL-Parametern vorhanden sind.

• http://example.org/crm/eware.dll/Do?SID=14189268433763&Act=432&Mode=1&CLk=&Key0=1&Key1=35
  &Key2=42&dotnetdll=Blog.dll&dotnetfunc=RunDemoPage

So zeigt der Parameter Act an, welche Funktionalität im CRM gerade aufgerufen wurde. In unserem Beispiel steht die 432, was bedeutet, dass hier eine .net DLL aufgeführt wird. Weiterhin zeigt der Parameter Key0 an, welcher der aktuell dominante Key im URL ist. In der Beispiel-URL wäre Key1 der dominante Key, was so viel bedeutet, dass der Nutzer sich hier im Kontext einer Firma befand. Weitere Beispiele für Keys wären Key2 für Personen, Key3 für Adressen oder Key6 für Kommunikationen. Weiterhin zeigt der durch Parameter Key1 bestimmte Wert die ID der gewählten Firma an, hier also die 35.

Zusätzlich dazu existieren in der Beispiel-URL noch zwei Parameter, die die .net Umgebung näher spezifizieren. Hier wurde also die Datei „Blog.dll“ gerufen mit der Funktion „RunDemoPage“. Somit kann der Supporter feststellen, welcher Datensatz dem Nutzer bei Auftreten des Fehlers angezeigt und welche Funktion aufgerufen wurde. Somit kann hier im Quelltext der entsprechenden Datei bereits nach Fehlern gesucht werden.

3.     Benennung des Nutzers

Ein weiterer wichtiger Aspekt ist der Nutzer, bei welchem das Problem aufgetreten ist. In unserem Beispiel ist es so, dass bestimmte Sicherheitseinstellungen das Problem ausgelöst haben. Wenn der Supporter nun mit dem Admin-Zugang versucht, das Verhalten nachzustellen, tritt der Fehler nicht auf, denn: Alle Aktionen, welche ein Administrator im CRM ausführt, werden ohne Sicherheitskontext ausgeführt. Das bedeutet, der Administrator kann in jedem Gebiet Datensätze anlegen, ansehen, ändern und löschen. Er erfährt hier keine Einschränkungen. Anders ist das bei normalen Nutzern. Diese unterliegen dem Berechtigungskonzept des CRM. Mit dem Wissen, welcher Nutzer den Fehler bekommen hat, hätte der Supporter hier die Protokolle auf Maximum stellen und das Problem gemeinsam mit dem Kunden nachstellen können. Das Ergebnis wäre eine aussagekräftige Fehlermeldung im .net Log:

Der Supporter könnte nun den Fehler beheben und das Ergebnis mit dem Kunden direkt nochmal prüfen. Resultat: Glücklicher Kunde = glücklicher Supporter. 

4.     Beschreibung der zur Fehler führenden Aktion

Hätte das Problem nun nicht an den Benutzerberechtigungen gelegen, hätte es ganz klar weitere Informationen gebraucht. Konkret ist das die Beschreibung zu den eingegebenen Daten, die zum Fehler führten. Die erste Frage dabei lautet: Tritt das Problem häufiger auf?  

Was im Tagesablauf störend ist, kann bei der Fehlerbehebung hilfreich sein. Wenn das Problem vermehrt auftritt und sich nachstellen lässt, ist es ratsam, eine möglichst genaue Beschreibung zur Reproduktion des Fehlers zu verfassen. Wichtig sind hierbei die Schritte,  welche durchgeführt werden müssen, um das Problem sicher zu provozieren.

Auch ist es an dieser Stelle wieder ratsam, den betroffenen Benutzer anzugeben, da auch hier der Berechtigungskontext eine wichtige Rolle spielt. 

Folgende Fragen können Sie sich bei der Aufgabe eines Fehlerberichts stellen: 

• Wo tritt das Problem auf? Immer auf der gleichen URL (siehe Punkt 2)? 
• Wie macht es sich bemerkbar?
• Welche Schritte müssen in welcher Reihenfolge durchgeführt werden, um den Fehler herbeizuführen? 

Wenn Sie diese Punkte beachten, schaffen Sie eine gute Grundlage für Ihren Supporter, das Problem zu lösen. 

Auf einen Blick: 4 Checkpunkte für Ihre perfekte Support-Anfrage

1.     Screenshot des kompletten Bildschirms inkl. Uhr 

2.     URL der Fehlerseite

3.     Nennung des Nutzers, bei dem der Fehler auftritt

4.     Beschreibung der ausgeführten Aktion, die zum Fehler geführt hat

Abschließend ist es also wichtig, dass Sie uns so viele Informationen zukommen lassen, wie es irgendwie geht. Am wichtigsten sind hierbei die aufgerufene Adresse und der Nutzer, welcher die Fehlermeldung erhalten hat. Hier liegt der höchste Informationsgehalt.

Sie wollen bzw. müssen das Gelernte direkt in die Tat umsetzen? Wir helfen Ihnen gern. 
Hier geht es zum Sellmore Support.

Noch kein Wartungsvertrag für Ihr CRM-System? Auch hier beraten und unterstützen wir Sie gern. Schreiben Sie uns über unser Kontaktformular. 

Der Autor: Michel Rienäcker, CRM Entwickler bei Sellmore

Michel ist seit 2015 Teil des Entwicklung-Teams. Sein Schwerpunkt liegt auf dem System Sage CRM. Sein Motto bei allen anstehenden Entwicklungsaufgaben: Geht nicht, gibt's nicht! Für den Sellmore CRM Blog gibt er Einblicke in das Daily-Business der CRM Entwicklungswelt.  

Zum Sellmore-Team

Screenshots ^© Sellmore GmbH