Completás el formulario, tocás «Enviar» y después no aparece ninguna consulta en tu correo. O el botón abre otra aplicación y no queda claro si el mensaje salió. Antes de pedir que rehagan toda la web, conviene ubicar qué parte del recorrido está fallando.
En un negocio de servicios, el contacto es una parte importante del sitio. La persona necesita explicar qué busca y vos necesitás recibir esa información para responder. Una página puede verse bien y aun así tener un problema en ese paso.
No hace falta conocer el código para describir el fallo. Sí ayuda distinguir lo que hizo la persona, lo que informó la web y lo que efectivamente llegó a destino.
Primero: ¿el botón envía o abre un correo?
Hay sitios en los que «Contactar» abre un borrador en el programa de correo del visitante. Eso suele hacerse con un enlace `mailto`. La persona todavía tiene que escribir o revisar el mensaje y enviarlo desde esa aplicación. MDN documenta ese comportamiento.
Puede servir como alternativa de contacto. Pero si la página lo presenta como un envío desde la web, hay una diferencia entre lo que promete y lo que hace. Que se abra un borrador no prueba que te hayan mandado un mensaje.
Un formulario con envío directo tiene otro recorrido: la persona completa los datos, la web los procesa y un sistema se ocupa de hacerlos llegar. Ese proceso también puede fallar. Por eso la confirmación debería describir lo que se comprobó.
Si no sabés qué tipo de contacto tenés, mirá qué ocurre al tocar el botón. ¿Seguís en la página? ¿Se abre tu aplicación de correo? ¿Aparece un error? Ese detalle ya sirve para empezar una revisión.
«Enviado» y «recibido» son comprobaciones distintas
Conviene separar estos pasos:
- La persona intentó enviar. Tocó el botón. Puede haber un campo inválido, un problema de conexión o un fallo de la página.
- El sistema aceptó el envío. Hay una respuesta del mecanismo encargado de procesarlo. Eso todavía no prueba que el correo esté en tu bandeja.
- El mensaje llegó al destino esperado. Lo encontraste en la casilla que usa el negocio, con la información necesaria para responder.
- La consulta tuvo valor comercial. Era una solicitud real, encajaba con tu servicio y pudiste avanzar. Eso requiere revisar la conversación; un formulario no puede demostrarlo por sí solo.
Esta separación evita dar por resuelto un problema porque apareció un mensaje verde. También evita llamar «cliente» a una consulta de prueba.
Cuando el formulario responde bien pero el correo no llega, el problema puede estar más adelante. La guía de Google para formularios y Gmail contempla mensajes enviados a spam o rechazados y la autenticación del sistema de correo. No todos los sitios necesitan la misma solución: primero hay que saber cómo envía el tuyo.
Qué podés revisar sin cambiar configuraciones
Si sos responsable del sitio, coordiná una prueba con quien recibe las consultas. Usá un mensaje claramente identificado como prueba y anotá la hora. Evitá poner datos de un cliente real.
Revisá la página desde un celular, además de la computadora. Prestá atención a estas preguntas:
- ¿Se entiende qué información pide cada campo?
- ¿Se distinguen los campos obligatorios de los opcionales?
- ¿Podés completar el recorrido sin que el teclado tape lo necesario?
- Si hay un error, ¿dice qué corregir?
- ¿La confirmación explica qué pasó y cuál es el próximo paso?
- ¿El mensaje aparece en la casilla acordada, incluyendo spam si corresponde?
No hace falta mandar varias veces el mismo formulario porque tarda. Un buen arreglo debe contemplar también qué pasa mientras se procesa el envío y cómo se comunica un error.
El tutorial de formularios de W3C recomienda instrucciones, controles identificados, validación y notificaciones de éxito o error. Son criterios útiles para revisar un contacto, no sólo detalles visuales.
Si te aparece una advertencia o un error técnico, guardá una captura. No cambies registros del dominio ni instales una herramienta al azar para probar suerte. Es mejor conservar el síntoma y revisar el sistema que ya usa la web.
El cambio en mi propio formulario
En mi sitio, el contacto pasó de abrir un correo con `mailto` a permitir el envío directo desde la web. La entrega se verificó con una consulta de prueba.
Ese caso me sirve para mostrar una diferencia concreta: antes había un paso adicional en otra aplicación; ahora la consulta puede procesarse desde la página. También sirve para poner un límite a lo que puedo afirmar. Verificar la entrega no demuestra que el cambio haya generado más consultas comerciales ni ventas.
Para saber eso necesito observar solicitudes reales y disponer de datos suficientes. Las pruebas muestran que el recorrido funciona bajo las condiciones revisadas. El resultado del negocio es otra pregunta.
Qué información mandar para pedir un arreglo
Un pedido como «el contacto no funciona» deja muchas posibilidades abiertas. Podés hacerlo más claro con esta ficha:
Página: [dirección exacta]
Qué debería pasar: [por ejemplo, enviar una consulta a la casilla del negocio]
Qué pasa ahora: [abre un correo / queda cargando / muestra un error / confirma pero no llega]
Dónde lo probé: [celular o computadora y navegador, si lo sabés]
Cuándo ocurrió: [día y hora aproximada]
Quién recibe las consultas: [rol o casilla de trabajo que se revisará en privado]
Si conocés la plataforma del sitio, agregala. Si no la conocés, la URL permite empezar a revisar. No compartas contraseñas ni accesos sensibles en ese primer mensaje.
Con esa información se puede evaluar si el problema está en el uso del formulario, el procesamiento o la entrega, y qué accesos hacen falta para trabajar.
Qué debería incluir el presupuesto del arreglo
Pedí que el alcance nombre el problema concreto, la página afectada y cómo se va a comprobar la solución. «Mejorar la web» es demasiado amplio si lo que necesitás es recibir consultas.
Una entrega clara puede incluir la corrección acordada, comprobaciones en celular y computadora, una prueba coordinada de recepción y una explicación de qué se cambió. Si hay un servicio externo o un costo recurrente, conviene conocerlo antes de empezar.
También hay que acordar los límites. Corregir el contacto no incluye automáticamente rediseñar el sitio, traer visitas o mantenerlo de manera continua. Podés consultar el alcance de mis arreglos web y formularios de contacto.
Cuándo dar el problema por resuelto
El cierre depende del fallo que se acordó corregir. Si el problema era que una solicitud no llegaba, no alcanza con comprobar que el botón cambió de texto: hay que revisar la recepción en el destino previsto. Si era una traba de uso en celular, hay que completar el recorrido en ese contexto.
Guardá una explicación breve de la prueba y del resultado. Si más adelante aparece otro error, vas a tener una referencia para comparar.
Después queda la parte comercial: qué consultas llegan, si corresponden al servicio y si podés responderlas. Una web que entrega los mensajes resuelve una condición necesaria del contacto. La cantidad y la calidad de las oportunidades se evalúan con evidencia propia.
¿Te pasa algo parecido? Mandame la página y contame qué ocurre. Con la URL, el síntoma y lo que esperás que pase puedo revisar si encaja como un arreglo puntual y qué necesitaríamos para definirlo.