Warteschleifen-Übersicht als Self-Service für Führungskräfte

Ausgangslage

Der Projektordner benennt das Ausgangsproblem nicht ausdrücklich. Belegt ist nur der Zweck in der Spezifikation: Abteilungsleitungen sollen einen Self-Service-Überblick über ihre Warteschleifen bekommen, statt darauf angewiesen zu sein, dass jemand anders nachschaut.

Ein Indiz deutet auf die Vorgeschichte, ist aber Interpretation: Im Ordner liegt eine PowerPoint-Datei, die den Anrufweg einer einzelnen Abteilung dokumentiert — Spezifikation und Code-Kommentare beziehen sich mehrfach darauf als „nur ein Beispiel“. Das legt nahe, dass solche Anrufwege vorher von Hand in Folien gepflegt wurden. Bestätigen kann das nur der Fachbereich selbst.

Ansatz

Zwei getrennte Teile.

Ein stündlich laufender Sammel-Job meldet sich unbeaufsichtigt per Zertifikat bei Microsoft Teams an, liest sämtliche Warteschleifen und Sprachmenüs aus und schreibt sie in eine Datenbank. Warum PowerShell statt einer normalen Schnittstelle, steht im Code: Für diese Konfigurationsdaten existiert schlicht keine REST-API. Jedes Objekt wird einzeln fehlerbehandelt, damit ein einzelner kaputter Datensatz nicht den ganzen Lauf abbricht.

Die Weboberfläche liest ausschließlich aus dieser Datenbank — sie ändert nie etwas in Teams. Bei jedem Zugriff prüft der Server, ob die Person diese Warteschleife sehen darf.

Die Live-Erreichbarkeit kommt aus Microsoft Graph, gebündelt in einem Aufruf für alle Personen einer Seite und 45 Sekunden zwischengespeichert. Die Seiten rendern sofort aus der Datenbank, die Erreichbarkeit lädt der Browser danach nach — ein langsamer oder gedrosselter Graph-Aufruf blockiert damit nie den Seitenaufbau. Ein Banner warnt, wenn die letzte Synchronisation zu alt ist.

Der Anrufweg wird als Diagramm dargestellt, vollständig aus den synchronisierten Daten erzeugt — inklusive Ansagen, Öffnungszeiten-Zweigen und verschachtelten Untermenüs.

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

Das Datenmodell für die Sprachmenüs wurde bewusst generisch gebaut, obwohl zum Zeitpunkt der Entwicklung nur ein einziger, konkret bekannter Menübaum vorlag.

Die Spezifikation formuliert das als Auflage: beliebig viele Optionen, verschachtelte Menüs, Ziele wie Voicemail, externe Nummer oder Ansage, und Warteschleifen ganz ohne Sprachmenü — „never hard-code its shape, depth, or option count“. Derselbe Satz steht noch einmal im Datenmodell selbst. Umgesetzt ist er über einen selbstreferenzierenden Baum und einen generischen Zieltyp; der Diagramm-Renderer klappt verschachtelte Menüs inline auf und schützt sich über eine Besuchsliste gegen Zyklen und mehrfach genutzte Untermenüs.

Das hätte anders ausgehen können: Den einen bekannten Menübaum fest zu verdrahten wäre schneller gewesen und hätte für den ersten Nutzerkreis identisch ausgesehen. Bezahlt wurde die Entscheidung im Sammel-Job, der jeden Teams-Zieltyp einzeln abbilden muss — samt der Einschränkung, die die Dokumentation selbst benennt: Teams-Objekte sehen je nach Konfiguration unterschiedlich aus, die Abbildung muss je Mandant verifiziert werden.

Ergebnis

Rund 3.400 Zeilen in 46 Dateien, 10 Datenbanktabellen, 19 Endpunkte, sechs Integrationspunkte. Aufgebaut von einer Person; die Commit-Historie taugt allerdings nicht als Aufwandsmaß — vier Commits heißen „first commit“, die Historie wurde also neu aufgesetzt.

Bewusst nur lesend: Warteschleifen und Sprachmenüs werden nirgends verändert. Jede Änderung passiert weiterhin von Hand im Teams Admin Center durch eine Person mit Administratorrechten. Ebenfalls manuell: Welche Führungskraft welche Warteschleife sieht, trägt ein Administrator ein; es wird nicht aus Organisationsdaten abgeleitet.

Ein Punkt, der ausdrücklich nicht technisch gelöst wird: Aggregat-Ansicht und Anonymisierung sind je Führungskraft schaltbar — die Freigabe durch Betriebsrat und Datenschutz für die Anzeige individueller Erreichbarkeit bleibt laut Spezifikation eine davon getrennte organisatorische Hürde. Der Schalter ersetzt den Prozess nicht.