Consulting Briefing

11.08.2026 · boddenberg.de

Teams: Erweiterte Call Queue Analytics

Executive Summary

Teams-Telefonie hat in vielen Organisationen einen unangenehmen blinden Fleck: Die Anlage läuft, die Rufnummern klingeln, alle sind zufrieden – und trotzdem kann dir niemand sagen, wie viele Anrufer heute Vormittag entnervt aufgelegt haben. Genau diese Lücke schließt die erweiterte Call-Queue-Analytik. Vorausgesetzt, du weißt, welche der drei parallel existierenden Datenwelten du gerade betrachtest.

Microsoft speist alle Zahlen aus einer gemeinsamen Quelle, dem Voice Applications Analytics Collector, präsentiert sie aber in drei sehr unterschiedlichen Oberflächen: dem schlanken Usage-Report im Teams Admin Center, den vier Power-BI-Berichten des Historical-Reports-Templates – aktuell Version 3.3.1 vom 20. Juli 2026 – und der Queues App mit Echtzeitkacheln für Teamleiter. Jede dieser Welten hat eine eigene Aufbewahrungsfrist, eine eigene Zeitzonenlogik und ein eigenes Rechtemodell. Wer das durcheinanderwirft, produziert Auswertungen, die im Steuerkreis auseinanderfliegen.

Der eigentliche Hebel liegt allerdings nicht im Betrachten, sondern im Nachsteuern. Anrufvolumen pro Stunde gegen eingebuchte Agenten gelegt, Abbruchquoten gegen die Agent Alert Time, Overflow- und Timeout-Ereignisse gegen die konfigurierte Ausnahmebehandlung: Daraus werden konkrete Konfigurationsänderungen. Und die kosten dich in aller Regel keinen Cent zusätzliche Lizenz – nur ein paar ehrliche Stunden im Admin Center.

Worum geht es im Detail?

Fangen wir dort an, wo die Daten entstehen. Jeder Anruf, der eine Auto Attendant oder eine Call Queue berührt, hinterlässt Diagnose-Telemetrie. Diese Telemetrie sammelt der Voice Applications Analytics Collector, kurz VAAC, und speist daraus sämtliche Berichte. Wichtig ist der Nachsatz, den Microsoft selbst in die Dokumentation geschrieben hat: Die Berichte sind nur so vollständig wie die Telemetrie, die tatsächlich ankommt. Ein falsch konfigurierter Proxy, eine Netzstörung, ein Client, der seine Daten nicht loswird – schon fehlen Datensätze. Deshalb ist der Einsatz dieser Berichte für Auditing, Compliance oder gar Lohnabrechnung ausdrücklich nicht unterstützt. Wer trotzdem den Provisionslauf darauf aufbaut, hat spätestens beim ersten Widerspruch ein Problem, das ihm kein Support-Ticket abnimmt.

Ein Rohdatenstrom, drei Konsumenten – mit jeweils eigener Zeitzone, Frist und Berechtigungslogik.

Latenz. Historische Daten stehen typischerweise rund 30 Minuten nach Gesprächsende bereit, im Ausnahmefall dauert es mehrere Stunden. Und der Bericht aktualisiert sich nicht von selbst: Du musst in Power BI aktiv aktualisieren. Wer morgens um 8:05 Uhr den Bericht für 8:00 Uhr aufreißt und sich über die leere Seite wundert, hat kein Produktproblem, sondern ein Geduldsproblem.

Das Power-BI-Template enthält vier Berichte. Cloud Auto Attendant Analytics zeigt dir, wie Anrufer durch das Menü laufen – inklusive der Pfade, die nie jemand geplant hat. Cloud Call Queue Analytics ist das Herzstück: angebotene Anrufe nach intern, extern und Click2Call, durchschnittliche Wartezeit und vor allem die Aufschlüsselung der Call Results in Agent Answered, Abandoned, Overflowed, Timed Out und No Agents. Cloud Agent Timeline Analytics zeigt pro Agent, wie viele Anrufe angenommen wurden und wie lange sie im Schnitt dauerten. Neu in Version 3.3.1 sind der Bericht für Teams Phone Agent – noch in der Vorschau – die Unterstützung für GCCH- und DoD-Mandanten sowie die Möglichkeit, in der Desktop-Variante Agentennamen statt UPN-Kürzeln anzuzeigen. Letzteres klingt kosmetisch, ist aber der Unterschied zwischen einem Bericht, den ein Abteilungsleiter liest, und einer Tabelle voller Kürzel, die er wegklickt.

Echtzeit. Die Echtzeitseite lebt in der Queues App. Dort sehen Teamleiter und Agenten Kennzahlen wie calls_waiting, die Wartezeit des ältesten Anrufs, avg_speed_answer, die Abbruchquote und die Service-Level-Werte. Voraussetzung sind Teams Phone und Teams Premium – letzteres liegt beim Listenpreis in der Größenordnung von rund zehn US-Dollar pro Nutzer und Monat und kommt zur bestehenden Lizenz obendrauf. Nach der Zuweisung kann es bis zu 48 Stunden dauern, bis die App im Client auftaucht. Plane das ein, sonst verbringst du einen halben Tag mit der Fehlersuche an einer Sache, die schlicht noch nicht fertig repliziert ist. Nebenbei bekommen berechtigte Anwender in der Queues App auch Monitor, Whisper, Barge und Takeover – also Mithören, Zuflüstern, Dazuschalten und Übernehmen.

Und dann ist da noch der Elefant im Raum: Service-Level-Metriken gibt es derzeit ausschließlich in der Echtzeitsicht, nicht im historischen Reporting. Du kannst also live zusehen, wie ihr das Ziel reißt – den Monatsbericht dazu musst du dir aber selbst wegschreiben. Wer ein belastbares SLA-Reporting braucht, kommt um eine eigene Datenhaltung nicht herum.

Der Standardbefund aus Projekten: Das Volumen kommt um neun, die Besetzung um elf.

Service Level. Der Schwellenwert selbst ist pro Warteschlange konfigurierbar, von 0 bis 40 Minuten. Ein leeres Feld schaltet die Berechnung komplett ab. Und es gibt eine hinterhältige Wechselwirkung: Setzt du den Service-Level-Schwellenwert höher als den Call Timeout, liegt dein Service Level immer bei 100 Prozent, solange überhaupt ein Anruf angenommen wurde – und bei 0 Prozent, wenn nicht. Microsoft erzwingt die Plausibilität ausdrücklich nicht. Du bekommst also ein makelloses Dashboard und eine katastrophale Realität. Änderst du den Schwellenwert während der Geschäftszeit, ist der ganze Tag unbrauchbar, weil zurückliegende Anrufe nicht neu bewertet werden.

Vier Formeln, ein Datensatz – und 17,5 Prozentpunkte Verhandlungsspielraum.

Was sind Chancen? Was sind Risiken?

Die größte Chance ist banal und wird trotzdem ständig verschenkt: Du kannst endlich mit Zahlen argumentieren statt mit Bauchgefühl. Die Visualisierung, die Anrufvolumen, Abbrüche und die maximale Zahl eingebuchter Agenten pro Stunde übereinanderlegt, beendet mehr Diskussionen als jede Präsentation. Wenn zwischen neun und elf Uhr 184 Anrufe auflaufen und dabei vier Agenten eingebucht sind, ist die Ursachenanalyse in dreißig Sekunden erledigt – und zwar ohne dass jemand sein Gesicht verliert, weil die Grafik niemanden persönlich anklagt.

Die zweite Chance heißt Delegation. Über Voice Applications Policies gibst du Teamleitern Reporting- und Konfigurationsrechte, ohne ihnen das Teams Admin Center zu öffnen. Eine Policy für Supervisoren mit Echtzeit- und Historiendaten, eine für Schichtleiter mit Echtzeitsicht und dem Recht, Agenten ein- und auszubuchen. Das reicht für erstaunlich viele Szenarien, für die früher reflexartig eine Contact-Center-Lösung gekauft wurde. Die Betonung liegt auf „erstaunlich viele“, nicht auf „alle“ – echtes Skill-based Routing oder Omnichannel bleiben ein anderes Thema.

Die Risiken liegen fast alle in der Interpretation. Nimm die bekannten Einschränkungen des Agent Timeline Reports: Wird ein Anruf per Overflow in eine andere Warteschlange umgeleitet und dort angenommen, zählt er auf die ursprüngliche Queue, nicht auf die annehmende. Rückrufe, die Agenten abarbeiten, tauchen dort überhaupt nicht auf – weshalb Call-Queue-Bericht und Agent Timeline systematisch unterschiedliche Zahlen beantworteter Anrufe zeigen. Und in bestimmten Szenarien weicht der Zähler sogar von der Anrufliste im Teams-Client ab; Microsoft bestätigt dabei den Client als korrekt. Wenn du das nicht vorher kommunizierst, erklärst du es hinterher unter deutlich schlechteren Bedingungen – üblicherweise im Beisein von jemandem, dessen Bonus daran hängt.

Risiko Nummer zwei ist die Architektur. Verschachtelst du Auto Attendants und Call Queues ohne Ressourcenkonten – was inzwischen erlaubt und lizenzsparend ist –, dann berichten die Usage-Reports im Admin Center diese Ebenen überhaupt nicht, und in den Power-BI-Berichten tauchen sie unter dem Ressourcenkonto auf, das den Transfer ausgelöst hat, beziehungsweise unter einer nackten GUID. Du sparst ein paar Lizenzen und bezahlst mit Blindflug. Das ist eine legitime Entscheidung – aber eine, die du bewusst treffen solltest und nicht aus Versehen.

Was müssen wir jetzt schon vorbereiten?

Zuerst die Inventur. Zieh dir alle Call Queues und Auto Attendants und dokumentiere pro Warteschlange Routingmethode, Agent Alert Time, maximale Zahl wartender Anrufe, Call Timeout und Ausnahmebehandlung. Die Voreinstellung sind 50 wartende Anrufe, einstellbar von 0 bis 200; der Call Timeout darf bis zu 45 Minuten betragen. Ein Timeout von 45 Minuten ist keine Konfiguration mehr, das ist eine Kriegserklärung an den Anrufer. Und bei einem Maximum von 0 wartenden Anrufen lässt sich nicht einmal mehr die Begrüßung abspielen.

Danach die dokumentierten Empfehlungen anwenden: Conference Mode an, Routingmethode auf Round Robin oder Longest Idle, präsenzbasiertes Routing an, Agent Alert Time auf mindestens 20 Sekunden. Bei Longest Idle gibt es einen Sonderfall, den man kennen muss: Sind weniger Anrufe in der Warteschlange als verfügbare Agenten, bekommen nur die beiden am längsten untätigen Agenten den Anruf angeboten. Wer das nicht weiß, sucht wochenlang nach einem Fehler, der gar keiner ist.

Dann Rechte und Rollen sauber schneiden. Definiere zwei bis drei Voice Applications Policies, trage die Teamleiter als autorisierte Anwender an den jeweiligen Warteschlangen ein – maximal 15 pro Warteschlange – und verzichte auf CQD-Rollen für Fachbereiche. Plane parallel die Betriebsratsabstimmung ein: Sobald du Berichte je Agent auswertest, ist das mitbestimmungsrelevant. Das klärst du erfahrungsgemäß entspannter vor dem Rollout als danach.

Werkzeugseitig brauchst du Power BI Desktop in aktueller Version, denn nur die jeweils jüngste Version wird unterstützt. Die Anmeldung an den beiden Datenquellen des Templates erfolgt einmalig mit dem Organisationskonto. Willst du den Bericht in den Power BI Service veröffentlichen und dort automatisch aktualisieren lassen, plane das getrennt – ausgerechnet die Anpassung, die Agentennamen statt UPN anzeigt, benötigt eine eigene Entra-ID-App-Registrierung und schaltet die geplante Aktualisierung im Service ab. Beides gleichzeitig geht nicht.

Zuletzt das Zeitverhalten der Organisation. Neue Mitglieder einer Gruppe können bis zu acht Stunden brauchen, bis der erste Anruf bei ihnen ankommt. Eine kanalbasierte Warteschlange braucht bis zu 24 Stunden, bis sie voll funktionsfähig ist. Schichtänderungen aus der Shifts-App synchronisieren mit rund 15 Minuten Verzögerung – und zwar in beide Richtungen. Wer am Montagmorgen um 7:55 Uhr umstellt, hat seine erste Eskalation um 8:05 Uhr.

Häufig gestellte Fragen

Wie lange werden Call-Queue-Daten in Teams aufbewahrt?

Die historischen Berichte reichen bis zu 45 Tage zurück, die Usage-Reports im Teams Admin Center nur 28 Tage. Wer längere Zeitreihen für Trendanalysen oder SLA-Nachweise braucht, muss die Daten regelmäßig exportieren und selbst vorhalten – einen automatischen Langzeitspeicher gibt es nicht.

Brauche ich Teams Premium für Call Queue Analytics?

Für die Power-BI-Berichte reichen Administratorrechte beziehungsweise eine passende Voice Applications Policy aus. Sobald du Teamleitern die Queues App mit Echtzeitkacheln, Monitor, Whisper und Barge geben willst, brauchen diese Anwender zusätzlich zu Teams Phone eine Teams-Premium-Lizenz.

Warum zeigen Call-Queue-Bericht und Agent Timeline unterschiedliche Zahlen?

Das ist erwartetes Verhalten und in der Dokumentation als bekannte Einschränkung vermerkt. Von Agenten abgearbeitete Rückrufe werden in der Agent Timeline nicht mitgezählt, und per Overflow umgeleitete Anrufe zählen auf die ursprüngliche Warteschlange statt auf jene, in der sie tatsächlich angenommen wurden.

Kann ich Service-Level-Werte rückwirkend auswerten?

Derzeit nicht. Service-Level-Kennzahlen stehen ausschließlich in den Echtzeitmetriken zur Verfügung und sind im historischen Reporting nicht enthalten. Wer einen Monatsbericht braucht, muss die Echtzeitwerte laufend abgreifen und in einer eigenen Datenhaltung sichern.

Warum fehlen im Bericht Anrufe, obwohl der Zeitraum stimmt?

Der häufigste Grund ist das Limit von 150.000 Zeilen pro Berichtsreiter, das ohne jede Warnung greift und stillschweigend Daten abschneidet. Verkürze den Zeitraum oder wechsle vom Berichtslevel „Per Call“ auf „Per Day“; seltener liegt es an fehlender Telemetrie durch Netz- oder Proxykonfiguration.