Un formulario confirma el envío, pero el CRM tarda en responder. El visitante reintenta y el asesor recibe dos oportunidades. También puede ocurrir lo contrario: el CRM guardó la solicitud, la conexión se cortó y n8n la considera fallida. Repetir todo el flujo puede duplicar el efecto comercial.
El objetivo de esta arquitectura es conservar cada solicitud legítima y procesar una sola vez cada evento repetido. Se aplica a captación web, contactos por WhatsApp y solicitudes de cotización para empresas de Perú. No equivale a borrar cualquier registro que comparta teléfono.
Reconstruye primero la operación incompleta
Identifica qué se recibió, qué se guardó y qué falta: evento de entrada, contacto, oportunidad y tarea son registros diferentes. Un mismo comprador puede pedir dos servicios. Deduplicar únicamente por teléfono borraría una intención válida.
Propón un identificador del evento y una referencia de oportunidad. Conserva el origen y el estado de procesamiento. La siguiente tabla es un modelo de diseño, no campos obligatorios de una plataforma.
| Registro | Función |
|---|---|
| evento_id | Reconocer una entrega repetida |
| contacto_id | Vincular a la persona ya identificada |
| oportunidad_id | Separar necesidades comerciales |
| estado y ultimo_error | Saber qué puede recuperarse |
| referencia_destino | Comprobar lo que guardó el CRM |
Confirma recepción después de registrar el evento
El nodo Webhook de n8n permite recibir solicitudes y configurar la respuesta. Diseña la confirmación según lo que realmente se completó. «Recibimos tu solicitud» no significa «la oportunidad ya fue asignada».
Valida autenticidad, tamaño y campos antes de aceptar. Registra de forma duradera el evento antes de confirmar recepción si la arquitectura promete recuperarlo más tarde. Si el registro falla, una respuesta de éxito ocultaría la pérdida. Las URLs de prueba y producción cumplen funciones distintas; verifica cuál usa el formulario publicado.
Redis puede coordinar, pero no demuestra que la venta se guardó
Una reserva atómica con SET y NX permite que un único trabajador tome una clave; la expiración evita un bloqueo indefinido. Estas opciones están documentadas en Redis SET. Elige una clave ligada al evento, no un valor aleatorio nuevo en cada intento.
El bloqueo temporal no sustituye un historial persistente de resultados. Si vence mientras el primer trabajador sigue activo, otro podría escribir. Usa una restricción única en el registro de eventos y, cuando el CRM lo permita, una clave de idempotencia o referencia externa única en destino. Para liberar un bloqueo, comprueba que sigue perteneciendo al trabajador que lo adquirió.
Resuelve el fallo incierto antes de reintentar
Si el CRM devuelve un error de validación, corrige datos y envía el caso a revisión. Si rechaza por límite temporal, respeta sus instrucciones y aplica espera limitada. Si se corta la conexión después de escribir, consulta la referencia externa antes de crear otra oportunidad.
Ni un bloqueo ni un historial local garantizan por sí solos «exactamente una vez» entre sistemas. Cuando no puedas comprobar el destino, marca el caso como incierto y solicita conciliación. Ese estado es preferible a duplicar una propuesta que el asesor ya está trabajando.
Cierra el circuito con conciliación y alertas
Compara eventos aceptados con oportunidades confirmadas. Una ejecución de n8n terminada sin error puede haber procesado cero registros o dejado una asignación vacía. La alerta comercial debería indicar referencia, etapa y acción pendiente, sin copiar datos personales innecesarios.
La gestión de errores de n8n permite asociar un flujo de error. Complétalo con una revisión de pendientes persistentes para detectar también operaciones que no llegaron a disparar el flujo esperado.
Prueba con eventos que llegan dos veces y respuestas que no llegan
Envía el mismo evento simultáneamente; debe existir una sola oportunidad. Envía dos consultas legítimas del mismo contacto; deben conservarse ambas. Simula caída tras escribir en el CRM; la recuperación debe localizar el resultado. Reasigna una oportunidad durante el proceso; no sobrescribas al nuevo asesor con un dato antiguo.
Esta base sirve para cotizaciones con versiones y ventas por WhatsApp. Una integración de APIs debe entregar también el procedimiento de recuperación, no únicamente el camino que funciona en una demostración.
