Incidencia de entrega fallida: protocolo paso a paso para distribuidoras

Resumen: Una entrega fallida sin protocolo definido se convierte en un reintento no planificado, un albarán abierto y un problema de facturación. Este artículo detalla cómo estructurar el flujo completo de incidencia —desde que el conductor notifica el fallo hasta que el albarán queda cerrado— para que nada quede en el aire.

• ¿Qué es una incidencia de entrega fallida y por qué necesita protocolo?
• Paso 1: notificación del conductor en ruta
• Paso 2: clasificación de la incidencia en oficina
• Paso 3: decisión sobre el reintento
• Paso 4: ajuste de stock y trazabilidad del bulto
• Paso 5: cierre del albarán y efecto en facturación
• Errores habituales sin protocolo formalizado
• Cómo el software reduce el coste de cada incidencia

¿Qué es una incidencia de entrega fallida y por qué necesita protocolo?

Una incidencia de entrega fallida ocurre cuando el conductor llega a una parada y no puede completar la entrega. Las causas más frecuentes son:

• Destinatario ausente en el momento de la entrega
• Local cerrado fuera del horario acordado
• Dirección incorrecta o inaccesible para el vehículo
• Rechazo de la mercancía por parte del destinatario
• Incidencia con el propio bulto (rotura, temperatura fuera de rango)

Sin un protocolo definido, cada conductor gestiona la situación a su manera: llama al responsable de ruta, manda un WhatsApp o apunta la incidencia en papel. El resultado es que la información llega tarde, incompleta y sin formato estándar. El reintento se planifica de forma reactiva y el albarán permanece abierto hasta que alguien lo recuerda.

En distribuidoras con 15 o más paradas diarias por ruta, una tasa de entrega fallida del 5 % implica entre 3 y 5 incidencias al día. Sin protocolo, cada una consume entre 20 y 40 minutos de gestión entre conductor, oficina y almacén.

Paso 1: notificación del conductor en ruta

El conductor es el primer eslabón. Su notificación debe cumplir tres condiciones para ser útil:

1. Inmediata: en el momento en que constata que la entrega no es posible, no al terminar la ruta.
2. Estructurada: debe indicar el motivo de la incidencia usando una lista cerrada de causas, no texto libre.
3. Verificable: idealmente con evidencia adjunta (foto del local cerrado, firma de rechazo, foto del bulto dañado).

Si el conductor usa papel o una llamada telefónica, cualquiera de esas tres condiciones falla de forma habitual. Una app de conductor con gestión de incidencias resuelve esto: el conductor selecciona el tipo de incidencia desde la parada, adjunta la evidencia y la notificación llega a oficina en tiempo real, geoposicionada y con marca de hora.

Un detalle crítico: la app debe funcionar en modo offline. Muchas zonas de reparto —polígonos industriales, áreas rurales— tienen cobertura intermitente. Si la app no guarda la incidencia localmente y la sincroniza en cuanto hay red, el conductor termina anotando en papel igualmente.

Paso 2: clasificación de la incidencia en oficina

Cuando la notificación llega a oficina, alguien debe clasificarla antes de actuar. La clasificación determina los pasos siguientes y evita que todas las incidencias sigan el mismo camino.

Una taxonomía básica útil para distribuidoras:

• Tipo A — Reintento viable en el mismo día: el destinatario está localizado, la ventana horaria lo permite y el conductor aún tiene margen en la ruta.
• Tipo B — Reintento programado para otro día: el destinatario confirma disponibilidad para una fecha concreta; se programa como parada en una ruta futura.
• Tipo C — Devolución al almacén: el destinatario rechaza el pedido o no hay posibilidad de reintento a corto plazo; el bulto regresa.
• Tipo D — Incidencia en el bulto: la mercancía presenta daños o problemas de temperatura; requiere protocolo de calidad además del logístico.

Esta clasificación debe quedar registrada en el sistema con el nombre de quien la toma y la hora. No como burocracia, sino porque si el albarán acaba en disputa con el destinatario, esa trazabilidad es lo único que protege a la distribuidora.

Paso 3: decisión sobre el reintento

El reintento tiene un coste real: kilómetros adicionales, tiempo del conductor y, en algunos contratos, una penalización pactada con el cliente si supera cierto número de reintentos.

Para tomar la decisión correcta, quien gestiona la incidencia necesita saber en ese momento:

• Dónde está el conductor físicamente y cuántas paradas le quedan.
• Si el bulto puede volver al almacén sin problema de temperatura o fragilidad.
• Si el destinatario ha respondido y confirma disponibilidad.

Sin visibilidad en tiempo real sobre la flota, esta decisión se toma con información incompleta o con una llamada al conductor que interrumpe la ruta. El seguimiento de flota integrado en el ERP permite tomar esta decisión desde el mapa, sin llamadas intermedias.

Si el reintento se programa para otro día, debe crearse automáticamente como parada pendiente, vinculada al albarán original, con el motivo de incidencia visible para quien planifique la ruta siguiente. Si esto se hace manualmente o en una hoja de cálculo aparte, el riesgo de que se pierda es alto.

Paso 4: ajuste de stock y trazabilidad del bulto

Si el bulto regresa al almacén —total o parcialmente—, el stock debe actualizarse en el mismo momento en que el vehículo entra a descarga. No al día siguiente, no cuando alguien tenga tiempo.

Para productos con trazabilidad por lote (alimentos, productos con fecha de caducidad, artículos con número de serie), el proceso es más estricto:

1. El bulto devuelto debe re-escanearse en almacén para confirmar que el lote registrado en el albarán es el que físicamente ha regresado.
2. Si hay dudas sobre el estado del producto, debe pasar a cuarentena antes de reincorporarse al stock disponible.
3. El movimiento de devolución debe quedar asociado al albarán original para que la trazabilidad sea completa de extremo a extremo.

Una distribuidora de alimentos en Galicia que trabaja con clientes que exigen trazabilidad por lote no puede permitirse que una devolución quede sin registrar correctamente: la mercancía reingresaría al stock con el lote sin confirmar, lo que invalida la cadena de trazabilidad en una eventual auditoría o recall.

Paso 5: cierre del albarán y efecto en facturación

Un albarán de entrega fallida no es un albarán cerrado. Mientras no se resuelva —reintento exitoso, devolución registrada o anulación acordada con el destinatario—, el albarán permanece abierto y la factura no puede emitirse.

El flujo correcto al cierre:

1. Reintento exitoso: el albarán se cierra con la firma del destinatario en el segundo intento. La factura se genera sobre el albarán original con la fecha de entrega real.
2. Devolución parcial: se genera un albarán de devolución por las líneas no entregadas. La factura refleja únicamente lo entregado.
3. Anulación total: el albarán se anula, el stock se reincorpora y no se genera factura. Si ya existía una factura proforma o un anticipo, hay que gestionar la reversión.

Si el ERP no conecta directamente el estado del albarán con el módulo de facturación, este paso se convierte en un proceso manual: alguien revisa los albaranes pendientes, llama al responsable de almacén para confirmar si la devolución entró y luego emite la factura. Con Verifactu activo, emitir una factura incorrecta y tener que anularla después tiene implicaciones en el registro contable que complican el cuadre con la asesoría.

Errores habituales sin protocolo formalizado

Estos son los fallos que se repiten en distribuidoras que gestionan incidencias sin un flujo definido:

• El conductor anota la incidencia al final de la jornada, no en el momento. La información llega con horas de retraso.
• La incidencia se comunica por WhatsApp y nadie la traslada al sistema. El albarán queda abierto indefinidamente.
• El bulto regresa al almacén sin re-escanear. El stock se actualiza con dato incorrecto o no se actualiza.
• El reintento se programa de memoria, sin vincularlo al albarán original. Se pierde el historial.
• La factura se emite sobre un albarán que incluye líneas no entregadas. El destinatario la rechaza o paga de más.

Cada uno de estos errores es corregible de forma individual. El problema es que sin protocolo se acumulan, y a fin de mes el responsable de operaciones dedica horas a reconciliar albaranes, facturas y movimientos de stock que deberían haber quedado cerrados en el momento.

Cómo el software reduce el coste de cada incidencia

El protocolo descrito arriba se puede implementar con papel, Excel y llamadas telefónicas. Funciona, pero cada incidencia consume tiempo de tres o cuatro personas. Con volumen, ese tiempo se convierte en el principal coste oculto de las entregas fallidas.

Un ERP diseñado para distribución con flota propia reduce ese coste de dos formas concretas:

Automatización de pasos intermedios. La notificación del conductor actualiza directamente el estado del albarán. La devolución en almacén ajusta el stock sin intervención manual. El albarán cerrado dispara la factura sin que nadie tenga que acordarse.

Visibilidad centralizada. El responsable de operaciones ve en un solo lugar qué incidencias están abiertas, en qué estado están y qué albaranes siguen sin cerrar. Sin tener que preguntar al conductor, al almacén y al administrativo por separado.

En Rowan ERP, la app de conductor registra la incidencia en la parada —con foto y tipo de causa— y la sincroniza con el ERP en cuanto hay conexión. Desde oficina, el responsable ve la incidencia en el albarán correspondiente, decide el siguiente paso y el sistema propaga el cambio al módulo de almacén y facturación sin pasos manuales adicionales.

Si gestionas entregas fallidas con un proceso que depende de que nadie se olvide de nada, estás asumiendo un riesgo operativo que crece con cada ruta. Puedes ver cómo funciona el módulo de conductor y incidencias en rowanerp.com.