Integración de entregas con CRM: qué datos se transfieren y cómo configurar el intercambio

Qué se rompe cuando el CRM y la operación viven por separado

El CRM se ocupa de la relación con el cliente: ahí están los tratos, los contactos y lo pactado sobre plazos y cobros. El sistema de gestión de entregas se ocupa de la ejecución: quién va, en qué orden y con qué se acredita que el trabajo se hizo. Mientras esos dos circuitos no estén conectados, en medio hay una persona que traslada los datos a mano, y el precio de ese trasvase no se mide solo en tiempo.

Las consecuencias habituales de esa desconexión son estas:

• Doble tecleo y erratas. Una dirección escrita por segunda vez es una dirección con posibilidades de salir mal. El técnico acaba en el sitio equivocado y el problema se resuelve ya en la calle.
• Estados que llegan tarde. El comercial no ve qué pasa con el pedido y le responde al cliente «ahora lo consulto» en lugar de darle una respuesta concreta. Cada consulta de esas es una llamada al coordinador.
• Pedidos perdidos. El trato pasó a la etapa «enviado a reparto», pero nunca llegó al coordinador: nadie se dio cuenta hasta que llamó el cliente.
• Informes que no cuadran. En el CRM hay un número de envíos y en el sistema operativo otro, y solo alguien con muy buena memoria para los detalles sabe explicar la diferencia.

La integración elimina esa capa manual: el pedido aparece ante el coordinador en el momento en que el trato alcanza la etapa correspondiente, y el resultado de la ejecución vuelve a la ficha del cliente sin que nadie tenga que contarlo. Lo demás —avisos, analítica, comodidad de las interfaces— se construye encima de ese intercambio básico. Por eso conviene diseñar la integración partiendo de la pregunta «qué hechos deben circular y en qué dirección», y no de «qué botones hay que pulsar».

Qué datos circulan entre el CRM y el sistema de entregas

El intercambio casi siempre es bidireccional, y va bien describirlo con dos listas cortas: qué sale del CRM y qué vuelve. Del CRM al sistema de entregas suelen transferirse:

• el pedido o la orden: número, tipo de trabajo, contenido y comentario del comercial;
• la dirección de ejecución con las indicaciones de acceso: portal, planta, pase de entrada, a quién llamar al llegar;
• los contactos del destinatario y la franja horaria acordada;
• el importe y la forma de pago, si el técnico cobra en mano;
• la marca de urgencia o prioridad, para que el coordinador vea qué no se puede dejar para mañana.

De vuelta, del sistema de entregas al CRM, regresan los hechos de la ejecución:

• el técnico asignado y la hora estimada de llegada;
• los estados: aceptado, en camino, en el domicilio, hecho, no hecho;
• el motivo de no ejecución elegido de una lista cerrada: rechazo, no contesta, dirección no localizada, aplazamiento a petición del cliente;
• los justificantes: informe fotográfico, firma del destinatario, hora y lugar del registro;
• el cobro realizado en el domicilio, si lo hizo el técnico.

Aparte hay que pactar qué ocurre con los maestros de clientes y direcciones. Si se dan de alta por ambos lados, los duplicados aparecen el primer mes: «Comercial Ramos SL» y «Ramos SL, Comercial» pasan a ser dos registros con historiales distintos, y cualquier informe por cliente habrá que montarlo a mano. Es más sencillo nombrar a un sistema dueño del maestro y al otro, consumidor.

Un truco práctico que ahorra semanas de correos: antes de empezar, vuelca los campos en una tabla de cuatro columnas —nombre en el CRM, nombre en el sistema de entregas, dirección del intercambio, qué hacer si el valor viene vacío—. Ese documento de una página es, en la práctica, el pliego técnico de la integración.

Vías de intercambio: API, webhooks y volcado por fichero

Técnicamente hay varias maneras de conectar los sistemas. La elección no depende de la moda, sino de con cuánta rapidez se necesitan los datos y de qué posibilidades ofrece tu CRM.

• Intercambio por API. Los sistemas se llaman directamente entre sí. Es la opción más flexible: se transfiere cualquier conjunto de campos y la lógica queda bajo control total. A cambio exige configuración y tener claro qué llamada se dispara en cada evento.
• Webhooks. El CRM avisa por su cuenta de que el trato pasó a la etapa indicada, y el sistema de entregas avisa de cada cambio de estado. Los datos se actualizan casi al instante y sin consultas repetidas, pero hay que prever de antemano los reintentos: si el receptor no estaba disponible, el evento no puede desaparecer sin dejar rastro.
• Volcado por fichero. Los pedidos salen por lotes según un horario, por ejemplo desde una hoja de cálculo. Es el arranque más rápido: no requiere desarrollo y encaja cuando los pedidos se cierran por la mañana y a lo largo del día cambian poco.
• Conector intermedio. Un servicio puente aparte concilia formatos y guarda correspondencias y reglas. Tiene sentido cuando la fuente no es una sola: parte de los pedidos llega del CRM, parte del sistema contable y parte del formulario de la web.

No hay una respuesta universal, pero sí una referencia sencilla. Si el cliente espera el estado el mismo día y el comercial atiende llamadas de «dónde está mi pedido», hace falta un intercambio por eventos. Si el flujo se prepara la víspera y es estable, basta con el volcado por fichero, y solo merece la pena complicarlo cuando aparezca un caso concreto que ya no resuelva.

itlogist admite integraciones con AmoCRM, Bitrix24, 1C y Excel: los pedidos entran en operación desde la fuente de siempre, sin volver a teclearlos. Qué pasa después con cada pedido —el reparto entre técnicos, las rutas sobre el mapa en tiempo real, la aplicación móvil del técnico con informes fotográficos y listas de comprobación, el portal del cliente con los estados— está recogido en la página Funcionalidades de itlogist.

Fuente de verdad, clave de correspondencia y gestión de errores

La mayoría de los problemas de una integración no son técnicos, sino de acuerdo previo. Van cuatro preguntas cuyas respuestas determinan si el intercambio funcionará sin vigilancia diaria.

• Clave de correspondencia. Por qué campo se empareja el pedido de la operación con el trato del CRM: número de trato, identificador interno, número de pedido. La clave debe ser única, inmutable y viajar en ambos sentidos. Emparejar por teléfono o por dirección se desmorona en cuanto el mismo cliente repite pedido.
• Fuente de verdad de cada campo. Quién manda sobre la dirección, quién sobre la hora de entrega, quién sobre el importe. Si el comercial cambió la franja en el CRM y el coordinador la cambió en el sistema de entregas, no debe ganar quien pulsó más tarde, sino quien establezca la regla.
• Un único modelo de estados. Las etapas del embudo del CRM y los estados de ejecución son cosas distintas. Hace falta una tabla explícita de correspondencia: qué estado operativo mueve el trato a qué etapa y qué transiciones están prohibidas. De lo contrario, el trato empezará a retroceder con cada reintento de entrega.
• Comportamiento ante el error. Qué ocurre si la dirección viene vacía, no se encuentra al cliente o el receptor no responde. El escenario que funciona: el pedido no se pierde en silencio, sino que pasa a una cola de reintento o a una lista de revisión manual, y alguien responde de esa lista.

Hay dos cosas más de las que uno se acuerda tarde. La primera: reenviar no debe generar un duplicado; si el evento llega dos veces, el segundo intento tiene que actualizar el pedido existente, no crear otro. La segunda: los permisos. La cuenta de integración ve y modifica solo lo necesario para el intercambio, y su acceso no está atado a un empleado concreto que un día se irá con su contraseña.

Orden de implantación: de un escenario al flujo completo

No conviene arrancar la integración a lo ancho desde el primer día. La secuencia que funciona es esta y suele caber en unas pocas iteraciones cortas.

• Describe un escenario de principio a fin. Coge el tipo de pedido más frecuente y recórrelo desde la etapa del CRM hasta la marca de ejecución. Los casos atípicos —devoluciones, rechazos parciales, segundas visitas— se añaden en un segundo paso.
• Acuerda el mapa de campos. Esa misma tabla de cuatro columnas. Mientras no la firmen las dos partes, es pronto para empezar a configurar.
• Pon orden en los datos. Direcciones normalizadas, teléfonos al día, indicaciones de acceso. La integración también acelera el traslado de la basura: una dirección mala simplemente llega antes al técnico.
• Prueba con un flujo de test. Una decena de pedidos en ambos sentidos, incluidos los erróneos a propósito: sin dirección, duplicados, cancelados después de la asignación.
• Retira el traspaso manual. En cuanto el intercambio funcione, hay que cancelar la vía antigua. Dos esquemas en paralelo siempre acaban en datos divergentes y en discutir cuál de los dos es el bueno.
• Pacta el soporte. Quién mira la cola de errores, con qué rapidez reacciona y qué hace si uno de los sistemas deja de estar disponible.

Para comprobar el resultado ayudan unos pocos indicadores sencillos medidos antes y después: cuánto tiempo pasa desde que el trato llega a la etapa hasta que el pedido aparece ante el coordinador, cuántos pedidos se dan de alta a mano y con qué frecuencia los comerciales llaman a coordinación para preguntar por un estado. Este último suele moverse el primero: es la señal de que la información empezó a circular por el sistema y no por las personas.

La barrera de entrada aquí es más baja de lo que se suele creer: la puesta en marcha lleva 7 días, sin contratos de permanencia, y la plataforma está pensada para equipos de 5 a 100 técnicos. Es decir, la conexión con el CRM puede probarse con el flujo real de pedidos y compararse con la base de partida al cabo de un mes.