Respuesta breve
El formulario se envió y el visitante vio la pantalla de agradecimiento: ahí termina la garantía. Tres destinos, uno a uno: el CRM, la pasarela de pago y la analítica. Qué necesita cada uno de usted, cómo se rompe y qué comprobaciones lo detectan a tiempo.
La respuesta corta: el formulario es solo el primer eslabón: Una integración es una cadena de entregas: la…
Una integración es una cadena de entregas. El navegador envía los datos al servidor, el servidor los guarda y solo entonces los pasa a un CRM, a una pasarela de pago o a un sistema de analítica. Cada eslabón de esa cadena falla por su cuenta y por motivos distintos.
El mensaje que dice «gracias, hemos recibido su consulta» describe el primer eslabón y nada más. Significa que la petición llegó al servidor y que el servidor respondió con un código de éxito. Lo que ocurrió después no forma parte de la promesa que el visitante acaba de leer.
En ese hueco vive la situación que da título al artículo. El formulario funciona, el visitante está convencido de que le ha escrito y, mientras tanto, el CRM está vacío, el aviso duerme en la carpeta de correo no deseado y el informe de canales no registra esa consulta en ninguna fila.
El resto del texto va destino por destino: qué necesita de usted cada integración antes de que alguien escriba una línea de código, cómo se rompe y qué comprobaciones de aceptación detectan un fallo silencioso antes de que lo detecte por usted un cliente perdido.
Qué demuestra de verdad un envío correcto
Una respuesta de éxito demuestra tres cosas: que la dirección existe, que los campos enviados pasaron la validación y que se escribió un registro en su propio lado. Es menos de lo que suele leerse en ella y, aun así, hace falta: sin ese eslabón no hay nada que reenviar a ninguna parte.
No demuestra que se haya entregado un correo, que haya aparecido una ficha en el CRM, que un pago esté confirmado ni que un evento haya llegado a analítica. Todo eso sucede después de enviar la respuesta y ocurre fuera de la vista del visitante.
Un desarrollador puede enseñar la respuesta correcta y cerrar la tarea de buena fe. Por eso la aceptación no debe probar el envío, sino cada destino con nombre propio: abrir el CRM y ver la ficha, abrir el correo y ver el aviso, abrir el panel y ver el evento registrado.
La solución técnica es una separación. La confirmación que ve el visitante se gana con la escritura en su lado, y la entrega a cada destino pasa a ser una segunda operación, con su registro, sus reintentos y su aviso a una persona concreta cuando no sale adelante.
Tres destinos y para qué sirve cada uno
El CRM es el dueño de la consulta. Guarda el contacto, el historial y la etapa del acuerdo, asigna a alguien que responda y permite preguntar seis semanas después qué fue de un aviso concreto. Un buzón compartido no hace eso: el hilo se hunde en la lista hasta que nadie lo recuerda.
La pasarela de pago se ocupa del dinero y de la parte legal: la tarjeta, la divisa, el justificante, la devolución. Un desajuste entre cobrado y registrado lo ven el comprador y su banco, y por eso este destino se comprueba con una transacción real y no con una captura del entorno de pruebas.
La analítica se ocupa de la atribución: de dónde llegó la persona, qué páginas leyó y en qué paso se marchó. Sin ella, el presupuesto de publicidad se decide por impresiones de despacho en lugar de por lo que su propio sitio puede contar sobre el camino que lleva hasta una consulta.
Tres sistemas, tres funciones, tres maneras de romperse. Por eso una línea de presupuesto que dice «configurar integraciones» no informa de nada útil sobre el trabajo. Cada una necesita su acceso, su correspondencia de campos y su comprobación propia en el momento de la entrega.
Qué necesita de usted una integración con el CRM
Una cuenta y los permisos para usarla. Un plan de CRM que permita crear registros a través de su API y una clave o conexión emitida a nombre de la empresa, no desde el perfil personal de un empleado que puede presentar su renuncia en marzo.
Un mapa de campos. La lista de campos del formulario y el campo del CRM en el que aterriza cada uno: nombre, teléfono, correo, mensaje, origen, campaña. Sin esa lista el desarrollador adivina, y el desajuste aparece con consultas reales de personas reales en lugar de durante las pruebas.
Las reglas del embudo. En qué etapa entra un registro nuevo, quién queda como responsable y qué debe ocurrir cuando la misma persona escribe dos veces: una ficha nueva, o una nota añadida a la ficha que ya existe bajo su número de teléfono.
Una respuesta a la pregunta de quién lo abre. La integración lleva la consulta hasta el sistema; el resto del camino lo recorre una persona con un aviso y un tiempo de respuesta acordado. Sin esa persona, un CRM ordenado se limita a acumular filas sin leer.
Dónde se rompen las integraciones con el CRM
Campos obligatorios. El CRM rechaza un registro que deja vacío un campo que su administrador marcó como obligatorio. El formulario de la web no conoce esa regla, así que el rechazo llega cuando el visitante ya ha visto la pantalla de agradecimiento y ha cerrado la pestaña.
Tipos y formatos. Un teléfono enviado como texto libre, un número con espacios y paréntesis, una fecha escrita en el otro orden: el sistema receptor rechaza el valor sin más o lo archiva en silencio en un sitio donde usted no lo va a buscar nunca.
Accesos caducados. Los tokens y las conexiones tienen una vida útil, y un cambio de contraseña o un permiso retirado por el administrador los cortan de inmediato. Una integración que llevaba seis meses funcionando deja de hacerlo un día en el que nadie tocó el código.
Deduplicación. Una regla de fusión por teléfono o correo puede pegar la consulta nueva a una ficha antigua y dejarla fuera de la lista de novedades. El registro existe formalmente; lo que no existe es alguien mirando el lugar donde ha caído.
Qué necesita de usted una integración de pagos
Su propia cuenta de comercio. El contrato con la pasarela lo firma su sociedad, que también pasa la verificación y designa la cuenta que recibe las liquidaciones. Un proveedor técnico conecta una cuenta que ya existe; abrirla en su nombre no es algo que un proveedor pueda hacer.
La capa legal. Condiciones de venta, política de devoluciones, datos de la empresa, el tratamiento fiscal del justificante y lo que su pasarela exija en la descripción del producto. Ese material lo aporta usted, y el paquete «Desarrollo de producto» dice con claridad que las licencias de pago no están incluidas.
Divisas e importes. En qué divisa está el precio, cómo funciona el redondeo y si el impuesto se muestra aparte. Las pasarelas reciben importes en la unidad más pequeña, céntimos en lugar de unidades, y confundir una con otra produce una cifra que se desvía en un factor de cien.
Una dirección para las notificaciones. La pasarela necesita un punto accesible desde fuera en su sitio para anunciar un pago completado, y una firma verificada en ese mensaje, de modo que una petición llegada desde otro lugar no pueda marcar como pagado uno de sus pedidos.
Dónde se rompen los pagos
El webhook sin confirmar. El comprador pagó, el banco cargó la tarjeta, la pasarela envió su notificación y la dirección respondió con un error. El dinero se movió, el pedido figura como impagado en su sistema y usted se entera por el correo del comprador dos días después.
Claves de prueba en un sitio en producción. Los pagos pasan por el entorno de pruebas de la pasarela y se ven correctos en pantalla mientras no se mueve un solo céntimo. Aquí hay una comprobación que merece confianza: hacer un pago real pequeño y encontrarlo en el panel de la pasarela.
El regreso al sitio. Después de pagar, la pasarela devuelve al comprador a una dirección configurada de antemano. Apúntela a una página que no existe, o a una que falla sin los parámetros del pago, y la persona se queda sin saber qué ha ocurrido y puede pagar por segunda vez.
Reintentos e idempotencia. Las pasarelas repiten una notificación hasta recibir una confirmación. Sin una clave de idempotencia, esa repetición crea un segundo pedido o un segundo apunte en su contabilidad, y la conciliación de fin de mes deja de cuadrar.
Qué necesita de usted una integración de analítica
Una lista de preguntas. No «instale un contador», sino una lista de decisiones: qué canal se paga solo, en qué punto el formulario pierde gente, qué páginas se leen antes de que alguien escriba. Los eventos se deducen de las preguntas, y hacerlo al revés produce números que nadie usa.
Las reglas de consentimiento. Qué scripts puede ejecutar antes de que el visitante acepte, cuáles solo después y qué ofrece el banner. Esto decide tanto la posición legal como qué parte de su tráfico llegará siquiera a aparecer en el informe, lo que cambia cómo hay que leerlo.
Un esquema de nombres de eventos. Un nombre por acción, escrito en algún sitio: formulario enviado, pago iniciado, pago confirmado. Los nombres improvisados según van saliendo las funciones convierten el panel en una columna de filas casi idénticas entre las que nadie sabrá elegir medio año después.
Un lector. Quién abre el panel, con qué frecuencia y qué hace con el número una vez lo tiene. La analítica sin lector es un montón de datos recogidos durante años que no cambia ni una sola decisión sobre dónde va el dinero.
Dónde se rompe la analítica
Consentimiento y bloqueo. Una parte de los visitantes no acepta, otra usa extensiones y algunos navegadores restringen por su cuenta los scripts de terceros. La cifra del panel queda por debajo del número real de visitas, y por eso se compara consigo misma en el tiempo y no con su extracto bancario.
Navegación sin recarga. En un sitio moderno el cambio de página ocurre a menudo sin una petición de documento nueva. Un contador escrito para la carga del documento ve la entrada y concluye que el visitante no fue a ninguna otra parte, así que los pasos internos desaparecen del embudo.
Duplicados. Dos copias de la misma etiqueta, una pegada en la plantilla y otra añadida después desde un gestor de etiquetas, duplican las páginas vistas y aplanan el porcentaje de rebote. El informe parece más sano de lo que está el sitio que hay detrás.
Contar el clic en lugar del resultado. Un evento de formulario enviado que se dispara con el botón cuenta también los intentos que nunca llegaron al servidor. Dispárelo con la respuesta confirmada, o la conversión que se enseña a sí mismo será mayor que la que realmente tiene.
El fallo silencioso y cómo se arregla
Un fallo silencioso es el estado en el que el visitante ve una confirmación, el destino no recibió nada y nadie se entera, porque el error ocurrió en segundo plano y no iba dirigido a ninguna persona. Nada en la interfaz está mal; sencillamente el resultado no llegó a producirse.
El primer remedio es un registro. Cada intento de entrega se anota: destino, hora, resultado y qué respondió el sistema receptor. La pregunta de si hubo alguna consulta el martes se resuelve entonces en un minuto, en vez de convertirse en una discusión entre dos partes.
El segundo es el reintento. Un fallo de red o una caída corta del CRM se resuelve con unas cuantas repeticiones separadas por una pausa creciente, de modo que una entrega que falló a las nueve sale adelante a las nueve y cinco sin que nadie abra el portátil.
El tercero es un aviso a una persona. Cuando los reintentos se agotan, alguien tiene que recibir un mensaje que lo diga. El silencio no funciona como sistema de vigilancia: se parece exactamente a una semana tranquila en la que no ha entrado ninguna consulta.
Lo que las integraciones cuestan a la página: velocidad y acceso
Cada script de terceros son bytes adicionales, conexiones adicionales y trabajo adicional en el hilo principal del navegador. La documentación de rendimiento de MDN explica cómo medir esa aportación y por qué el código que usted no controla va detrás del contenido por el que ha venido el visitante.
La consecuencia práctica es una regla de orden. Un widget de chat, un píxel publicitario y un gestor de etiquetas no deberían interponerse entre el visitante y un formulario utilizable. El formulario es el motivo de la visita; los scripts que lo observan pueden esperar su turno detrás de él.
La accesibilidad del formulario está recogida en la referencia rápida del W3C para WCAG 2.2. Un error debe identificarse con texto y no solo con color, y los mensajes de estado deben llegar al lector de pantalla sin robar el foco del campo en el que la persona estaba escribiendo.
WCAG 2.2 añade además un criterio sobre la entrada redundante: no obligue a nadie a escribir dos veces el mismo dato dentro de un mismo proceso. En una compra eso es justamente el paso de confirmación, donde la dirección introducida en la pantalla anterior ya debería estar puesta.
Cómo encargar el trabajo y qué queda fuera de cada paquete
Site Fix Pack cuesta $70 y ocupa 1-2 días laborables: hasta cinco correcciones acordadas, una revisión en móvil y escritorio, una lista de antes y después en la entrega y una ronda de revisiones. Las páginas nuevas, el rediseño y las migraciones quedan fuera, así que conectar una pasarela por primera vez no es trabajo de este paquete.
«Sitio para lanzamiento» cuesta $380 y ocupa 3-5 días laborables: maquetación adaptable, conexión del CMS o de los datos, configuración del despliegue y dos rondas de revisiones antes del lanzamiento, con el contenido y las traducciones aportados por el cliente. La versión Express cuesta $520 y ocupa 2 días laborables: el mismo alcance en cola prioritaria, con compilaciones diarias, una lista de comprobación de lanzamiento, una llamada de entrega y una ronda de revisiones después de la primera compilación completa.
«Desarrollo de producto» cuesta $880 y ocupa 2-3 semanas: entrega de funcionalidades, lógica de estado y de rutas, pruebas y endurecimiento, y dos rondas de revisiones por cada funcionalidad entregada. Las aplicaciones móviles nativas y las licencias de pago no están incluidas, y esa es la línea que conviene leer antes de dar por hecho que un proveedor tramitará su alta como comercio.
«Soporte técnico continuo» cuesta $290 al mes: actualizaciones prioritarias, un ritmo semanal de publicaciones y mantenimiento técnico, facturado en ciclo mensual y con 30 días de preaviso para terminar, y con el volumen de cada ciclo acordado al principio del ciclo. Una construcción nueva o un rediseño se presupuestan aparte en lugar de absorberse en la cuota mensual.
Lista práctica
- Enumere todos los destinos que debe alcanzar un envío: su propio registro, correo, CRM, pasarela y analítica.
- Escriba el mapa de campos del formulario al CRM antes de que empiece el desarrollo.
- Emita los accesos a nombre de la empresa y no desde el perfil personal de un empleado.
- Haga un pago real pequeño y localícelo en el panel de la pasarela.
- Dispare el evento de formulario enviado con la respuesta confirmada del servidor, no con el clic.
- Designe a la persona que recibe el aviso cuando la entrega falla y acuerde un tiempo de respuesta.
Preguntas frecuentes
El formulario se envía, pero no llegan consultas. ¿Dónde hay que mirar?
Recorra los destinos en orden. Si existe un registro en su propio lado; qué dice el registro de entregas sobre el último intento; si el aviso está en la carpeta de correo no deseado; qué respondió el CRM a la última petición; si la clave de acceso ha caducado. Mientras no haya un registro de intentos, cada una de esas respuestas hay que sacarla a mano.
¿Cuánto cuesta reparar una integración que ha dejado de funcionar?
Para averías acotadas está Site Fix Pack por $70 y 1-2 días laborables: hasta cinco correcciones acordadas, una revisión en móvil y escritorio, una lista de antes y después en la entrega y una ronda de revisiones. Las páginas nuevas, el rediseño y las migraciones no están incluidas, así que conectar una pasarela por primera vez no cabe en ese paquete.
¿Pueden abrir ustedes nuestra cuenta de comercio en la pasarela de pago?
No. El contrato lo firma su sociedad, que además pasa la verificación de la pasarela y designa la cuenta que recibe las liquidaciones. «Desarrollo de producto» incluye las licencias de pago entre lo que no cubre. Un proveedor conecta una cuenta que ya existe, prepara el punto de notificaciones y verifica la firma de los mensajes entrantes.
¿Qué conviene preparar antes de empezar con las integraciones?
Acceso al CRM emitido a nombre de la empresa, un mapa de campos del formulario al CRM, las reglas del embudo y un responsable con nombre, los datos de la empresa y la política de devoluciones para los pagos, y la lista de preguntas que debe responder la analítica. El contenido y las traducciones los aporta usted: redactarlos no forma parte de los paquetes de desarrollo.
¿Por qué los números de analítica no coinciden con las consultas recibidas?
Una parte de los visitantes no acepta el consentimiento, otra usa bloqueadores y algunos navegadores restringen los scripts de terceros. A eso se suman la navegación sin recarga, que un contador de carga no llega a ver, y las etiquetas duplicadas, que duplican las páginas vistas. Concilie las conversiones con la respuesta confirmada del servidor y compare el panel consigo mismo en el tiempo.