Berichte und Metriken - Chatarmin CX Docs

Mit der Reporting-API von Chatarmin CX verfolgst du Ticketvolumen, Antwortzeiten, Zufriedenheit und Automatisierung in deinen eigenen Dashboards.

Zugriff und Limits

Beide Endpoints erweitern die bestehende /public/v1-API. Sende deinen API-Schlüssel im Header cx-api-key. Der Schlüssel braucht analytics:read und muss einem Support-Agenten zugewiesen sein. Richte ihn unter Einstellungen → API ein. Berichtsabfragen beachten die Dashboard-Berechtigungen sowie Kanal-, Team- und Agenten-Einschränkungen dieses Agenten. Eine Metrik im Katalog gibt dir nicht automatisch Zugriff auf ihre Daten.

Endpoint	Zweck	Rate-Limit-Stufe
`GET /public/v1/reports/metrics`	Metrikdefinitionen entdecken	Liste: 60 Requests/Minute
`POST /public/v1/reports/query`	Berichtsergebnisse lesen	Analytics: 10 Requests/Minute

Keiner der Endpoints verändert Tickets oder sendet Nachrichten. Unter Rate Limits findest du Hinweise zu Wiederholungen. Die OpenAPI-Referenz enthält die vollständigen Antwortschemas. Für einzelne Umfragen und erfasste Login-Intervalle statt aggregierter Werte nutze CSAT- und Sitzungsexporte. Diese Endpoints erfordern organisationsweiten Dashboard-Zugriff.

Metriken entdecken

curl 'https://api.armin.cx/public/v1/reports/metrics' \
  -H "cx-api-key: $CX_API_KEY"

Die Antwort ist { "success": true, "data": [...] }. Sie enthält den vollständigen statischen Katalog ohne Pagination. Jeder Eintrag hat folgende Felder:

Feld	Bedeutung
`id`	Metrik-ID für `SHOW`, zum Beispiel `new_tickets`
`label`, `description`	Anzeigename und Definition
`group`, `dataType`	Metrikkategorie und Werttyp
`format`	`count`, `duration-seconds`, `percent`, `decimal` oder `currency-eur`
`aggregation`	`count`, `sum`, `median`, `average` oder `ratio`
`attribution`	Welches Ereignis oder welcher aktuelle Zustand den Zeitraum der Metrik bestimmt
`denominator`	Optionale Erklärung zum Nenner oder zur Berechnung
`snapshot`	Ob die Metrik den aktuellen Zustand statt historischer Aktivitäten beschreibt
`higherIsBetter`	Ob ein höherer Wert eine Verbesserung bedeutet

Der Katalog enthält keine Tickets, Kundendaten, Workspace-Entitäts-IDs oder internen Datenquellennamen. Namen und Beschreibungen sind auf Englisch. Cache diese Metadaten, statt sie vor jeder Abfrage neu zu laden. Nicht jede Metrik unterstützt jede Gruppierung oder Visualisierung.

Berichtsdaten abfragen

Starte mit einer Metrik und einem kurzen Zeitraum. Sende JSON mit zwei Pflichtfeldern: query und einer IANA-Zeitzone in timezone, zum Beispiel Europe/Vienna oder UTC. Für die Rohdaten-Pagination kannst du zusätzlich das unten beschriebene optionale Feld cursor senden.

curl 'https://api.armin.cx/public/v1/reports/query' \
  -H "cx-api-key: $CX_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"query":"FROM tickets\nSHOW new_tickets\nDURING yesterday\nVISUALIZE TYPE kpi","timezone":"Europe/Vienna"}'

Die Antwort nutzt { "success": true, "data": ... }. Über data.kind erkennst du die Ergebnisform: kpi enthält zum Beispiel value, previousValue und format; time-series enthält series und points. Du erhältst Diagrammdaten, kein Bild und keinen CSV-Export.

Abfragesprache

Schreibe jede Klausel in eine eigene Zeile. Das ist die CX-Berichtsabfragesprache, kein SQL: Beliebige Tabellen, Joins und SQL-Ausdrücke sind nicht erlaubt. Für Public API v1 gelten die kanonischen Formen auf dieser Seite: WHERE, metrikfreies VISUALIZE TYPE und typisierte SET-Zeilen. Der Service kann einige ältere gespeicherte Aliasformen weiterhin lesen. Neue Clients dürfen jedoch weder FILTER noch OPTIONS oder Metriklisten in VISUALIZE erzeugen.

Klausel	Verwendung
`FROM tickets`	Pflicht. Nur der Datensatz `tickets` ist verfügbar.
`SHOW new_tickets, resolved_tickets`	Pflicht. Nutze IDs aus dem Metrikkatalog.
`DURING yesterday`	Pflichtzeitraum, alternativ `SINCE ... UNTIL ...`. Weitere benannte Zeiträume sind `today`, `this_week`, `last_week`, `this_month` und `last_month`.
`SINCE 2026-08-01 UNTIL 2026-08-07`	Konkrete Kalendertage in der angegebenen Zeitzone, einschließlich Enddatum. Nicht mit `DURING` kombinieren.
`WHERE status is_one_of open, resolved`	Optionaler Filter. Wiederhole `WHERE` in separaten Zeilen, um mehrere Bedingungen gleichzeitig zu verlangen.
`GROUP BY channel_type`	Optionale Gruppierung. Nutze eindeutige IDs wie `channel_type`, `connected_channel`, `topic_l2` und `topic_l3`. Möglich sind bis zu zwei Kategoriegruppen plus eine optionale Zeitgruppe.
`TIMESERIES day`	Optionale Zeitgruppierung: `hour`, `day`, `week` oder `month`.
`COMPARE TO previous_period`	Optionaler Vergleich für KPIs und unterstützte Zeitreihen; auch `previous_year` ist möglich.
`ORDER BY new_tickets DESC`	Optionale Sortierung mit `ASC` oder `DESC`.
`LIMIT 25`	Optionales Ergebnislimit bis 1.000.
`SET show_average_row = true`	Optionale typisierte Einstellung. Nutze eine `SET`-Zeile pro Einstellung; sende in v1-Abfragen kein `OPTIONS`-JSON.
`VISUALIZE TYPE kpi`	Pflicht. Wähle nur den Visualisierungstyp. Metriken stehen in `SHOW`; nutze für einen KPI genau eine Metrik.

Die Public API v1 unterstützt kpi, line, area, grouped_bar, stacked_bar, split_bar, horizontal_bar, data_table und agent_table. Diagramme brauchen Metriken mit demselben format; stapel keine unterschiedlichen Einheiten oder nicht addierbaren Reihen. Eine data_table darf Formate mischen und unterstützt bis zu zwei Kategoriegruppen plus eine optionale Zeitgruppe. Die coordinates jeder Zeile halten die Dimensionen getrennt fest. Alle Metriken, auch Automatisierung und CSAT, nutzen FROM tickets; es gibt keine separaten Nachrichten- oder Umfragedatensätze. Pivot-Tabellen und Heatmaps gehören nicht zum öffentlichen v1-Vertrag.

Rohe Ticketfelder

Nutze den Rohdatenmodus, wenn du eine Zeile pro Ticket statt aggregierter Metriken brauchst. Ersetze SHOW und VISUALIZE durch ein erlaubtes SELECT und FORMAT raw:

FROM tickets
SELECT ticket_id, ticket_number, assignee_id, resolved_by_id, status, reopen_count, last_reopened_at, topic_l1, topic_l2, topic_l3
DURING last_month
LIMIT 100
FORMAT raw

Der Rohdatenmodus unterstützt FROM tickets, SELECT, einen Zeitraum, LIMIT und FORMAT raw. Kombiniere ihn nicht mit SHOW, WHERE, GROUP BY, TIMESERIES, COMPARE TO, ORDER BY, SET oder VISUALIZE. DURING und SINCE ... UNTIL ... filtern nach dem Erstellungszeitpunkt des Tickets. Das unterscheidet sich von aggregierten Metriken, die das Ereignis aus ihrer jeweiligen Zuordnung nutzen. Du kannst bis zu 100 Zeilen pro Request auswählen. Ergebnisse sind absteigend nach created_at und danach nach ticket_id sortiert. Wenn data.pagination.has_more den Wert true hat, sende data.pagination.next_cursor im nächsten Request als oberstes Feld cursor neben query und timezone. Ein Cursor ist an den API-Agenten und die exakte Abfrage gebunden.

Feld	Bedeutung
`ticket_id`, `ticket_number`	Stabile Ticketkennungen.
`created_at`, `updated_at`, `resolved_at`	Ticketzeitpunkte.
`assignee_id`, `assignee_name`	Aktuell zugewiesener Agent. Eine Neuzuweisung nach der Lösung kann diesen Wert ändern.
`resolved_by_id`, `resolved_by_name`	Erfasster Lösungsagent (`solved_by`). Bleibt `null`, wenn niemand erfasst wurde, und fällt nie auf den Assignee zurück.
`status`	Aktueller Ticketstatus, nicht der Status bei Erstellung oder der vollständige Verlauf.
`reopen_count`, `last_reopened_at`	Erfasste Anzahl der Wiedereröffnungen und letzter Wiedereröffnungszeitpunkt.
`topic_l1`, `topic_l2`, `topic_l3`	Aktuelles Reporting-Thema je Kategorieebene als `{ "id", "label" }` oder `null`.

Rohe Zeilen schließen gelöschte, importierte und Seitentickets aus. Dashboard-Berechtigungen sowie Kanal-, Team- und Agenten-Einschränkungen gelten weiterhin. Der Rohdatenmodus enthält bewusst keine Kundeninhalte und keinen vollständigen Statusverlauf. Für eigene Kategoriefelder wie „Kontaktgrund“ nutze die Ticketfeld-Erweiterung; der Rohdatenmodus rät nicht, welches benutzerdefinierte Feld deine Kategorie darstellt.

Gruppieren und filtern

GROUP BY verändert die Form des Ergebnisses; WHERE entfernt Tickets vor der Aggregation. GROUP BY channel_type liefert zum Beispiel eine Zeile oder Serie je Kanaltyp. WHERE channel_type IN ("email", "whatsapp") berücksichtigt dagegen nur E-Mail- und WhatsApp-Datensätze. channel_type steht für allgemeine Transportarten, connected_channel für eingerichtete Kanalverbindungen. Mit topic_l2 und topic_l3 wählst du unterschiedliche Ebenen der Themenhierarchie. Mit TIMESERIES oder einer Zeit-ID in GROUP BY legst du hour, day, week oder month fest. LIMIT begrenzt zurückgegebene Kategoriezeilen. Es senkt weder die Abfragekosten noch verändert es Nenner von Prozentmetriken oder berechnet Gesamtsummen neu.

Abfragebeispiele

Sende jede vollständige Abfrage unten als query-String im HTTP-Request oben, mit timezone: "Europe/Vienna". Datumsangaben und Metrik-IDs behalten in allen Beispielen dasselbe Format.

Tägliches Ticketvolumen

Vergleiche erstellte und gelöste Tickets je Tag. Das sind unterschiedliche Ereignisgruppen, nicht unbedingt dieselben Tickets.

FROM tickets
SHOW new_tickets, resolved_tickets
TIMESERIES day
SINCE 2026-08-01 UNTIL 2026-08-07
VISUALIZE TYPE line

Ticket-KPI für gestern

Vergleiche neue Anfragen mit dem Vortag.

FROM tickets
SHOW new_tickets
DURING yesterday
COMPARE TO previous_period
VISUALIZE TYPE kpi

Neue Tickets nach Kanal

Sortiere Kanaltypen nach eingehendem Ticketvolumen. channel_type liefert Transportarten wie email und whatsapp; mit connected_channel gruppierst du nach einzelnen verbundenen Postfächern.

FROM tickets
SHOW new_tickets
GROUP BY channel_type
DURING last_week
ORDER BY new_tickets DESC
LIMIT 10
VISUALIZE TYPE horizontal_bar

Tickets nach Kontaktgrund

Vergleiche neue und gelöste Tickets für ausgewählte Kontaktgründe. Dieses Beispiel setzt ein Dropdown-Ticketfeld mit dem gespeicherten field_key contact_reason, dem Anzeigenamen Contact reason und den Optionsnamen Delivery und Return voraus. Ersetze sie durch den Feldschlüssel und die Optionsnamen deines Workspaces.

FROM tickets
SHOW new_tickets, resolved_tickets
GROUP BY ticket_field("contact_reason")
DURING last_week
ORDER BY new_tickets DESC
SET surface = categories
SET ticket_field_values = Delivery, Return
SET show_average_row = false
VISUALIZE TYPE data_table

GROUP BY ticket_field("contact_reason") wählt direkt ein bestimmtes Feld. Alternativ akzeptiert SET ticket_field den gespeicherten Feldschlüssel (contact_reason) oder den Anzeigenamen (Contact reason). Leerzeichen am Anfang und Ende sowie Groß-/Kleinschreibung werden beim Abgleich ignoriert. Nutze den gespeicherten field_key aus der öffentlichen Ticketfeld-Erweiterung: Fordere include=ticket_fields bei GET /public/v1/tickets oder GET /public/v1/tickets/:ticketNumber an. Leite keinen Schlüssel aus dem Namen ab, indem du Leer- oder Satzzeichen ersetzt. Ein Name kann sich ändern, ohne dass sich der gespeicherte Schlüssel ändert. Wenn du den Feldschlüssel selbst änderst, passe auch die Abfragen deiner Integration an. SET ticket_field_values wählt Optionsnamen innerhalb dieses Felds aus. Dabei gelten dieselben Regeln für Leerzeichen und Groß-/Kleinschreibung. Lasse die Option weg, um alle Werte des ausgewählten Felds einzubeziehen. Der exakte Wert "all" ist für alle Felder oder alle Werte reserviert. Für einzelne Werte musst du ein Feld statt "all" auswählen. Passt eine Referenz zu mehr als einer Entität, lehnt die API sie mit 400 VALIDATION_ERROR ab. Das gilt auch, wenn der Name eines Felds dem Schlüssel eines anderen entspricht. Die kanonische v1-Sprache akzeptiert über SET ticket_field einen Feldschlüssel oder Anzeigenamen. Interne Kompatibilitätsoptionen mit IDs gehören nicht zum dokumentierten v1-Vertrag. Diese Einstellungen begrenzen die Kategorieaufteilung, nicht die Ticketmenge eines eigenständigen KPIs. Sie ermöglichen keine WHERE-Filter mit benutzerdefinierten Feldschlüsseln oder Optionsnamen.

Kontaktgründe in Prozent und fehlende Werte

Zeige Anzahl und Prozentwerte zusammen. new_tickets_share teilt die eindeutigen neuen Tickets je Kategorie durch alle zulässigen neuen Tickets mit passendem Zeitraum, Berechtigungen und WHERE-Filtern. Der Nenner wird vor Feld-/Optionsauswahl, Gruppierung, topN oder LIMIT berechnet. Zum Beispiel bleiben 20 Delivery-Tickets von 100 passenden Tickets bei 20 %, auch wenn du nur Delivery auswählst oder das Ergebnis auf eine Zeile begrenzt.

FROM tickets
SHOW new_tickets, new_tickets_share
WHERE language is de
GROUP BY ticket_field
DURING last_week
ORDER BY new_tickets DESC
LIMIT 10
SET surface = categories
SET ticket_field = contact_reason
SET ticket_field_values = Delivery, Return
SET include_missing = true
SET show_average_row = false
VISUALIZE TYPE data_table

SET include_missing ist ein Boolean und standardmäßig deaktiviert. Bei aktiven, nicht archivierten Ticketfeldern ergänzt true eine Kategorie Missing für Tickets ohne nutzbaren Wert, auch bei leerem Text. Boolean false und die Zahl 0 sind Werte, nicht fehlend. Fehlende Tickets bleiben auch bei ausgewählten Optionsnamen berücksichtigt; ein anderer ausgefüllter Optionswert wird nicht als fehlend umgedeutet. Bei allen Feldern wird die fehlende Belegung pro Feld berechnet. Limits können diese Zeile trotzdem ausblenden. Prozentwerte über mehrere Felder oder überlappende Werte müssen nicht 100 % ergeben; ein Zeilenlimit berechnet sie nicht neu.

Aktive Ticketbearbeitungszeit

average_ticket_handle_time misst Ticketbearbeitungszeit nur, wenn dieselbe Person während der Bearbeitungsphase eine relevante, gespeicherte Aktion an diesem Ticket ausführt. Dazu zählen Änderungen am Ticket oder an der Zuweisung, Notizen sowie das Bearbeiten, Löschen oder Ausblenden einer Nachricht. Eine Antwort oder E-Mail zählt erst, wenn die verknüpfte Nachricht den Status sent, delivered oder read hat; wartende oder fehlgeschlagene Nachrichten zählen nicht. Öffnen, Lesen, Tippen oder Klicken allein reicht nicht aus. Pro Person und Workspace läuft über alle Tabs hinweg nur ein Ticket-Timer. Beim Ticketwechsel läuft der Timer für das neue Ticket weiter. Der Wechsel in einen externen Tab pausiert ihn nicht. Nach 30 Minuten ohne Aktivität stoppt der Timer; die nächste Aktivität beginnt eine neue Bearbeitungsphase. Eine Aktion aus einer früheren Phase qualifiziert keine spätere. Kehrst du innerhalb derselben Phase zu einem Ticket zurück, werden die Zeiten addiert: 10 Minuten auf A, 20 auf B und weitere 30 auf A ergeben 40 Minuten für A und 20 für B, sofern jedes Ticket eine qualifizierende Aktion hat. Eine spätere Aktion auf A kann alle 40 Minuten qualifizieren. Berichte enthalten auch laufende, noch nicht gespeicherte Zeit – höchstens bis jetzt oder bis zur 30-Minuten-Inaktivitätsgrenze, je nachdem, was früher liegt. Wird eine qualifizierende Aktion verspätet gespeichert, erscheint sie beim nächsten Abruf. Gelöschte, importierte und Seitentickets sind ausgeschlossen. Der gesamte Sitzungswert zählt im Zeitraum und Zeitabschnitt der effektiven letzten Beobachtung oder des Endes (ended_at, gegebenenfalls um den laufenden Timer verlängert). Er wird durch die Anzahl eindeutiger Agent-Ticket-Paare in diesem Abschnitt geteilt. Sitzungen über Mitternacht oder eine Berichtsgrenze werden nicht minutengenau aufgeteilt: Eine am Dienstag endende Sitzung zählt vollständig zum Dienstag, auch wenn sie am Montag begann. Eine spätere Beobachtung kann den gesamten Wert in einen späteren Abschnitt verschieben. Das Ende des Berichtszeitraums ist exklusiv. Fehlende historische Erfassung wird nicht durch Lösungs- oder Online-Zeiten ersetzt. Frage AHT nach menschlichem Agenten ab, um gemessene Ticketarbeit zu vergleichen. Werte werden in Sekunden geliefert. human_agent ist der Agent, dem die gemessene Arbeit zugeordnet wurde, nicht zwingend der aktuell zugewiesene oder erfasste Lösungsagent.

FROM tickets
SHOW average_ticket_handle_time
GROUP BY human_agent
DURING last_month
ORDER BY average_ticket_handle_time DESC
LIMIT 100
SET show_average_row = false
VISUALIZE TYPE data_table

Zeiten bis zur ersten Antwort

Vergleiche die mediane Wartezeit auf eine qualifizierende menschliche oder KI-Antwort mit der Wartezeit auf eine menschliche Antwort. Beide Reihen liefern Sekunden, keine Durchschnittswerte.

FROM tickets
SHOW customer_first_response_time, human_first_response_time
TIMESERIES day
DURING last_week
VISUALIZE TYPE line

Dieses Beispiel lässt responseTimeAttribution weg und behält das bisherige Datums- und Werteverhalten der FRT bei. Das bisherige Datum ist die Ticketerstellung plus die ausgewählten gespeicherten FRT-Sekunden, kein erfasster Antwortzeitpunkt. Ohne diese Option nutzt auch human_first_response_time_mean dieselbe bisherige Grundgesamtheit wie human_first_response_time, selbst wenn erfasste Zeitstempel vorhanden sind. Menschliche FRT misst Wartezeit innerhalb der Geschäftszeiten. Sie zur Erstellung zu addieren ergibt deshalb nicht den tatsächlichen Antwortzeitpunkt.

Mittelwert und Median der ersten menschlichen Antwort

Mit dem Mittelwert erkennst du den Einfluss besonders langer Wartezeiten, mit dem Median eine typische Wartezeit. Beide nutzen dieselben zulässigen menschlichen Antwortbeobachtungen und liefern numerische Sekunden, keine formatierten Zeitstrings. Bei 60, 120 und 900 Sekunden beträgt der Mittelwert 360 Sekunden und der Median 120 Sekunden. Dieses Beispiel aktiviert ausdrücklich erfasste Antwortzeitpunkte statt der bisherigen Datumsberechnung:

FROM tickets
SHOW human_first_response_time_mean, human_first_response_time
GROUP BY day, human_agent
DURING last_week
ORDER BY label ASC
SET show_average_row = false
SET response_time_attribution = recorded_reply
VISUALIZE TYPE data_table

SET response_time_attribution = recorded_reply stellt alle ausgewählten FRT-Metriken (customer_first_response_time, human_first_response_time, human_first_response_time_mean und ai_first_response_time) auf ihre gespeicherten tatsächlichen Antwortzeitpunkte um. Für die Kunden-FRT wählt die Option die früheste qualifizierende gespeicherte menschliche oder KI-Antwort samt zugehöriger Dauer, wobei Zeitpunkt und Dauer vorhanden sein müssen, statt menschliche Geschäftszeitsekunden mit verstrichenen KI-Sekunden zu vergleichen. Andere Metriken einer gemischten Tabelle behalten ihre eigene Zuordnung. Die Option braucht mindestens eine FRT-Metrik und wird von agent_table nicht unterstützt. Jeder andere Wert, auch "legacy", oder die Verwendung ohne FRT-Metrik liefert 400 VALIDATION_ERROR. Für bisheriges Verhalten lässt du die Option weg.

Die FRT-Abdeckung mit erfassten Antwortzeitpunkten ist unvollständig. Nur Abfragen mit dieser Option schließen Beobachtungen aus, deren benötigter Zeitstempel null ist. Es gibt keinen zeilenweisen Ersatz durch bisherige Datumswerte. Ohne verbleibende zulässige Beobachtungen kann das Ergebnis 0 sein; das bedeutet nicht, dass Antworten keine Wartezeit hatten. Die Migration mit nullable Zeitstempeln und die aktualisierten Schreibpfade erfassen Zeitpunkte, befüllen aber keine historischen Daten. Im Rahmen dieser Änderung wurde kein historischer Backfill abgeschlossen. Bestehende Berichte ohne die Option behalten ihr bisheriges Verhalten. Es gibt keine automatische Umstellung, auch nicht nach einer zukünftigen vollständigen Neuberechnung oder einem Backfill.

CSAT-Wert und Stichprobengröße

Zeige die Anzahl der Antworten neben dem Wert, damit du kleine Stichproben einschätzen kannst. Eine Tabelle erlaubt Dezimalwert und Anzahl in einem Ergebnis.

FROM tickets
SHOW csat_average, csat_responses, low_csat_tickets
GROUP BY day
DURING last_month
ORDER BY label ASC
VISUALIZE TYPE data_table

CSAT-Antwortquote nach Versandkohorte und Agent

Vergleiche versendete Umfragen, davon eingereichte und bewertete Umfragen sowie ihre Antwortquote. Bei gleichem Umfang gilt csat_response_rate = 100 × csat_answered_from_sent / csat_sent. Spätere Einreichungen aktualisieren die ursprüngliche Versandkohorte, auch nach Ende des Berichtszeitraums. Teile nicht csat_responses durch csat_sent: Erstere zählt nach Einreichungsdatum und kann früher versendete Umfragen enthalten. Ohne versendete Umfragen ist die Quote null.

FROM tickets
SHOW csat_sent, csat_answered_from_sent, csat_response_rate
GROUP BY day, human_agent
DURING last_month
ORDER BY label ASC
SET show_average_row = false
VISUALIZE TYPE data_table

Für einzelne niedrige Bewertungen, Kommentare und gespeicherte Umfragezuordnungen nutze den CSAT-Rohdatenexport. Rohdatenexporte lesen nur die gespeicherte Umfragezuordnung. CSAT-Agentenaufteilungen in Berichten nutzen diese Zuordnung, wenn vorhanden, sonst den projizierten Lösungsagenten des Tickets. Dieser bestehende Ersatzwert im Bericht schreibt keine Umfragen um, kann aber eine im Rohdatenexport nicht zugeordnete Umfrage einem Agenten im Bericht zuordnen. Auch Berichtsprojektionen können unvollständig sein; beide Ergebnisse müssen sich deshalb nicht automatisch decken.

Antworten und Online-Zeit pro Stunde

Vergleiche öffentliche menschliche Nachrichten mit Online-Sekunden je Agent und Stunde. Das sind unterschiedliche Grundgesamtheiten: Eine Person kann online sein, ohne zu antworten. Die Zeilen vereinen alle beobachteten Zeit-/Agentenpaare der ausgewählten Metriken. Fehlende Metrikzellen darin sind null; es entsteht kein vollständiges Raster aller Agenten und Stunden.

FROM tickets
SHOW agent_messages, agent_online_time
GROUP BY hour, human_agent
DURING yesterday
ORDER BY label ASC
SET show_average_row = false
VISUALIZE TYPE data_table

Online-Zeit begrenzt Sitzungen auf den angefragten Zeitraum, vereinigt überlappende Intervalle je Agent gegen Doppelzählung und verteilt sie auf lokale Zeitabschnitte. Für dieses Aggregat endet eine veraltete offene Sitzung bei ihrer letzten Aktivität; eine kürzlich aktive offene Sitzung spätestens jetzt. Tage mit Zeitumstellung können 23 oder 25 Stunden haben. Wiederholte lokale Stunden haben unterschiedliche Zeitstempelschlüssel: Nutze Schlüssel statt Labels als Kennung. Das ist weder Ticketbearbeitungszeit noch ein Pausenprotokoll. Der Rohdatenexport für Sitzungen behält bewusst die ursprünglichen, ungekürzten Datensätze.

Wöchentlich gelöste Tickets je Agent

Prüfe den Lösungsdurchsatz nach erfasstem Lösungsagenten und Woche, nicht die in dieser Woche erstellten Tickets.

FROM tickets
SHOW resolved_tickets
GROUP BY week, human_agent
DURING last_month
ORDER BY label ASC
SET show_average_row = false
VISUALIZE TYPE data_table

Monatliche Agentenaktivität

Setze den Agenten an die erste Stelle der Zeilendimensionen, um monatliche Antworten und Online-Zeit zu prüfen. Die umgekehrte Dimensionsreihenfolge ändert die Darstellung, nicht die ausgewählten Grundgesamtheiten.

FROM tickets
SHOW agent_messages, agent_online_time
GROUP BY human_agent, month
SINCE 2026-07-01 UNTIL 2026-08-31
ORDER BY label ASC
SET show_average_row = false
VISUALIZE TYPE data_table

Einsparungen und KI-Ausgaben

Vergleiche geschätzte Einsparungen mit geschätzten Ausgaben in EUR. Dieses Tagesdiagramm nutzt dasselbe Format für beide Reihen und ist kein Rechnungsabgleich. Diese speziellen Automatisierungsmetriken unterstützen KPIs, tägliche Diagramme oder Tabellen sowie Aktionsaufteilungen, außer bei KI-Ausgaben. Mische sie nicht mit anderen Ticketmetriken und ergänze keine Kategorieaufteilungen.

FROM tickets
SHOW money_saved, ai_spend
TIMESERIES day
DURING last_week
VISUALIZE TYPE line

Gefilterte Teamauslastung

Prüfe gelöste deutschsprachige Tickets nach Team, einschließlich Lösungsdauer. Mehrere Filter werden mit AND verknüpft. status ist der aktuelle Ticketstatus, nicht der Status bei Erstellung. Nutze für Filter wie team, channel_type, connected_channel oder human_agent die Entitäts-IDs deines Workspaces statt Anzeigenamen.

FROM tickets
SHOW resolved_tickets, full_resolution_time
WHERE language is de
WHERE status is resolved
GROUP BY team
DURING last_week
ORDER BY resolved_tickets DESC
LIMIT 25
SET show_average_row = false
VISUALIZE TYPE data_table

Aktuell auf Kunden wartende Tickets

Zähle offene Tickets, die auf Informationen vom Kunden warten, nicht Kunden, die auf den Support warten. Die Sprache verlangt eine Datumsklausel, aber diese macht einen Snapshot nicht zu historischen Daten. Ergänze bei Snapshots weder TIMESERIES noch COMPARE TO.

FROM tickets
SHOW awaiting_response_now
DURING today
VISUALIZE TYPE kpi

Ergebnisse lesen

Diese Antwortformen nutzen erfundene Beispielwerte, keine garantierten Ergebnisse für die Beispielzeiträume. Zeilen und Datenpunkte sind gekürzt. Nutze zurückgegebene Labels und Schlüssel, statt übersetzte Labels oder feste Kanal-IDs anzunehmen. Ein KPI liefert eine Zahl und ihr Format. previousValue kann null sein; historische KPIs können auch ohne expliziten Vergleich einen Vorperiodenwert enthalten. Mit COMPARE TO wählst du den Vergleichszeitraum ausdrücklich. Snapshot-KPIs haben keinen historischen Vergleich.

{
  "success": true,
  "data": { "kind": "kpi", "value": 42, "previousValue": 38, "format": "count" }
}

Werte in Zeitreihenpunkten nutzen die Schlüssel aus series. Explizite Vergleiche ergänzen Reihenschlüssel mit der Endung __compare.

{
  "success": true,
  "data": {
    "kind": "time-series",
    "format": "count",
    "series": [
      { "key": "new_tickets", "label": "New tickets" },
      { "key": "resolved_tickets", "label": "Resolved" }
    ],
    "points": [
      { "date": "2026-08-01", "label": "Aug 1", "values": { "new_tickets": 42, "resolved_tickets": 35 } }
    ]
  }
}

Ein Kategorieergebnis enthält Werte mit Labels.

{
  "success": true,
  "data": {
    "kind": "category",
    "format": "count",
    "items": [{ "key": "channel_example", "label": "Support email", "value": 42 }]
  }
}

Eine Tabelle beschreibt Metrik und Format jeder Spalte. Addiere oder mittle keine täglichen Prozentsätze, Mediane oder Durchschnittswerte, um einen Zeitraum-KPI nachzubauen. Frage stattdessen den KPI für diesen Zeitraum ab.

{
  "success": true,
  "data": {
    "kind": "data_table",
    "rowDimension": "day",
    "columns": [
      { "measureId": "csat_average", "label": "CSAT", "format": "decimal" },
      { "measureId": "csat_responses", "label": "CSAT responses", "format": "count" },
      { "measureId": "low_csat_tickets", "label": "Low-CSAT tickets", "format": "count" }
    ],
    "rows": [
      {
        "key": "2026-08-01",
        "label": "Aug 1",
        "coordinates": [{ "dimension": "day", "key": "2026-08-01", "label": "Aug 1" }],
        "values": { "csat_average": 4.5, "csat_responses": 10, "low_csat_tickets": 1 }
      }
    ]
  }
}

Bei Zeit-/Agententabellen bleibt rowDimension die erste angefragte Dimension. Das zusätzliche Array rowDimensions listet beide Dimensionen in Request-Reihenfolge. Jede Zeile ergänzt eine dimensions-Map mit getrennten Schlüsseln und Labels. Behandle den kombinierten Zeilenschlüssel key als undurchsichtige Kennung. Tabellen mit einer Dimension behalten ihre bisherige Form; Clients müssen die neuen optionalen Felder tolerieren. Die optionale average-Zeile ist eine Anzeigezusammenfassung, keine neu berechnete Periodenmetrik. Mit SET show_average_row = false lässt du sie weg. coordinates ist der kanonische Ort für Tabellenkoordinaten; dimensions bleibt für bestehende Clients als Kompatibilitätsfeld erhalten.

{
  "success": true,
  "data": {
    "kind": "data_table",
    "rowDimension": "hour",
    "rowDimensions": ["hour", "human_agent"],
    "columns": [
      { "measureId": "agent_messages", "label": "Agent messages", "format": "count" },
      { "measureId": "agent_online_time", "label": "Agent online time", "format": "duration-seconds" }
    ],
    "rows": [
      {
        "key": "[\"2026-08-01T08:00:00.000Z\",\"agent_example\"]",
        "label": "10:00 / Alex Example",
        "coordinates": [
          { "dimension": "hour", "key": "2026-08-01T08:00:00.000Z", "label": "10:00" },
          { "dimension": "human_agent", "key": "agent_example", "label": "Alex Example" }
        ],
        "dimensions": {
          "hour": { "key": "2026-08-01T08:00:00.000Z", "label": "10:00" },
          "human_agent": { "key": "agent_example", "label": "Alex Example" }
        },
        "values": { "agent_messages": 12, "agent_online_time": 3600 }
      }
    ]
  }
}

Metrikreferenz

Unten stehen alle 58 registrierten Metrik-IDs, gruppiert wie im Katalog. Aggregation, Format und Zuordnung sind die exakten Katalogwerte. Du wählst die Metrik, keine eigene Aggregationsfunktion.

count zählt die definierten Tickets, Nachrichten, Umfragen, Aktionen oder Ereignisse; sum addiert Werte; average ist das arithmetische Mittel; median ist der mittlere Beobachtungswert; ratio teilt den passenden Zähler durch seinen Nenner.
duration-seconds liefert Sekunden, currency-eur EUR, decimal einen Dezimalwert und percent Prozentwerte: 75 bedeutet 75 %, nicht 0.75. CSAT-Werte nutzen eine Skala von 1 bis 5.
Die Zuordnung bestimmt den Datumsbezug: ticket_created ist eine Erstellungskohorte; ticket_resolved, reply_event, reopen_event, reassignment_event, survey_submitted, action_executed und order_paid beziehen sich auf das jeweilige Ereignis. agent_presence misst Online-Sitzungszeit; mixed_events kombiniert Erstellung und Lösung; current_snapshot bedeutet jetzt.
Werte einer Erstellungskohorte können sich mit den Tickets weiterentwickeln. Besonders messages und messages_per_ticket enthalten erfasste Nachrichten auf Tickets, die im Zeitraum erstellt wurden, nicht nur Nachrichten, die darin gesendet wurden. Für öffentliche menschliche Nachrichten mit Sendedatum im Zeitraum nutze agent_messages.
Aktuelle Snapshots erlauben keine Zeitdimensionen oder historischen Vergleiche. Das Alter offener Tickets zählt ab Erstellung, nicht ab der letzten Nachricht. Auch mit einer älteren Datumsklausel rekonstruiert ein Snapshot keinen Rückstand zum Periodenende.
Raten nutzen die Nenner in den Definitionen unten, innerhalb des jeweiligen Umfangs. Nullwerte oder leere Ergebnisse beweisen allein keine fehlende Aktivität: Berichtsdaten können unvollständig sein oder auf Aktualisierung warten. Prüfe wichtige Summen, bevor du sie für Zusagen oder Finanzberichte nutzt.
csat_sent und csat_answered_from_sent nutzen survey_sent als Zuordnung. Auch csat_response_rate nutzt die Versandkohorte, behält aber die bestehende Katalogzuordnung survey_submitted. Bewertungs- und Einreichungsmetriken nutzen das Einreichungsdatum.
time_saved und money_saved sind Schätzungen aus den Aktionszeiten und dem Stundensatz deines Workspaces. ai_spend rechnet erfasste KI-Credits mit einem EUR-pro-Credit-Ersatzwert um; das ist weder deine Rechnung noch eine Garantie deines Vertragspreises. Obwohl im Katalog action_executed steht, zählt für Ausgaben das Erstellungsdatum des KI-Laufs, auch an Tagen ohne erfasste Aktionen.

Volumen und Auslastung

Metrik-ID	Definition und Nenner	Aggregation	Format	Zuordnung
`new_tickets`	Im Zeitraum erstellte Tickets.	`count`	`count`	`ticket_created`
`new_tickets_share`	Eindeutige neue Tickets der Gruppe geteilt durch alle zulässigen neuen Tickets im Zeitraum mit passenden WHERE-Filtern, vor Feldwertauswahl oder Limits.	`ratio`	`percent`	`ticket_created`
`resolved_tickets`	Im Zeitraum gelöste Tickets.	`count`	`count`	`ticket_resolved`
`tickets_replied_to`	Eindeutige Tickets mit einer erfassten öffentlichen Support-Antwort im Zeitraum.	`count`	`count`	`reply_event`
`answered_tickets`	Eindeutige Tickets mit einer einem Agenten zugeordneten menschlichen oder KI-Nachricht im Zeitraum.	`count`	`count`	`reply_event`
`reopened_tickets`	Eindeutige im Zeitraum wiedereröffnete Tickets, nicht die Anzahl der Wiedereröffnungen.	`count`	`count`	`reopen_event`
`backlog_now`	Aktuell offene, ungelöste Tickets.	`count`	`count`	`current_snapshot`
`backlog_over_24h`	Offene Tickets, die vor mehr als 24 Stunden erstellt wurden.	`count`	`count`	`current_snapshot`
`backlog_over_48h`	Offene Tickets, die vor mehr als 48 Stunden erstellt wurden.	`count`	`count`	`current_snapshot`
`awaiting_response_now`	Offene Tickets, die auf Informationen vom Kunden warten, nicht auf den Support.	`count`	`count`	`current_snapshot`
`net_backlog_change`	Neue minus gelöste Tickets im Zeitraum; keine Rekonstruktion jeder Rückstandsänderung.	`sum`	`count`	`mixed_events`
`messages`	Alle Kunden-, menschlichen und KI-Nachrichten auf im Zeitraum erstellten Tickets.	`sum`	`count`	`ticket_created`
`agent_messages`	Im Zeitraum gesendete öffentliche Geschäftsnachrichten menschlicher Agenten.	`count`	`count`	`reply_event`
`messages_per_ticket`	Kunden-, menschliche und KI-Nachrichten geteilt durch im Zeitraum erstellte Tickets.	`average`	`decimal`	`ticket_created`
`agent_online_time`	Gesamte Online-Zeit der Agenten im Posteingang im Zeitraum, keine Ticketbearbeitungszeit.	`sum`	`duration-seconds`	`agent_presence`
`messages_sent_per_online_hour`	Menschliche Agentennachrichten geteilt durch deduplizierte Online-Stunden im gleichen Umfang.	`ratio`	`decimal`	`mixed_events`
`one_touch_tickets`	Gelöste Tickets mit genau einer öffentlichen Support-Antwort und ohne Wiedereröffnung.	`count`	`count`	`ticket_resolved`
`one_touch_rate`	One-Touch-Tickets geteilt durch gelöste Tickets.	`ratio`	`percent`	`ticket_resolved`
`zero_touch_tickets`	Gelöste Tickets ohne menschliche Antwort; KI oder Automatisierung kann trotzdem aktiv gewesen sein.	`count`	`count`	`ticket_resolved`
`reassignments`	Zuweisungsänderungen im Zeitraum; ein Ticket kann mehrfach zählen.	`count`	`count`	`reassignment_event`
`reassignment_rate`	Neu zugewiesene Tickets geteilt durch im Zeitraum erstellte Tickets.	`ratio`	`percent`	`ticket_created`
`demand_coverage`	Erstellte Tickets mit abschließender Lösung geteilt durch neue Tickets im Zeitraum, nicht Lösungsdurchsatz geteilt durch neue Anfragen.	`ratio`	`percent`	`ticket_created`
`support_revenue`	Support-Tickets zugeordneter Shopify-Bestellumsatz in EUR, nach Zahlungsdatum.	`sum`	`currency-eur`	`order_paid`

Antwort und Lösung

Metrik-ID	Definition und Nenner	Aggregation	Format	Zuordnung
`average_ticket_handle_time`	Gemessene Ticketzeit mit relevanter gespeicherter Aktion derselben Person in der Bearbeitungsphase. Ein Timer über alle Tabs; Stopp nach 30 Minuten Inaktivität. Inklusive begrenzter laufender Zeit. Sitzungswerte geteilt durch eindeutige Agent-Ticket-Paare im Zeitraum bzw. Abschnitt des effektiven Endes. Historische Zeiten werden nicht geschätzt.	`average`	`duration-seconds`	`ticket_work`
`customer_first_response_time`	Mediane Wartezeit bis zur ersten qualifizierenden menschlichen oder KI-Antwort.	`median`	`duration-seconds`	`reply_event`
`human_first_response_time`	Mediane Wartezeit bis zur ersten qualifizierenden menschlichen Antwort.	`median`	`duration-seconds`	`reply_event`
`human_first_response_time_mean`	Arithmetische mittlere Wartezeit bis zur ersten qualifizierenden menschlichen Antwort, mit derselben Grundgesamtheit wie der menschliche Median: bisherige Datumswerte standardmäßig, gespeicherte Antwortzeitpunkte nur mit recorded_reply-Opt-in.	`average`	`duration-seconds`	`reply_event`
`ai_first_response_time`	Mediane Wartezeit bis zur ersten qualifizierenden KI-Antwort.	`median`	`duration-seconds`	`reply_event`
`full_resolution_time`	Mediane verstrichene Zeit von Ticketerstellung bis Lösung.	`median`	`duration-seconds`	`ticket_resolved`
`full_resolution_time_mean`	Arithmetischer Mittelwert der verstrichenen Zeit von Ticketerstellung bis Lösung für im Zeitraum gelöste Tickets mit erfasster Dauer.	`average`	`duration-seconds`	`ticket_resolved`
`active_resolution_time`	Mediane Zeit innerhalb der Geschäftszeiten von Erstellung bis Lösung, abzüglich Wartezeiten auf den Kunden.	`median`	`duration-seconds`	`ticket_resolved`
`waiting_on_customer_time`	Median der gesamten Kundenwartezeit pro gelöstem Ticket innerhalb der Geschäftszeiten. Pro Ticket werden die Intervalle zwischen menschlicher Support-Antwort und nächster Kundenantwort summiert.	`median`	`duration-seconds`	`ticket_resolved`
`sla_resolution_met`	Rechtzeitig eingehaltene Lösungs-SLA-Fristen für im Zeitraum erstellte Tickets.	`count`	`count`	`ticket_created`
`sla_resolution_breached`	Überschrittene Lösungs-SLA-Fristen für im Zeitraum erstellte Tickets.	`count`	`count`	`ticket_created`

Qualität und Zufriedenheit

Metrik-ID	Definition und Nenner	Aggregation	Format	Zuordnung
`reopen_rate`	Gelöste Tickets mit Wiedereröffnung geteilt durch gelöste Tickets.	`ratio`	`percent`	`ticket_resolved`
`csat_average`	Durchschnittlicher Wert von 1 bis 5 aus im Zeitraum eingereichten bewerteten Umfragen.	`average`	`decimal`	`survey_submitted`
`csat_responses`	Im Zeitraum eingereichte bewertete Umfragen.	`count`	`count`	`survey_submitted`
`csat_sent`	Im Zeitraum versendete Umfragen, beantwortet oder nicht.	`count`	`count`	`survey_sent`
`csat_answered_from_sent`	Im Zeitraum versendete Umfragen mit Einreichung und Bewertung, auch bei Einreichung nach dem Zeitraum.	`count`	`count`	`survey_sent`
`csat_response_rate`	Im Zeitraum versendete und bewertete Umfragen geteilt durch versendete Umfragen; beachte die Versanddatum-Ausnahme oben.	`ratio`	`percent`	`survey_submitted`
`low_csat_tickets`	Eindeutige Tickets mit einem eingereichten Wert von höchstens 3.	`count`	`count`	`survey_submitted`

KI und Automatisierung

Metrik-ID	Definition und Nenner	Aggregation	Format	Zuordnung
`ai_involved_tickets`	Im Zeitraum erstellte Tickets, auf denen ein KI-Agent lief oder eine erfasste Aktion abschloss.	`count`	`count`	`ticket_created`
`ai_resolved_tickets`	Tickets, deren abschließendes Ergebnis durch einen KI-Agenten gelöst wurde.	`count`	`count`	`ticket_resolved`
`ai_resolution_rate`	KI-gelöste Tickets geteilt durch gelöste Tickets mit KI-Beteiligung, nicht durch alle eingehenden Tickets.	`ratio`	`percent`	`ticket_resolved`
`human_handoffs`	Gelöste Tickets mit erfasster KI-Übergabe an einen Menschen, nach Lösungsdatum statt Übergabezeitpunkt.	`count`	`count`	`ticket_resolved`
`handoff_rate`	Menschliche Übergaben geteilt durch gelöste Tickets mit KI-Beteiligung.	`ratio`	`percent`	`ticket_resolved`
`workflow_resolved_tickets`	Durch Workflow-Automatisierung abgeschlossene gelöste Tickets.	`count`	`count`	`ticket_resolved`
`workflow_resolution_rate`	Durch Workflows gelöste Tickets geteilt durch gelöste Tickets.	`ratio`	`percent`	`ticket_resolved`
`ai_actions`	Erfasste kundenbezogene Aktionen, die KI im Zeitraum abgeschlossen hat.	`count`	`count`	`action_executed`
`human_actions`	Erfasste kundenbezogene Aktionen, die Menschen im Zeitraum abgeschlossen haben.	`count`	`count`	`action_executed`
`action_automation_rate`	KI-Aktionen geteilt durch alle erfassten Aktionen, kein Mittelwert der Automatisierungsanteile je Ticket.	`ratio`	`percent`	`action_executed`
`time_saved`	Geschätzte durch KI-Aktionen gesparte menschliche Zeit anhand der Aktionszeiten des Workspaces.	`sum`	`duration-seconds`	`action_executed`
`money_saved`	Geschätzte EUR-Einsparung anhand gesparter Zeit und des Workspace-Stundensatzes.	`sum`	`currency-eur`	`action_executed`
`ai_spend`	Geschätzte EUR aus erfassten KI-Credits zum Ersatzwert; beachte die Laufdatum-Ausnahme oben.	`sum`	`currency-eur`	`action_executed`
`ai_reopen_rate`	Wiedereröffnete KI-gelöste Tickets geteilt durch KI-gelöste Tickets.	`ratio`	`percent`	`ticket_resolved`
`ai_csat`	Durchschnittlicher eingereichter CSAT-Wert für Tickets mit KI-Beteiligung, auf der Skala von 1 bis 5.	`average`	`decimal`	`survey_submitted`
`ai_suggestion_used_rate`	Verwendete KI-Antwortentwürfe geteilt durch angebotene KI-Vorschläge, auf im Zeitraum gelösten Tickets.	`ratio`	`percent`	`ticket_resolved`
`suggestion_fidelity`	Durchschnittlicher Anteil des akzeptierten KI-Vorschlagstexts, der in verknüpften gesendeten Nachrichten im Zeitraum erhalten bleibt.	`average`	`percent`	`reply_event`

Fehlerbehebung

Antwort	Was du prüfen solltest
`401`	Sende einen gültigen API-Schlüssel.
`403`	Vergib `analytics:read`, weise den Schlüssel einem Agenten zu und prüfe für Abfragen dessen Dashboard-Berechtigungen.
`400`	Prüfe Syntax, Metrik-IDs, Zeitzone und die Kombination aus Metrik und Gruppierung. Begrenze den Zeitraum auf 90 Kalendertage, bei Stundenberichten auf 31 Tage. Zu große Zeiträume liefern `VALIDATION_ERROR` mit `details.requested_days`, `details.max_days` und `details.timezone`. Teile die Abfrage in nicht überlappende `SINCE`/`UNTIL`-Zeiträume auf. Beide Daten sind inklusive, beginne den nächsten Zeitraum also am Folgetag. Reduziere Metriken oder Vergleiche, wenn die Abfrage ihr Ausführungsbudget überschreitet.
`429`	Warte die Zeit aus dem Header `Retry-After` ab.

Zeitraumvalidierung, eine geschätzte Aufwandsprüfung und Limits für zurückgegebene Zeilen oder Punkte garantieren weder eine allgemeine maximale Laufzeit noch eine Grenze für jede Ergebniszelle oder zugrunde liegende Datenbankoperation. LIMIT kürzt zurückgegebene Zeilen oder Punkte; es ist keine Pagination und garantiert nicht weniger Datenbankarbeit. Teile große Reporting-Aufgaben in kleinere Zeitfenster. Historische Vollständigkeit und Aktualität hängen von den verfügbaren Berichtsdaten ab; eine erfolgreiche Antwort bestätigt beides nicht. Scheitert eine gültige kleine Abfrage oder wirken Summen unvollständig, kontaktiere den Support mit der request_id aus der Antwort, der Zeitzone und einer bereinigten Abfrage. Teile niemals deinen API-Schlüssel.

​Zugriff und Limits

​Metriken entdecken

​Berichtsdaten abfragen

​Abfragesprache

​Rohe Ticketfelder

​Gruppieren und filtern

​Abfragebeispiele

​Tägliches Ticketvolumen

​Ticket-KPI für gestern

​Neue Tickets nach Kanal

​Tickets nach Kontaktgrund

​Kontaktgründe in Prozent und fehlende Werte

​Aktive Ticketbearbeitungszeit

​Zeiten bis zur ersten Antwort

​Mittelwert und Median der ersten menschlichen Antwort

​CSAT-Wert und Stichprobengröße

​CSAT-Antwortquote nach Versandkohorte und Agent

​Antworten und Online-Zeit pro Stunde

​Wöchentlich gelöste Tickets je Agent

​Monatliche Agentenaktivität

​Einsparungen und KI-Ausgaben

​Gefilterte Teamauslastung

​Aktuell auf Kunden wartende Tickets

​Ergebnisse lesen

​Metrikreferenz

​Volumen und Auslastung

​Antwort und Lösung

​Qualität und Zufriedenheit

​KI und Automatisierung

​Fehlerbehebung