Un paquete contra entrega fallido puede borrar la ganancia de varios pedidos buenos. Descubre de dónde viene el retorno al origen, cómo calificar y confirmar pedidos antes de despachar, atender los NDR rápido y probarlo todo en seis semanas.
Author
Anichur Rahaman
Mil pedidos contra entrega salieron la semana pasada de una tienda en línea. El lunes a las 9:10, la responsable de operaciones abre el reporte: se entregó el 78 por ciento. El 22 por ciento restante va de regreso: 80 los rechazó el cliente en la puerta, en 60 nadie contestó el teléfono, en 50 el repartidor no encontró la dirección y 30 se perdieron en algún centro de distribución. Las cifras de esta escena son ilustrativas, pero el patrón le resulta familiar a cualquiera que venda cobrando en efectivo.
Cada uno de esos 220 paquetes se empacó, se pagó su envío, viajó de ida y de vuelta, y dejó su mercancía dos semanas inmovilizada, sin poder venderse. Buena parte de la ganancia de los 780 pedidos entregados ya se gastó en los 220 que no llegaron.
La tesis de este artículo es simple: el retorno al origen (RTO) se decide antes de que el paquete salga de la bodega y en las primeras 48 horas después de un intento fallido, no en la puerta. Si confirmas el pedido, evalúas el riesgo y respondes rápido al primer reporte de no entrega de la paquetería, la mayoría de esos 220 paquetes ni siquiera empieza el viaje, o no lo termina de regreso.
El pago contra entrega sigue siendo común en Medio Oriente, el sur y el sudeste de Asia, América Latina, África y partes de Europa central y oriental. El comprador lo elige porque desconfía de un formulario de tarjeta, no tiene tarjeta o quiere ver la mercancía antes de pagar. Para el vendedor, eso traslada todo el riesgo al último metro.
Hay dos términos que conviene tener claros. El reporte de no entrega (NDR) es el estatus que la paquetería registra tras un intento fallido: cliente ausente, dirección incompleta, rechazo. El paquete todavía se puede rescatar. El retorno al origen (RTO) ocurre cuando se agotan los intentos y el paquete regresa a ti, por tu cuenta.
Este es un pedido ilustrativo, con todas las cifras en la misma unidad monetaria:
| Concepto | Pedido entregado | Pedido fallido (RTO) |
|---|---|---|
| Valor del pedido cobrado | 40.00 | 0.00 |
| Costo del producto | -22.00 | 0.00 (la mercancía regresa) |
| Envío de ida | -3.00 | -3.00 |
| Envío de regreso | 0.00 | -2.50 |
| Empaque | -0.50 | -0.50 |
| Surtido y empaque | -1.00 | -1.00 |
| Revisión y reingreso a inventario | 0.00 | -1.00 |
| Comisión por manejo del cobro contra entrega | -0.80 | 0.00 |
| Daño en el regreso (8% de 22.00) | 0.00 | -1.76 |
| Contribución | 12.70 | -9.76 |
La diferencia entre los dos resultados es de 22.46. Un solo paquete fallido borra entonces la contribución de 0.77 de un pedido exitoso, y eso sin contar lo que nadie registra: la unidad estuvo fuera de inventario dos semanas y el dinero llegó tarde o nunca.
Un RTO de 20 por ciento no es un problema con una sola solución. Son al menos tres, y cada uno pide una palanca diferente.
Pedidos por impulso, pedidos de broma, o un mejor precio que el cliente encontró en otro lado mientras tanto. Cancelar un pedido contra entrega no le cuesta nada al comprador, así que rechazarlo en la puerta sale gratis. La palanca está en la intención: confirmación, anticipos, incentivos.
Un dígito equivocado en el teléfono, un celular apagado en la ventana de entrega, un repartidor que llama una sola vez. La palanca está en el contacto: números validados, un segundo canal como WhatsApp o SMS, y la posibilidad de reprogramar.
Direcciones de texto libre sin referencia, el barrio equivocado, o una zona que la paquetería atiende mal. La palanca es la calidad de la dirección y elegir la paquetería por zona, que es justo lo que casi ninguna tienda mide.
Trata un pedido contra entrega como un embudo de pagos con fugas en cada etapa. Cuenta cuántos pedidos entran y cuántos salen, y las fugas dejan de ser una corazonada.
En este ejemplo, que coincide con la escena del lunes, los 1,000 pedidos se despachan, 690 se entregan en el primer intento, 780 después de los reintentos y 770 se concilian con el efectivo en 30 días. Los 90 rescatados por los reintentos muestran cuánto vale responder rápido, y los 10 entregados pero nunca remesados muestran por qué finanzas necesita su propia etapa. Cada etapa tiene un responsable: la confirmación, atención a clientes; el primer intento, la paquetería; los reintentos, quien responde el NDR; y la liquidación, finanzas. Si una etapa no tiene dueño, nadie ve su fuga.
El RTO más barato es el paquete que no enviaste. Entre el pago y la lista de surtido, pon dos filtros: una calificación de riesgo y una confirmación.
Para empezar no hace falta un modelo. Basta una tabla de puntos sobre campos que ya están en tu base de pedidos, y además se le puede explicar al equipo de soporte. Estos son pesos iniciales, para ajustar con tu propio historial:
Un ejemplo con números: un comprador nuevo hace un pedido a las 2:00 a. m., por 3.4 veces el promedio, desde una zona débil y con una dirección corta. La calificación es 15 + 15 + 15 + 10 = 55. Por debajo de 20, el pedido se envía. De 20 a 49, requiere confirmación. Desde 50, pides anticipo o prepago completo. Los umbrales los mueves tú cuando veas los resultados.
La confirmación puede ser una llamada, un mensaje de WhatsApp con dos botones («Confirmar» y «Cancelar»), una respuesta por SMS o un aviso de voz automático. El mensaje debe repetir el artículo, el total que se entregará, la dirección y la ventana de entrega. Quien responde es alguien que espera el paquete.
Registra cada paso en el pedido: la calificación, las señales que la produjeron, el mensaje enviado, la respuesta y la hora. Cuando empieces a analizar el RTO, ese historial te dice qué regla ayudó y cuál solo molestó a clientes buenos.
A la banda de riesgo alto dale una forma de conservar su pedido. Un anticipo de 10 a 20 por ciento con tarjeta o billetera móvil demuestra intención y cubre el envío de regreso si el paquete rebota. Una comisión pequeña por pago contra entrega, mostrada al pagar y no en la puerta, hace que el prepago sea la opción más barata. Un descuento o envío gratis para pedidos prepagados logra lo mismo desde el otro lado.
Prueba esto como experimentos, no como políticas. Una comisión en todos los pedidos puede bajar la conversión. Aplicada solo a la banda alta, toca a una fracción pequeña de pedidos y filtra a los que más probablemente rechazarían.
Un primer intento fallido es el momento de mayor posibilidad de rescate. Los estatus cambian según la paquetería, pero el patrón es el mismo: aparece un NDR con un código de motivo, la paquetería programa otro intento en uno o dos días y, tras el último intento, el paquete pasa a devolución.
Asigna a cada motivo una acción que se ejecute en horas:
Un NDR respondido el mismo día le da al siguiente intento una oportunidad real. Un NDR que nadie lee termina en RTO por omisión.
Las paqueterías son fuertes en algunas zonas y débiles en otras. Agrupa tus paquetes por paquetería y zona de entrega, y compara el éxito del primer intento y el RTO de cada celda. Luego asigna en consecuencia: la más barata donde rinde bien, la mejor donde no.
El breve recorrido por la gestión de entregas de StoreConsole que sigue muestra cómo se ven los datos de paqueterías, zonas y estado en vivo en una sola pantalla.
Entregado no significa cobrado. La paquetería cobra el dinero, descuenta su comisión y lo remesa por lotes, muchas veces una semana o más después. Concilia cada archivo de remesa contra los pedidos que dice cubrir. De esa conciliación salen tres grupos: pedidos pagados completos, pedidos pagados incompletos (diferencias de comisión o redondeo) y pedidos entregados que no aparecen en ninguna remesa.
Guarda en cada pedido estos campos: paquetería, número de guía, monto por cobrar, monto remesado, comisión retenida, referencia y fecha de la remesa. Un pedido marcado como entregado hace 14 días y sin referencia de remesa pasa a una lista de cobranza. Sin esa conciliación, los paquetes sin pagar se quedan en una hoja de cálculo hasta que alguien nota el hueco en la caja.
Cambia una palanca a la vez para saber qué funcionó.
| Métrica | Cómo se calcula | Por qué importa |
|---|---|---|
| Tasa de RTO | Paquetes devueltos / paquetes despachados | La pérdida principal, desglosada por paquetería y zona |
| Éxito en el primer intento | Entregados en el intento 1 / despachados | Muestra la calidad de direcciones y contacto |
| Tasa de confirmación | Confirmados / pedidos enviados a confirmar | Muestra cuántos pedidos tenían intención real |
| Tasa de recuperación de NDR | Entregados tras un NDR / NDR generados | Mide tu respuesta, no la de la paquetería |
| Días para cobrar | Fecha de remesa menos fecha de entrega | Capital de trabajo inmovilizado por pedido |
| Contribución neta por pedido | Contribución total / pedidos realizados | El número que decide si un cambio valió la pena |
Juzga siempre un cambio por la contribución neta por pedido, no solo por el RTO. Vuelve al ejemplo de antes: con una confirmación de 0.30 por pedido, 6 de 20 pedidos condenados cancelados antes del despacho y 2 salvados en la puerta, cada 100 pedidos dan 82 entregados a 12.70, 12 fallidos a -9.76 y 30 gastados en confirmar. El total es 894.28 en lugar de 820.80, una ganancia de 73.48 por cada 100 pedidos, cerca de 9 por ciento, sin tocar un solo precio.
Seis semanas después, la responsable de operaciones abre el mismo reporte. De 1,000 pedidos, 60 se cancelaron en la confirmación y ni siquiera se empacaron. Cada primer intento fallido tiene un código de motivo y una respuesta enviada, y la zona más débil ahora la atiende otra paquetería. El RTO bajó de 22 a 12 por ciento y el dinero de las entregas de la semana pasada ya está conciliado con los archivos de remesa.
El producto y el precio son los mismos. Lo que cambió es que cada pedido pasa ahora por un filtro antes de salir y por un reloj después de fallar.
Anichur Rahaman es arquitecto de software y creador de StoreConsole. Diseña sistemas de comercio y ERP para negocios en crecimiento, con enfoque en arquitectura orientada a eventos, integridad de datos y operación en servidores propios.
About the Author
Anichur Rahaman
Continue Reading
