Integración web con CRM: comprueba que llegan las consultas
Neaptide · 7 de septiembre de 2026 · 6 min de lectura · Actualizado: 3 de octubre de 2026
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 que te enseñen el envío guardado, su registro en el CRM y la persona responsable. Y si el proceso se detiene por el camino, tiene que 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. Según cómo deban tratarse tus consultas, bastará un formulario nativo del CRM o un conector ya hecho, o hará falta código propio contra la API.
Define cuándo se considera recibida una consulta
Hay tres etapas distintas: la web guarda el envío, el CRM confirma el registro y alguien de ventas recibe una tarea. Un aviso por correo o Telegram no acredita por sí solo que se hayan cumplido las tres.
Cuando el CRM no está disponible, la web puede guardar la consulta de forma fiable para enviarla después, y entonces sí puede confirmar que la ha recibido. Si tampoco consigue guardarla, debe mostrar el error y permitir reintentar o contactar por otra vía. En cuanto a los plazos de respuesta, acuérdalos antes con el equipo comercial.
Elige una conexión que puedas mantener
Mira primero si un formulario nativo o un conector existente envía los campos que necesitas, asigna las consultas a quien corresponde y recupera el envío tras un error. Pide que te lo enseñen con consultas de prueba. El código a medida no es más fiable por el hecho de ser a medida.
Una cola separa la recepción del procesamiento, pero obliga a que alguien vigile los mensajes pendientes y fallidos. Con un volumen pequeño y estable, un servicio de colas independiente puede añadir una complejidad que no necesitas. Ten en cuenta el mantenimiento al decidir.
Conserva el contexto de la consulta
Documenta de dónde sale cada campo y adónde va en el CRM. Hablamos del mensaje, el servicio, la página, el formulario, la hora de recepción y la fuente disponible. Después comprueba qué campos son obligatorios en el CRM y qué valores admiten.
Acuerda si guardarás la primera fuente conocida, la de la consulta actual o ambas. Que falten los UTM no demuestra una visita directa. Puede que el origen, sencillamente, no se conozca.
Las credenciales del CRM se quedan en el servidor. Limita también el acceso a los registros de errores y no copies en ellos mensajes completos de clientes si no hace falta.
Un reintento no es una nueva consulta
Pongamos un ejemplo ficticio. La web guarda el envío S-104 y el CRM crea el registro C-208, pero la confirmación se pierde. Lo único que ve la web es que se ha agotado el tiempo de espera. Si vuelve 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, porque pueden llegar dos solicitudes a la vez. Y que se agote el tiempo de espera no demuestra que el CRM no haya guardado los datos.
Si el mismo cliente pide otro servicio al día siguiente, eso es una consulta nueva, S-105. Puedes asociarla al contacto existente y conservar la petición. Si eliminaras todo lo que tenga el mismo teléfono, ocultarías consultas legítimas.
Prueba qué ocurre cuando falla la conexión
Estos casos describen lo que debería ocurrir en un entorno de pruebas. No son mediciones hechas sobre un CRM concreto. Aplícalos a todos los formularios y versiones de idioma, y guarda el identificador de cada envío para poder 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
En la entrega, pide la tabla de correspondencias de campos, las reglas para nuevas consultas de un contacto existente y las instrucciones para revisar errores. Tiene que haber un responsable y un tiempo máximo de entrega acordado. Pide también que te enseñen 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, porque algunas consultas se añaden a contactos u oportunidades existentes. Lo que hay que revisar son 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.