Prueba de entrega: qué es y cómo implantarla

Qué es la prueba de entrega y por qué zanja las disputas

La prueba de entrega, conocida por sus siglas en inglés como POD, es la confirmación documentada de que el mensajero completó el trabajo: la mercancía se traspasó, el servicio se prestó, el destinatario aceptó el resultado. Es el último paso del ciclo del pedido y el único que convierte una promesa en un hecho que puedes mostrar a un cliente, a un contable o a un juez.

Cada día hay tres grupos de personas que dependen de ese registro, y cada uno lo necesita por un motivo distinto:

• El operador de tráfico necesita saber que un pedido está realmente cerrado, y no solo marcado como cerrado, para equilibrar el turno y asignar el siguiente trabajo.
• El área financiera necesita una base para facturar y para liquidar a los mensajeros: un trabajo que nunca se confirmó no debería pagarse ni cobrarse dos veces.
• El cliente necesita una respuesta a la única pregunta que importa cuando algo sale mal: quién recibió el paquete, cuándo y en qué estado llegó.

El valor del POD se ve precisamente en los casos incómodos. Un destinatario asegura que no llegó nada. Una tienda insiste en que la caja venía dañada. Un cliente discute una factura por un servicio que nadie recuerda. Sin registro, cada una de esas situaciones se convierte en la palabra de uno contra la del otro, y la empresa suele pagar para acabar con la discusión. Con un registro, la conversación se cierra en un minuto.

Firma en papel frente a confirmación electrónica

El esquema tradicional resulta familiar: el mensajero lleva un taco de albaranes, el destinatario firma, el papel vuelve a la oficina y se archiva en algún sitio. Funciona, en el sentido de que acaba produciendo una evidencia, pero el coste de esa evidencia es alto y llega tarde.

Los puntos débiles del papel son estructurales, no accidentales:

• El retraso. La oficina se entera de lo ocurrido solo cuando el mensajero regresa, así que durante el turno el operador está a ciegas y responde a las llamadas de los clientes con suposiciones.
• Las pérdidas. Las hojas se arrugan, se mojan, se quedan en el coche o directamente nunca se entregan, y una hoja perdida significa un servicio sin ninguna evidencia.
• Una firma demuestra muy poco. Un garabato ilegible no dice nada sobre quién firmó, a qué hora ni en qué estado venía la mercancía.
• La transcripción manual. Alguien vuelca el papel en una hoja de cálculo, lo que cuesta horas y va introduciendo errores en silencio.

La prueba de entrega electrónica, o ePOD, elimina el viaje de vuelta a la oficina. El mensajero registra el resultado en la puerta del cliente y el dato aparece en el sistema de inmediato, asociado al pedido y no a un trozo de papel. El operador ve el trabajo cerrado en tiempo real, el cliente ve un estado y no hay que teclear nada dos veces. El papel no desaparece por completo —algunos clientes siguen exigiendo un documento sellado—, pero deja de ser el canal principal de la verdad.

Qué debe contener un registro completo

Una confirmación solo sirve si responde a las preguntas que surgirán después. Un simple estado cambiado a «hecho» no responde a ninguna. Un registro que merezca la pena guardar combina varios elementos, y cada uno despeja un tipo de duda diferente:

• Una foto. El elemento más convincente: el paquete en la puerta, la mercancía en manos del destinatario, el equipo instalado, el trabajo terminado. Una foto muestra el estado, no solo el hecho.
• Un checklist. Una lista breve de lo que había que hacer o comprobar en el punto, marcada por el mensajero: es lo que consigue que distintos mensajeros cierren los servicios de la misma manera.
• Un estado con marca de tiempo. Aceptado, en tránsito, entregado, reprogramado, rechazado: la secuencia de estados reconstruye toda la historia del pedido.
• El resultado de la visita. No todas las paradas terminan en un traspaso, y el registro tiene que poder decirlo de forma explícita.

Lo importante es que esos cuatro elementos vivan en el propio pedido, en un solo sistema, y estén disponibles en el momento en que se capturan. En itlogist eso forma parte del ciclo estándar: Gestión de mensajeros cubre la recepción y el reparto de pedidos, las rutas en vivo sobre el mapa, la aplicación móvil con informes fotográficos y checklists, el portal del cliente con estados y la confirmación in situ de que el trabajo se completó, de modo que la evidencia aterriza en el mismo lugar donde se creó el pedido.

Cómo captura el mensajero la evidencia sobre el terreno

Tenga el aspecto que tenga la pantalla del operador, el registro lo crea una persona que está de pie ante una puerta, a menudo bajo la lluvia y con una caja en las manos. Si capturarlo lleva demasiado tiempo o exige demasiados toques, se saltará el paso, y un sistema lleno de confirmaciones vacías es peor que un papel honesto, porque parece fiable mientras no te cuenta nada.

Por eso, al evaluar cualquier herramienta de POD, la parte de campo merece el escrutinio más atento:

• La barrera de entrada. En itlogist el empleado de campo trabaja a través de una interfaz web móvil, sin instalación obligatoria de una app desde la tienda: el mensajero abre un enlace y ve sus pedidos y su ruta. Eso importa especialmente con personal temporal y subcontratas, que si no necesitarían una instalación, una cuenta y una sesión de formación antes del primer turno.
• Fotos y checklists en el punto. La captura ocurre donde ocurre el trabajo, en un par de toques, y no en un parte redactado después de memoria.
• Estados que cambian sobre la marcha. El mensajero actualiza la situación de cada pedido y el operador lo ve en tiempo real, lo que elimina las eternas llamadas de «¿dónde estás?».
• La ruta en el mismo sitio. La secuencia de paradas está junto al paso de confirmación, así que el mensajero no hace malabares con varias apps entre una dirección y la siguiente.

Una prueba útil durante un piloto: dale la herramienta a tu mensajero con menos paciencia durante un turno. Si los registros vuelven completos sin que nadie tenga que perseguirlos, el proceso sobrevivirá al contacto con un viernes complicado.

Excepciones: la evidencia importa más cuando no se entregó nada

Los equipos suelen diseñar la confirmación pensando en el caso ideal y luego descubren que los casos caros son los otros. No había nadie en casa. El destinatario rechazó la mercancía. La dirección resultó ser incorrecta. El cliente pidió volver mañana. Esas paradas no producen ningún traspaso, pero el mensajero gastó igualmente una hora de su turno y sigue debiendo una explicación.

Una excepción debe registrarse con la misma disciplina que un reparto exitoso:

• Un motivo concreto elegido de una lista cerrada, para que las reprogramaciones se puedan contar y comparar en lugar de quedar descritas en un texto libre que nadie lee.
• La evidencia del intento: una foto tomada en la dirección y una marca de tiempo que demuestre que el mensajero estuvo allí.
• El siguiente paso —reprogramar, devolver o hacer un segundo intento— anotado en el mismo pedido y no acordado de palabra.

De aquí se derivan dos cosas. Primero, las disputas por visitas fallidas dejan de ser imposibles de ganar: puedes demostrar que un mensajero estuvo en la dirección a una hora concreta. Segundo, obtienes estadística. Cuando cada fallo lleva un código de motivo, al cabo de un mes el patrón se hace visible: un distrito que genera la mayoría de las reprogramaciones, un cliente cuyas direcciones son sistemáticamente erróneas, una franja horaria en la que nunca hay nadie en casa. Esos números son los que permiten corregir las causas en lugar de discutir sobre los síntomas.

Implantar la confirmación electrónica: checklist breve

Pasar del papel a un registro electrónico es menos un proyecto técnico que un acuerdo sobre cómo se cierra un trabajo. La tecnología es la mitad fácil; la disciplina es la parte que decide el resultado. Un orden práctico de pasos sería este:

• Define qué cierra un servicio. Escribe, para cada tipo de pedido, qué hay que capturar: qué foto, qué puntos del checklist, qué estado final. Las reglas vagas producen evidencias vagas.
• Mantén corta la parte del mensajero. Cada campo obligatorio de más es un campo que alguien falseará al final de un turno largo. Pide solo lo que vayas a usar de verdad.
• Conecta las fuentes de pedidos. Una confirmación vale tanto como el pedido del que cuelga: itlogist intercambia datos con 1C, AmoCRM, Bitrix24 y Excel, así que los pedidos llegan desde los sistemas que ya usas y los estados regresan por el mismo camino.
• Abre el estado al cliente. Un portal del cliente con estados convierte la mayoría de las llamadas a soporte en una página que el propio cliente consulta.
• Empieza pequeño y rápido. itlogist está pensado para arrancar en 7 días y funciona sin contratos de permanencia, y encaja en equipos de 5 a 100 empleados de campo: margen suficiente para pilotar con un grupo de mensajeros antes de extenderlo a toda la plantilla.
• Revisa los registros cada semana. Durante el primer mes, mira una muestra de pedidos cerrados. Las fotos que faltan y los checklists idénticos son las primeras señales de que el proceso se está esquivando.

Hecho así, confirmar deja de ser papeleo extra impuesto a los mensajeros y se convierte en el final natural del trabajo: el momento en que el pedido se cierra solo, el cliente ve el resultado y nadie tiene que reconstruir la jornada de memoria.