La consulta que nunca llegó: por qué un formulario de contacto puede fallar sin avisar

La mayoría de los formularios están construidos al revés: mandan un correo y no guardan nada. Si ese envío falla, el visitante ve el gracias de todos modos y la consulta desaparece sin dejar rastro. La regla que lo evita es una sola: guardar primero, enviar después.

Una persona entró a la web de un cliente, completó el formulario de contacto y apretó enviar. En vez de un gracias, le apareció en pantalla un mensaje de error del servidor.

Eso fue lo que nos avisó. Un visitante viendo un error.

Lo que estaba pasando abajo era peor que el mensaje feo: el formulario intentaba escribir un archivo contador antes de hacer nada más, no podía, y ahí se caía. La consulta no se guardaba en ningún lado. Y de paso, el error mostraba en pantalla la ruta interna del servidor.

El problema no era el error. Era no saber desde cuándo

Buscamos hacia atrás y no encontramos forma de saber cuánto tiempo llevaba así.

No hay registro de una consulta que no se guardó. Un error que se ve, avisa; una consulta que se perdió, no avisa nada. No aparece como error en ningún reporte, no aparece como cero, no aparece.

Si el aviso por correo también estaba fallando —y no teníamos manera de comprobarlo— hubo gente que escribió pidiendo un presupuesto y nadie se enteró nunca.

Ese cliente no tenía un problema de formulario. Tenía un problema de ventas que no sabía que existía.

Casi todos los formularios están construidos al revés

Este no es un caso raro. Es cómo funciona la mayoría de los formularios que nos encontramos.

El orden habitual es: alguien completa, el sitio arma un correo, lo manda, y listo. La consulta existe solamente como ese correo. Si el envío falla —porque la cuenta rebotó, porque el proveedor la clasificó como spam, porque una credencial venció— la consulta no queda en ninguna parte.

Es un único punto de falla, y encima silencioso. Nadie se entera de que dejaron de llegar consultas. Se entera cuando pasa un mes flojo y lo atribuye al mercado.

Guardar antes de enviar

La regla que aplicamos es de una sola línea, y cambia todo:

Primero se guarda la consulta. Después se intenta el correo.

Si el correo falla, la consulta ya está guardada y el fallo queda anotado para reintentar. Puedes perder el aviso; no puedes perder al cliente.

En el formulario que reconstruimos no dimos ese orden por sentado: lo medimos. Mandamos una consulta de prueba y comprobamos contra los registros que quedó guardada antes de que saliera el correo. Un orden que está escrito en el código pero que nadie verificó es una intención, no una garantía.

Cómo revisar el tuyo en cinco minutos

No hace falta que nos creas nada. Haz esto:

• Entra a tu propia web y completa el formulario como si fueras un cliente.
• Fíjate que llegue el correo. Si no llega, ya encontraste algo.
• Y ahora la pregunta que importa: ¿dónde quedó guardada esa consulta, además del correo?

Si la única respuesta es "en mi bandeja de entrada", tienes el mismo problema que tenía este cliente. Todavía no se manifestó, nada más.

Un cuarto punto, si quieres ir más a fondo: pídele a quien te hizo la web que te muestre las consultas de los últimos tres meses. No los correos: las consultas. Si no existe ese lugar, no existen.

Lo que aprendimos nosotros

Que un formulario que funciona y uno que falla se ven exactamente igual desde afuera. Los dos muestran el mismo botón.

Por eso desde entonces, en cada web que entregamos, probamos el formulario de punta a punta antes de dar nada por terminado: se completa como lo haría un visitante, se comprueba que la consulta quedó registrada, y solo después se mira si llegó el correo. En ese orden, que es el mismo en el que trabaja el sistema.

Mirar el código no alcanza. Hay que mandar la consulta y buscarla.

¿Quieres que revisemos el tuyo?

Si tienes dudas de si tu web está perdiendo consultas, lo miramos. Es una comprobación corta y te decimos qué encontramos, sin vueltas.

El diagnóstico es gratis. Te contactaremos pronto.