Un operador de transporte turístico en Cancún y los traslados sin dobles asignaciones

Resumen:

• El chat no guarda estado: registra peticiones, no compromisos de recursos.
• El bloqueo por conflicto de horario resolvió más que cualquier algoritmo de asignación.
• Reservar solo el trayecto, y no el servicio completo, es lo que genera empalmes invisibles.
• Los vuelos retrasados obligan a diseñar para el recorrido de agenda, no para el plan perfecto.

Un operador de transporte turístico en Cancún, dieciocho unidades entre vans y sedanes, poco más de treinta conductores entre planta y eventuales. Mueve traslados de aeropuerto a hotel, excursiones a zona arqueológica y servicios privados contratados por agencias.

La operación vivía en WhatsApp. Había un grupo con los conductores, otro con los coordinadores, y conversaciones privadas del jefe de tráfico con cada chofer. El calendario del día existía en una libreta y en la memoria de una persona.

Nos buscaron después de un fin de semana malo: dos pasajeros esperando en la terminal mientras el chofer asignado estaba a treinta kilómetros, terminando otro servicio que alguien le había comprometido en paralelo.

El costo de la asignación invisible

Antes de hablar de sistemas, pedimos reconstruir los últimos dos meses. No para calcular pérdidas, sino para entender dónde se rompía la cadena. Aparecieron cuatro patrones.

El empalme puro. El mismo conductor comprometido en dos servicios con horarios que se tocan. Ocurría sobre todo con servicios cargados en días distintos: el jefe de tráfico recordaba lo que había asignado esa mañana, no lo que había prometido el martes anterior para el sábado.

El empalme por tiempo mal calculado. Más frecuente que el anterior y más difícil de ver. Dos servicios que sobre el papel no chocan, pero que en la práctica sí, porque entre uno y otro hay cuarenta minutos de regreso a posición que nadie contabilizó.

El servicio huérfano. Una agencia confirmaba por correo, el coordinador lo pasaba al grupo, y el mensaje se perdía entre otros cuarenta. Nadie quedaba asignado y nadie lo notaba hasta la hora del servicio.

La doble confirmación. El conductor preguntaba por privado si seguía en pie el servicio de mañana, el coordinador contestaba con la información que recordaba, y a veces esa información ya había cambiado.

Lo relevante de la lista es que ninguno de los cuatro problemas se resuelve con más disciplina en el chat. Un chat es un registro de conversaciones. Lo que faltaba era un registro de compromisos.

Qué se intentó antes

El operador no llegó a nosotros sin haberlo intentado. Habían pasado por dos etapas previas.

La primera fue una hoja de cálculo compartida en la nube, con una pestaña por día y una fila por servicio. Funcionó unas semanas. Se rompió porque dos coordinadores editaban al mismo tiempo, porque nadie actualizaba la hoja desde el celular en domingo, y porque la hoja no impedía escribir el mismo nombre de chofer dos veces en el mismo renglón horario.

La segunda fue una aplicación genérica de agenda de equipo. Permitía ver eventos por persona y detectaba traslapes. Falló por otro motivo: no entendía el concepto de servicio con origen, destino, pasajeros y agencia. Todo era un evento con un título de texto, y la información crítica terminaba escrita en el campo de notas, donde nadie puede buscar ni validar nada.

Ese segundo intento fue útil para nosotros. Mostró que el problema no era la visualización de un calendario, sino el modelo de datos de lo que se agenda.

Decisión uno: el recurso se reserva, no se avisa

La pieza central del sistema es sencilla de describir y fue la que resolvió el grueso del problema. Un servicio no se asigna a un conductor: reserva un bloque de tiempo de ese conductor y de esa unidad. Si el bloque se cruza con otro ya existente, el sistema no deja guardar.

Suena obvio. En la práctica obligó a definir cosas que nunca se habían escrito.

La primera: cuánto dura realmente un servicio. La respuesta inicial del cliente fue el tiempo de manejo. Insistimos y salió la versión real: tiempo de aproximación al punto de origen, margen de espera del pasajero, trayecto, maniobras de equipaje y regreso a una posición útil. Cada tipo de servicio recibió sus propios márgenes, configurables, porque un traslado de aeropuerto no tiene la misma espera que una recogida en hotel.

La segunda: qué recursos se reservan. Chofer y unidad son recursos distintos y a veces se mueven por separado, porque una unidad en taller se sustituye sin cambiar al conductor. El sistema reserva ambos de forma independiente y valida los dos.

Decisión dos: el sistema no decide, impide

La propuesta inicial que trajo el cliente era un motor que asignara solo. Lo discutimos y lo dejamos fuera de la primera versión por una razón concreta: en las entrevistas, el jefe de tráfico asignaba usando criterios que no estaban escritos en ningún lado.

Había conductores que ciertas agencias pedían por nombre. Había uno que hablaba francés y se reservaba para dos hoteles específicos. Había zonas que algunos conocían mejor. Y había una lógica de reparto de carga que buscaba que nadie terminara el mes con muy pocos servicios.

Automatizar eso sin entenderlo habría producido asignaciones correctas sobre el papel y mal recibidas en la operación. La decisión fue construir un asistente, no un sustituto: el sistema ordena los conductores elegibles mostrando quién está libre, quién tiene menos carga esa semana y quién ya trabajó con esa agencia, y la persona elige. Lo que el sistema sí hace de forma inflexible es impedir el conflicto.

Seis meses después, con historial suficiente, se añadió una sugerencia automática para los traslados estándar de aeropuerto, que son los más repetitivos. Los servicios privados y las excursiones siguen asignándose a mano, y el cliente no quiere cambiarlo.

Decisión tres: el aviso al conductor es parte del registro

El segundo problema serio era que el conductor no siempre sabía lo que tenía. La solución no fue mandar más mensajes, sino convertir el aviso en parte del flujo.

Cuando se asigna un servicio, el conductor recibe la notificación con los datos completos y un botón de acuse. El acuse queda registrado con hora. En la pantalla del coordinador, los servicios sin acuse después de cierto tiempo se destacan, y esa lista corta es lo primero que se revisa cada tarde para el día siguiente.

El cambio de comportamiento fue inmediato. Antes, la ausencia de respuesta era normal y no significaba nada. Ahora significa algo y alguien la mira.

El conductor, por su lado, abre su agenda del día siguiente en el teléfono y ve lo que tiene, con direcciones y horas. Esa fue la contraparte que hizo que la adopción no costara: el sistema no solo les exige, también les ahorra la llamada nocturna para confirmar.

El escenario que obligó a rediseñar: el vuelo retrasado

La primera versión funcionaba bien con un plan que se cumple. La realidad en Cancún no es esa. Un vuelo con dos horas de retraso desordena la tarde completa de un conductor.

El diseño original trataba el retraso como una edición: alguien cambiaba la hora del servicio y el sistema validaba. El problema es que al cambiar la hora, el servicio entraba en conflicto con el siguiente, y el sistema simplemente se negaba a guardar, dejando al coordinador con un error y sin salida en el momento de más presión.

Se rediseñó. Ahora, al recorrer un servicio, el sistema muestra en la misma pantalla qué servicios posteriores de ese conductor quedan comprometidos y ofrece reasignarlos, con la lista de quién está libre en esa ventana. El conflicto se resuelve en una pantalla y no en tres llamadas.

Ese cambio es el que más valoró el cliente, y no estaba en el alcance original porque nadie lo pidió. Apareció mirando trabajar a la mesa de control en un día malo.

Errores que cometimos

El primero fue de interfaz. La primera pantalla de asignación era una tabla, ordenada y completa, con una fila por servicio. Nadie la usaba a gusto. Lo que el jefe de tráfico necesitaba era una vista de líneas de tiempo, una por conductor, donde el hueco libre se ve como hueco y el empalme se ve como solapamiento. Cambiarlo costó dos semanas que se habrían ahorrado observando antes de diseñar.

El segundo fue de alcance. Metimos en la primera versión un módulo de cálculo de comisiones por servicio que el cliente mencionó al pasar. Se construyó, se entregó, y durante cuatro meses nadie lo abrió, porque las comisiones se seguían calculando en la hoja de siempre y cambiar eso implicaba una conversación con el área contable que nadie quería tener todavía. Fue trabajo real convertido en nada.

El tercero fue de supuestos. Asumimos que todos los conductores tendrían datos móviles suficientes. Varios eventuales no. La aplicación tuvo que guardar la agenda del día en el dispositivo y funcionar sin conexión para la consulta, dejando el acuse pendiente de envío hasta recuperar señal.

Cómo se midió

Se definieron cuatro indicadores antes de arrancar, con medición manual durante el mes previo para tener punto de partida.

• Conflictos de asignación detectados por el sistema. No es una medida de calidad del servicio, sino de cuántos errores se evitaron. El primer mes el sistema bloqueó un número de intentos que sorprendió al cliente, porque confirmó que los empalmes no eran excepcionales.
• Servicios sin acuse a la hora de corte. Bajó de forma sostenida en seis semanas y se estabilizó cerca de cero, salvo con eventuales nuevos.
• Servicios sin conductor asignado a veinticuatro horas. Este indicador existía para cazar el servicio huérfano. Dejó de aparecer en el segundo mes.
• Reasignaciones el día del servicio. No bajó, y no tenía por qué: los vuelos siguen retrasándose. Lo que cambió fue el tiempo que toma resolver cada una.

Se discutió medir también la puntualidad real contra la hora comprometida. Se dejó fuera de la primera etapa porque exigía capturar hora de llegada en cada servicio, y añadir esa captura antes de que el sistema estuviera asentado habría dado un dato de mala calidad. Se incorporó medio año después.

Preguntas frecuentes

¿Por qué falla la asignación por WhatsApp si el equipo es pequeño?

Porque el mensaje no tiene estado. Un chat registra que alguien pidió algo, no que el recurso quedó comprometido. Con ocho o diez traslados al día el jefe de tráfico sostiene el calendario en la cabeza; con cuarenta, deja de poder y empiezan los empalmes.

¿El sistema debe asignar solo o debe decidir una persona?

En este caso decide una persona y el sistema impide lo imposible. La asignación automática completa suele chocar con criterios que nadie escribió: qué chofer trata bien a cierto cliente, quién conoce una zona. Conviene empezar bloqueando conflictos y dejar la decisión al humano.

¿Cómo se calcula el tiempo que hay que reservar por traslado?

No con el tiempo de manejo en línea recta, sino con el servicio completo: traslado al punto de origen, espera, trayecto, descarga de equipaje y regreso a posición. Reservar solo el trayecto es la causa más común de empalmes que parecen imposibles sobre el papel.

¿Qué pasa con los vuelos retrasados?

Son el escenario que rompe cualquier calendario rígido. El sistema tiene que permitir recorrer un servicio y mostrar de inmediato qué otros servicios de ese chofer quedan en riesgo, para reasignarlos antes de que el conflicto ocurra, no después.

¿Los conductores aceptan que el sistema los controle?

La aceptación depende de qué les devuelve. Si solo les quita libertad, hay resistencia. Si además les da su agenda del día por anticipado, con direcciones y horarios claros, y los libra de llamadas a medianoche para confirmar, lo adoptan rápido.

Lo que quedó fuera

El cliente pidió desde el principio una integración con las plataformas de las agencias para recibir reservas de forma automática. Se dejó fuera y sigue fuera. Cada agencia tiene su propio mecanismo, algunas solo mandan correo, y construir eso antes de que la operación interna estuviera ordenada habría significado automatizar la entrada de datos a un proceso que todavía se rompía.

También se dejó fuera el seguimiento por localización de las unidades en tiempo real. Es la función que más se pide y la que menos resolvía el problema planteado: saber dónde está una van no evita que el chofer esté comprometido en dos lugares a la vez. Es una conversación distinta, con implicaciones de privacidad y de costo operativo propias, y conviene tenerla cuando el calendario ya es confiable.

Si estas en una situacion parecida

Si en tu operación los recursos se comprometen por mensajes y nadie puede decir con certeza quién tiene qué mañana, el primer paso no es elegir tecnología: es ordenar el proceso y saber que datos ya tienes. Podemos revisarlo contigo.

Cuentanos tu caso en westribe.com.mx/solicitar/ o escribenos por WhatsApp al +52 312 554 2845.