Una exportadora de hortalizas en Culiacán y el seguimiento de embarques

Resumen:

• El estatus se arma con eventos que el almacén ya registraba, no con capturas nuevas.
• El portal muestra la antigüedad del dato: un estatus viejo se señala, no se disfraza.
• Se publicó poco al inicio y se amplió con las preguntas reales de los clientes.
• El rastreo satelital de terceros quedó fuera del primer alcance, a propósito.

Una exportadora de hortalizas del valle de Culiacán mueve producto a varios distribuidores del otro lado de la frontera durante una temporada corta e intensa. En el pico, salen varios embarques diarios y cada uno lleva producto de distintos productores y presentaciones.

El problema que nos plantearon no fue de almacén ni de producción. Fue del área comercial: tres personas pasaban buena parte del día contestando llamadas y mensajes de clientes preguntando lo mismo. Dónde viene mi pedido. Cuántas cajas salieron. Ya cruzó. Cuándo llega.

El costo de contestar lo mismo todo el día

Para responder una de esas preguntas, la persona de comercial tenía que llamar al almacén o caminar hasta allá. El almacén revisaba su bitácora, a veces preguntaba a quien cargó, y devolvía una respuesta. El ciclo completo podía tardar veinte minutos. Multiplicado por decenas de consultas diarias, el área comercial dejaba de hacer el trabajo por el que estaba ahí.

El segundo costo era la calidad de la respuesta. Al no haber un registro único, dos personas podían dar respuestas distintas sobre el mismo embarque el mismo día. Eso pasó varias veces y acabó generando una desconfianza que después costó trabajo revertir: algunos clientes empezaron a pedir confirmación por escrito de todo, lo que agregó más trabajo.

El tercer costo era el que nadie contabilizaba. En temporada alta, con el teléfono saturado, las llamadas de consulta competían con las llamadas de pedido. Hubo semanas donde ampliar la venta era imposible porque la línea estaba ocupada atendiendo preguntas de estatus.

Lo que ya se había intentado

El primer intento fue un reporte diario por correo. Se enviaba a las ocho de la mañana con el estatus de los embarques abiertos. Duró tres meses. Falló porque el día en una exportadora no tiene ocho de la mañana: los eventos ocurren a toda hora y el reporte quedaba desactualizado antes de mediodía. Los clientes seguían llamando, ahora además para preguntar si el reporte estaba actualizado.

El segundo intento fue un grupo de mensajería por cliente. Mejoró la inmediatez y empeoró todo lo demás. La información quedaba dispersa en conversaciones, no había forma de buscar el histórico de un embarque y el personal quedó disponible a cualquier hora.

Los dos intentos compartían la raíz del problema. Estaban trasladando información a mano desde donde ocurría hasta donde se preguntaba.

Decisión técnica: el estatus se deriva, no se captura

La decisión central fue no crear un campo de estatus que alguien tuviera que mantener.

Se hizo un inventario de lo que el almacén ya registraba por obligación propia: entrada de producto a cámara con lote y productor, armado de tarima con su contenido, asignación de tarima a embarque, cierre de carga, y emisión de documentos. Esos eventos ya existían porque sin ellos no se puede facturar ni cumplir requisitos de exportación.

El estatus del embarque pasó a ser una función de esos eventos. Si existe el armado y no existe el cierre de carga, está en preparación. Si existe el cierre y no el documento, está cargado. Si existe el documento, está en tránsito. Nadie captura un estatus; el estatus se calcula.

Esa decisión tiene una consecuencia que vale la pena nombrar: el portal es tan bueno como la disciplina de registro del almacén. Si el almacén deja de registrar el cierre de carga, el portal muestra un embarque eternamente en preparación. En lugar de esconder eso, se hizo visible.

Decisión técnica: mostrar la antigüedad del dato

Un portal que muestra un estatus equivocado con aire de certeza es peor que no tener portal. El cliente deja de llamar, confía en el dato, y cuando se da cuenta de que era falso ya no vuelve a creer en la herramienta.

Cada estatus se publica con la hora del último evento que lo sustenta. Y se definieron umbrales por etapa: si un embarque lleva más de cierto tiempo sin evento nuevo, el portal lo marca como sin actualización reciente en lugar de mostrar el estatus viejo sin matiz.

Esa marca cumple dos funciones. Hacia afuera, le dice al cliente que conviene llamar. Hacia adentro, genera una lista de embarques estancados que el supervisor de almacén revisa, y esa lista resultó ser el mejor detector de registros no hechos.

El acceso se resolvió sin complicarlo: cada distribuidor tiene su cuenta y ve únicamente sus pedidos. Se evaluó dar acceso por enlace sin contraseña, más cómodo, y se descartó porque los enlaces se reenvían y la información de volúmenes y precios por cliente no debe circular entre clientes.

Qué se publicó y qué no

Las tres exclusiones fueron deliberadas y se explicaron al cliente antes de empezar. La más discutida fue la hora estimada de llegada, que era justamente lo que el área comercial más quería. Se sostuvo la exclusión porque una estimación equivocada en un producto perecedero no es un dato impreciso, es una promesa incumplida.

Errores que cometimos

El primer error fue de público. Diseñamos la primera versión pensando en el comprador que está frente a una computadora. En la práctica, quien más consulta es el encargado de recepción del distribuidor, de pie en un andén, con el teléfono. La primera versión era inservible en pantalla chica. Se rehizo la interfaz priorizando el teléfono y el uso subió de inmediato.

El segundo error fue de notificaciones. Agregamos aviso por correo en cada cambio de estatus. Con varios embarques por cliente, eso produjo tantos correos que los clientes los filtraron. Se cambió a un resumen por embarque en dos momentos: cuando se cierra la carga y cuando se emite el documento.

El tercer error fue de orden. Trabajamos primero el portal y después la disciplina de registro en almacén. Debió ser al revés. Las primeras dos semanas el portal mostró datos incompletos y la impresión inicial de algunos clientes fue que la herramienta no servía. Recuperar esa impresión costó más que el trabajo técnico.

Qué se midió

• Llamadas y mensajes de consulta de estatus, contados durante dos semanas antes y después.
• Consultas al portal por cliente, para distinguir adopción real de acceso único por curiosidad.
• Embarques marcados como sin actualización reciente, como indicador de disciplina de registro.
• Tiempo entre cierre de carga y publicación del documento.

Las consultas telefónicas de estatus bajaron de forma clara en temporada alta, que era el objetivo. El dato que no esperábamos fue el tercero: durante el primer mes, uno de cada cinco embarques aparecía marcado como estancado, casi siempre por el mismo turno y el mismo evento. Resolver eso fue un asunto de operación, no de software, y mejoró el portal más que cualquier cambio en el código.

El cuarto indicador terminó siendo el más valioso comercialmente. Publicar el documento rápido permitía al distribuidor preparar su recepción, y dos clientes lo mencionaron de forma espontánea como la razón para concentrar más volumen en esta exportadora.

Preguntas frecuentes

¿Qué datos necesita ver un cliente en un portal de embarques?

Menos de los que uno supone: qué pedido, cuántas cajas y de qué presentación, en qué estatus está, con qué documento y cuándo cambió por última vez. Agregar temperatura, placas y tiempos estimados antes de tener confiable lo básico solo multiplica las preguntas.

¿De dónde sale el estatus si nadie quiere capturarlo?

De eventos que el almacén ya registra por otras razones: entrada a cámara, armado de tarima, carga y emisión de documento. Un estatus que exige una captura adicional dedicada se queda desactualizado en una semana.

¿Conviene integrar el GPS del transportista desde el inicio?

Rara vez. Son varios transportistas con sistemas distintos y la integración tarda más que el portal completo. Conviene publicar primero los eventos propios, que son los que el cliente pregunta, y evaluar el rastreo después con el dato en mano de cuántos lo piden.

¿Qué pasa cuando el estatus publicado está equivocado?

Es el riesgo real del proyecto y hay que diseñarlo. Cada estatus muestra cuándo se actualizó por última vez, y si pasa demasiado tiempo sin movimiento el portal lo señala en lugar de mostrar un dato viejo como si fuera vigente.

¿El portal sustituye al vendedor?

No, le cambia la conversación. Deja de contestar dónde viene el camión y pasa a atender lo que sí requiere criterio: un faltante, un cambio de presentación, una reclamación de calidad.

Si estás en una situación parecida

Si tu equipo comercial pasa el día contestando preguntas de estatus, el primer paso no es elegir tecnología: es ordenar el proceso y saber qué datos ya tienes. Podemos revisarlo contigo.

Cuéntanos tu caso en westribe.com.mx/solicitar/ o escríbenos por WhatsApp al +52 312 554 2845.