Speditionssoftware entwickeln: Smart Freight, vom Angebot bis zum Konnossement

Wer Speditionssoftware entwickeln will, findet in den meisten Leitfäden zuerst eine Featureliste: Ratenmanagement, Buchung, Tracking, Dokumente, Rechnungsstellung. Wir beginnen mit dem Datensatz. In der Seefracht und im Containerversand beschreiben Angebot, Buchung und Konnossement dieselbe Sendung. Liegt jedes davon in einem anderen Postfach oder System, wird abgetippt, und jedes Abtippen ist eine Stelle, an der eine Sendung ins Rutschen gerät.

Smart Freight ist der Fall hinter dieser Notiz: eine Buchungsplattform für Seefracht für Komplettladungen (Full Container Load, FCL) im britischen Markt. Logics7 baut sie seit 2024, und sie ist live. Ein Versender vergleicht Routenangebote auf einer Karte, wählt eine Tarifstufe, bucht und spricht im Chat mit dem Sendungskoordinator. Aus der Buchung wird ein Konnossement-Entwurf erzeugt, den der Agent prüft.

Im Folgenden: wo die Frachtbuchung bricht, was die Plattform tut, wie sie gebaut wurde und was sie über Make or Buy sagt.

Die Buchung eines Containers läuft noch immer über E-Mail, Telefon und Tabellen. Eine Rate kommt als Anhang. Die Regeln zu freier Standzeit und Cut-off stehen in einer Fußnote. Die Buchungsbestätigung liegt in einem Postfach, und das Konnossement wird daraus in ein anderes System abgetippt.

Jede Übergabe zwischen Versender, Agent und Reederei kostet einen Anruf, eine Verzögerung oder einen Fehler. Ein Angebot ist keine Buchungsanfrage, eine Buchungsanfrage ist keine Buchungsbestätigung, und eine Bestätigung ist kein Dokument. Trotzdem müssen dieselben Daten durch alle hindurch: Hafenpaar, Reederei, Containertyp, Fahrplan, Ladungsdaten.

Das Problem ist kein fehlendes Feature. Es ist das Fehlen eines Datensatzes, den Angebot, Buchung und Dokumente teilen, und genau das muss man zuerst lösen, wenn man Speditionssoftware entwickeln will. Buchungssoftware, die weitere Screens auf dieselbe E-Mail-Kette setzt, verlagert das Abtippen; sie beseitigt es nicht.

Smart Freight bringt den Weg vom Angebot zur Buchung und die Dokumente auf eine Buchungsplattform für Seefracht. Die Produktdetails stehen in der Fallstudie zu Smart Freight; hier geht es um die Logik.

Routenangebote und Tarifstufen

Angebote von Hafen zu Hafen erscheinen auf einer Live-Karte. Jedes zeigt Reederei, Containertyp, Cut-off, Abfahrt, Ankunft, Transitzeit und Preis, sodass der Versender Fakten vergleicht, statt auf ein Angebot per E-Mail zu warten.

Jedes Angebot gibt es in drei Tarifstufen: Standard, Flexible und All inclusive. Die Stufen legen freie Standzeit, Cut-off-Flexibilität, Demurrage und Support-Umfang vorab fest. Das ist Ratenmanagement im Moment der Wahl: Frachtraten und ihre Regeln kommen zusammen, als Teil des Angebots, nicht als Kleingedrucktes.

Buchung und Chat zur Sendung

Der Buchungsablauf führt den Versender durch Tarifstufe, Abfahrt, eine Buchungsübersicht mit Incoterms und die Bestätigungsschritte, mit dem Gesamtpreis pro Container. Berechnet wird erst, wenn der Agent die Verfügbarkeit bestätigt.

Jede Buchung hat ihren eigenen Chat mit dem Sendungskoordinator, neben den Systembenachrichtigungen. Eine Sendungsliste zeigt den Status jeder Buchung, und eine Tracking-Ansicht sorgt für Transparenz über die Sendung. Die Konversation bleibt an der Sendung, um die es geht, nicht in jemandes Postfach.

Konnossement-Entwurf

Die Plattform erzeugt aus der Buchung einen Konnossement-Entwurf mit Transportangaben und Ladungsdaten; Schiff, Reise und Häfen stehen auf jedem Dokument. Der Agent prüft den Entwurf, statt ihn abzutippen.

Das elektronische Konnossement (eBL) ist ein eigenes Thema. Die DCSA veröffentlicht einen Standard für das elektronische Konnossement; diese Notiz trifft für Smart Freight keine eBL-Aussage. Was die Plattform erzeugt, ist ein Entwurf für den Agenten.

Die folgende Abfolge ist der Kern des Produkts. Jeder Schritt gehört zum selben Sendungsdatensatz; keiner beginnt mit einem leeren Formular.

Für alle, die digitale Spedition planen, ist das beim Entwickeln von Speditionssoftware der wichtigste Teil. Die teuren Fehler liegen zwischen den Schritten, nicht in ihnen: Ein falscher Containertyp im Angebot wird zu einer falschen Buchung und dann zu einem falschen Dokument. Wenn Buchung, Konversation, Benachrichtigungen und Konnossement-Entwurf eine Sendung teilen, tippt niemand ab, was das System schon weiß.

Smart Freight ist ein Kundenprodukt. Die Rolle von Logics7 umfasst Produktstruktur, Webplattform, Buchungs-Workflow und Dokumentenautomatisierung, von 2024 bis heute. Die technischen Bausteine sind eine Webplattform, Karten und Routing, Echtzeit-Chat und Dokumentenerzeugung.

Drei Entscheidungen haben das Produkt geformt:

• →Angebote statt Mailverläufen mit Preisanfragen. Der Versender vergleicht Fakten auf einer Karte, statt auf eine E-Mail zu warten.
• →Regeln als Teil des Produkts. Freie Standzeit, Cut-off und Demurrage gehören zum Angebot, nicht ins Kleingedruckte, und berechnet wird erst, wenn der Agent die Verfügbarkeit bestätigt.
• →Ein Datensatz. Buchung, Konversation, Benachrichtigungen und Dokumente teilen dieselbe Sendung.

Keine der drei ist eine Technologieentscheidung. Jede legt fest, wie die Transaktion für Versender und Agent funktioniert, und der Code folgt daraus. Das ist das Prinzip dahinter, wie Logics7 arbeitet: keine Entwicklung ohne Produktlogik.

Es beweist, dass eine Transaktion, bei der Preis, Regeln und Dokumente übereinstimmen müssen, als ein Produkt laufen kann statt als Kette von E-Mails – ohne Transformationsprogramm.

Für Spediteure und NVOCCs lautet die erste Frage beim Entwickeln von Speditionssoftware Make or Buy, und die Antwort hängt davon ab, wo der Unterschied liegt. Standard-Speditionssuiten und NVOCC-Software decken die übliche Backoffice-Arbeit ab: Dokumentation, Zoll, Rechnungsstellung, EDI/API-Anbindung an Reedereien, Verbindungen zu einem TMS oder CRM. Passt Ihr Prozess zum Paket, kaufen Sie es. Individuelle Logistiksoftware ist sinnvoll, wenn die kundenseitige Transaktion das Produkt ist: wie Angebote dargestellt und Regeln genannt werden und wie aus einer Buchung ein Dokument wird.

Dieselbe Logik gilt für Buchungsmarktplätze, Kundenportale für den Sendungsstatus, Sendungsverfolgung, Rechnungs- und Dokumentenautomatisierung sowie operative Dashboards. Für ein neues eigenständiges Produkt ist das unsere Route Product Partnership. Für ein bestehendes Unternehmen, dessen Abläufe an Menschen und Tabellen hängen, ist es Annual Product Operations: erst der Geschäftsprozess, dann eine Jahres-Roadmap, Monat für Monat umgesetzt.