Un cliente de logística ya no quiere descolgar el teléfono para saber dónde está su paquete. Abre una aplicación, escribe un número de seguimiento y espera un mapa, un estado y una ETA realista. Si no lo obtiene de ti, encontrará un transportista que se lo dé. Por eso el seguimiento de envíos y un portal de cliente han dejado de ser un extra agradable para formar parte del propio servicio.
Por nuestra experiencia, el cuello de botella rara vez es la idea de funcionalidades. Lo difícil es construir un seguimiento y trazabilidad capaz de soportar el tráfico, enchufarse a tu TMS y a la telemática, y seguir teniendo sentido para un cliente no técnico. Aun sin enseñar un despliegue concreto en este sector, aportamos a las personas y las competencias que diseñan y mantienen esos sistemas, en modelo de refuerzo de equipo o de equipo dedicado.
¿Qué espera realmente hoy un cliente de logística?
Las expectativas se han desplazado con fuerza hacia el autoservicio: el cliente quiere resolverlo por su cuenta, a cualquier hora, sin llegar a un gestor de cuenta. Eso se traduce en unos pocos requisitos duros para el software.
- Visibilidad en tiempo real - dónde está el envío y qué le ha pasado.
- Una ETA fiable - no «a final de semana», sino una ventana horaria concreta.
- Información proactiva - un aviso antes de que el cliente empiece a preocuparse.
- Un único punto de acceso - un portal que muestre todos los pedidos, no enlaces dispersos.
Cumplir estas expectativas reduce el volumen de llamadas, porque la mayoría de los «dónde está mi envío» se responden sin una persona.
¿Cómo diseñar una página de seguimiento de envíos (estados, eventos, ETA)?
Una página de seguimiento y trazabilidad parece simple y, sin embargo, por debajo está dirigida por eventos. Su núcleo es el historial de eventos del envío (event log): recibido en el almacén, cargado, transbordado en el hub, en reparto, entregado. Cada evento lleva una marca de tiempo, una ubicación y su fuente, y de ahí derivamos el estado actual y la ETA prevista.
Diseñamos el modelo de datos de forma que un evento técnico (un escaneo bruto, una señal de telemática) quede separado del estado que se muestra al cliente, lo que nos permite añadir una fuente o renombrar estados sin rehacer la pantalla. Calculamos la ETA a partir de datos históricos y de la posición actual del vehículo, no de un plan fijo, porque solo entonces vale algo.
¿Cómo construir un portal de cliente y un portal de socios (autenticación, roles)?
Un portal es donde el cliente entra para ver la imagen completa de sus pedidos, mientras que un socio o un transportista ve solo su parte. La autenticación y los roles son el meollo, porque deciden quién ve qué.
- Autenticación - email y contraseña, inicio de sesión corporativo (SSO, OAuth) y, opcionalmente, un segundo factor.
- Modelo de roles (RBAC) - expedidor, destinatario, transitario, transportista, administrador de la cuenta.
- Multi-tenancy - un portal que atiende a muchas empresas cliente, con los datos separados.
- Permisos sobre los datos - el cliente ve sus pedidos, el socio sus tareas, nadie los ajenos.
La mayor trampa aquí no es el aspecto, sino aislar limpiamente los datos entre tenants, así que diseñamos la división de permisos desde el primer día en lugar de añadirla después.
¿Cómo gestionar la prueba de entrega (POD: firma, foto, geolocalización)?
La prueba de entrega cierra el ciclo de vida de un envío y a menudo sirve de evidencia en disputas. Hoy rara vez es papel: el conductor confirma la entrega en una aplicación móvil, y el sistema reúne un conjunto completo de pruebas y las ata al pedido.
Eso suele significar una firma del destinatario en la pantalla, una foto del paquete o del punto de entrega, y la geolocalización y la marca de tiempo de la entrega. Lo diseñamos para trabajar sin conexión, porque un conductor en carretera pierde cobertura con regularidad: la app guarda la prueba de entrega localmente y la sincroniza cuando vuelve el enlace, de modo que no se pierde ninguna prueba. La confirmación aparece después en el portal de cliente como parte del historial del envío.
¿Cómo construir las notificaciones y las alertas de excepción (eventos)?
Un buen seguimiento y trazabilidad no espera a que el cliente consulte el estado; envía una señal cuando algo importa. Conviene separar dos tipos de mensaje: las notificaciones rutinarias de progreso y las alertas de excepción, es decir, situaciones que exigen una reacción.
- Notificaciones de eventos - recibido, en reparto, «sale hoy», entregado.
- Alertas de excepción - retraso, entrega fallida, daño, bloqueo en aduana.
- Canales - email, SMS, push en la aplicación y un webhook para clientes con sistema propio.
- Reglas - quién recibe qué alerta y tras cuánto tiempo salta un escalado.
Construimos estas alertas sobre el mismo flujo de eventos que alimenta la página de seguimiento, para que el cliente y el operador vean siempre lo mismo.
¿Cómo conectarlo con el TMS y la telemática?
Un portal vale lo que valgan los datos que entran en él. Esos datos rara vez nacen en el propio portal, así que el trabajo de verdad es integrar con el TMS y con la telemática de los vehículos. Del TMS traemos pedidos, rutas y estados operativos; de la telemática y de los móviles de los conductores, la posición GPS y los eventos en ruta.
Unimos estas fuentes con una capa de integración, normalmente mediante APIs y webhooks, y mediante ficheros (EDI, CSV) cuando un socio intercambia datos por lotes. La normalización importa: distintos transportistas y dispositivos describen los mismos eventos de forma diferente, así que los mapeamos a un vocabulario de estados común antes de que lleguen al cliente. El portal muestra entonces una imagen coherente, sin importar cuántos sistemas lo alimenten.
¿Qué competencias aportamos a un proyecto así?
Damos forma al equipo según el alcance concreto, no «por si acaso». Un proyecto de seguimiento y trazabilidad abarca un backend dirigido por eventos, una app para conductores e integraciones, así que suele necesitar varios roles.
- Un desarrollador de backend que construye el modelo de eventos, las APIs y la lógica de estados y ETA.
- Un desarrollador de frontend que monta el portal de cliente y la página de seguimiento.
- Un desarrollador móvil responsable de la app con prueba de entrega y trabajo sin conexión.
- Un especialista en integraciones que conecta el TMS, la telemática y el intercambio de datos con socios.
- Un especialista DevOps que levanta la nube, el CI/CD y la monitorización para tráfico de producción.
Cubrimos estos roles con especialistas verificados antes de empezar. Opcionalmente añadimos una capa de IA/Datos (dentro del RITS Group, nuestros equipos de IA/LLM/datos desarrollan las competencias de LLM y datos) para predecir la ETA o detectar anomalías en ruta, pero lo tratamos como un conjunto de competencias, no como una caja ya hecha.
¿Cómo lo hacemos en RITS?
Trabajamos como partner nearshore desde Polonia, con experiencia en proyectos industriales y en sistemas que unen dispositivos, nube y aplicaciones. No fingimos tener un seguimiento y trazabilidad ya hecho en un cajón; en su lugar, te damos a las personas que diseñarán y mantendrán ese sistema junto a tu equipo.
- Cubrimos los roles según la especificación del proyecto y verificamos las competencias antes de que nadie se incorpore.
- Entramos en modelo de refuerzo de equipo o de equipo dedicado, según si ya tienes un equipo base.
- Trabajamos en una zona horaria cercana, así que las revisiones de código y las reuniones funcionan sin una rampa larga.
- Diseñamos el seguimiento y la trazabilidad de extremo a extremo: desde el flujo de eventos, pasando por la prueba de entrega, hasta las integraciones.
Para un producto nuevo suele ser un proyecto de software a medida; para desarrollar un portal existente, refuerzo de equipo. Expusimos las diferencias entre estos modelos en nuestro artículo sobre modelos de colaboración en TI.
¿Por dónde empezar con el seguimiento y el portal?
Empieza por la pregunta de cliente que más golpea a soporte (normalmente «dónde está mi envío y cuándo llega»). Responderla define el modelo mínimo de eventos, la primera pantalla de seguimiento y trazabilidad y la integración que hay que construir primero. El resto del portal lo añades por capas cuando esa base funciona.
¿Construyes un seguimiento de envíos o un portal de cliente logístico? Hablemos - ajustaremos un equipo y una arquitectura a tu seguimiento y trazabilidad.
Construye con nosotros el seguimiento de envíos y el portal de cliente