Scan-to-Label in 5 Sekunden: Engineering hinter dem Speed-USP
„Scan-to-Label in unter 5 Sekunden" steht auf der Karl-Hauptseite. Dieser Beitrag erklärt, mit welchen Architektur-Entscheidungen wir das in einem gut aufgesetzten Lager-Workflow erreichen, vom Scan des Order-Barcodes bis das Versandlabel aus dem Thermodrucker rollt.
Das Problem mit klassischem Versand-Workflow
Ein typischer Shopify-Lager-Workflow ohne Spezialisierung sieht so aus:
- Mitarbeiter öffnet Versand-App im Browser
- Sucht Order-Nummer manuell (oder per Barcode-Scan)
- Wählt Carrier aus Dropdown
- Wählt Service-Level aus Dropdown
- Klickt „Label erstellen"
- Wartet auf Carrier-API-Antwort
- Klickt „Drucken"
- Wählt Drucker (wenn nicht voreingestellt)
Das dauert real 25-60 Sekunden pro Paket. Bei 500 Paketen am Tag sind das im Worst Case 8 Stunden, die mit Klick-Arbeit verbracht werden. Plus: 6 manuelle Entscheidungen sind 6 mögliche Fehlerquellen (falscher Carrier, falsches Gewicht, falscher Service).
Karls Architektur: drei Tricks
1. Routing wird vor dem Scan berechnet
Sobald eine Shopify-Order eingeht, triggert Karl den Routing-Algorithmus asynchron. Carrier und Service werden anhand smarter Routing-Regeln bestimmt und im Karl-Cache abgelegt. Zuschlagslisten werden ebenfalls vorab geprüft. Wenn der Lagermitarbeiter Stunden später den Barcode scannt, ist die Entscheidung „welcher Carrier, welcher Service, welcher Preis" bereits getroffen. Latency-Kosten dieses Schritts beim Scan: 0 ms.
2. Carrier-API-Call wird vorab spekulativ ausgelöst
Sobald die Order im Status „bezahlt + Paketgewicht steht fest" ist, fordert Karl das Label bereits vorab beim ausgewählten Carrier an und hält es lokal vor. Wenn der Mitarbeiter scannt, wird kein neuer API-Call beim Carrier ausgelöst: das Label wird aus dem Cache geholt. Das erspart den Carrier-Roundtrip im kritischen Pfad.
3. Drucker-Push via WebSocket statt PDF-Download
Klassische Versand-Apps schicken das Label als PDF an den Browser, der Mitarbeiter klickt „Drucken", das Betriebssystem öffnet einen Drucker-Dialog. Das sind ~3 Sekunden Overhead, mit Klickbedarf.
Karl hält einen WebSocket zum Lager-PC offen (oder direkt zum netzwerkfähigen Thermodrucker via IPP). Beim Scan-Event wird das gecachte Label per WebSocket-Push direkt an den Drucker geschickt: kein Browser, kein PDF, kein Klick. Der Drucker druckt, sobald die Bytes ankommen. Was Karl beim Drucken von Versandetiketten in Shopify sonst noch mitbringt (Sammeldruck, Auto-Print, alle 7 Carrier) steht auf der Feature-Seite.
Wo die Sekunden im Workflow wirklich liegen
Die Software-Schritte von „Barcode-Scan" bis „Label rollt aus dem Drucker" sind in einem gut aufgesetzten Workflow im Sub-Sekunden-Bereich: der Routing-Lookup ist gecacht, das Label liegt vorberechnet bereit, der Druck-Push geht über eine stehende Verbindung an den Lagerdrucker. Die längste Variable ist regelmäßig der physische Druckvorgang selbst und die Netzwerk-Latenz zwischen Lager-PC und Cloud-App. Ohne die Software-Klick-Kette davor (App öffnen, Order suchen, Carrier wählen, …) bleibt unter dem Strich eine Größenordnung um die 5 Sekunden: der größere Teil davon ist Hardware, kein API-Call.
Warum das wirtschaftlich relevant ist
Die Größenordnung der Ersparnis hängt vom konkreten Workflow ab. Eine einfache Beispielrechnung: wenn ein Shop täglich 1.000 Pakete versendet und der Workflow pro Paket 25 Sekunden einspart, sind das rund 7 Stunden Arbeitszeit pro Tag, die nicht mit Klick-Arbeit verbracht werden müssen. Plus: weniger manuelle Fehlentscheidungen bei Carrier- und Service-Auswahl, weil das Routing bereits beim Ordereingang automatisiert getroffen wurde. Wer Bestellungen aus einem ERP oder WMS heraus verschicken will, spricht denselben Kern über die Versand-API von Karl an: Tarife vergleichen und Labels erstellen, ohne den Umweg über die Oberfläche.
Wenn du Karl in deinem eigenen Lager testen willst: Die App ist im Shopify App Store. Scan-to-Label ist schon im Start-Tarif dabei, und Start hat keine Grundgebühr: 0 € im Monat, 0,25 € je Label, für Versand im Inland.