2025 — actualidad

Nexio Fleet GmbH

Cofundador · Estrategia, Operations y Producto

Berlín y Brandeburgo, Alemania

800+Conductores monitoreados
8Flotas
60–70%Menos administración

Las empresas alemanas de Mietwagen (transporte con conductor bajo licencia) son auditadas por la LABO (la autoridad de licencias de Berlín) sobre los Lenk- und Ruhezeiten (tiempos de conducción y descanso). La mayoría cumple esa obligación con hojas de cálculo y memoria, conciliando a mano las exportaciones de turnos de las plataformas en las que trabajan sus conductores. Quien no entrega la reconstrucción no recibe una multa: pierde la Konzession. Nexio convierte la obligación en un flujo de trabajo: extraer los datos de turnos automáticamente, marcar los huecos que no superarían una auditoría y generar el paquete que pide un auditor.

ProductoCompliance

El pipeline de compliance

Sustituyó la reconstrucción mensual en hojas de cálculo por un pipeline de cinco etapas que un operador termina de una sola vez.

Desglosé la obligación de auditoría a partir de lo que la LABO realmente exige y luego la dividí en etapas de las que se responsabilizan la máquina o la persona. Las tres primeras etapas corren sin supervisión; el operador sólo ve los turnos que requieren una decisión. Definir ese punto de traspaso — qué puede corregir el software en silencio y qué debe autorizar el titular de la Konzession — fue la decisión de producto central de toda la plataforma.

4×/día por conductor-día sólo marcadas exportación firmada Integraciones de plataforma Registro de turnos normalizado Motor de reglas de pausas Revisión del operador Paquete de auditoría SIN SUPERVISIÓN FIRMA EL TITULAR
Fig. 1 — Dónde termina la máquina y empieza el titular de la Konzession. Reconstruido para este caso de estudio.

ProductoOperations

Revisión de turnos y pausas

Los operadores reportan alrededor de 60–70 % menos carga administrativa por ciclo de compliance.

La pantalla sólo muestra los turnos que el motor de reglas no pudo resolver por su cuenta. La gravedad está codificada en la fila misma, de modo que el operador escanea por color en lugar de leer cada línea — la diferencia entre revisar 214 turnos y revisar los seis que importan. Cada ajuste se escribe como una entrada del audit trail, porque una corrección que el operador no pueda justificar después es peor que ninguna corrección.

  • Vista de excepciones primero
  • Audit trail inmutable
  • Gravedad en dos niveles
Análisis de turnos SEMANA 37 · 214 TURNOS · 6 MARCADOS CONDUCTOR VENTANA DE TURNO CONDUCCIÓN PAUSA TOMADA ESTADO D-0142 06:12 — 14:38 8h 26m 42 min Conforme D-0177 05:50 — 15:10 9h 20m 18 min Pausa muy corta D-0203 07:00 — 13:45 6h 45m 35 min Conforme D-0219 04:30 — 15:05 10h 35m 0 min Excede límite diario D-0244 08:10 — 16:00 7h 50m 45 min Conforme
Fig. 2 — Maqueta de interfaz reconstruida. Los identificadores de conductor y todos los horarios son datos de ejemplo inventados; no se reproduce ninguna pantalla de producción ni registro de operador.

DatosAutomatización

Ingesta de datos de las plataformas

Eliminó por completo el paso de descarga manual — incluso en la plataforma que no ofrece API.

La actividad de los conductores vive dentro de las plataformas de ride-hailing, y no todas la exponen de forma programática. Especifiqué una capa de ingesta que trata ambos casos como el mismo problema: sea cual sea la fuente, la salida es un documento normalizado por conductor-día. Esa forma única es lo que permite que el motor de reglas, el panel y el generador de informes lean los mismos datos sin saber de dónde vienen.

  • Python · FastAPI
  • Automatización de navegador headless
  • Firestore · Google Cloud
Plataforma con API pública turnos · pausas · ingresos Plataforma sin API exportación de reportes consulta REST por hora exportación nocturna Worker de ingesta programado · normalizar · deduplicar escribe documentos normalizados Almacén de documentos un documento por conductor-día leído por Motor de reglas de pausas marca infracciones Panel del operador revisar + ajustar Generador de informes exportación del paquete
Fig. 3 — Esquema de arquitectura reconstruido. Las plataformas de origen se describen por tipo de integración en lugar de nombrarse.

EstrategiaGo-to-market

Arquitectura comercial y posicionamiento

Reestructuró la oferta en una base de compliance más módulos de pago, y sacó el discurso comercial del terreno de las multas.

Vender compliance con la amenaza de multas ubicaba al producto en la misma categoría mental que la factura del contador: un costo a minimizar. Replantearlo en torno al riesgo sobre la Konzession lo movió a la categoría de aquello sin lo cual un operador no puede funcionar. El modelo de precios siguió la misma lógica: todos pagan la base de compliance, y los módulos que generan margen en lugar de obligación se venden por separado.

Los operadores responden a «supere su próxima auditoría», no a «evite una multa de X €». Lo primero es un resultado que ya les preocupa; lo segundo, una cifra que descartan.

  • 3 módulos de precios
  • Modelo financiero completo

Referencia

Carta de referencia disponible

De Aleksander Boski, CEO y cofundador de Nexio Fleet GmbH. Acredita la responsabilidad sobre el producto, la contribución estratégica y el alcance operativo durante la construcción temprana de la plataforma.

Abrir carta de referencia

Sobre las figuras

Cada diagrama de esta página fue dibujado desde cero para el caso de estudio. Nada de lo aquí mostrado reproduce una pantalla de producción, un registro de cliente ni una condición comercial.

  • Sin nombres de clientes. Los operadores piloto y de referencia se describen únicamente por segmento y región.
  • Sin nombres de plataformas. Las integraciones se identifican por tipo — con o sin API pública — que es lo que realmente moldeó la arquitectura.
  • Sin registros reales. Los identificadores de conductor, las ventanas de turno y los tiempos de pausa de la Fig. 2 son inventados y coherentes entre sí, no tomados de datos en vivo.
  • Sin detalle comercial. Se omiten precios, proyecciones de ingresos y participación accionaria.