Sistemas de gestión de entregas: qué tipos hay y en qué se diferencian

Qué se considera un sistema de gestión de entregas

Bajo ese nombre conviven en el mercado productos bastante distintos, así que conviene fijar primero los límites. Un sistema de gestión de entregas se ocupa del circuito operativo: de cuanto ocurre entre la aparición del pedido y la confirmación de que se ha cumplido sobre el terreno. El conjunto habitual de tareas es este:

• recepción y asignación de pedidos a los operarios;
• rutas en el mapa en tiempo real;
• aplicación móvil del operario con informes fotográficos y listas de verificación;
• portal del cliente con los estados;
• optimización de rutas teniendo en cuenta ventanas de entrega y restricciones;
• confirmación del trabajo realizado in situ.

En eso se diferencia del sistema contable y del CRM: estos se ocupan del dinero, los documentos, los clientes y las operaciones, no de dónde está ahora el mensajero ni de por qué no llegó en la ventana acordada. En la práctica los límites son difusos: parte de esas funciones aparece también en la contabilidad y en servicios móviles sueltos. Por eso tiene sentido comparar las soluciones no por la etiqueta de la categoría, sino por qué parte del ciclo del pedido cubren realmente.

También ayuda entender de dónde suele nacer la necesidad de un producto así. Casi nunca se busca «para el futuro»: el detonante es una avería concreta. El gestor deja de recordar dónde está cada operario. El cliente llama antes de que la empresa se entere de que la visita se ha aplazado. Los resultados del turno se recopilan a mano por la tarde y las discrepancias aparecen al día siguiente. Si sabes qué fallo exacto quieres cerrar, el panorama del mercado se reduce drásticamente: la mayoría de las opciones se descartan con la primera pregunta sobre tu cuello de botella.

Cinco tipos de solución y el techo de cada uno

Prácticamente cualquier herramienta con la que hoy se gestionan entregas cae en uno de estos cinco tipos. La diferencia entre ellos no está en el número de funciones, sino en la escala a la que dejan de dar abasto.

• Hojas de cálculo y mensajería instantánea. Excel más un chat de trabajo: no cuesta nada y le resulta familiar a cualquiera. El techo llega enseguida: los estados solo existen en la conversación, el reparto se hace a mano, el historial se pierde y la discusión de «entregado o no» no hay con qué zanjarla.
• Navegadores y mapas. Trazan bien el trayecto entre puntos, pero no gestionan pedidos: no los reparten entre los operarios, no tienen en cuenta ventanas ni restricciones, no registran el hecho de la ejecución y no dan informes.
• Módulo de entregas dentro del sistema contable o del CRM. Los datos quedan junto a los pedidos, y eso es una ventaja. El punto débil es la parte de campo: el trabajo cómodo del operario desde el móvil, los informes fotográficos y las listas de verificación suelen quedar cubiertos de forma superficial.
• Desarrollo a medida. Encaja exactamente con tu proceso, pero se paga con plazos, con dependencia de unos programadores concretos y con el coste de mantenimiento cada vez que el proceso cambia.
• Plataformas especializadas de gestión de mensajeros y personal de campo. El circuito entero —desde la recepción del pedido hasta la confirmación in situ— vive en una sola ventana y se conecta con tus fuentes de datos.

itlogist pertenece a este último tipo: es un sistema de gestión de mensajeros y personal de campo para equipos de 5 a 100 operarios, y las Funcionalidades de itlogist están reunidas en un único circuito de despacho, con el reparto de pedidos, las rutas en el mapa, el trabajo móvil del operario y los estados para el cliente.

Lo más frecuente al empezar a elegir es que en la empresa no funcione un solo tipo, sino un híbrido: los pedidos llegan al CRM, el orden de los puntos se calcula a ojo en el navegador, el informe del turno se cuadra en una hoja de cálculo y el hilo que une las piezas es la conversación del chat. Ese esquema aguanta mucho tiempo e incluso parece gratis, hasta que el coste empieza a contarse en horas del gestor y en segundas visitas perdidas. El sentido de pasar a un tipo especializado no es tener más funciones, sino eliminar las costuras manuales entre herramientas: es justo en las costuras donde se pierden los datos.

Ejes de comparación: qué mirar en lugar de qué creer

Una vez elegido el tipo de solución, la comparación dentro de él se puede reducir a unos pocos ejes. Son estables: cualquier producto se puede verificar según ellos durante la demo, sin depender de las fórmulas del marketing.

• Cobertura del ciclo. El sistema lleva el pedido desde su entrada hasta la confirmación de la ejecución, o bien cubre una sola etapa y el resto hay que armarlo con varios servicios.
• Parte de campo y barrera de entrada. Lo fácil que le resulta al operario ponerse a trabajar. En itlogist es una interfaz web móvil sin necesidad de instalar una aplicación: el mensajero abre un enlace y ve sus pedidos y su ruta.
• Optimización de rutas. Hay una diferencia entre ordenar direcciones sin más y una optimización de verdad. En itlogist trabaja un motor basado en OR-Tools que tiene en cuenta las ventanas de entrega y las restricciones.
• Integraciones. Los pedidos deben entrar en el sistema desde tu fuente habitual: se admiten 1C, AmoCRM, Bitrix24 y Excel.
• Transparencia para el cliente. Un portal con los estados libera al gestor del aluvión de llamadas de «¿dónde está mi pedido?».
• Condiciones de arranque. Una puesta en marcha en 7 días y sin contratos a largo plazo permite probar el sistema con tus propios pedidos, en lugar de emprender un proyecto de implantación de muchos meses.

Un consejo de la práctica: compara según estos ejes con tus propios pedidos. Un juego de datos de demostración siempre queda impecable; tus direcciones, ventanas y aplazamientos reales retratan el sistema con más honestidad.

Los ejes no pesan lo mismo, y el peso lo marca tu cuello de botella. Si el tiempo se va en repartir pedidos entre operarios, lo decisivo serán la asignación y la optimización de rutas. Si lo que más abunda son las disputas de «hecho o no hecho», pasa al primer plano la parte de campo con informes fotográficos y listas de verificación. Si los gestores reteclean datos de un programa a otro, lo más importante son las integraciones y el retorno de los estados. Ordena los ejes según tu prioridad de antemano: si no, la comparación se desviará hacia detalles de interfaz que no influyen en el resultado del turno.

Lo que no se ve en las tablas comparativas

Las tablas de «función contra función» son cómodas, pero hay varias cosas importantes que casi nunca entran en ellas. Y son precisamente esas las que luego deciden si el sistema arraiga o se queda como una segunda ventana en la que nadie entra.

• El retorno de los datos. Meter un pedido en el sistema es fácil; la cuestión es si el resultado vuelve a tu contabilidad: hecho y hora de la ejecución, estado, confirmaciones. Sin ese retorno, el gestor sigue metiendo cada dato a mano.
• La disciplina de registro. Quien introduce los datos es el operario sobre el terreno. Cuantas más acciones le exija la interfaz, más pobres y más tardíos serán los datos en los que te apoyas.
• Quién mantiene los catálogos. Si los clientes y las direcciones se dan de alta en dos sitios, acabarán duplicándose: esa regla hay que fijarla desde el principio.
• El comportamiento ante los errores. Qué pasa con un pedido si la dirección está vacía o no se encuentra al cliente: se pierde en silencio o cae en una cola para revisar.
• Los porcentajes de ahorro prometidos. No sirven para comparar: el efecto depende de la densidad de puntos, de la duración de las ventanas y de la disciplina de los operarios. Hay que comprobarlo en tus propias rutas, en un piloto.

La prueba práctica en la demo lleva cinco minutos: pide que lleven un pedido tuyo de principio a fin, desde la fuente al sistema, al operario, a la interfaz móvil y de vuelta con el estado. Si el recorrido transcurre sin copiar nada a mano, la integración funciona.

Otra partida invisible en las tablas es el coste de propiedad. La licencia o la suscripción es solo una parte de la suma: a ella se suman la configuración para tu proceso, la formación de gestores y operarios y el soporte cada vez que cambian las reglas de trabajo. El desarrollo a medida es aquí el más traicionero: la programación parece una inversión única, pero el mantenimiento resulta permanente y dependiente de personas concretas. Por eso, al comparar, es más honesto poner sobre la mesa no el precio mensual, sino la respuesta a esta pregunta: cuánto tiempo pasará desde la decisión hasta el momento en que un turno entero transcurra dentro del sistema, sin muletas.

Qué encaja con tu segmento

Los requisitos cambian bastante según lo que hagan tus empleados sobre el terreno. Un mismo producto puede cubrir de maravilla el reparto de mensajería y pasar de largo por las tareas del servicio a domicilio.

• Reparto de mensajería. Son críticos el reparto rápido del flujo de pedidos, las rutas en el mapa en tiempo real, los estados y la confirmación de la entrega. La densidad de puntos es alta y la prioridad son la velocidad de procesamiento y la transparencia para el destinatario.
• Servicio a domicilio: instalación, reparación, mediciones, mantenimiento. La visita es larga y sustanciosa: importan las listas de verificación, los informes fotográficos y la confirmación del trabajo realizado in situ, no solo la marca de «he llegado».
• Distribución y representantes comerciales. Hacen falta rutas regulares por los puntos de venta, control de las visitas y recogida de datos directamente sobre el terreno.

De ahí se deduce una regla de selección sencilla: si un sistema está hecho de origen para un solo escenario, los contiguos los cubrirá a duras penas. Plataformas como itlogist abarcan los tres segmentos con un mismo circuito, algo cómodo cuando en la empresa hay reparto, trabajos de campo y ventas sobre el terreno y no se quiere mantener tres herramientas inconexas.

Mira también la composición del equipo. Una plantilla mixta, con una parte contratada y otra que se incorpora en el pico de temporada, impone su propio requisito: el recién llegado tiene que poder trabajar el primer día, sin instalar ni configurar nada en su teléfono. La estacionalidad añade un segundo: aguantar con tranquilidad tanto cinco operarios en temporada baja como varias decenas en el pico, sin rehacer los procesos. El rango de 5 a 100 operarios habla justamente de equipos así: el sistema no debe romperse ni en el límite inferior ni en el superior.

Un algoritmo breve para elegir

Reunamos el panorama en una secuencia de pasos con la que ir hacia la decisión sin vueltas de comparación innecesarias.

• Describe tu cuello de botella. Qué es exactamente lo que come tiempo ahora: el reparto manual, las llamadas a los operarios, los pedidos perdidos o los resultados de visita en disputa.
• Descarta el tipo que no encaja. Si necesitas registrar la ejecución y trabajar desde el móvil sobre el terreno, las hojas de cálculo y los navegadores quedan fuera de inmediato: esa capa no la cubren.
• Comprueba la integración con tu fuente de pedidos. 1C, CRM o Excel: los pedidos deben entrar en el sistema sin traspaso manual.
• Haz un piloto con tus datos. Uno o dos turnos reales completos enseñan más que cualquier presentación.
• Valora las condiciones de entrada. Un arranque corto y la ausencia de contratos largos significan que el precio del error es bajo.

La conclusión del panorama es simple: no se elige el sistema «con más funciones», sino aquel en el que el gestor y los operarios trabajan más rápido que con hojas de cálculo y llamadas, y en el que los datos del trabajo realizado llegan solos a tu contabilidad.

Al piloto conviene ponerle criterios de éxito por adelantado; si no, la discusión final se reducirá a valoraciones de gusto. Un mínimo razonable: el gestor montó el turno sin llamar a nadie; los operarios cerraron los puntos con confirmación fotográfica; el cliente vio los estados por su cuenta; el resultado del turno acabó en la contabilidad sin traspaso manual; los aplazamientos y las cancelaciones quedaron registrados con su motivo y no en el chat. Si cuatro de esos cinco puntos se cumplen ya en la primera semana, el tipo y el producto están bien elegidos. Si no, el error casi siempre está en el tipo de solución y no en los ajustes, y hay que volver al primer paso.