Wir arbeiten an einem standardisierten Retourenprozess – einem definierten Ablauf für den Fall, dass ein Fahrer eine nicht zustellbare Bestellung zum ursprünglichen Abholort zurückbringen muss. So entsteht ein konsistenter, plattformweit definierter Ablauf für fehlgeschlagene Zustellungen in allen Mandanten.

Retouren können aus verschiedenen Gründen notwendig werden – verpasste Zustellungen, fehlgeschlagene Verifizierungen, falsche Adressen – und jedes davon braucht einen verlässlichen, einheitlichen Ablauf. Ohne einen plattformweit definierten Retourenprozess können Retouren nicht sauber in andere Workflows integriert werden, wie zum Beispiel in das kommende DOB-Handshake-Feature.

Wir starten mit dem Kernretourenprozess und bauen darauf auf. Als Nächstes folgen erneute Zustellversuche (Redelivery Attempts). Danach erweitern wir den Umfang schrittweise auf weitere Szenarien für fehlgeschlagene Zustellungen. Wenn ihr konkrete Use Cases aus dem operativen Alltag habt, gebt uns gern Bescheid!

Wir rollen aktuell ein automatisches Eigenschaften-Upgrading aus. Dabei wird die benötigte Fahrer-Eigenschaft anhand der Auftragsdetails angepasst, zum Beispiel basierend auf Anzahl und Wert der Artikel. Überschreitet eine Bestellung etwa das, was ein Fahrradkurier sinnvoll transportieren kann, wird automatisch ein Auto als erforderliches Fahrzeug gesetzt. So steigt die Wahrscheinlichkeit, dass der zugewiesene Fahrer den Auftrag erfüllen kann, und fehlgeschlagene Zustellungen aufgrund von falschen Kapazitäten werden reduziert.

Organisationsmanager, die mehrere Organisationen verwalten, können jetzt festlegen, in welche Organisation ein Fahrer eingeladen werden soll. Das ist heute bereits über die API verfügbar. Unterstützung im Dashboard folgt in den nächsten Wochen. Bisher wurden eingeladene Fahrer immer der ersten verwalteten Organisation des Managers zugeordnet. Wenn keine Ziel-Organisation angegeben ist, bleibt das Verhalten unverändert.

Der booking.in_progress Webhook wurde erweitert. Er wird nun nicht nur ausgelöst, wenn eine Tour initial in den Status „Auf dem Weg“ wechselt, sondern auch dann, wenn Buchungen in eine bereits aktive Tour disponiert werden. So erhalten Integrationen konsistente Benachrichtigungen für alle Buchungen – unabhängig davon, wann sie der Tour hinzugefügt wurden.

Wir haben die Nutzererfahrung beim Hinzufügen eines Stops zu einer bestehenden Buchung oder einer Tour verbessert. Das aktualisierte Modal zeigt jetzt eine Vorschau des Stopp-Standorts auf der Karte und erlaubt es, den Stopp mit einem Ort zu verknüpfen. Dadurch bleiben Standortdaten sauber und konsistent.