Wie wir unser Helpdesk-System gesägt haben

Vor vier Jahren verwendete das technische Support-Team des Plarium Krasnodar-Studios ein Ticketsystem eines Drittanbieters, das viele Nachteile aufwies. Heute haben wir nicht nur unser eigenes System, sondern auch einen Helpdesk, der auf die Bedürfnisse des Unternehmens zugeschnitten ist. Wie es passiert ist - lesen Sie den Artikel.







Was haben wir damit zu tun, dass wir über die Entwicklung eines eigenen Ticketsystems nachgedacht haben? Hauptprobleme:

1. Unser Team erhielt jeden Tag 1–1,5 Tausend Treffer von Benutzern.
2. Bequeme Statistiken fehlten. Alles musste manuell in verschiedenen Dokumenten vermerkt werden.
3. Die Hauptschwierigkeit: Bei den meisten Anfragen musste der Status des Spielerkontos überprüft werden, auf das zu diesem Zeitpunkt nicht direkt zugegriffen werden konnte. Wir haben nur mit den Texten der Anfragen selbst und den E-Mail-Adressen gearbeitet.
4. Komplexität und Schnittstelle geschaffen. Die Lösungen anderer Leute sind meistens unpraktisch, da sie nicht auf ein bestimmtes Spiel und die technischen Supportbestimmungen für ein bestimmtes Unternehmen zugeschnitten sind.
5. In Anbetracht all dieser Punkte war die Bezahlung eines Drittanbieter-Systems nicht sehr rentabel.

Und wir treffen eine epochale Entscheidung - unser eigenes Ticketsystem zu kürzen! Und was? Es gibt Kraft, es gibt viele Ideen, Begeisterung - mehr als genug. Zu diesem Zeitpunkt gab es jedoch keine entsprechenden Prozesse: Wir, das Support-Team, hatten noch nie etwas beim internen Toolkit-Entwicklungsteam bestellt und waren nicht eng mit diesem interagiert.



Wo soll man anfangen? Wir haben in zwei Spalten unsere Erwartungen an das Tool (etwas im Stil von „Wir möchten Nachrichten empfangen und darauf antworten“) und Beschwerden über die aktuelle Version („Hier ist ein unbequemes Fenster, machen Sie es bequemer“) niedergeschrieben, es als technische Aufgabe bezeichnet und an die Entwickler weitergegeben. Der weitere Vorgang dauerte ca. 3 Monate. Es gab keine Testphase, alle Fehler wurden von den Entwicklern oder dem Support selbst bereits bei Verwendung des Tools gefunden.



Wie Sie sich vorstellen können, kam dieser Pfannkuchen klumpig heraus. Wir haben es versucht und dachten, dass die Nachteile des gekauften Dienstes nicht so schwerwiegend sind. Und dann schlug das Team des kommerziellen Helpdesks eine Integration vor, bei der Informationen über den Benutzer aus dem Spiel empfangen und in Tickets an unseren Support gesendet werden (dies würde das Hauptproblem lösen). Einige der Integrationsbedingungen widersprachen jedoch den vom Unternehmen festgelegten Sicherheitsanforderungen. Also, welche Optionen hatten wir:

1. Machen Sie eine unsichere Integration mit dem kommerziellen Helpdesk.
2. Nutzen Sie die reduzierte Funktionalität.
3. Zurück zur Werkzeugentwicklung.

Wir haben den letzten Weg genommen. Wir haben alles behoben, was nach der ersten Iteration nicht funktioniert hat, und das Ticketsystem mit Spielen verbunden. Es hatte grundlegende Funktionen: Wir akzeptierten Bewerbungen und antworteten darauf, indem wir Nachrichten an die Mail schickten. Vor allem aber haben wir endlich die Möglichkeit, die Spieler-ID im Ticketsystem zu sehen, das sich auf unser anderes internes Tool mit den restlichen Kontoinformationen bezieht.



Das Team, das den Entwicklungsprozess bereitstellte, bestand zunächst aus dem Product Owner, dem PM und dem Entwicklerteam. Wir haben das Design selbst gezeichnet, die Entwickler bearbeitet und das Produkt so weit wie möglich getestet. Dann kamen UI / UX-Designer und QA hinzu. Als Ergebnis stellte sich der folgende Prozess heraus: Der Kunde schreibt, was er will, UI / UX sagt, wie es am besten geht, Entwickler implementieren es, QS-Prüfungen und PM steuern die gesamte Kette und das Timing.







Nachdem wir ein Ticketsystem mit minimaler Funktionalität eingeführt hatten, begannen wir, es zu verbessern und an die Bedürfnisse und Ziele des Unternehmens anzupassen. Insgesamt wurden bisher mehr als 200 Funktionen implementiert, die wichtigsten sind unten aufgeführt.

1. . , KPI , , . 7 50 .
2. — ( ) .
3. .
4. .
5. HTML- .
6. -. - .
7. .
8. . , .
9. - .
10. , .
11. ( new, waiting, answered, resolve close, inprogress, pending). ; , / ; ( ).
12. .
13. .
14. , .
15. Programmierbare Flow-installierte Lösungen, einschließlich Benachrichtigung der verantwortlichen Mitarbeiter im Falle eines Ereignisses im Ticketsystem.

Was war unser Technologie-Stack:

• In C # als Backend geschriebene .NET-Web-API-Anwendung;
• Angular Client;
• MongoDB für die Datenbank und ElasticSearch für die Volltextsuche;
• Mailgun zum Senden von Mail-Nachrichten an Spieler.

Gesamtansicht des Support Ticket Systems Fassen



wir zusammen.

Vorteile der Entwicklung eines eigenen Ticketsystems

1. Schärfen Sie den Helpdesk für Ihr Unternehmen bei der Lösung von Problemen, vereinfachen Sie den Ablauf und verfolgen Sie die Indikatoren.
2. Vertiefung des Wissens über die Funktionsweise des Ticketsystems und über die Arbeit des technischen Supportteams, das Ihnen gegenüber sitzt.
3. -. , - .
4. , .
5. .
6. . , - , .
7. . , , .
8. , , .
9. . , «» , , QA UI/UX- , .

1. . — , . . 40 50–70 , 3–5 ( ). -, , , , . , , -.
2. Wir müssen einen langen und schwierigen Weg gehen. Wir haben den Entwicklungsprozess mehrmals geändert, gekämpft und aufgebaut, hergestellt und überarbeitet. In diesen 3,5 Jahren wurden mehr als 1.500 Fehler behoben.
3. Strukturelle Änderungen sind erforderlich. Es wird ein Team benötigt, das interne Prozesse unterstützt. Es ist notwendig, diejenigen, die das Produkt des Unternehmens herstellen, von denen zu trennen, die Backoffice-Tools herstellen. Es ist unwahrscheinlich, dass es möglich sein wird, die Hauptentwickler für die Erstellung eines solchen Tools zu gewinnen.

Es liegt an Ihnen, sich auf dieses Geschäft einzulassen oder nicht. Und wir bedauern nicht, dass wir uns engagiert haben. Es war gruselig. Und es war auch schrecklich interessant.