Zippendo

SendungsverfolgunginEchtzeitundwassiewirklichbraucht

Jeder Versanddienstleister beschreibt ein Paket anders. Wie wir das auf neun Status normalisieren, woher die Updates kommen und was wir bewusst dir überlassen.

tutorials
Ein weißer Lieferwagen auf einer Landstraße, mitten in der Fahrt mit einem Mitzieher eingefangen

Foto von Jan Kopřiva auf Unsplash

„Wo ist meine Bestellung?“ ist die teuerste E-Mail, die ein Onlineshop bekommt. Nicht, weil die Antwort schwer wäre, sondern weil antworten heißt: die Website des Versanddienstleisters öffnen, eine Nummer einfügen, einen dänischen Status lesen, der etwas leicht anderes bedeutet als der norwegische, und das Ganze in eigenen Worten wieder abtippen.

Die Lösung ist keine schönere E-Mail-Vorlage. Sie besteht darin, den tatsächlichen Zustand des Pakets in deinem eigenen System zu haben, und zwar in einer Form, die für jeden deiner Versanddienstleister gleich ist.

Neun Status, ganz bewusst

Jeder Versanddienstleister erfindet sein eigenes Vokabular. Wir bilden alles davon auf neun Status ab:

  • created, das Versandetikett existiert und der Versanddienstleister weiß davon
  • awaiting_pickup, wartet auf die Abholung durch den Versanddienstleister
  • picked_up, das Paket ist beim Versanddienstleister
  • in_transit, unterwegs im Netzwerk
  • out_for_delivery, im Zustellfahrzeug
  • ready_for_pickup, liegt in einem Paketshop und wartet auf den Empfänger
  • delivered
  • returned
  • exception, etwas ist schiefgelaufen

delivered und returned sind Endstatus. Sobald ein Paket einen davon erreicht, fragen wir nicht mehr nach, und nichts kann es wieder herausholen. Ein Versanddienstleister, der drei Tage später ein altes Ereignis erneut sendet, macht eine Zustellung nicht rückgängig. Das klingt selbstverständlich, bis du es in einem fremden System hast passieren sehen.

Zwei Wege, auf denen die Updates ankommen

Versanddienstleister teilen sich in zwei Lager, und jedes behandeln wir nach seinen eigenen Regeln.

Die meisten bieten eine API für die Sendungsverfolgung an, also fragen wir sie ab. Ein stündlicher Job fragt nach allem, was noch keinen Endstatus hat, und ordnet zu, was zurückkommt.

Einige pushen stattdessen. Event Cast von Bring sowie Instabox, Budbee und Porterbuddy senden Ereignisse in dem Moment, in dem sie passieren. Wir abonnieren sie beim Versand, und die Ereignisse landen auf einer Callback-URL.

Push ist besser, und wir nutzen es überall, wo ein Versanddienstleister es anbietet. Aber beide Wege enden am selben Ort: bei einem Dienst, der das Ereignis dedupliziert, speichert und die Sendung aktualisiert. So sieht ein Verlauf gleich aus, egal auf welchem Weg er befüllt wurde. Du solltest weder wissen müssen noch dich darum kümmern, in welchem Lager ein Versanddienstleister steht.

Was wir bewusst nicht tun

Wir schreiben deinen Kunden keine E-Mails. Es gibt keine Seite zur Sendungsverfolgung im Zippendo-Design, die unseren Namen unter dein Liefererlebnis setzt.

Stattdessen bekommst du jedes Mal einen tracking.updated-Webhook, wenn eine Sendung ihren Status ändert, und dasselbe Ereignis steht über Klaviyo, Customer.io, Mailchimp, SendGrid, Zapier und Make zur Verfügung. Die Nachricht bleibt deine: deine Worte, deine Vorlage, deine Absenderdomain, deine Entscheidung, ob „in Zustellung“ eine SMS wert ist.

Wir halten diese Aufteilung für richtig. Du kennst deine Kunden. Wir wissen, wo das Paket ist.

Wo du anfängst

Schalte den tracking.updated-Webhook ein und richte ihn auf etwas, das mitprotokolliert. Beobachte eine Woche lang, wie echte Pakete die neun Status durchlaufen, bevor du darauf irgendetwas automatisierst. Du merkst schnell, welche deiner Versanddienstleister gesprächig sind und welche zwischendurch zwei Tage lang still bleiben, und genau das solltest du wissen, bevor du einem Kunden ein Lieferfenster versprichst.

Tags

trackingcarrierswebhooksKundenerlebnis