Analizaremos cómo funciona su entrega y le diremos qué se automatiza en primer lugar
Cómo reciben hoy las tareas los mensajeros, quién mantiene los estados, qué acredita una entrega y en qué programas están ya sus pedidos.
Software para mensajeros
Tareas, ruta, estados y confirmación de la entrega en una sola aplicación
Mientras hay dos mensajeros, la entrega funciona con llamadas y chat: las direcciones van a una mensajería, el orden de paso se acuerda de palabra y a la pregunta de dónde está un pedido responde quien primero localice al mensajero. Al crecer el número de entregas eso deja de funcionar: las tareas se pierden, los estados van por detrás de la realidad y no hay con qué zanjar la discusión «lo entregamos — no, no lo entregasteis». El software para mensajeros acaba con esa forma de trabajar: la tarea llega a la aplicación del ejecutor, el estado lo pone quien lleva el pedido en el momento de la acción y el hecho de la entrega se registra con hora y autor. A continuación, cómo funciona: desde la asignación de un pedido hasta el cierre del turno.
Qué es un programa
para mensajeros
Software para mensajeros — la herramienta de trabajo del ejecutor: le lleva al mensajero las tareas del turno, le muestra las direcciones y el contenido del pedido, le guía de punto a punto y registra qué ha pasado en cada uno. Del lado de la empresa esto es gestión de la entrega: el coordinador ve quién está dónde y qué se ha hecho ya sin llamar a todo el turno.
La diferencia se ve en un solo ejemplo. Sin software, el mensajero recibe direcciones por chat, llama al cliente para aclarar qué portal es y por la tarde le dicta al coordinador qué entregó. El coordinador lo pasa a una hoja de cálculo, si se acuerda y si el mensajero no ha perdido la cuenta. Al final del día nadie puede decir la hora exacta a la que se entregó un pedido concreto.
En el software todo eso son registros. Una entrega tiene ficha, la ficha tiene dirección, contenido, franja horaria y estado actual, y cada cambio tiene hora y autor. Responder dónde está un pedido y qué le ha pasado lleva segundos y no depende de que el mensajero coja el teléfono.
Un ejemplo. Por la mañana el pedido se preparó en el almacén y se asignó a un mensajero: la tarea apareció en su aplicación junto con la dirección y la franja de entrega. El mensajero recogió la carga, marcó la recogida, recorrió los puntos y en cada uno cambió el estado. En la tercera dirección el cliente no estaba: el mensajero introdujo un motivo y la entrega no desapareció, sino que pasó a la cola de aclaración del coordinador. Por la tarde el gestor respondió al cliente con el registro del sistema y no con la memoria del mensajero.
La automatización del reparto por mensajería empieza donde las respuestas a tres preguntas ya no caben en la cabeza del coordinador: a quién está asignado este pedido, en qué estado está ahora mismo y qué acredita que se entregó.
- 1Pedido
- 2Asignación
- 3Recogida de la carga
- 4Ruta
- 5Entrega
- 6Confirmación
- 7Cierre
Este es el recorrido de una sola entrega y no una lista de las pantallas del programa. Cada transición la ejecuta una persona y en el momento de la acción: el coordinador asigna y el mensajero marca la recogida y la entrega. Por eso el sistema muestra el estado de la entrega y no la intención de quien la planificó.
Qué ve el mensajero de cada tarea
- Qué llevar — el número de pedido, el contenido, el número de bultos y el peso o las medidas cuando importan
- Adónde — la dirección de entrega con sus notas: portal, planta, portero automático, acceso desde el patio
- Cuándo — la fecha y la franja de entrega o el plazo en el que hay que entregar el pedido
- A quién — el nombre y los datos de contacto del destinatario cuando hacen falta para ejecutar la tarea
- Qué tener en cuenta — la nota del pedido: frágil, hace falta ascensor, llamar 15 minutos antes
- Pago — si el pedido está prepagado o hay que cobrar en la entrega, y cuánto
- En qué estado está — el estado actual de la entrega y qué debe hacer el mensajero a continuación
Qué no hace el software por sí mismo
No lleva el pedido ni sustituye al mensajero. Quita el trabajo manual alrededor de una acción: trae la tarea sin llamada, guarda la dirección con sus notas, no deja cerrar una entrega sin resultado y registra cada cambio. La decisión de aplazar una entrega o devolver un pedido sigue siendo de una persona, pero se toma a partir de un registro y no de un acuerdo verbal.
Del mismo modo, el sistema no ve al mensajero por sí solo: sabe exactamente lo que él ha escrito en él mediante una acción. Por eso la calidad de los datos no depende del número de funciones, sino de si las marcas se ponen en el momento del hecho.
Por dónde suelen empezar las empresas
Dos cosas van primero: una lista finita de estados y un resultado obligatorio para cada entrega. El motivo es sencillo: mientras cada cual entienda «en curso» a su manera y una entrega cerrada sin motivo cuente como correcta, no hay con qué construir un informe, por muchas pantallas que tenga la aplicación.
Qué problemas resuelve el programa
A continuación no hay una lista de funciones, sino seis problemas por los que se automatiza el reparto por mensajería en primer lugar. Cada uno se plantea igual: qué ocurre sin software y qué cambia con él.
Las tareas dejan de perderse
Sin software, las direcciones llegan por mensajería, una parte de viva voz por teléfono y otra como lista en una hoja de cálculo. El mensajero compone su día con tres fuentes y algo se le escapa. En el software una tarea es un registro con número y ejecutor: está en curso o cerrada con un resultado.
El estado lo pone quien lleva el pedido
Mientras el coordinador mantenga los estados con lo que le cuentan por teléfono, van una hora por detrás de la realidad y cuestan medio turno. La marca del mensajero en el momento de la acción da las horas reales: cuándo lo recogió, cuándo llegó, cuándo lo entregó.
Las direcciones no hay que aclararlas por teléfono
El portal, la planta, el portero automático y el acceso desde el patio están en la ficha de la entrega y no en la memoria de quien fue la última vez. Un mensajero nuevo cierra la dirección al primer intento y no después de dos llamadas al cliente y una al coordinador.
La entrega queda confirmada
Quién aceptó el pedido, cuándo y con qué fundamento es un registro del sistema y no un recuerdo. La forma de confirmación se elige por proyecto, pero el resultado es el mismo: la discusión «lo entregamos — no, no lo entregasteis» se resuelve abriendo una ficha y no con una consulta entre el gestor y el mensajero.
El turno se ve sin llamar a nadie
El coordinador mira una pantalla: quién está en ruta, cuántos puntos están cerrados y dónde una entrega va por detrás de su franja. «Dónde está mi pedido» deja de ser una tarea para tres personas: el gestor le responde al cliente él mismo.
Las disputas se resuelven desde el registro
Cada cambio va firmado con autor y hora. No es vigilancia del mensajero, sino la posibilidad de aclarar un caso concreto: en qué paso se atascó la entrega y por qué. Además muestra la carga de trabajo: cuántos puntos se cerraron en un turno y quién lo hizo.
De qué se compone el programa
El sistema se compone de módulos. No todas las empresas necesitan todos: un servicio con tres mensajeros y direcciones previsibles no necesita diez escenarios de excepción, mientras que el reparto de comida no puede prescindir de franjas horarias y avisos al cliente. La composición depende de la tarea, pero los módulos están pensados de antemano para encajar entre sí y no se acoplan después.
Lista de tareas
La jornada del mensajero en una pantalla: qué tiene asignado para el turno, en qué orden, qué está ya cerrado y qué queda. Es el punto de entrada del software: aquí empieza el mensajero el día y aquí vuelve después de cada punto.
Ficha de la entrega
Todo sobre un pedido: contenido y número de bultos, dirección con sus notas, franja horaria, destinatario, pago y estado actual. Exactamente lo necesario para ejecutar la tarea, sin los catálogos ni los informes de la empresa.
Puntos y ruta
Las direcciones del turno en un mapa y como lista, el orden de paso y el salto del punto actual al siguiente. Una ruta es un objeto de negocio igual que una tarea: tiene fecha, ejecutor e historial de cambios durante el día.
Estados de la entrega
Un conjunto finito de estados y las reglas de transición entre ellos. El mensajero cambia el estado con una acción y no eligiendo de una lista larga: asignado, recogido, en camino, en la dirección, entregado.
Confirmación de la entrega
Registro del resultado en el punto: el cambio de estado y la forma de confirmación elegida para el proyecto. Sin resultado la tarea no se cierra: «probablemente entregado» no es un estado de una entrega.
Recepción de la carga
La marca de la recogida de un pedido en el almacén o en el punto de partida. Desde ese momento la responsabilidad de la carga es del mensajero y el sistema muestra que el pedido ya no está en el almacén, sino en camino.
Avisos
Mensajes al mensajero y al destinatario: pedido nuevo asignado, tarea modificada, franja que se acerca, pedido cancelado. Los canales de envío se eligen durante la implantación y se conectan mediante integraciones.
Historial de tareas
Qué cerró el mensajero en un día, una semana, un mes: entregas cerradas, tiempos de ejecución, puntos problemáticos. Con esas mismas anotaciones se compone su rendimiento: para eso no hace falta un control aparte.
Contacto con el coordinador
Llegar al coordinador directamente desde la ficha de la tarea, sin buscar un número en el teléfono. El coordinador ve de qué entrega se trata y responde sobre ella en lugar de averiguar qué dirección se quiere decir.
Funcionamiento sin conexión
Las marcas puestas fuera de cobertura —en un sótano, en un ascensor, en un barrio bajo— se guardan en el dispositivo y salen en cuanto aparece conexión. Reenviarlas no crea una segunda entrega.
Panel de operaciones
El puesto de trabajo de la empresa: mensajeros activos, pedidos asignados, estados, entregas cerradas y problemáticas y carga del personal. Se abre en el navegador, no hay nada que instalar.
API e integraciones
La interfaz externa del sistema: crear una entrega, asignar un ejecutor, consultar un estado, extraer la confirmación y el registro. Por ahí se conectan la tienda en línea, el almacén, la logística y los sistemas contables.
Recepción de tareas
cómo llega un pedido al mensajero
Una vez creada la entrega, el pedido se asigna a un mensajero concreto. La asignación no es un mensaje en un chat, sino una operación: la entrega recibe un ejecutor y el ejecutor recibe una tarea con número, hora de emisión y estado actual.
La tarea aparece en la aplicación del mensajero al instante, sin llamada y sin reenviar la dirección. El mensajero abre la lista y ve todo su turno: cuántos puntos tiene asignados, qué está ya cerrado y qué entrega viene después.
Quién asigna. Normalmente el coordinador, a mano o según reglas que fija la empresa: por zona de la ciudad, por tipo de pedido, por tiempo libre del mensajero. El reparto automático se puede implementar según el proceso de un servicio concreto; no lo afirmamos de antemano como función lista: las reglas de reparto son distintas en todas partes y no se pueden inventar en lugar de la empresa.
Qué puede hacer el mensajero con una tarea:
- Aceptar — confirmar que la tarea ha llegado y que se hace cargo de ella
- Abrir la ficha — ver el contenido, la dirección, la franja, las notas y la forma de pago
- Cambiar el estado — marcar la recogida de la carga, la salida, la llegada al punto y la entrega
- Dejar un comentario — anotar lo que será útil la próxima vez o lo que explica un retraso
- Señalar un problema — registrar el motivo por el que una entrega no se produjo
- Escribir al coordinador — hacer una pregunta sobre una entrega concreta sin salir de la tarea
Lo que una tarea no debe contener es nada superfluo. Un mensajero no necesita el importe del pedido, el historial del cliente ni los informes de la empresa: en la pantalla queda lo necesario para llevarlo y entregarlo. Todo lo demás se cierra con permisos de acceso y no con letra pequeña.
Qué ocurre en una reasignación
Un mensajero enferma, se retrasa o no se presenta al turno: una situación corriente y no un fallo. El coordinador le quita la tarea y se la asigna a otro ejecutor; el historial de la entrega conserva ambas asignaciones con sus horas y no solo la última.
Eso cuenta en la práctica: sin un registro de la reasignación, aclarar por qué un pedido llegó tarde tropieza con que el sistema muestra al mensajero actual, que lo recibió una hora antes del fin de la franja.
Los datos de contacto del destinatario
El teléfono del destinatario se muestra cuando hace falta para ejecutar la tarea y solo a quien entrega. El acceso a los datos personales es un permiso propio y no parte de un paquete general de «empleado»: la lista de todos los clientes de la empresa nunca se le abre a un mensajero.
Cómo se muestra exactamente el contacto —completo, en parte o mediante una llamada con número enmascarado— se decide en el estudio previo: depende de con qué datos trabaja la empresa y qué está obligada a proteger.
| № | Franja | Dirección | Bultos | Pago | Estado |
|---|---|---|---|---|---|
| 1 | 10:00—12:00 | Ajunbáyeva 97, portal 2 | 1 | prepagado | entregado |
| 2 | 11:00—14:00 | Toktogula 125, oficina 4 | 3 | prepagado | entregado |
| 3 | 12:00—15:00 | Baitik Baatyra 53 | 1 | 2 400 som | en la dirección |
| 4 | 14:00—17:00 | Chuy 219, acceso desde el patio | 2 | prepagado | en camino |
| 5 | 16:00—19:00 | Ibraímova 42, planta 7 | 1 | 1 150 som | asignado |
La lista está ordenada por franja horaria y no por hora de asignación: al mensajero le importa el orden del día y no el orden en que el coordinador repartió los pedidos. La columna del pago está junto a la dirección por algo: el importe a cobrar hay que verlo antes de haber subido al séptimo piso.
Aplicación móvil
del mensajero
Una aplicación para mensajeros — no es una copia reducida del panel del coordinador, sino una interfaz aparte construida para las condiciones de trabajo del ejecutor: el teléfono en una mano, la caja en la otra, la pantalla al sol, la conexión que va y viene y la batería justa por la tarde.
Tiene un objetivo práctico: toda la información de trabajo en un solo sitio. Un mensajero no debería tener abiertos tres chats, una hoja de direcciones y un historial de llamadas: la tarea, la dirección, el contenido del pedido, el estado y la vía para llegar al coordinador están en una sola interfaz.
La pantalla está construida sobre el principio de «el punto actual y el siguiente». Todo lo que no hace falta ahora queda más abajo: listas de días anteriores, catálogos, detalles que no afectan a la entrega. Cuantos menos elementos en la pantalla, menos errores en el turno y más corta la formación de una persona nueva.
Requisitos que pesan más que el conjunto de funciones:
- Elementos grandes — el estado cambia con un toque y no eligiendo de un desplegable
- El mínimo de tecleo — lo que se puede rellenar desde la ficha de la entrega no lo teclea el mensajero
- Comportamiento previsible sin red — una marca se acepta y se envía después en lugar de perderse con un error
- Uso moderado de la batería — la aplicación no debe pedir una batería externa a media jornada
- Legibilidad al aire libre — el contraste está pensado para la luz del día y no para un monitor de oficina
No tiene sentido calcular cuánto tiempo ahorra esa unificación: depende de en qué se haya convertido hoy el trabajo del mensajero. Se ve otro efecto: desaparece toda una clase de errores, aquellos en los que un pedido se entrega en la dirección del mensaje de ayer porque la nueva llegó a otro chat.
Una aplicación o una interfaz web
La forma se elige según la tarea: puede ser una aplicación móvil para Android e iOS o una página web adaptada que se abre en el navegador del teléfono.
La segunda opción es más barata y más rápida de lanzar; la primera hace falta donde cuentan el trabajo sin conexión, los avisos y el acceso a la cámara. Qué encaja en una empresa concreta se determina en el estudio previo y no se elige de antemano.
Trabajo con mala conexión
La conexión se cae de forma previsible: en un sótano, en un ascensor, en un barrio bajo, en un aparcamiento subterráneo. Si en ese momento una marca no pasa, el mensajero o espera o deja de marcar del todo, y los estados vuelven a vivir en las llamadas.
Por eso las marcas se guardan en el dispositivo y salen cuando vuelve la conexión. Reenviarlas no crea una segunda entrega: cada marca tiene una clave y el sistema la acepta una vez. Es la misma regla por la que funciona el intercambio con los sistemas externos.
- Pedidos en cursopantalla principalLas entregas que el mensajero ya ha asumido, cada una con su estado actual
- Lista de puntospantalla principalLas direcciones del turno en el orden de paso: cerradas, la actual y las que quedan
- Mapadepende del proyectoLos puntos de entrega en un mapa de la ciudad, conectados mediante una integración con un servicio de mapas
- Rutadepende del proyectoEl orden de paso y el salto al siguiente punto; la construcción de la ruta es una posibilidad y no una función lista
- Datos de la entregapantalla principalContenido del pedido, número de bultos, franja horaria, notas, destinatario y pago
- Estadospantalla principalEl cambio del estado de la entrega en una acción, sin elegir de una lista larga
- Confirmación del cierrepantalla principalRegistro del resultado en el punto por la forma elegida para el proyecto
- Historial de tareassegundo nivelQué cerró el mensajero en turnos anteriores; queda más abajo para no recargar el día en curso
- Avisosdepende del proyectoUna tarea nueva, un cambio de ruta, una franja que se acerca, un pedido cancelado
- Contacto con el coordinadorpantalla principalUna pregunta sobre el punto actual directamente desde la ficha de la tarea, sin buscar un número en el teléfono
La marca «depende del proyecto» aparece allí donde la capacidad depende de conectar un servicio externo o de las condiciones de trabajo de un servicio concreto. Todo lo demás es el mínimo de trabajo: sin él la interfaz del ejecutor no sustituye al chat, sino que se le añade como décima fuente de tareas.
Ruta
y puntos de entrega
Un punto de entrega — una dirección con una entrega. El turno de un mensajero se compone de puntos y la aplicación los muestra de dos formas a la vez: como lista en el orden de paso y como marcadores en un mapa. La lista responde a qué hacer después, el mapa a cuán lejos está.
El orden se fija de antemano y es visible para el mensajero: qué punto es el actual, cuáles están cerrados y cuáles quedan. Cerrado un punto, el siguiente pasa a ser el actual: el mensajero no tiene que buscarlo en la lista ni decidir cada vez adónde va.
El orden se puede cambiar durante el día. El coordinador reordena puntos, añade una entrega urgente o quita una cancelada; los cambios llegan al mensajero y el historial de la ruta conserva qué cambió y cuándo. El sistema nunca debe sustituir el plan por otro en silencio: un mensajero que se entera de un cambio a posteriori tiene que replanificar el día.
La construcción automática del orden óptimo — una capacidad que se puede implementar o conectar mediante una integración con un servicio de mapas. No la afirmamos como función lista: la calidad de esa optimización depende de los datos de tráfico y de las limitaciones de un servicio concreto: franjas horarias de los destinatarios, zonas, capacidad de una bolsa o de un vehículo.
En la práctica, a muchos servicios les basta un orden manual: el coordinador conoce la ciudad mejor que el algoritmo y las franjas horarias de los destinatarios ponen de todos modos un marco rígido al día.
Una dirección es más que una calle y un número
La mitad del tiempo perdido de un mensajero no se va en la carretera, sino en encontrar el portal. Por eso un punto tiene notas: portal, planta, código del portero automático, acceso desde el patio, barrera —avisar al vigilante—, segundo bloque, puerta gris.
Las notas las completa el mensajero después de una entrega y se quedan en la ficha de la dirección. El siguiente que vaya allí no tendrá que averiguar lo mismo otra vez: solo así el conocimiento sobre la ciudad se acumula en el sistema y no en las cabezas del turno.
Qué cambia a lo largo de la ruta
Los estados no se cambian en bloque al final del día, sino en cada punto y en el momento de la acción. He llegado a la dirección: en la dirección; lo he entregado: entregado; no he encontrado al destinatario: un motivo y un aplazamiento. De esas marcas salen la hora real de la entrega y la duración de la parada; de lo contrario ambas se reconstruyen de memoria, es decir, no se reconstruyen.
| Orden | Dirección | Franja | Qué se transporta | Nota del punto | Estado |
|---|---|---|---|---|---|
| 1 | Baitik Baatyra 53 | 12:00—15:00 | 1 bulto | Barrera, avisar al vigilante | cerrado |
| 2 | Chuy 219 | 14:00—17:00 | 2 bultos | Acceso desde el patio, puerta gris | actual |
| 3 | Ibraímova 42 | 16:00—19:00 | 1 bulto | Planta 7, ascensor hasta la 6.ª | pendiente |
| 4 | Moskóvskaya 180 | 17:00—20:00 | 3 bultos | Oficina, acreditación en recepción | pendiente |
| 5 | Ajunbáyeva 97 | antes de las 20:00 | 1 bulto | Devolución: el destinatario ha rechazado | añadido |
El quinto punto se añadió a la ruta durante el día: es una devolución por rechazo que hay que recoger. Una devolución viaja como punto propio con dirección y estado y no como un «ya lo devuelves mañana» de palabra: de lo contrario el pedido se sale de la contabilidad justo en el momento en que ya no responde nadie de él.
Estados de la entrega
Un estado no es un rótulo en una pantalla, sino una condición que determina qué acciones están permitidas. El conjunto es finito y corto: mientras no se nombre de forma explícita, cada empleado entiende «en curso» a su manera, y con una docena de estados parecidos el mensajero empieza a elegir al azar.
- AsignadaLa entrega tiene ejecutor y la tarea ha llegado al mensajero. La carga sigue en el almacén o en el punto de partida y la responsabilidad sobre ella no ha cambiado
- Recogida por el mensajeroEl mensajero ha recogido físicamente el pedido y lo ha marcado. Aquí la responsabilidad pasa del almacén al ejecutor: la única transición con dos lados
- En caminoEl mensajero va de camino al destinatario. En este tramo aparecen los eventos intermedios: retenido en el punto anterior, orden de paso cambiado
- En la direcciónEl mensajero ha llegado a la dirección. La marca no está para controlar, sino para medir el tiempo: de ella se cuenta la duración de la propia entrega
- EntregadoEl destinatario aceptó el pedido y la confirmación quedó adjunta a la entrega. Solo ahora la tarea está cerrada, y no en el momento en que el mensajero salió del edificio
Cinco estados son el mínimo de trabajo y no la lista completa. Los intermedios (entregado a clasificación, pasado a otro mensajero) se añaden según el proceso de la empresa, pero el conjunto sigue siendo finito y explícito: cada estado debe responder a qué puede hacer el mensajero a continuación.
| Qué ha ocurrido | Qué hace el sistema | Estado |
|---|---|---|
| El cliente no es localizable: no responde ni en la puerta ni al teléfono | Registra un intento fallido con motivo y comentario del mensajero, deja el pedido con él y plantea la cuestión de una nueva entrega | aclaración |
| La entrega se aplazó a petición del destinatario | Registra la nueva fecha o franja junto con quién acordó el cambio y cuándo; el punto sale de la ruta de hoy | normal |
| El destinatario ha rechazado el pedido | Cierra la entrega con motivo de rechazo y crea un punto de devolución para llevar el pedido de vuelta al almacén o al punto de partida | aclaración |
| El destinatario ha aceptado el pedido en parte | Divide la entrega: las posiciones aceptadas se cierran y las rechazadas pasan a una devolución como registro aparte en lugar de darse de baja con el resto | aclaración |
| Un problema con la dirección: no existe ese edificio, no se encuentra el portal | Abre un evento con el comentario del mensajero y pasa el punto al coordinador para aclararlo, sin cerrar la entrega como cumplida | aclaración |
| El pedido se canceló con el mensajero ya en camino | Quita el punto de la ruta y pasa la entrega a devolución: el pedido no se disuelve, alguien sigue respondiendo de él | normal |
| El mensajero no se ha presentado al turno | Libera sus tareas para reasignarlas y muestra al coordinador todas las entregas afectadas en una lista | aviso |
El principio general: un desenlace fallido no desaparece ni se convierte en uno correcto. La entrega sigue abierta y pasa a la cola de aclaración: sale más barato que un informe sin problemas porque no había dónde registrarlos.
Qué excepciones necesita una empresa se decide en el estudio previo. El reparto de comida necesita franjas cortas y aplazamientos rápidos; el de electrónica, rechazos parciales y devoluciones; el de documentos, comprobación de la identidad del destinatario. El conjunto es configurable, pero la regla es la misma: toda entrega termina con un motivo y el motivo va al informe.
Confirmación
de la recogida y la entrega
Una entrega tiene dos puntos en los que la responsabilidad cambia de manos y ambos se registran. El primero es la recogida de la carga por el mensajero: el pedido sale del almacén y desde ese momento responde de él el ejecutor. El segundo es la entrega al destinatario: la entrega se cierra y la obligación de la empresa queda cumplida.
Sin un registro de esos dos momentos, cualquier pérdida se convierte en un interrogatorio del turno: el almacén cree que entregó el pedido, el mensajero dice que no fue él quien lo llevaba y el gestor le dice al cliente que se está aclarando. La marca lleva segundos; la aclaración sin ella cuesta un día de trabajo y la confianza del cliente.
Qué registra el sistema en la entrega:
- Resultado — la entrega se cumplió, se cumplió en parte o no se produjo, con motivo
- Cuándo — la hora real de la entrega y no la hora a la que el mensajero llegó a comunicarla
- Quién entregó — el ejecutor al que estaba registrada la tarea en ese momento
- A quién — el destinatario o quien aceptó el pedido en su nombre, donde las reglas lo permiten
- Qué lo acredita — la forma de confirmación elegida para el proyecto y el propio resultado
- Pago — donde el pedido se paga al recibirlo: el importe, la forma y el hecho de haberlo cobrado
La forma de confirmación se elige por proyecto. Las opciones que siguen no son una lista de funciones listas ni una promesa de que todas estén ya implementadas. Qué encaja en un servicio concreto depende de qué se entrega, a quién y qué requisitos se ponga la propia empresa.
Sin resultado una tarea no se cierra
Esa regla pesa más que la propia forma de confirmación. Mientras no se registre un resultado, la entrega sigue abierta y el coordinador la ve. De lo contrario, a fin de mes todas las entregas estarán cerradas mientras los casos en disputa haya que resolverlos a base de llamadas.
Pago contra entrega
Donde un pedido se paga en el acto, la confirmación de la entrega y la del pago son dos registros distintos. El importe a cobrar llega junto con la tarea y el hecho de haber cobrado se marca aparte: de lo contrario, al final del turno no hay forma de saber cuánto efectivo lleva el mensajero.
La aceptación del pago con tarjeta o transferencia es posible mediante una integración con un servicio de pagos o con el terminal del ejecutor; el alcance depende del proveedor y se aclara en el estudio previo.
Devoluciones y pedidos no entregados
Un pedido que no se ha podido entregar se queda con el mensajero hasta el momento en que lo devuelve: al almacén, al punto de partida o a otro ejecutor. La devolución se tramita igual que la recogida: por dos partes. Hasta entonces los pedidos no entregados se ven en una lista aparte en lugar de disolverse en la estadística general del turno.
- Cambio de estadoopción básicaEl mensajero marca la entrega en la aplicación: se registran la hora, el autor y el resultado. Funciona siempre y encaja donde las disputas son raras
- Código de confirmaciónopciónEl destinatario dicta un código corto de un mensaje: la prueba de que el pedido se le entregó a él y no se dejó en la puerta
- Código QRopciónEl mensajero escanea un código del pedido o el destinatario escanea uno de la pantalla del mensajero. Cómodo donde se entregan varios pedidos seguidos en un mismo punto
- FotografíaopciónUna imagen del pedido entregado o del sitio donde se dejó por acuerdo. Se adjunta a la entrega y se guarda con ella
- Marca electrónica del destinatarioopciónUna firma o confirmación en la pantalla del dispositivo del mensajero: el sustituto habitual del albarán en papel
- DocumentoopciónUna marca en un albarán o acta donde el papel es obligatorio. No sustituye al registro del sistema, lo complementa
Ninguna de las opciones es obligatoria y ninguna se afirma como ya construida: el conjunto se determina en el estudio previo, a partir de qué se entrega, qué disputas surgen más a menudo y qué requisitos se ponga la propia empresa. Cuanto más estricta es la confirmación, más tiempo está el mensajero en el punto, por eso conviene endurecerla donde de verdad se producen casos en disputa.
Conexión con el almacén
entrega del pedido al mensajero
El almacén y la entrega no son dos departamentos con un chat común, sino dos etapas de un proceso. Un pedido preparado pero no entregado y un pedido entregado pero no marcado son estados distintos, y confundirlos sale caro: el primero se busca en el almacén, el segundo en el mensajero.
La juntura es sencilla: el operario marca la entrega, el mensajero marca la recogida. Hasta que ambas marcas están puestas, el pedido se mantiene en un estado intermedio visible para las dos partes. Así un bulto que falta tiene siempre una etapa en la que se perdió y la aclaración no se convierte en un interrogatorio del turno.
La contabilidad completa del almacén —recepción, almacenamiento por ubicaciones, existencias, preparación e inventario— es objeto de una página aparte, Para el almacén. Aquí solo se describe la juntura: qué entrega el almacén al mensajero y qué recibe de vuelta.
Si el almacén funciona en otro programa — la situación habitual: la contabilidad del almacén se lleva ya en un sistema existente y nadie piensa cambiarlo. Entonces la juntura se construye como un intercambio: el software de mensajeros recibe la disposición de los pedidos y la composición de los bultos y devuelve estados, confirmaciones y devoluciones.
El alcance del intercambio lo determina lo que el sistema externo pueda entregar al exterior y se aclara en el estudio previo. Declarar de antemano una integración lista sería hacer una promesa por un producto ajeno.
El mismo principio vale en sentido contrario, en las devoluciones. Sin una marca de entrega, un pedido no entregado vive en el maletero del mensajero hasta el turno siguiente y desaparece de la contabilidad justo en el momento en que ya no responde nadie de él.
Qué confirma el mensajero en la recogida
- Qué pedidos — los números de las entregas que asume en esta salida
- Cuántos bultos — el número de cajas o bolsas de cada pedido
- Estado del embalaje — intacto o dañado; lo dudoso se señala en el sitio y no en la puerta del cliente
- Cuándo y quién — la hora de la entrega y ambos empleados: quién dio y quién tomó
Qué vuelve al almacén
El flujo inverso cuenta igual: los pedidos no entregados, los rechazos y las devoluciones parciales vuelven con el motivo de su regreso. El almacén los acepta mediante una operación, igual que aceptaría una entrega, y el pedido vuelve a ser su responsabilidad.
- 1Pedido preparado
- 2Comprobado
- 3Entregado al mensajero
- 4Entrega iniciada
La tercera transición es la única en la que el pedido cambia de manos, por eso la tramitan dos partes: el almacén entregó, el mensajero aceptó. Si el paso se salta, cuando desaparece un bulto no se puede nombrar la etapa y la responsabilidad la reparte quien más alto hable en la reunión.
Aplicación para mensajeros
Ruta y puntos
Confirmación de la entrega
Panel de operaciones
Panel de operaciones
qué ve la empresa
Panel de operaciones — la otra mitad del sistema: lo que ve la empresa mientras los mensajeros trabajan en la aplicación. Su tarea no es mostrar todos los datos, sino reunir en una pantalla lo que exige una decisión ahora y dejar el resto más abajo.
Aquí hay una idea principal: la empresa entiende qué ocurre con una entrega sin llamar constantemente a cada mensajero. El coordinador mira una pantalla en lugar de llamar a cinco personas seguidas para averiguar quién ha cerrado qué dirección.
Qué muestra el panel:
- Mensajeros activos — quién está de turno, quién está en ruta, quién ha terminado y a quién se le agota la jornada
- Pedidos asignados — qué entregas están vinculadas a quién y cuántos puntos le quedan a cada uno
- Estados actuales — el reparto de las entregas por estado en una lista, sin contar a mano
- Entregas cerradas — qué se ha cerrado durante el turno, con la hora de la entrega y la confirmación
- Entregas problemáticas — intentos fallidos, rechazos, devoluciones y puntos con la franja a punto de vencer
- Sin asignar — pedidos que aún no están asignados a ningún mensajero
- Carga del personal — cuántos puntos tiene asignados cada persona y cuántos cierra realmente en un turno
- Historial de operaciones — qué ha pasado con cualquier entrega, con autor y hora de cada cambio
Permisos de acceso separan el panel por roles: un mensajero ve solo sus tareas del día, un coordinador su turno o su zona y la dirección todas las direcciones y los informes. El acceso a los datos de contacto de los destinatarios y la cancelación de una entrega son permisos propios y no parte de un paquete general de «empleado».
Resumen del turno
146entregas asignados
7puntos con riesgo de retraso
3de la entrega en aclaración
11pedidos sin asignar
Una pantalla del sistema, las cifras son ilustrativas. El orden de los recuadros no es casual: primero va el volumen del turno y después lo que exige una decisión. Los pedidos sin asignar van al final, porque es el único recuadro que el coordinador cierra él mismo y por completo.
Contacto con el mensajero
Un mensaje llega al coordinador vinculado a una entrega: se ve de qué dirección se trata y en qué estado está. Eso quita la mitad de la conversación: la mitad que se va en averiguar de qué pedido se habla.
Al revés funciona igual: el mensaje del coordinador le llega al mensajero en la ficha de la tarea y no como una llamada aparte que oirá en la escalera entre el sexto y el séptimo piso.
Un rol en lugar de un conjunto de casillas
La separación se fija por rol y no con permisos individuales para cada persona. De lo contrario, medio año después a un empleado nuevo se le configura «el mismo acceso que a Ivánov» y ya nadie puede decir a qué tiene acceso exactamente.
Conexión con la logística
Un sistema logístico gestiona el proceso de entrega en su conjunto: solicitudes, cargas, vehículos, planificación del día y reparto del trabajo. El software para mensajeros es la herramienta de trabajo del ejecutor dentro de ese proceso. No son dos productos que compiten, sino niveles distintos de una misma tarea: uno responde a cómo organizar una entrega y el otro a cómo ejecutarla y registrarla.
- 1Almacén
- 2Logística
- 3Mensajero
- 4Cliente
El almacén responde de que el pedido esté preparado y entregado. La logística responde de a quién se le asigna y para qué día. El mensajero responde de que llegue y se entregue. El cliente cierra la cadena al recibirlo. Una rotura entre dos eslabones cualesquiera tiene el mismo aspecto: el pedido existe en un sistema y falta en otro, y responde de él quien primero cogió el teléfono.
Qué llega de la logística
Una entrega lista con la dirección, la franja horaria, el contenido del pedido y el destinatario, más la asignación: a qué mensajero se le ha dado y para qué día. La planificación del día y el reparto del trabajo se quedan del lado del sistema logístico.
Qué hace el software para mensajeros
Lleva la tarea al ejecutor, le guía por los puntos y registra estados y confirmación de la entrega. Es la única fuente de datos reales de la entrega: todo lo demás es plan y no hecho.
Qué vuelve
Estados reales con horas, el resultado de cada punto, los motivos de las entregas fallidas, las devoluciones y los comentarios del mensajero. Con eso la logística construye el informe del periodo y el gestor responde al cliente sin llamar al ejecutor.
Si la logística ya existe
El software para mensajeros puede funcionar como aplicación aparte conectada por API al sistema existente: recibe tareas y devuelve estados y confirmaciones. Esa opción hace falta donde no se piensa cambiar la capa logística.
El análisis detallado del lado logístico —solicitudes de transporte, registro de cargas, planificación de rutas y trabajo de la flota— está en la página de software para logística. Aquí importa otra cosa: las marcas del mensajero son la única fuente de estados reales, por eso su puesto de trabajo se diseña el primero y no el último.
Avisos
Un aviso hace falta allí donde de otro modo habría que llamar. Son pocos y concretos: cada uno informa de un evento tras el cual alguien tiene que hacer algo. Todo lo demás se queda en la lista de tareas y no distrae al mensajero en la escalera.
Pedido nuevo asignado
El mensajero ha recibido una tarea: dirección, franja y contenido. La ve enseguida y no al terminar la entrega en curso, y puede encajar el punto en el orden de paso antes de cruzar al otro extremo de la ciudad.
Tarea o ruta modificada
El coordinador ha reordenado los puntos, ha añadido una entrega urgente o ha quitado una cancelada. Sin aviso el mensajero se entera al llegar a la dirección antigua y pierde una hora en volver.
Se acerca la hora de la entrega
Un recordatorio de un punto cuya franja está a punto de agotarse. Llega con antelación y no en el momento de perderla: no se trata de registrar el retraso, sino de evitarlo.
El pedido se ha cancelado
La cancelación le llega al mensajero antes de que suba al séptimo piso. Si el pedido ya está en sus manos, el aviso viene con qué hacer después: devolverlo al almacén o pasarlo a otro ejecutor.
Se requiere acción del mensajero
Una tarea lleva tiempo sin marca, una entrega no se ha cerrado con un resultado, el coordinador ha hecho una pregunta sobre un punto. No es control por el control: una entrega que queda abierta por la tarde se convierte al día siguiente en una aclaración.
Mensajes al destinatario
También al cliente hay algo que decirle: el pedido se ha entregado a un mensajero, el mensajero va de camino, la entrega se ha aplazado. Eso quita parte de las llamadas entrantes a la empresa: quien conoce el estado no llama para preguntarlo.
Los canales de envío —un mensaje en la aplicación, SMS, una mensajería, el correo— se eligen durante la implantación y se conectan mediante integraciones. No afirmamos de antemano que existan conexiones listas con servicios concretos: el conjunto depende de qué usan los clientes de la empresa y de qué hay disponible en su país.
Historial de acciones
El historial no es un archivo por si acaso, sino una herramienta de aclaración. Las anotaciones no se editan: una corrección se añade como evento nuevo con motivo. Por eso la pregunta de por qué un pedido llegó a las siete de la tarde tiene una respuesta y no varias versiones.
A quién estaba asignado el pedido
El ejecutor, la hora de la asignación y el autor, junto con cada reasignación si la tarea pasó de un mensajero a otro durante el día.
Cuándo lo recogió el mensajero
El hecho de la entrega por ambas partes: quién dio, quién tomó, cuándo y cuántos bultos. El momento a partir del cual la responsabilidad del pedido es del ejecutor.
Cuándo cambió el estado
Cada transición con hora exacta y autor: salió, llegó al punto, entregó. De esas marcas se compone la duración real de la entrega.
Cómo terminó todo
El resultado de la entrega y la forma de confirmación y, donde no se produjo, el motivo, el comentario del mensajero y lo que se decidió después.
| Hora | Evento | Quién | Qué se registró |
|---|---|---|---|
| 09:12 | Asignada | Coordinador | Ejecutor: mensajero Azamat, franja 12:00—15:00 |
| 10:05 | Recogida por el mensajero | Almacén + mensajero | 1 bulto, embalaje intacto, entrega confirmada por ambas partes |
| 12:41 | En la dirección | Mensajero | Llegada a Baitik Baatyra 53 |
| 12:58 | Intento fallido | Mensajero | El destinatario no responde; comentario: la barrera está cerrada, el vigilante no me deja pasar |
| 13:20 | Aplazada | Coordinador | Acordado con el destinatario para las 17:00—19:00 del mismo día |
| 17:34 | Entregada | Mensajero | Código de confirmación aceptado, cobrados 2 400 som en efectivo |
Ese registro muestra no solo que el pedido se entregó, sino también por qué llegó cinco horas después de la franja. Precisamente esas cadenas merecen atención: muestran qué paso del proceso ocurre fuera del sistema; en este caso, el procedimiento para pasar el control de seguridad nunca se anotó en la dirección.
Analítica de la entrega
Los informes se componen con las mismas anotaciones que los mensajeros ponen durante el turno: no hace falta una introducción de datos aparte para la analítica. Los indicadores son pocos y cada uno responde a una pregunta sobre la que se decide: cuántos mensajeros hacen falta mañana, dónde se rompe el proceso con más frecuencia y a quién toca descargar.
Número de entregas
Cuántos pedidos se asignaron en un día, una semana o un mes: por empresa, por zona y por mensajero. La cifra base con la que se calcula todo lo demás.
Entregas cerradas
Cuántas se cerraron con un resultado y qué porcentaje de ellas cayó dentro de la franja acordada. Lo segundo pesa más que lo primero: «entregado tarde» no es lo mismo que «entregado».
Cancelaciones y devoluciones
Cuántos pedidos volvieron y por qué motivos: el destinatario rechazó, la empresa canceló, no se entregó. El motivo es obligatorio: sin él la cifra no explica nada.
Tiempo de ejecución
Cuánto dura una entrega desde la recogida de la carga hasta la entrega y cuánto dura la propia parada. Esas dos cifras muestran adónde se va el tiempo: a la carretera o al sitio.
Carga de los mensajeros
Cuántos puntos recaen en una persona y cuántos cierra realmente. De ahí sale la respuesta a si hace falta otro mensajero o si es cuestión del reparto del trabajo.
Pedidos problemáticos
La lista de entregas que exigieron una aclaración, con motivos. A fin de mes no se ve «estas cosas pasan», sino una lista concreta de fallos recurrentes.
Historial de trabajo
Rendimiento por empleado y por dirección durante un periodo. Se compone con las tareas cerradas, por eso no hace falta un control horario aparte.
Exportación
Los informes se exportan a un archivo, se pueden generar según calendario o extraer por API desde un sistema externo, para cuando los informes consolidados de la empresa se llevan en otro programa.
Las barras muestran el porcentaje sobre la primera línea y no sobre el número total de pedidos: la comparación con sentido es con el desenlace normal y no con una media. La línea que hay que mirar en una tabla así es la segunda: setenta y cuatro entregas tardías en una semana no son un horario apretado, sino direcciones concretas y horas concretas que el turno no saca adelante.
Integraciones e intercambio de datos
Una entrega rara vez está sola: los pedidos llegan de un programa, los clientes se llevan en un segundo y el almacén en un tercero. A continuación, las direcciones por las que más a menudo se construye el intercambio. El alcance concreto lo determina lo que el sistema externo pueda entregar al exterior y se aclara en el estudio previo: no prometemos conectores listos de antemano.
Comercio electrónico
Un pedido realizado se puede transmitir automáticamente a la entrega y el estado se le puede devolver al cliente en su área personal. Cómo están construidos el propio escaparate y la gestión de pedidos se explica en la página de comercio electrónico.
Sistema de almacén
La disposición del pedido y la composición de los bultos llegan del almacén, mientras que el hecho de la entrega al mensajero y las devoluciones vuelven. La capa de almacén se analiza en detalle en la página Para el almacén.
Logística
Puede trabajar junto con un sistema logístico: este planifica el día y reparte los pedidos mientras el software para mensajeros devuelve los estados reales. En detalle, en la página de logística.
CRM
Es posible una integración con el catálogo de clientes y el historial de oportunidades: una entrega se crea desde la ficha del cliente y su resultado vuelve al gestor. El intercambio funciona con el identificador del cliente para no crear contactos duplicados.
ERP y sistemas contables
Puede trabajar junto con la capa contable de la empresa: pedidos, albaranes, liquidaciones, pago contra entrega. La dirección del intercambio la determina qué contabilidad se reconoce como principal.
Servicios de mapas
El mapa, la geocodificación de direcciones y el trazado de un camino entre puntos se conectan mediante una integración con un servicio externo. Cuál se elige lo deciden la cobertura de las ciudades que necesita y las condiciones de uso.
Avisos y servicios externos
Mensajes al mensajero y al destinatario, servicios de pago para el cobro contra entrega, transportistas subcontratados. Cada conexión es un módulo de intercambio propio y no una casilla en los ajustes.
API
La interfaz propia del sistema: crear una entrega, asignar un ejecutor, consultar estado y confirmación, extraer el registro de eventos. Todo lo que no tiene un módulo propio se conecta a través de ella.
Las reglas del intercambio son las mismas en todas partes: cada operación tiene una clave, de modo que un reenvío no crea una segunda entrega; un desenlace fallido no desaparece, sino que pasa a la cola de aclaración; cada mensaje y cada respuesta se escriben en el registro del intercambio. Sin esas tres reglas una integración funciona exactamente hasta el primer corte de conexión.
Orden de implantación
Una entrega no pasa a un sistema entera en un día: mientras parte de las tareas transcurran fuera del software, sus estados no significan nada. Por eso el arranque va por etapas y cada una se apoya en una etapa anterior que ya funciona.
1. Estudio previo
Cómo reciben hoy las tareas los mensajeros, quién mantiene los estados, qué acredita una entrega, qué excepciones surgen más a menudo y qué programas hay ya. El resultado es una descripción del proceso y una lista de lo que se automatiza primero.
2. Estados y resultados
Una lista finita de estados, las reglas de transición entre ellos y un resultado obligatorio para cada entrega. La etapa más subestimada: sin ella la aplicación se convierte en un sitio más donde la gente mantiene una conversación.
3. Un piloto con un grupo de mensajeros
Una zona, un turno o dos o tres ejecutores recorren el ciclo completo con entregas reales: asignación, recogida de la carga, ruta, estados, confirmación y aclaración de los puntos problemáticos.
4. Despliegue e intercambio
Los mensajeros restantes siguen el patrón probado, después los roles y permisos y después las integraciones como módulos de intercambio propios. A partir de ahí se acumula historial y aparecen los informes por periodos y los datos para planificar los turnos.
Nuestros clientes
Hablemos de su entrega
Contacte con nosotros ahora
Cuéntenos cuántos mensajeros tiene y cuántas entregas salen al día, cómo se reparten hoy las tareas, qué acredita una entrega y en qué programas están sus pedidos y clientes. Le diremos qué se automatiza primero, qué se puede conectar a sus sistemas actuales y por dónde tiene sentido empezar el piloto.
