Llamadas de control a conductores, automatizadas para equipos de logística

En una empresa de transporte, logística o intermediación de cargas de 50 a 100 personas, una llamada de control casi nunca es una sola llamada. Un técnico de tráfico localiza la carga, llama al conductor, espera respuesta, la apunta y actualiza el TMS o la hoja de seguimiento, y repite el ciclo en cada turno y en cada zona horaria. El trabajo importa, pero la conversación es repetitiva. Un buen proceso de voz para logística elimina el copiar y el perseguir, y deja el criterio en manos de tráfico.

La unidad útil no es una marcación. Es un punto de control actual y atribuible que permite al siguiente responsable decidir qué hacer. La automatización debe hacer que una carga que va según lo previsto se lea de un vistazo y que una incidencia sea difícil de pasar por alto. Para eso hay que definir la fuente de cada dato, su vigencia, la identidad de quien lo da y el evento que da por cerrado el trabajo.

Separar los controles rutinarios de las incidencias

La mayoría de las llamadas de control hacen preguntas previsibles: ¿ha llegado el conductor? ¿Está cargada la mercancía? ¿Dónde está el camión? ¿Sigue siendo realista la hora estimada de llegada? ¿Se ha aceptado la entrega? Un control rutinario confirma un evento esperado o un estado estable. Normalmente puede cerrarse con un estado estructurado, la hora observada, el siguiente control previsto y sin pasar la llamada a nadie.

Una incidencia cambia el plan operativo o exige una decisión. Por ejemplo: una llegada tarde, una espera en el muelle, una carga rechazada o incompleta, daños, una avería, un límite de tiempos de conducción y descanso, un cambio de ruta, documentación que falta, un destinatario cerrado o un conductor que no puede seguir. La falta de respuesta pasa a ser una incidencia cuando se supera el número de intentos acordado o la ventana de vigencia. Para cada incidencia, defina la categoría, la gravedad, el responsable, la siguiente acción, el plazo y la condición de pausa antes de que el agente entre en producción.

No reduzca estos estados a un único resultado del tipo «comprobado» o «contactado». Una llamada atendida puede dejar una incidencia sin resolver, y una llamada perdida puede dejar la carga en estado desconocido, no necesariamente con retraso. El registro debe ayudar al técnico de tráfico a ordenar el trabajo por riesgo y plazo, no premiar al sistema por haber contactado.

Controles adaptados a cada carga

Recogida

En la recogida, confirme la referencia de la carga o del viaje, el estado de la cita, la hora de llegada, el estado de la carga, la hora de salida y cualquier problema con el número de bultos, el precinto o la documentación. Si el conductor está esperando, anote el almacén, la hora de llegada, el motivo que le han dado y si ya se ha hablado con alguien del almacén. Mantenga la cita prevista separada del evento observado, para que la cronología del TMS muestre el plan y la realidad.

En ruta

En un control en ruta, confirme la referencia de la carga, la ubicación aproximada o el último punto seguro de parada, si el camión está en marcha, la mejor estimación de llegada y cualquier cosa que pueda cambiarla. No pida al conductor que escriba, haga fotos o gestione una interacción detallada mientras conduce. Si la ubicación o la hora estimada necesitan una confirmación cuidadosa, ofrezca devolver la llamada cuando el conductor esté parado. Una ubicación que da el conductor es una declaración observada, no la prueba de una posición GPS.

Entrega

En la entrega, confirme la llegada, el estado de la descarga o de la cita, la hora real de entrega, si el albarán firmado está disponible y cualquier daño, falta o rechazo. Un rechazo es una incidencia, no una entrega completada. Derívelo a una persona con el almacén, la referencia de la carga, el motivo que se ha dado, las pruebas disponibles y la decisión que hace falta, también cuando el destinatario está cerrado o hay que cambiar la cita.

Que se vea la vigencia de cada dato

Cada punto de control tiene una antigüedad. Guarde la marca de tiempo de la fuente, la zona horaria, cuándo se intentó la llamada, cuándo respondió el conductor y cuándo se escribió el registro. La ubicación de un conductor por la mañana puede ser un contexto útil, pero no debe mostrarse como actual por la tarde. Una hora estimada no es una llegada observada, y un estado «cargado» antiguo no debe tapar una incidencia posterior.

Fije ventanas de vigencia por fase y por riesgo en lugar de usar una única cifra para todo. El estado de una recogida puede tener que estar al día alrededor de la cita; una actualización en ruta puede valer durante otro intervalo; una incidencia en la entrega puede necesitar revisión humana inmediata. Cuando el último evento de la fuente queda fuera de su ventana, marque la carga como desactualizada y pida una nueva observación o cree una tarea para tráfico. No actualice nunca una marca de tiempo solo porque se leyó un registro o se intentó una llamada.

Verificar la identidad del conductor y del transportista

Antes de dar datos de la carga o aceptar una actualización con consecuencias, cruce la carga con el conductor y el transportista aprobados para ese proceso. Un número de teléfono es una buena pista para enrutar, pero no basta como prueba de identidad: los números cambian, las oficinas de tráfico comparten líneas, los conductores en equipo se cambian el móvil y un transportista puede subcontratar un servicio. Use la combinación mínima aprobada de referencia de la carga, relación con el conductor o el transportista y un dato de confirmación que no sea sensible. No pida información personal innecesaria.

Guarde en campos separados la identidad del conductor, la del transportista y la autoridad de quien habla. Quien responde puede ser el conductor, alguien de tráfico del transportista, un contacto intermedio o alguien que se ha equivocado de número. Si la referencia no coincide, coinciden dos registros, la persona no puede confirmar el dato aprobado o la asignación del transportista está desactualizada, pare antes de revelar la ubicación, el destinatario u otros datos de la carga. Registre la discrepancia de identidad y derívela al responsable que corresponda. Que una voz segura o un número conocido nunca conviertan una coincidencia dudosa en una escritura.

Recoger el registro mínimo útil

Antes de escribir un guion largo, acuerde el registro más pequeño que hace accionable un control:

• Referencia de la carga, del envío o del viaje, con la identidad del conductor, la del transportista y el estado de la coincidencia.
• Punto de control, ID del intento, marca de tiempo del evento, marca de tiempo de la llamada y zona horaria.
• Estado observado, ubicación o punto de parada seguro, hora estimada de llegada y fuente de cada valor.
• Estado de vigencia, categoría de la incidencia, nota factual, urgencia, siguiente acción, responsable y plazo.
• Resultado del intento, consentimiento o preferencia de contacto cuando se exija, y resultado de la escritura en el sistema.

Use valores cerrados para el estado y el tipo de incidencia, con una breve nota factual como contexto. Separe «lo que dijo el conductor», «lo que devolvió el sistema» y «lo que decidió tráfico». Así los informes son comparables y tráfico puede actuar sin volver a escuchar la llamada. Además, los datos desactualizados quedan a la vista y la última actualización correcta no pasa por ser la verdad más reciente.

Una matriz de decisión compacta para las llamadas de control

La matriz siguiente es una hoja de trabajo inicial para un piloto. Adapte los umbrales a las ventanas de cita, los acuerdos con transportistas y la cobertura de traspaso de la operación, y lleve los valores finales a la definición del proceso.

Escribir en el TMS y dejar el mando a tráfico

La llamada solo está completa cuando el resultado llega adonde el equipo gestiona las cargas. Asigne cada resultado al objeto correcto del TMS o del CRM: estado del envío o de la carga, marca de tiempo del hito, código de incidencia, tarea, nota y siguiente seguimiento. La capa de integración debe pasar la referencia de la carga, el ID del intento y el resultado estructurado, no solo el texto de la llamada. Así se pueden montar colas de recogidas con retraso y de seguimiento a transportistas sin volver a teclear nada.

Documente qué campos puede leer el agente, cuáles puede escribir y cuáles solo puede proponer para que los apruebe una persona. Empiece con acceso de solo lectura y escrituras reversibles de bajo riesgo. Para cada escritura, defina la fuente de verdad, los valores permitidos, la confirmación necesaria, el evento de auditoría y la respuesta ante un fallo. Pedir una escritura no es haberla hecho. El agente solo debe decir que un estado se ha actualizado cuando el sistema receptor lo confirme.

Diseñe pensando en fallos parciales y repeticiones. Si la llamada termina pero el TMS no está disponible, conserve el resultado estructurado y cree una tarea de conciliación. Si un tiempo de espera agotado deja el resultado en el aire, reintente con un intento idempotente o compruebe el registro antes de volver a escribir. Si la actualización del TMS funciona pero falla el resumen, muestre al equipo el estado parcial. Una actualización fallida o rechazada debe estar en una cola de revisión visible, no en un registro que se presenta como actual.

La responsabilidad de tráfico tiene que ser explícita. Cada cola de incidencias necesita un equipo con nombre, una regla de gravedad, una regla de plazos, un respaldo para el traspaso y una definición de cierre. Tráfico decide si contacta con el cargador, el transportista, el almacén o el conductor, si cambia el plan o si lo deja como está. La automatización reúne los hechos y deja clara la siguiente decisión; no negocia tarifas, no aprueba cargos adicionales, no promete citas, no interpreta contratos ni replanifica cargas en silencio.

Ventanas de reintento y reglas para cuando nadie responde

La falta de respuesta es un estado operativo, no un campo en blanco. Defina ventanas de reintento en torno a la cita y al movimiento esperado en lugar de usar la misma cadencia para todas las cargas. Una llamada antes de la recogida puede reintentarse antes que un control en ruta, que puede esperar a que el conductor probablemente esté parado. Respete las normas locales sobre llamadas, las franjas en las que no se llama, las preferencias del transportista y cualquier exclusión.

Dé a cada intento un ID y registre la hora, la ruta, el resultado y el siguiente intento permitido. Use una política finita: por ejemplo, un primer intento, un reintento limitado tras un intervalo razonable y después una tarea para una persona. Los intervalos exactos los fija la operación, pero la política debe decir cuándo espaciar, cuándo escalar de inmediato y cuándo parar. No vuelva a marcar indefinidamente, no trate un buzón de voz como un estado confirmado, no borre el historial de intentos fallidos tras una conexión ni siga reintentando después de que alguien pida no ser llamado.

Escale antes en caso de recogida perdida, rechazo en la entrega, problema de seguridad, discrepancia de identidad o carga desactualizada cerca de un hito crítico. Una tarea por falta de respuesta debe llevar el último estado verificado, la hora del último evento conocido, el motivo de riesgo y el responsable, para que tráfico pueda priorizarla. Cuando el conductor vuelva a estar localizable, concilie el historial de intentos en lugar de sobrescribirlo con una única etiqueta de «atendida».

Proteger la seguridad del conductor y el criterio humano

El conductor tiene que poder ignorar, aplazar o terminar una llamada sin penalización. Ofrezca devolver la llamada más tarde o un seguimiento por escrito seguro cuando proceda, y no haga depender nunca un KPI operativo de que responda en un momento concreto. Haga solo preguntas que puedan responderse con seguridad. El proceso debe aceptar «estoy conduciendo», «ahora no puedo hablar» o el silencio como motivo para aplazar, no como un incumplimiento.

No use la llamada para recoger información detallada con el vehículo en marcha, no pida al conductor que manipule un dispositivo y no le presione para cumplir una hora de llegada que las condiciones no permiten. Si el conductor comunica un accidente, un problema médico, una amenaza, un problema con mercancías peligrosas, una sospecha de robo o que no puede continuar, siga la vía de emergencia y seguridad revisada del transportista. El agente no debe diagnosticar, investigar, buscar culpables ni aconsejar fuera de esa vía.

Defina un límite de traspaso para los problemas de seguridad, las exigencias legales, el acoso, los conflictos delicados y todo lo que el agente no pueda clasificar con seguridad. Pase el problema, la referencia de la carga, el estado de la identidad, el punto de control, la hora, la preferencia para devolver la llamada con seguridad y los datos recogidos, para que tráfico tome el relevo sin que el conductor tenga que repetir lo básico. Cualquier decisión que cambie un compromiso, cree un riesgo material o dependa de un contrato o del criterio operativo local debe quedar en manos de una persona.

Un piloto acotado y con filtros

Empiece con una ruta, un programa de cliente o un punto de control y un conjunto pequeño de incidencias. Revise guiones, grabaciones, campos del TMS, reglas de citas, tratamiento de la identidad, ventanas de reintento y vías de traspaso. Haga llamadas supervisadas, compare los estados propuestos con las decisiones de tráfico y revise cada escritura en el sistema. Deje que las llamadas rutinarias actualicen solo los campos aprobados, mientras las personas revisan las incidencias, los registros desactualizados, las discrepancias de identidad y los contactos fallidos.

Filtros del piloto

• Entrada: un proceso, una vía en el TMS, cargas definidas, periodo de referencia, un responsable de tráfico con nombre, un límite de seguridad aprobado y alguien con autoridad para pausar.
• Seguimiento: revisar llamadas rutinarias y con incidencias en todos los turnos, transportistas, puntos de control y resultados sin respuesta; conciliar a diario los eventos de llamada con los registros del TMS.
• Ampliación: exigir definiciones estables, escrituras suficientemente completas, modos de fallo conocidos, colas de incidencias con personal y ningún problema crítico de seguridad o identidad sin resolver.
• Pausa: detener la vía afectada si se revelan datos de otra carga, se hacen preguntas poco seguras, se repiten escrituras erróneas, se pierden escalados críticos, quedan tareas sin responsable o se ve que datos desactualizados se presentan como actuales.

Dé al piloto una revisión operativa semanal con tráfico, el personal que trata con los transportistas y el responsable del proceso. Lleve un pequeño conjunto de llamadas revisadas, correcciones, tareas abiertas, resultados de reintentos y comentarios de conductores. Un piloto está listo para crecer cuando el equipo sabe explicar sus fallos, completa las tareas que generan y puede volver a la vía anterior si una nueva versión se comporta mal.

Muestreo de calidad y métricas útiles

El muestreo de calidad debe incluir una parte aleatoria de llamadas rutinarias y una parte elegida a propósito por su riesgo. Durante el piloto, revise cada escalado de seguridad, discrepancia de identidad, fallo de escritura y dato desactualizado; muestree también llamadas correctas para detectar falsas seguridades. Estratifique por punto de control, transportista, papel del conductor o de quien llama, hora del día, idioma si procede, resultado sin respuesta y destino del traspaso. Compare la conversación, el registro de origen, la escritura en el TMS y la acción de tráfico como un único caso.

Puntúe si la identidad se trató bien, si el punto de control estaba al día, si no se pidió al conductor nada inseguro, si el estado y la hora estimada se apoyaban en lo que dijo el conductor, si la incidencia se clasificó bien, si el traspaso llevaba contexto suficiente y si la escritura coincidía con el resultado de origen. El proceso de calidad debe conservar los casos fallidos como pruebas de regresión, en lugar de tomar un registro corregido como prueba de que la llamada original era aceptable.

Mida los controles completados por punto de control, la tasa de respuesta y de no respuesta, las cargas desactualizadas encontradas, las incidencias detectadas antes del siguiente hito, el tiempo hasta la acción humana, el cierre de tareas y la tasa de corrección. Use un denominador y una ventana de tiempo definidos para cada métrica. No optimice para llamadas cortas o pocas transferencias si eso genera llamadas repetidas, registros incompletos o retrasos al actuar sobre las incidencias. La analítica de llamadas puede separar la actividad de marcación de las actualizaciones útiles, pero la interpretación sigue siendo de tráfico.

Gobernar las versiones de Agent Factory con evidencias

El trabajo de calidad continúa después del piloto. Revise las llamadas reales con tráfico y clasifique los fallos: pregunta poco clara, campo que falta, fuente desactualizada, identidad mal cruzada, incidencia derivada tarde, reintento mal hecho, pregunta poco segura o escritura que no coincide. Convierta los hallazgos repetidos en un caso de prueba, un cambio de guion, una regla de datos, un cambio de enrutamiento o un límite de seguridad. Una llamada revisada es la evidencia de un cambio propuesto, no un permiso para modificar producción en silencio.

Agent Factory, la forma en que DRING crea, prueba y mejora sus agentes, debe dar a cada versión un número, un alcance, un responsable, el punto de control afectado, el comportamiento esperado, los casos de regresión, los cambios de herramientas y campos, quién aprueba, la parte del tráfico, la ventana de seguimiento y la acción de marcha atrás. Ejecute el caso nuevo junto con la prueba de regresión existente sobre estados rutinarios, datos desactualizados, discrepancias de identidad, vías sin respuesta, límites de seguridad y fallos de escritura. Mantenga disponible la versión anterior hasta que el nuevo comportamiento haya superado su ventana de revisión.

Use filtros de publicación proporcionales al riesgo. Un cambio de texto puede necesitar una revisión de contenido; una nueva acción de escritura necesita la aprobación de integración y de tráfico; un cambio en la identidad, la grabación, la seguridad o el traspaso necesita al responsable de esa política. Promueva los cambios en una parte limitada del tráfico, compárelos con la versión actual, revise muestras de calidad y documente la decisión. Si una versión mejora los controles rutinarios pero empeora la detección de incidencias, o ayuda en la vía de un transportista y perjudica la de otro, mantenga el alcance reducido o vuelva atrás. Así la mejora rinde cuentas ante la evidencia y la responsabilidad de tráfico sigue a la vista.

Hoja de trabajo práctica para el piloto

• Alcance: anote el primer punto de control, el grupo de cargas, las franjas horarias de llamada, el objeto del TMS y los casos excluidos.
• Identidad: indique los campos de coincidencia aprobados, la vía para las discrepancias y el responsable de los registros erróneos o duplicados.
• Vigencia: fije para cada fase la ventana del evento observado, la etiqueta de desactualizado, el comportamiento de reintento y el plazo de escalado.
• Seguridad: redacte la frase para aplazar, la vía segura para devolver la llamada, el límite de emergencia y el disparador de pausa.
• Responsabilidad: indique la cola de tráfico, el respaldo, la definición de cierre y la antigüedad máxima de las incidencias abiertas.
• Evidencia: elija la muestra aleatoria y la ponderada por riesgo, los denominadores de las métricas, los revisores semanales y quién aprueba las versiones.

Un modelo operativo claro

El resultado no es simplemente más llamadas completadas. Es un estado al día para las cargas rutinarias, una incidencia factual y priorizada para tráfico, un historial de reintentos finito cuando no se localiza al conductor y un registro en el TMS que refleja lo que pasó de verdad. El agente se encarga del paso repetible de recogida de datos, dentro de sus permisos. Tráfico se encarga del plan, de la incidencia y de la decisión de cambiarlo.