Aus dem Browser-Tab wird eine Desktop-Anwendung fürs Contact Center

Ausgangslage

Der Projektordner enthält keine ausdrückliche Problembeschreibung. Was er durchgehend dokumentiert, sind die Probleme, gegen die gebaut wurde: verpasste Aufgaben-Benachrichtigungen, unzuverlässige Auswahl des Audiogeräts, Headset-Knöpfe, die nichts taten, und Sitzungen, die nach Netzwerkunterbrechungen oder abgelaufenen Token still starben. Ganze Dokumente sind einzelnen dieser Fehlerbilder gewidmet.

Dass die Mitarbeitenden die Contact-Center-Oberfläche vorher schlicht im Browser nutzten, ist naheliegend — steht so aber nicht im Projekt und bleibt eine Folgerung.

Ansatz

Kern ist eine Electron-Anwendung, die die vorhandene Weboberfläche in einem eingebetteten Fenster lädt und native Fähigkeiten darum herum ergänzt. Drei Schichten arbeiten zusammen:

• Ein eingeschleustes Beobachtungsskript läuft innerhalb der Seite, hängt sich in die Telefonie-SDKs und meldet jedes relevante Ereignis — Aufgabe erstellt, angenommen, abgelehnt, Statuswechsel, Verbindungsabbrüche, Token-Ablauf — plus einen Herzschlag.
• Eine Brücke leitet diese Ereignisse als einzigen zugelassenen Kanal zwischen Webseite und Desktop-Prozess weiter.
• Der Hauptprozess reagiert mit nativem Verhalten: ein immer sichtbares Benachrichtigungs- fenster mit Annehmen/Ablehnen, Klingeltöne je Kanal, Taskleisten-Blinken, ein abtrennbares Bedienfeld für Stumm/Halten/Auflegen, ein Nachbearbeitungs-Timer und Headset-Steuerung.

Drumherum: mehrschichtige Verbindungsüberwachung mit automatischem Neuladen oder Neuanmelden, Audiogeräte-Erkennung mit gespeicherter Präferenz, Sitzungsverfolgung und täglich rotierende Protokolldateien. Dazu der Betrieb: automatische Updates, ein Fernabruf für Protokolle — die Anwendung fragt eine Warteschlange ab und lädt auf Anforderung ein Diagnose-Archiv hoch — und ein Rollout-Skript, das Installationen je Benutzer auf eine Installation je Rechner umzieht.

Der Punkt, an dem es anders hätte laufen können

Die Selbstheilung ist der Gesprächssicherheit bewusst untergeordnet.

Die Anwendung heilt aggressiv: Herzschläge, Erkennung veralteter Verbindungen, erzwungenes Neuladen, erneute Anmeldung. Der naheliegende Entwurf lässt das auslösen, sobald die Verbindung ungesund aussieht.

Stattdessen weigert sich der Code ausdrücklich, neu zu verbinden, solange eine aktive Aufgabe oder ein aktives Gespräch läuft: Eine erkannte veraltete Verbindung wird protokolliert und übersprungen, wenn eines von beidem zutrifft.

Die Begründung ist einfach und richtig: Ein abgebrochen aussehender Verbindungskanal ist ärgerlich. Eine Automatik, die ein laufendes Kundengespräch auflegt, ist inakzeptabel.

Dass diese Balance hart erarbeitet wurde und nicht zufällig entstand, zeigt ein einzelnes Änderungsprotokoll: fünf aufeinanderfolgende Korrekturen an übereifriger Wiederherstellungslogik — Neulade-Schleifen, falsch erkannter Token-Ablauf. Die Gegenrichtung derselben Abwägung.

Ergebnis

Rund 30 handgeschriebene Quelldateien, etwa 10.100 Zeilen, sechs angebundene Systeme. Die Version erreichte 1.0.58 — also dutzende ausgelieferte Builds statt eines einmaligen Wurfs. Protokolle aus dem Betrieb reichen deutlich über den letzten Commit hinaus, die Anwendung war also lange nach Entwicklungsende aktiv im Einsatz.

Offen benannte Grenzen: Keine automatisierten Tests — die Qualitätssicherung ist manuell und protokollgetrieben, sichtbar an einem Ordner mit Beispielprotokollen und ausführlichen Dokumenten je Fehlerbild. Windows in der Praxis, obwohl andere Ziele in der Build-Konfiguration stehen: Tonausgabe, Lautstärke, Installer und Rollout sind alle Windows-spezifisch. Ein Mandant — die Anmelde-URL und die Status-Zuordnung sind fest verdrahtet. Und die Binärdateien sind nicht signiert, was die Dokumentation samt der Folge — Warnhinweise beim Start — ausdrücklich festhält.

Eine strukturelle Abhängigkeit bleibt und ist dem Ansatz inhärent: Das eingeschleuste Skript hängt sich in undokumentierte Objekte der Weboberfläche. Ein Update der Plattform kann die Integration brechen.