> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# First-Reply-Time-Metriken lesen: Was die Zahl umfasst und wie Sie sie bewegen

> First Reply Time von Resolution Time abgrenzen, die 30-Tage-First-Reply-Kennzahl in Inbox → Analytics und im SLA-Report finden und lesen, wie Channel-Mix und Dispositionen verändern, was in die Zahl eingeht — mit ausgearbeiteten Beispielrechnungen.

# First-Reply-Time-Metriken lesen: Was die Zahl umfasst

Die First-Reply-Time (auch First-Response-Time genannt) ist die meistzitierte SLA-Zahl im Inbox — und die am häufigsten falsch gelesene. Diese Seite ist die Semantik: was die Metrik tatsächlich misst, wo die 30-Tage-Werte leben und was in sie eingeht und was nicht. Sobald Sie sie korrekt lesen, übernehmen die Seiten [SLA-Timer-Engine](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md) und [SLA-Report](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md) die Mechanik und die Live-Breach-Ansicht.

## 1. First Reply Time und Resolution Time im Vergleich

Zwei Uhren messen zwei verschiedene Versprechen:

* **First Reply Time** — die verstrichene Zeit von der ersten eingehenden Nachricht des Kunden bis zur ersten Antwort, die Ihr Team sendet. Sie misst, *wie lange ein Kunde ohne jede Antwort warten musste*.
* **Resolution Time** — die verstrichene Zeit vom Öffnen der Konversation bis zu dem Moment, in dem sie geschlossen wird. Sie misst, *wie lange das gesamte Anliegen gedauert hat*.

Eine fünfminütige Resolution in einem alten Thread kann immer noch ein First-Reply-Breach sein; eine einminütige erste Antwort, gefolgt von einer dreitägigen Resolution, ist ein Resolution-Breach. Lesen Sie beide immer getrennt. (Eine dritte Uhr, der Vollständigkeit halber: **Next-Response-Time** — die Wartezeit nach der Folgenachricht des Kunden — startet bei jedem erneuten Kontakt neu.)

Ein einziges Prädikat entscheidet, ob die First-Reply-Uhr überhaupt existiert: Sie startet nur bei einer **eingehenden** Nachricht. Ein vom Agenten initiierter Thread, den der Kunde nie beantwortet hat — eine Kampagne, eine proaktive Notiz, ein ausgehender Anruf — trägt keine First-Reply-Uhr, kann also nie als First-Reply-Breach zählen und verwässert die Metrik nie. Das zählt in den Nennern unten.

## 2. Wo die 30-Tage-First-Reply-Kennzahl gelesen wird

Drei Oberflächen, drei verschiedene Fragen:

* **Inbox → Analytics → Team performance** — die Review-Oberfläche. Die Kachel **First-response SLA** zeigt den *Anteil* der fristgerechten ersten Antworten als Prozentsatz (grün über 95 %, gelb 80–95 %, rot unter 80 %); die Tabelle **Per-agent breakdown** trägt denselben Prozentsatz je Agent, und das Aufklappen von **More metrics** ergänzt **Avg first reply** — die rohen Sekunden hinter dem Prozentsatz. Wählen Sie im Fensterauswahl **Last 30 days**, und die Zeile, die Sie im Wochenreview screenshoten, ist die Standard-30-Tage-First-Reply-Zahl.
* **Inbox → SLA report** — die Live-Oberfläche. Beantwortet „wie viele Threads liegen *jetzt gerade* über der First-Reply-Linie“, plus einer Aufschlüsselung je Channel. Sie zeigt immer den aktuellen Zustand, nicht den historischen Durchschnitt. Siehe [Den Inbox-SLA-Report lesen](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md).
* **[SLA-Eskalationsrichtlinien](https://docs.orbit.devotel.io/inbox/sla-escalation-policies.md)** — kein Metrik-Reader, sondern der Ort, der dieselbe Breach-Logik auf Queue-Ebene konsumiert: Eine Eskalationsrichtlinie je digitaler Queue entscheidet, was geschieht, wenn First-Reply-Breaches sich häufen. Lesen Sie die Metrik in Analytics oder im SLA-Report; handeln Sie sie mit Eskalationsrichtlinien ab.

Die zu erwartende Diskrepanz: Der Analytics-Prozentsatz ist eine 30-Tage-*Attainment*-Zahl; die SLA-Report-Zahl ist eine Live-*Breach*-Momentaufnahme. Sie werden nicht übereinstimmen, und beide sind richtig.

## 3. Wie Channel-Mix das Fenster weitet oder verengt

Der First-Reply-Durchschnitt ist ein Mix, und der Mix bewegt sich, wenn sich die Channel-Volumina bewegen. Läuft Ihre WhatsApp-Richtlinie mit einem 30-Minuten-Ziel und E-Mail mit einem Vier-Stunden-Ziel, zieht eine WhatsApp-lastige Woche den aggregierten Durchschnitt nach **unten**, selbst wenn sich die Geschwindigkeit je Channel nicht ändert — und ein nächtlicher SMS-Schub zieht ihn nach **oben**, wenn `business_hours_only`-Richtlinien die Uhr über Nacht anhalten.

Praxisregel: Bevor Sie einen Trend als echt deklarieren, öffnen Sie die Zeile **SLA by channel** im SLA-Report und vergleichen Sie das Attainment je Channel; lesen Sie das Aggregat erst wieder, wenn der Channel-Mix stabil ist. Ein Drilldown in **More metrics** der Per-Agent-Tabelle klärt, ob der rohe Durchschnitt sich für einen Channel bewegt hat oder für alle.

## 4. Wie Dispositionen die First-Reply-Abrechnung beeinflussen

Dispositionen sind Conversations-Ergebnislabels (Resolved, Refund issued, Escalated). Sie heften sich an den **Abschluss** einer Konversation — also an die Resolution, nicht an die erste Antwort. Die First-Reply-Time startet bei der ersten eingehenden Nachricht und stoppt bei der ersten ausgehenden Antwort, unabhängig davon, wie die Konversation später dispositioniert wird.

Wo Dispositionen *doch* ins First-Reply-Bild eingehen:

* **Das Label wird beim Schließen gestempelt**, also zählt eine Konversation, die geschlossen wurde, ohne dass je eine erste Antwort gesendet wurde (Spam, ein falsch verbundener Thread), weiterhin in die Resolution Time, lässt die First-Reply-Uhr aber unbeantwortet. Wenn Sie diese Fälle in ein eigenes Label dispositionieren (zum Beispiel „No response needed“), filtern Sie Ihre Lektüre entsprechend aus — sonst blähen sie den Resolution-Durchschnitt auf, während der First-Response-Prozentsatz sauber bleibt.
* **Wieder eröffnete Konversationen** (eine Wiedereröffnung innerhalb Ihres Re-Contact-Fensters) starten die Resolution-Uhr neu, aber die First-Reply-Uhr war bereits einmal beantwortet und bleibt beantwortet. Bereinigungs-Dispositionen halten diese Threads aus der Menge der wieder eröffneten heraus.

Für das Design dieser Label-Sets, damit das Reporting sauber bleibt, siehe [Inbox-Dispositionen entwerfen](https://docs.orbit.devotel.io/guides/inbox-dispositions.md).

## 5. Beispielrechnungen

Gearbeitet im Fallstil von [Unified inbox SLA engine](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md). Synthetische Standard-Schwellenwerte gelten, bis Sie eine Richtlinie anhängen (4 h First Response, 24 h Resolution, nur Geschäftszeiten):

**Beispiel A — erste Antwort innerhalb des Ziels, Resolution darüber.** Ein Kunde schreibt um 09:12; der Operator antwortet um 09:37 (25 Minuten First Reply), und die Konversation schließt um 11:47 (2 h 35 min Resolution). Ergebnis: First Response *nicht* breached (unter 4 h), Resolution *nicht* breached (unter 24 h) — aber lesen Sie die Uhren getrennt, denn eine längere Resolution wäre ein Resolution-Breach gewesen, während die erste Antwort sauber blieb.

**Beispiel B — vom Agenten initiierter Thread, keine First-Reply-Uhr.** Eine ausgehende Kampagnennachricht geht um 14:00 hinaus; der Kunde antwortet nie. Ergebnis: Es existiert keine First-Reply-Uhr, also kann nie ein First-Response-Breach feuern; die Resolution Time läuft von Open bis Close gegen das 24-h-Standardziel (oder Ihr Richtlinienziel). Lassen Sie solche Threads Ihren First-Response-Prozentsatz nicht verwässern — sie sind durch das Eingehende-Nachricht-Prädikat ausgeschlossen, nicht durch Sie.

**Beispiel C — Business-Hours-Richtlinie friert die First-Reply-Uhr ein.** Ein Kunde schreibt Freitag 17:40; Ihr Workspace hinterlegt Geschäftszeiten Mo–Fr 09:00–18:00, und die Richtlinie hat `business_hours_only: true`. Der Operator antwortet Montag 09:05. Ergebnis: Die erste Antwort zählt nur die Geschäftszeiten zwischen Nachricht und Antwort — 17:40–18:00 (20 Minuten) plus 5 Minuten am Montagmorgen = 25 Minuten gegen ein 30-Minuten-Ziel: innerhalb.

**Beispiel D — 30-Tage-Attainment-Prozentsatz aus Rohdaten.** Auf der Team-Performance-Seite bei Last 30 days: 1.842 eingehende Konversationen mit erster Antwort; 1.774 fristgerecht gesendet. First-response SLA = 1.774 / 1.842 = 96,3 % — grün. Die Spalte **Avg first reply** liest die rohen Sekunden jener 1.842 ersten Antworten; der Prozentsatz und der Durchschnitt beantworten verschiedene Fragen, und beide erscheinen auf der Seite.

## 6. Die Metrik über die API lesen

Die Team-Performance-Zahlen lösen sich auch in eine Endpoint-Familie auf — `GET /api/v1/inbox/team-performance/agents` (Per-Agent-Rollup) und `GET /api/v1/inbox/team-performance/trends` (Tagesserie) — sodass der Prozentsatz, den die Seite rendert, programmatisch reproduzierbar ist: `days` begrenzt das Rückblickfenster (1–90; das „Last 30 days“ der Seite ist `days=30`), und `fcr_window_hours` begrenzt das Re-Contact-Fenster (Standard 24).

```bash cURL theme={null}
curl "https://api.orbit.devotel.io/api/v1/inbox/team-performance/agents?days=30&limit=50" \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

Kein getyptes SDK deckt diese Routen ab — fallen Sie auf raw fetch zurück gemäß [How to read a worked sample](https://docs.orbit.devotel.io/guides/using-orbit-samples.md):

```typescript fetch theme={null}
const res = await fetch(
  `https://api.orbit.devotel.io/api/v1/inbox/team-performance/agents?days=30&limit=50`,
  { headers: { "X-API-Key": process.env.ORBIT_API_KEY! } },
);
const { data } = await res.json();
// data.totals.first_response_sla_attainment — the team headline; each agents[] row carries the same percentage + raw seconds.
```

**Response — 200 OK**

```json theme={null}
{
  "data": {
    "agents": [
      {
        "agent_id": "usr_8a2c…",
        "display_name": "Maya",
        "tickets_total": 214,
        "avg_first_response_seconds": 1543,
        "first_response_sla_attainment": 97.2,
        "avg_resolution_seconds": 13140,
        "resolution_sla_attainment": 92.5
      }
    ],
    "totals": {
      "active_agents": 12,
      "tickets_total": 1842,
      "first_response_sla_attainment": 96.3,
      "resolution_sla_attainment": 93.8
    }
  },
  "meta": { "request_id": "req_abc123" }
}
```

Lesen Sie die Per-Agent-Felder so, wie die Seite Beispiel D liest: `first_response_sla_attainment` ist der 0–100-Attainment-Prozentsatz, und `avg_first_response_seconds` sind die rohen Sekunden dahinter — dieselben zwei Oberflächen, die die Team-Performance-Kachel und die Per-Agent-Tabelle zeigen. Der zugehörige `/trends`-Endpoint liefert eine Zeile je Tag im Fenster, sodass die Serie `first_response_sla_attainment` das Attainment über die Zeit chartet statt als einzelnes 30-Tage-Rollup.

## 7. Zwei Lesebeispiele: Trend oder Ausreißer, Besetzung oder Fähigkeit

Lesen Sie die Tagesserie, bevor Sie eine Veränderung für echt halten. Ein Rückgang von 96 % auf 89 % für drei Tage, gefolgt von einer Rückkehr auf 96 %, ist ein Ausreißer: Prüfen Sie Queue-Ausfall, Kampagnenspitze oder Channel-Mix, bevor Sie die Besetzung ändern. Ein Rückgang, der bei stabilem Channel-Mix und Volumen anhält, ist ein Trend; vergleichen Sie die Agentenzeilen, bevor Sie das Ziel ändern.

Wenn der Teamdurchschnitt fällt, trennen Sie **Besetzung** von **Fähigkeit**. Wenn alle Agents an denselben Tagen schlechter werden, ist Abdeckung oder Eingangsvolumen die wahrscheinliche Ursache. Wenn sich ein Agent oder ein Channel bewegt, während die anderen stabil bleiben, prüfen Sie Konversationen und den Coaching-Weg auf eine Fähigkeits- oder Workflow-Ursache. Übergeben Sie die Belege an [QA-Evaluierungen](https://docs.orbit.devotel.io/guides/quality-evaluations.md) für eine bewertete Prüfung und üben Sie das verfehlte Muster anschließend in [Practice Studio Roleplay](https://docs.orbit.devotel.io/guides/practice-studio-roleplay.md).

## Was First-Reply-Time nicht ist

First-Reply-Time ist nicht Resolution Time, die Live-Breach-Zahl oder ein Versprechen, dass jede Konversation eine Antwort erhält. Agenten-initiierte Threads ohne eingehende Nachricht sind ausgeschlossen; warum eine Antwort spät war, erklärt die Metrik erst zusammen mit Channel-, Abdeckungs- und Agentenkontext.

## Siehe auch

* [Unified inbox SLA engine](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md) — die Timer-Mechanik, die diese Seite semantisch liest
* [Den Inbox-SLA-Report lesen](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md) — die Live-Breach-Oberfläche
* [Team-Performance-Analytics](https://docs.orbit.devotel.io/guides/inbox-team-performance.md) — das 30-Tage-Review-Deck, in dem First-response SLA und Avg first reply leben
* [SLA-Eskalationsrichtlinien je digitaler Queue](https://docs.orbit.devotel.io/inbox/sla-escalation-policies.md) — wiederkehrende First-Reply-Breaches auf Queue-Ebene abhandeln
* [Inbox-Dispositionen entwerfen](https://docs.orbit.devotel.io/guides/inbox-dispositions.md) — Label-Sets, die das Abschluss-Reporting sauber halten


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.