CRM para empresas de mensajería

Por qué a una mensajería no le basta con una CRM

La CRM nació para vender: ficha de cliente, embudo, oportunidades, tareas comerciales, historial de conversaciones. Para eso AmoCRM y Bitrix24 funcionan muy bien. Pero en una empresa de mensajería el trabajo de verdad empieza cuando la venta ya está cerrada, y ahí una CRM estándar enseguida se queda corta.

• No hay mapa ni rutas. La CRM no sabe dónde está el mensajero ni puede ordenar las direcciones teniendo en cuenta las ventanas de entrega.
• No hay puesto de trabajo para quien reparte. El mensajero necesita una pantalla sencilla de «adónde voy, qué llevo, cómo registro el resultado», no la interfaz de un comercial.
• No hay confirmación in situ. Fotos, checklist, constancia de entrega: al final se recoge por mensajería instantánea y se copia después a mano.
• Los estados son demasiado gruesos. Una etapa del embudo como «Enviado a reparto» no dice si el pedido va en camino, está en la puerta o vuelve al almacén.

Intentar resolverlo con campos personalizados y automatizaciones dentro de la CRM suele terminar con el despachador llevando una hoja de cálculo paralela y los comerciales llamando a los mensajeros para saber cómo va cada pedido. Por eso el esquema que funciona es dejar a la CRM lo que sabe hacer y conectarle un sistema independiente para la ejecución de los pedidos.

Cómo repartir los papeles entre la CRM y el sistema de reparto

La regla de oro al integrar CRM y reparto: cada objeto tiene un único dueño. Si el mismo campo se puede editar en dos sitios, tarde o temprano los datos dejarán de coincidir.

• La CRM es dueña del cliente y de la oportunidad: contactos, datos fiscales, contenido del pedido, importe, acuerdos del comercial.
• El sistema de gestión de mensajeros es dueño de la ejecución: a quién se asigna el pedido, en qué orden circula el mensajero, hora real, informe fotográfico, confirmación de entrega.
• 1C u otro sistema contable es dueño del dinero y del stock: documentos, cobros, movimientos de almacén.

Con este reparto, el comercial sigue trabajando en su CRM de siempre, el despachador en el mapa con pedidos y rutas, y el mensajero en una interfaz web móvil sin necesidad de instalar ninguna app. Cada uno ve lo suyo, pero los datos no se duplican: el pedido se crea una sola vez y a partir de ahí solo cambia de estado.

Conviene decidir también quién sigue la entrega desde fuera. Al cliente le resulta más cómodo consultar el estado en el área de cliente que llamar al comercial, lo que quita carga tanto al equipo de ventas como al de despacho.

Sincronización de pedidos con la CRM: qué enviar y cuándo

La sincronización de pedidos con la CRM se diseña mejor como dos flujos: el pedido va de la CRM al reparto y el resultado vuelve.

De la CRM al sistema de reparto se envía lo imprescindible para que el mensajero pueda cumplir el pedido:

• número de oportunidad o de pedido, la clave con la que ambos sistemas se reconocen;
• dirección y contacto del destinatario, teléfono, indicaciones sobre el portal o la oficina;
• ventana de entrega deseada y prioridad;
• contenido del envío y datos que influyen en la asignación: peso, volumen, cobro en destino.

Del sistema de reparto a la CRM vuelve lo que necesitan el comercial y el cliente:

• cambio de estado: asignado, en camino, entregado, no entregado;
• motivo de rechazo o de aplazamiento;
• hora real de ejecución y enlace al informe fotográfico o a la confirmación.

Es clave acordar en qué etapa del embudo pasa el pedido a reparto. Demasiado pronto, y los mensajeros recibirán pedidos sin confirmar; demasiado tarde, y el despachador no tendrá tiempo de planificar las rutas. Lo habitual es usar como disparador una etapa propia, del tipo «Listo para expedir», a partir de la cual el comercial ya no cambia la dirección sin consultarlo con el despachador.

Cómo elegir: checklist para una empresa de mensajería

Al elegir una CRM para reparto y el sistema que trabajará con ella, no compare listas de funciones: compruebe su día real. Tome una decena de pedidos típicos y recórralos desde la oportunidad hasta la confirmación.

• Integración lista con su CRM. ¿Hay conexión con AmoCRM o Bitrix24 de serie o habrá que programar el intercambio desde cero?
• Enlace con la contabilidad. Si el dinero y los documentos están en 1C, hace falta conectarlo también; si no, la conciliación seguirá siendo manual.
• Asignación y rutas. ¿El sistema propone el orden de las direcciones según ventanas de entrega y restricciones, o solo pinta puntos en el mapa?
• Pantalla del mensajero. ¿Puede empezar a trabajar desde el móvil el primer día? ¿Hay informes fotográficos y checklists?
• Estados de vuelta. ¿Ve el comercial el resultado de la entrega en la ficha de la oportunidad sin llamar al mensajero?
• Exportación. ¿Se pueden sacar los datos a Excel para análisis e informes?
• Plazo de puesta en marcha. ¿Cuánto falta hasta el primer turno real y hace falta un contrato a largo plazo?

itlogist está pensado justo para estos requisitos: recepción y asignación de pedidos, rutas en el mapa en tiempo real, optimización con el motor OR-Tools teniendo en cuenta las ventanas de entrega, interfaz móvil para quien reparte e integraciones con 1C, AmoCRM, Bitrix24 y Excel. Más información en Funcionalidades de itlogist.

Implantación sin parar la operación

La integración de CRM y reparto conviene lanzarla por fases, para que el servicio siga entregando mientras se ajusta el intercambio.

• Paso 1. Un solo flujo. Elija un tipo de pedido o una zona y configure el envío de pedidos desde la CRM. Los mensajeros de ese grupo ya trabajan en el nuevo sistema.
• Paso 2. Estados de vuelta. Cuando los pedidos lleguen de forma estable, active el retorno de estados y motivos de rechazo a la CRM. Compruebe que los comerciales han dejado de llamar al despachador para pedir información.
• Paso 3. Rutas y ventanas. Active la optimización de rutas y compare el plan con cómo repartía el despachador los pedidos a mano.
• Paso 4. Escala. Pase el resto de tipos de pedido y zonas y añada el área de cliente.

Errores típicos en el camino: crear el pedido a mano en ambos sistemas «por si acaso», no definir la clave de correspondencia (y acabar con duplicados), permitir cambiar la dirección en la CRM después de enviarla a reparto. Conviene dejar estas reglas por escrito antes del lanzamiento. itlogist está pensado para equipos de 5 a 100 personas en ruta y se pone en marcha en 7 días sin contratos a largo plazo: los primeros resultados se ven ya en el flujo piloto.