Integración web con CRM: comprueba que llegan las consultas
Neaptide · 7 de septiembre de 2026 · 6 min de lectura
Conecta los formularios al CRM, conserva el origen y evita duplicados al reintentar. Incluye un caso de fallo y una lista de pruebas de aceptación.
En este artículo
Un mensaje de agradecimiento no demuestra que la consulta haya llegado al CRM. Antes de dar la web por terminada, pide ver el envío guardado, su registro en el CRM y la persona responsable. Si el proceso se detiene, debe quedar claro en qué punto.
La integración transmite los datos del formulario al sistema comercial y aplica las reglas acordadas para crear consultas, asociar contactos y asignar responsables. Puede utilizar un formulario nativo, un conector o código propio.
Define cuándo se considera recibida una consulta
Distingue entre guardar el envío en la web, confirmar el registro en el CRM y asignar una tarea comercial. Un aviso por correo o Telegram no acredita por sí solo las tres etapas.
Si el CRM no está disponible, la web puede guardar la consulta de forma fiable para enviarla después y confirmar que la ha recibido. Si tampoco puede guardarla, debe mostrar el error y permitir reintentar o contactar por otra vía. Los plazos de respuesta deben acordarse con el equipo comercial.
Elige una conexión que puedas mantener
Revisa primero los formularios y conectores existentes: campos, asignación y recuperación de errores. Pide una demostración. El código a medida no es más fiable por definición.
Una cola separa la recepción del procesamiento, pero exige vigilar los mensajes pendientes y fallidos. Para un volumen pequeño y estable, un servicio de colas independiente puede añadir complejidad innecesaria. Incluye el mantenimiento en la decisión.
Conserva el contexto de la consulta
Documenta el origen y destino de cada campo: mensaje, servicio, página, formulario, hora de recepción y fuente disponible. Comprueba los campos obligatorios y sus valores permitidos en el CRM.
Acuerda si guardarás la primera fuente conocida, la de la consulta actual o ambas. La ausencia de UTM no demuestra una visita directa; el origen puede ser desconocido.
Mantén las credenciales del CRM en el servidor. Limita el acceso a los registros de errores y evita copiar mensajes completos de clientes sin necesidad.
Un reintento no es una nueva consulta
Ejemplo ficticio: la web guarda S-104, el CRM crea C-208 y se pierde la confirmación. La web detecta que se ha agotado el tiempo de espera. Volver a crear el registro sin comprobar el resultado puede duplicarlo.
Mantén el mismo identificador al reenviar la consulta. Si la API admite idempotencia, puede tratar los reintentos como una sola operación. Si no, habrá que diseñar una forma de relacionar y comprobar los registros. Buscar antes de crear no evita por sí solo los duplicados cuando llegan dos solicitudes a la vez. Que se agote el tiempo de espera no demuestra que el CRM no haya guardado los datos.
Si el mismo cliente pide otro servicio mañana, se trata de una nueva consulta S-105. Puedes asociarla al contacto existente y conservar la petición. Eliminar todo lo que tenga el mismo teléfono ocultaría consultas legítimas.
Prueba qué ocurre cuando falla la conexión
Estos casos definen resultados esperados en pruebas; no son resultados medidos de un CRM. Aplícalos a todos los formularios y versiones de idioma. Guarda el identificador de cada envío para comparar la misma consulta entre sistemas.
| Caso | Qué comprobar |
|---|---|
| Consulta normal | Campos, origen, registro y responsable correctos. |
| CRM no disponible | Envío guardado, espera visible y entrega posterior. |
| Se agota la espera tras crear el registro | El reintento no crea otra consulta; se comprueba mediante el identificador. |
| Campo obligatorio inválido | Error visible, sin reintentos interminables. |
| Nueva petición, mismo teléfono | Petición conservada según las reglas acordadas. |
| Sin UTM | La fuente desconocida no se sustituye por una campaña inventada. |
Acuerda quién se ocupa después
Pide la tabla de correspondencias de campos, las reglas para nuevas consultas de un contacto existente y las instrucciones para revisar errores. Asigna un responsable y acuerda el tiempo máximo de entrega. Comprueba también cómo se reanuda el proceso tras una reparación sin duplicar registros.
El número de oportunidades nuevas no basta para comprobar la recepción: algunas consultas se añaden a contactos u oportunidades existentes. Revisa los identificadores de los envíos y sus estados, teniendo en cuenta pruebas, spam y solicitudes pendientes.
Para un proyecto web con Neaptide, envía la dirección del sitio, el CRM, la lista de formularios y un ejemplo del registro deseado sin datos personales. Explica cómo tratar a los clientes que vuelven y quién aprobará el resultado desde ventas.