Um unsere Cloud-Lösungen zu konzipieren, entwickeln wir unsere eigenen Unternehmensanwendungen. Diese Software-Kontrolle verstärkt unsere Unabhängigkeit und verschafft unseren Mitarbeitenden die effizientesten Tools. Eines unserer Teams erhielt für die Weiterentwicklung der Support-Tools von Infomaniak jüngst einen Persilschein. Im Folgenden schildern wir dieses Projekt aus der Perspektive unserer Entwickler.

Wir mögen unseren Support mindestens genauso wie Sie.

Unsere Support-Mitarbeitenden sind das Bindeglied zwischen unseren Tätigkeiten und unseren Benutzern. Sie leiten Ihre Anregungen und Probleme an uns weiter, sodass wir unsere Produkte unter Berücksichtigung Ihrer Prioritäten weiterentwickeln können. Ohne die Unterstützung des Supports wäre Infomaniak nicht das, was es heute ist.

Zuhören. Ermitteln. Priorisieren. Programmieren. Anpassen.

Um unsere Tools zu verbessern, haben unsere Entwickler mit ihren Kollegen vom Support im kleinen Kreis ohne Zwischenpersonen zusammengearbeitet. Alles begann mit einem Meeting zwischen dem Support, den Entwicklern und den Systemingenieuren. Das Team hat enormes Verbesserungspotenzial ermittelt, wobei sich Folgendes optimieren liesse:

  • die Kundenzufriedenheit
  • das interne Management des Dienstes
  • die Effizienz des Prozesses
  • der Arbeitskomfort und die Zufriedenheit der Mitarbeitenden

Es galt, ein Gleichgewicht zwischen dem Machbaren und dem gemeinsamen Idealbild zu finden. Jede Entwicklung einer Funktion wurde den Endbenutzern vorgelegt, um ihre Eindrücke und Rückmeldungen zu erhalten und so letzte Anpassungen vornehmen zu können.

Auf die spezifischen Probleme des Supports eingehen

Wir haben die Entwickler gebeten, uns die neuen Funktionen zu erläutern, die sie für den Support entwickelt haben:

1 – Verkürzung der Warteschlangen

Um bei Nichtverfügbarkeit bestimmter Warteschlangen die Wartezeit zu verkürzen, leitet ein “Fallback”-System Kundenanrufe zum ersten in ihrer Sprache verfügbaren Mitarbeitenden weiter. Die Zeiten der einzelnen Warteschlangen werden an jedem Wochentag einzeln gesteuert – je nach der Verfügbarkeit der jeweiligen Experten oder Sprachen. Um Kunden schnellstmöglich zu informieren, können unsere Mitarbeitenden dynamische Audio-Nachrichten erzeugen, die je nach Umstand, etwa Warteschlangen, technisches Problem mit einem Produkt, Sprache, abgespielt werden können.

2 – Analyse und Verbesserung der Produktivität

Wir haben Statistiken und neue Indikatoren (KPI) eingerichtet, um einen Gesamtüberblick über den Zustand des Supports in bestimmten Phasen zu erhalten. Support-Mitarbeitende können:

  • Probleme schneller ermitteln
  • Erwartungen der Kunden möglichst gut gerecht werden
  • sich in Stosszeiten gegenseitig helfen, Kunden schneller zu antworten

3 – Dynamische Verwaltung der Support-Zentrale

Die verantwortlichen Personen können Mitarbeitende zu Warteschlangen hinzufügen oder von diesen entfernen, ihre Rolle festlegen und ändern, ihren Status anzeigen und eine interne Nummer festlegen, was zuvor nicht möglich war. Ebenso können sie eine Wartemusik einrichten, die verschiedenen Alarmschwellen ändern und die Intervalle festlegen:

  • bis zu einem anderen Mitarbeitenden weitergeleitet wird
  • zwischen den einzelnen Anrufen
  • bis zur Auslösung der «Rush Time» und des «Fallback»

Anrufe können für die Bearbeitung ab sofort automatisch zu Mobiltelefonen weitergeleitet werden, selbst wenn ein Mitarbeitender nicht vor Ort ist (Bereitschaftsdienst).

Im Mittelpunkt der Entwicklung

In Hinblick auf den Support trägt jedes Detail zum finalen Benutzererlebnis bei. Folglich haben wir alles intern bewerkstelligt und dabei unsere technologischen Sachzwänge und künftigen Ziele berücksichtigt.

Dieses Projekt verdeutlicht sehr gut, wie der Arbeitsalltag unserer Entwickler aussieht. Technologische Entscheidungen werden hinterfragt und den konkreten Verbesserungen gegenübergestellt, die wir dem Benutzer verschaffen wollen. Gleichzeitig erlaubt das Projekt aber eine sehr grosse Freiheit in den verschiedenen Umsetzungsphasen. Julien Viard, VP of Engineering bei Infomaniak

Das Frontend

Die Entwicklung der Verwaltungsschnittstelle und der Schnittstellen des Live-Supports (Echtzeit-Kontrollmonitore der Zentrale) erfolgte mit dem Framework AngularJS. Dies ist die bisherige Technologie der Anwendung, an der sich die Entwickler orientierten.

Um die Benutzerfreundlichkeit zu erhöhen, wurden mehrere massgeschneiderte Komponenten hinzugefügt, darunter:

  • die Auswahl der Benutzer für die Zuordnung zu den Warteschlangen
  • der Wechsel des Kunden-Accounts in der Schnittstelle
  • das automatische Scrollen zu den Schnittstellen des Live-Supports

Für den Live-Support war eine Entscheidung zu treffen: entweder Sockets (IPS) einrichten oder Pooling verwenden und alle 3 / 4 Sekunden ein Backend-Call durchführen. Im Hinblick auf eine umweltgerechte Gestaltung und eine einfache Umsetzung wurde die zweite Lösung ausgewählt. Statt zwischen Frontend und Backend ständig einen Kanal offenzuhalten, um die Daten zu aktualisieren, verwalten wir die Berechnungen serverseitig. Die Frontend-Schnittstelle bezieht die Daten aus dem Cache, der in Drei-Sekunden-Intervallen (statt 1 Sekunde) verfügbar ist, um die Zahl der Serveraufrufe und redundante Berechnungen zu begrenzen. Um den Support-Mitarbeitenden flüssige und gut lesbare Grafiken zu bieten, wird jede Sekunde eine Echtzeit-Aktualisierung mit visuellen Inkrementen simuliert.

Die Statistiken (KPI) haben die Einrichtung mehrerer Grafiken und Tabellen erforderlich gemacht, die mit verschiedenen Zeitskalen angezeigt werden können. Für einen Tag und für einen Monat werden die Statistiken pro Stunde bzw. pro Tag angezeigt.

Das Backend

Die Technologie der Support-Zentrale beruhte bislang auf Asterisk (SIP-Protokoll) und AngularJS für bereits bestehende Tools. Um rasch bestimmte Informationen abzurufen, die Support-Mitarbeitenden zu steuern und alle damit verbundenen Funktionen zu schaffen, musste die Datenbank von Asterisk herangezogen werden. Im Rahmen dieser Tools arbeiten wir nur mit API-Routen (REST), die über die Schnittstelle aufgerufen werden.

Das Projekt hat allgemein betrachtet sehr viel Spielraum für Kreativität beschert. Asterisk und eine Echtzeit-DB haben ermöglicht, nahezu alle unsere Wünsche umzusetzen. Eine interessante Funktion besteht darin, dass ein Mitarbeitender auf eine Warteschlange klicken kann, in der er zunächst gar nicht ist (z.B. eine andere Abteilung oder Sprache), um aus dieser Warteschlange einen einzigen Anruf herauszupicken. Es genügt, den Mitarbeitenden dynamisch zur Warteschlange hinzuzufügen, ihn anschliessend wieder zu entfernen und den nächsten eingehenden Anruf entgegenzunehmen (mithilfe des Systems für die Ereignisverwaltung).

Wir haben ein System für Ereignisverwaltung eingerichtet. Der Telefon-Server führt API-Aufrufe mit bestimmten Parametern aus und veranlasst die mit dem Backend verbundenen Aktionen. Mithilfe dieser Ereignisart lässt sich der damit verbundene Kunden-Account (je nach der Nummer des Anrufers) in der Schnittstelle anzeigen, wenn der Anruf entgegengenommen wird. Dieses System ruft die in der Anfrage gespeicherten Daten ab, verteilt die Aufgaben anschliessend, damit die API-Antwort sehr rasch erfolgt und die Entgegennahme des eigentlichen Anrufs nicht verzögert.

Für die Verwaltung dynamischer Nachrichten wird der Text in Sprache umgewandelt und anschliessend direkt in einem Git-Repository umgesetzt. Die Zentrale wird dann auf dieses übertragen und kann in Echtzeit auf Nachrichten zugreifen. Die Entwicklung dieser Funktion hat Spass gemacht, zumal sich so rasch ein kleines Verzeichnis mit Sprachnachrichten anlegen lässt, das über eine dedizierte Schnittstelle abgehört und bearbeitet werden kann.

Bestimmte API-Routen werden direkt über die Skripts unsere Systemadministratoren konsumiert. Die Parameter weichen leicht von denjenigen unserer Schnittstelle ab, da die Funktionen nicht vollständig identisch sind. Der Zustand einer Weiterleitung kann über eine Befehlszeile angezeigt und geändert werden, wobei lediglich die zu verwendende interne und externe Nummer anzugeben ist. Dies ermöglicht die automatische Verwaltung von Umleitungen im Zusammenhang mit dem Bereitschaftsdienst.

Interne Entwicklung: Herausforderung und Katalysator

Bei einem Projekt so viel Freiheit zu haben, ist nicht unbedingt üblich. Die möglichst starke Annäherung an die Endbenutzer hat einen Produktivitätsfluss mit schnellem, gutem und angemessenem Ergebnis ermöglicht. Florian Grenier, Frontend-Developer

Die Herausforderung, aber auch der wesentliche Nutzen dieses Projekts gründet auf seiner Einfachheit, die maximale Autonomie und Effizienz ermöglicht. Die Endbenutzer sind unsere eigenen Kollegen, wodurch sich die Akzente verschieben lassen. Das bewusst minimalistisch gehaltene Team hat zwei Monate lang im kleinen Kreis gearbeitet. Wir haben mit einem Staging-1-Server für einen Produktionsserver eine kontinuierliche Integration (CI) vorgenommen, und die automatisierte Umsetzung auf einem Testserver wird über ein internes Skript bewerkstelligt.

Ein altes Framework zu neuen Leistungen führen

Obwohl eine in den Asterisk-Server integrierte API besteht, haben wir uns gegen deren Nutzung entschieden. Denn einerseits entsprach sie nicht unseren Anforderungen, und andererseits konnten wir ihr Verhalten nicht ändern. Folglich haben wir unsere eigenen API entwickelt.

Die technische Schwierigkeit bei diesem Projekt bestand darin, zwischen den verfügbaren Funktionen, dem Bestand und den spezifischen Entwicklungen einen Kompromiss herzustellen, gleichzeitig jedoch recht kurze Umsetzungszeiten und eine hohe Qualität sicherzustellen.

Erforderliche Anpassungen

Es war schwierig, Tests unter echten Produktionsbedingungen durchzuführen: viel mehr Anrufe auf einmal / länger dauernde Anrufe / längere Wartezeiten. Das Entwicklungsteam war hierdurch bislang einmaligen Rahmenbedingungen ausgesetzt, was kleine Patches erforderlich machte, etwa mit Blick auf die Echtzeit-Anzeige.

Eines der grössten Probleme zeigte sich nicht sofort. Es dauerte mehrere Wochen, bis klar wurde, welch gewaltiges Log-Volumen die Zentrale generierte. Hierdurch bestand die Tendenz, die Erzeugung der Statistiken und die verschiedenen Aktionen zu sehr zu verlangsamen. So wurde ein automatisches Flush-System mit Cache-System eingerichtet, um die erneute Berechnung von Daten zu verhindern, die nicht mit derselben Frequenz aktualisiert werden müssen.

Die Entwickler des Projekts

Florian Grenier, Frontend-Developer: Ich kam vor zwei Jahren als Frontend-Developer zu Infomaniak. Davor habe ich einiges gemacht: PHP-, anschliessend C#-Entwickler, kurzer Abstecher zur mobilen App ionic, Junior-Projektleiter und dann Java-Entwickler. 2016 habe ich die französische Hochschule Y-NOV nach fünfjährigem Studium mit einem Diplom verlassen und dort an zahlreichen Development-Projekten und -Wettbewerben, auch ausserhalb der Schule, teilgenommen. Was die Ressourcen angeht, hole ich mir öfter auf dieser Website Anregungen. Mir gefallen auch die Tutorials von Grafikart auf YouTube.

Sich mit alten Technologien herumzuschlagen, kann frustrierend sein (technische Schuld). Ein Entwickler muss auf Bestehendem aufbauen – was nicht unbedingt so prickelnd ist –, um dann letztlich eine Qualitätslösung zu bieten, die sich spürbar im Tempo des Unternehmens niederschlägt.

Noé Fleury, Backend-Developer: Ich bin seit ungefähr einem Jahr Backend-Entwickler bei Infomaniak. Zuerst habe ich mir mehrere Programmiersprachen selbst beigebracht (PHP, C, Python, SQL usw.), dann aber vor zwei Jahren an einer Ingenieurschule (FH) einen Bachelor-Abschluss in Informatik gemacht und meine Kenntnisse ausgebaut.

Es zeigt, dass wir sehr effiziente Tools entwickeln können, ohne auf weniger flexible externe Lösungen zurückgreifen zu müssen. Da die Schnittstelle nur für die interne Nutzung ausgelegt ist, konnten wir kleine, nicht vorgesehene Funktionen hinzufügen, die aber im Alltag letztlich sehr nützlich sind.