Un formulario de contacto útil recoge lo necesario para que alguien pueda dar el siguiente paso. Antes de añadir un campo obligatorio, pregunta quién usará la respuesta y para qué. Si la explicación es «quizá nos sirva más adelante», plantéate pedirla después.
Esta guía está pensada para una empresa que revisa un formulario de consultas, no un proceso de pago, una solicitud regulada ni una licitación detallada. No existe un número de campos ideal para todos. Una reparación y una cotización mayorista necesitan datos distintos. El objetivo es iniciar una conversación útil, con un recorrido claro desde el envío hasta la respuesta.
1. Empieza por la siguiente acción
Define qué ocurrirá cuando el comprador pulse Enviar. ¿Alguien concertará una llamada, comprobará la disponibilidad del servicio o preparará una cotización? Haz una lista de los datos necesarios para esa acción. Separa lo imprescindible para calcular un precio final de lo necesario para empezar a ayudar.
Por ejemplo, una empresa de servicios puede necesitar un medio de respuesta, una descripción del trabajo y la zona. Un mayorista puede necesitar una referencia, cantidad y destino para evaluar la consulta. Son ejemplos orientativos, no plantillas obligatorias. Si el comprador todavía no conoce el código del producto, permite describir lo que busca en lugar de obligarlo a inventar uno.
El manual de servicios de GOV.UK recomienda documentar por qué hace falta cada pregunta y cómo se utilizará su respuesta. Aplica ese razonamiento a tu formulario: asigna una finalidad y una persona que use cada dato. Su contexto de servicios públicos no convierte todos los diseños de GOV.UK en requisitos para una web comercial.
2. Elige los campos de la primera consulta
Esta tabla es una propuesta para revisar el formulario con tu diseñador. Un campo obligatorio debería significar que el equipo no puede dar el siguiente paso acordado sin esa respuesta, no que le gustaría conocerla.
| Información | Cuándo ayuda a la primera respuesta | Cuándo dejarla opcional o pedirla después |
|---|---|---|
| Nombre o empresa | Permite dirigirse a la persona o identificar la consulta | Separar razón social y nombre comercial rara vez debe bloquear el primer contacto |
| Correo o teléfono | Proporciona un medio de respuesta utilizable | Exigir ambos necesita un motivo; acuerda cómo se tratará el canal preferido |
| Servicio o producto | Dirige la solicitud a quien puede ayudar | Incluye una opción general si la lista cerrada no cubre todos los casos |
| Zona o destino | Permite comprobar cobertura o viabilidad del envío | Quizá no haga falta la dirección completa antes de confirmar la cobertura |
| Cantidad, medidas o referencia | Ayuda a evaluar una consulta técnica o comercial | Permite una explicación si el comprador no conoce la especificación exacta |
| Presupuesto o plazo | Ayuda a valorar si la solicitud es viable | No obligues a inventar una respuesta cuando primero se necesita asesoramiento |
| Archivo adjunto | Una foto o lista puede aclarar una solicitud compleja | Ofrece otra vía e indica formatos y tamaño máximo si permites archivos |
Contrasta cada campo obligatorio con una tarea real del equipo. Eliminar un campo no siempre mejora el proceso: perder el destino de una consulta de envío puede generar preguntas adicionales evitables. En cambio, copiar un formulario completo de alta de cliente en la página de contacto puede exigir datos que todavía nadie necesita.
No pidas documentos sensibles ni datos de pago en un campo de consulta general. Si una etapa posterior necesita más información, utiliza un proceso adecuado para esa etapa.
3. Facilita las respuestas
El tutorial de formularios del W3C recomienda formularios sencillos y breves que pidan información necesaria para el proceso. También explica la función de las etiquetas y las instrucciones. Esto respalda revisar preguntas innecesarias; no demuestra que eliminar una cantidad concreta de campos produzca un aumento concreto de ventas.
Usa etiquetas visibles que sigan siendo comprensibles al escribir. Distingue los datos obligatorios de los opcionales. Explica los términos poco conocidos junto al campo y ofrece un ejemplo cuando el formato importe. Si esos datos ayudan al equipo, una indicación como «Cuéntanos qué necesitas, la cantidad si la sabes y dónde se utilizará» orienta mejor que un cuadro vacío titulado «Detalles».
Pide al diseñador que muestre los estados de respuesta ausente o incorrecta. El comprador debe poder localizar el problema, corregirlo y conservar el resto del mensaje. Consulta las instrucciones para formularios del W3C sobre cómo presentar requisitos y ayuda. Un texto que desaparece al escribir no debería contener la única explicación.
Comprueba la experiencia real en el teléfono. ¿Se leen las etiquetas, se eligen opciones y se llega a Enviar sin desplazamientos incómodos dentro de un control? ¿Una persona que utiliza el teclado puede recorrerlo en un orden lógico? Para una revisión más amplia, consulta la guía de accesibilidad para pequeñas empresas.
4. Acuerda qué significa Enviar
La confirmación visible debe describir la etapa que ha alcanzado el sistema. Guardar una solicitud no equivale a que una persona la haya leído, aceptado una reserva o confirmado un precio. Pide al diseñador que explique qué ocurre si se guarda la consulta pero falla el correo de aviso.
Indica un siguiente paso realista: qué equipo atenderá la consulta, cómo hacer seguimiento y cualquier plazo de respuesta que la empresa pueda cumplir. No copies una promesa de «respuesta en una hora» de una plantilla si tu operación no puede sostenerla. Ofrece una alternativa de contacto que el equipo mantenga.
Asigna una persona responsable de revisar solicitudes nuevas, incluido el correo no deseado y los fallos de notificación. Si el formulario parece funcionar pero los mensajes no llegan, sigue la guía para diagnosticar problemas de entrega. Esa guía sigue el mensaje perdido; esta ayuda a decidir qué preguntar antes del envío.
5. Acepta el formulario con una consulta de prueba completa
Antes de aprobar el trabajo, prueba una consulta normal y los fallos relevantes en ordenador y móvil. Utiliza un destino de pruebas controlado o coordina la prueba con el equipo receptor. Anota página, dispositivo, referencia de prueba, resultado y quién confirmó la recepción.
- Envía una solicitud realista y confirma que todas las respuestas previstas llegan al registro receptor. Prueba nombres con tildes y descripciones largas cuando corresponda.
- Deja una respuesta obligatoria vacía e introduce después un correo no válido. Comprueba que se explica el problema y se conservan los demás datos.
- Si hay archivos adjuntos, prueba uno permitido y un formato rechazado o un archivo demasiado grande según los límites indicados.
- Comprueba que se puede dejar vacío un campo opcional y que el equipo ve el medio de respuesta preferido.
- Abre la consulta como persona receptora y verifica que Responder llega al contacto de prueba previsto, no a una dirección que no admite respuestas.
Después del lanzamiento, distingue la actividad del formulario de los resultados comerciales útiles. Un clic es un intento de acción; una solicitud guardada todavía necesita revisión. Registra las consultas reales, si el equipo pudo responder y qué información faltaba. Usa esas observaciones para ajustar el formulario. El spam, las pruebas duplicadas o una pantalla de confirmación no demuestran que exista un cliente nuevo.
Para revisar el recorrido que lleva a la página de contacto, utiliza la lista de revisión de la web. Empieza por una decisión concreta: identifica el campo que tu equipo no sabe justificar y acuerda si pertenece a la primera conversación.
