2025 — heute

Nexio Fleet GmbH

Mitgründer · Strategie, Operations & Produkt

Berlin & Brandenburg, Deutschland

800+Überwachte Fahrer
8Flottenbetreiber
60–70%Weniger Verwaltungsaufwand

Deutsche Mietwagenunternehmen werden von der LABO auf Lenk- und Ruhezeiten geprüft. Die meisten erfüllen diese Pflicht mit Tabellen und Gedächtnis und gleichen Schichtexporte der Plattformen, auf denen ihre Fahrer arbeiten, von Hand ab. Wer die Rekonstruktion nicht liefert, zahlt kein Bußgeld — er verliert die Konzession. Nexio macht aus der Pflicht einen Workflow: Schichtdaten automatisch abrufen, die Lücken markieren, die eine Prüfung nicht bestehen würden, und das Paket erzeugen, das ein Prüfer verlangt.

ProduktCompliance

Die Compliance-Pipeline

Ersetzt die monatliche Rekonstruktion in Tabellen durch eine fünfstufige Pipeline, die ein Betreiber in einem Durchgang abschließt.

Ich habe die Prüfpflicht von dem her aufgeschlüsselt, was die LABO tatsächlich verlangt, und sie anschließend in Stufen zerlegt, die jeweils Maschine oder Mensch verantworten. Die ersten drei Stufen laufen unbeaufsichtigt; der Betreiber sieht nur die Schichten, die eine Entscheidung erfordern. Diesen Übergabepunkt zu definieren — was die Software still korrigieren darf und was ein Konzessionsinhaber freigeben muss — war die zentrale Produktentscheidung der gesamten Plattform.

4×/Tag pro Fahrer-Tag nur markierte signierter Export Plattform- anbindungen Normalisiertes Schichtprotokoll Pausenregel- Engine Betreiber- prüfung Prüf- berichtspaket LÄUFT UNBEAUFSICHTIGT KONZESSIONSINHABER ZEICHNET
Abb. 1 — Wo die Maschine endet und der Konzessionsinhaber beginnt. Für diese Fallstudie nachgebaut.

ProduktOperations

Schicht- und Pausenprüfung

Betreiber berichten von rund 60–70 % weniger Verwaltungsaufwand pro Compliance-Zyklus.

Der Bildschirm zeigt nur Schichten, welche die Regel-Engine nicht selbst freigeben konnte. Der Schweregrad steckt in der Zeile selbst, sodass ein Betreiber nach Farbe scannt, statt jede Zeile zu lesen — der Unterschied zwischen 214 zu prüfenden Schichten und den sechs, auf die es ankommt. Jede Anpassung wird als Eintrag im Audit-Trail zurückgeschrieben, denn eine Korrektur, die ein Betreiber später nicht begründen kann, ist schlimmer als gar keine Korrektur.

  • Ausnahmen zuerst
  • Unveränderlicher Audit-Trail
  • Zweistufiger Schweregrad
Schichtanalyse KW 37 · 214 SCHICHTEN · 6 MARKIERT FAHRER SCHICHTFENSTER LENKZEIT PAUSE GENOMMEN STATUS D-0142 06:12 — 14:38 8h 26m 42 min Konform D-0177 05:50 — 15:10 9h 20m 18 min Pause zu kurz D-0203 07:00 — 13:45 6h 45m 35 min Konform D-0219 04:30 — 15:05 10h 35m 0 min Tageslimit überschritten D-0244 08:10 — 16:00 7h 50m 45 min Konform
Abb. 2 — Nachgebauter Interface-Mock. Fahrerkennungen und sämtliche Zeiten sind erfundene Beispieldaten; kein Produktivbildschirm und kein Betreiberdatensatz wird wiedergegeben.

DatenAutomatisierung

Datenerfassung aus den Plattformen

Beseitigt den manuellen Download-Schritt vollständig — auch bei der Plattform, die keine API anbietet.

Die Fahreraktivität liegt in den Ride-Hailing-Plattformen, und nicht alle geben sie programmatisch heraus. Ich habe eine Erfassungsschicht spezifiziert, die beide Fälle als dasselbe Problem behandelt: unabhängig von der Quelle entsteht ein normalisiertes Dokument pro Fahrer-Tag. Genau diese einheitliche Form erlaubt es Regel-Engine, Dashboard und Berichtsgenerator, dieselben Daten zu lesen, ohne deren Herkunft zu kennen.

  • Python · FastAPI
  • Headless-Browser-Automatisierung
  • Firestore · Google Cloud
Plattform mit öffentlicher API Schichten · Pausen · Einnahmen Plattform ohne API Betreiber-Reportexport stündlicher REST-Abruf nächtlicher Export Erfassungs-Worker geplant · normalisieren · deduplizieren schreibt normalisierte Dokumente Dokumentenspeicher ein Dokument pro Fahrer-Tag gelesen von Pausenregel-Engine markiert Verstöße Betreiber-Dashboard prüfen + anpassen Berichtsgenerator Export des Prüfpakets
Abb. 3 — Nachgebaute Architekturskizze. Quellplattformen werden nach Integrationstyp beschrieben statt benannt.

StrategieGo-to-Market

Kommerzielle Architektur und Positionierung

Das Angebot in eine Compliance-Basis plus kostenpflichtige Module umstrukturiert und die Argumentation vollständig von Bußgeldern gelöst.

Compliance über die Drohung mit Bußgeldern zu verkaufen, rückte das Produkt gedanklich in dieselbe Kategorie wie die Rechnung des Steuerberaters — ein zu minimierender Kostenpunkt. Die Neurahmung über das Konzessionsrisiko verschob es in die Kategorie dessen, worauf ein Betreiber nicht verzichten kann. Die Preisgestaltung folgte derselben Logik: Alle zahlen für die Compliance-Basis, und die Module, die Marge statt Pflicht erzeugen, werden separat verkauft.

Betreiber reagieren auf „bestehen Sie Ihre nächste Prüfung“, nicht auf „vermeiden Sie ein Bußgeld von X €“. Das Erste ist ein Ergebnis, um das sie sich ohnehin sorgen; das Zweite eine Zahl, die sie abtun.

  • 3 Preismodule
  • Vollständiges Finanzmodell

Referenz

Referenzschreiben verfügbar

Von Aleksander Boski, CEO und Mitgründer der Nexio Fleet GmbH. Bestätigt Produktverantwortung, strategischen Beitrag und operativen Verantwortungsbereich während des frühen Aufbaus der Plattform.

Referenzschreiben öffnen

Zu den Abbildungen

Jede Abbildung auf dieser Seite wurde eigens für die Fallstudie neu erstellt. Nichts davon gibt einen Produktivbildschirm, einen Kundendatensatz oder eine Vertragskondition wieder.

  • Keine Kundennamen. Pilot- und Referenzbetreiber werden ausschließlich nach Segment und Region beschrieben.
  • Keine Plattformnamen. Integrationen werden nach Typ benannt — mit oder ohne öffentliche API — denn das ist der Teil, der die Architektur tatsächlich geprägt hat.
  • Keine echten Datensätze. Fahrerkennungen, Schichtfenster und Pausenzeiten in Abb. 2 sind erfunden und in sich stimmig, nicht aus Live-Daten entnommen.
  • Keine kommerziellen Details. Preise, Umsatzprognosen und Beteiligungsverhältnisse bleiben außen vor.