Wir führen strukturierte Fehlergründe für Stopps ein. Wenn ein Disponent oder Fahrer einen Stopp als fehlgeschlagen markiert, kann in Zukunft ein Grund aus einer vordefinierten, Stopptyp-spezifischen Liste ausgewählt werden – z. B. „Empfänger nicht erreichbar“ oder „Standort geschlossen“ – und optional ein kurzer Freitext-Kommentar ergänzt werden. Der ausgewählte Grund und der Kommentar werden am Stopp gespeichert und sind in der Buchung für alle Beteiligten sichtbar.

Die Unterstützung für Fehlergründe wird in den kommenden Wochen schrittweise über API, Dashboard und Fahrer-Apps ausgerollt.

Bisher gab es keine konsistente Möglichkeit, zu erfassen, warum ein Stopp nicht abgeschlossen werden konnte. Fahrer waren auf Freitext-Notizen oder Prozesse außerhalb des Systems angewiesen – dadurch lassen sich Muster schwer erkennen und Kunden bekommen oft keine aussagekräftige Erklärung. Standardisierte Gründe machen jeden fehlgeschlagenen Stopp zu strukturierten, vergleichbaren Daten – hilfreich für Operations, Analytics und die Kommunikation mit Kunden.

Fehlergründe werden in die kommende „Fehlschlagen mit Ergebnis“-Experience für Disponenten integriert: Die Auswahl des Grundes ist dort der erste Schritt in einem vollständigen Recovery-Flow.

Im Zuge einer größeren Überarbeitung der Fahrer-Experience erhält der Screen „Aktive Tour“ in der Fahrer-App ein konfigurierbares Set an Labels – ähnlich wie die Off-Route-Anzeige heute bereits funktioniert. Mandanten können so festlegen, welche Informationen Fahrer während einer laufenden Tour auf einen Blick sehen, und aus einer Vielzahl von Label-Typen wählen, passend zu ihren Abläufen.

Die Unterstützung für Labels bei aktiven Touren wird in den kommenden Wochen schrittweise über API, Dashboard und Fahrer-Apps ausgerollt.

Das Dashboard bekommt eine präzisere Darstellung von Touren: Statt Luftlinien-Verbindungen zwischen Stopps zeigt es künftig die tatsächliche Route, die Fahrer im Straßennetz zurücklegen. Man sieht dadurch klarer, wo Touren in der Praxis entlanglaufen und ob die Routenplanung den operativen Erwartungen entspricht.

Der Rollout der echten Routen im Dashboard erfolgt in den kommenden Wochen.

Beim Erstellen von Buchungen oder Touren kann der Service jetzt über ein menschenlesbaren Key ausgewählt werden statt die UUID nachschlagen zu müssen. Dieser wird von Admins bei der Service-Konfiguration festgelegt (z. B. „default“ oder „express“). Das ermöglich es Integrationen schneller einzurichten und weniger diese fehleranfällig.

Wir haben ein 500-Zeichen-Limit für das Feld „Zusätzliche Informationen“ bei Buchungen und Stopps sowie für das Feld „Zusätzliche Zeile“ bei Stopps eingeführt. Das Limit hilft, Benachrichtigungen an Fahrer und Kunden zuverlässig zu halten – auch bei Buchungen mit sehr langen Notizen.

Wir haben Package Failure Reasons in eine einheitliche Reasons API überführt, die alle Reason-Kategorien (Stop-Fehlschläge, Package-Fehlschläge und künftig weitere) in einem konsistenten Format abbildet. Der Legacy-Endpoint funktioniert noch bis zum 16. September 2026. Wenn eure Integration ihn nutzt, schaut bitte in den Migration Guide für Details.