Caso de estudio
Packatrack: control de liquidaciones para la última milla
Nuestro producto propio: un SaaS B2B con roles, datos operativos, informes y suscripciones. La misma complejidad que resolvemos para nuestros clientes, asumida de principio a fin.
El problema
Un operador de reparto de última milla tiene los datos de su negocio repartidos: las rutas cerradas en una herramienta, las incidencias en WhatsApp, las tarifas en una hoja de cálculo. La liquidación del carrier llega semanas después, en otro formato, cuando el detalle operativo ya se ha olvidado. Cuando algo no cuadra, encontrar el origen cuesta horas, y un error pequeño repetido en muchas rutas se convierte en pérdida de margen real.
La decisión de producto
Packatrack no compite como planificador de rutas ni como sistema de seguimiento: son categorías saturadas y con soluciones maduras. Elegimos deliberadamente una capa más estrecha y más valiosa, la conciliación posterior a la operación, y renunciamos al resto. El producto responde a una sola pregunta: ¿nos ha pagado el carrier lo que nuestras rutas, tarifas e incidencias dicen que nos debe? No sustituye al TMS del cliente: se conecta al final del proceso.
Qué construimos
Un motor de conciliación que calcula el importe esperado de cada ruta aplicando la versión de tarifa vigente en su fecha, lo cruza con la liquidación recibida y clasifica cada referencia en cuadrada, posible desajuste, discrepancia, sin liquidar o sin operativa. Alrededor de eso: importación CSV de operativa y liquidación con validación fila a fila, reglas de incidencia con lógica de pago, cola de excepciones ordenada por impacto económico, informe de cierre mensual exportable y expediente de evidencias por cada diferencia.
Decisiones de ingeniería
El cálculo se resuelve siempre por la fecha de la ruta, nunca por la tarifa actual: un cierre antiguo recalculado hoy tiene que dar el mismo importe, y eso condiciona el modelo de datos entero (versiones de tarifa con vigencias que no pueden solaparse). El motor es TypeScript puro sin dependencias del framework, para poder moverlo del navegador al servidor sin reescribirlo. El desglose del cálculo se guarda materializado junto a cada discrepancia: un expediente ya revisado no debe cambiar porque alguien corrija una tarifa después. Y el aislamiento entre organizaciones se plantea declarativo en base de datos, no comprobado en cada consulta.
Qué cambiamos después de validar
Packatrack empezó como una app de control personal para el repartidor individual, a un precio de suscripción de consumo. Al contrastarlo, el comprador con el problema caro y repetible no era el conductor, sino el operador que cierra el mes con varias tarifas y varios formatos de liquidación. Reposicionamos el producto a SaaS B2B, rehicimos precios y mensaje, y retiramos del sitio las promesas que no sostenía. Documentar ese giro, en vez de disimularlo, es parte del caso.
Estado actual
El producto está en validación con operadores del segmento objetivo. El sitio público y el posicionamiento están cerrados; el motor de conciliación funciona como prototipo sobre datos reales anonimizados, con importación CSV y exportación del cierre. La persistencia multi-tenant, las suscripciones y los conectores con carriers están planificados y documentados, no construidos. Mantenemos esa distinción a propósito: es la misma honestidad de estado que aplicamos al informar de un proyecto de cliente.
Qué demuestra
Que en SkyQuetz no solo diseñamos software, también lo operamos. Packatrack es nuestro propio SaaS para una operación de última milla, construido con usuarios, roles, suscripciones, datos sensibles e informes. Esa experiencia de producto, incluida la disciplina de matar lo que no funciona, se aplica a cada sistema a medida que entregamos.
¿Tu operación también vive entre Excel, portales y procesos manuales? Hablemos.
Construimos software a medida para negocios en remoto, con foco en Guatemala y Santander/Cantabria. Mira también nuestro servicio de plataformas y sistemas.