Cómo comprobar dónde termina una consulta enviada desde tu web
El formulario muestra «Gracias». La persona que lo envía espera que alguien atienda su consulta. Entre ambos momentos puede ser necesario guardar, enrutar, asignar y revisar un registro. La prueba debe avanzar hasta identificar quién se responsabiliza de la siguiente acción.
Nuestra web guarda la consulta con un registro persistente de entrega. Su estado distingue trabajo en cola, fallo temporal y destino bloqueado. Las notificaciones al responsable tienen un resultado independiente. Son detalles de nuestra implementación revisados para este artículo; una consulta en cola no acredita conversación ni venta.
Define la promesa del mensaje
Anota qué promete la pantalla. «Hemos recibido tu consulta» y «Un asesor ha respondido» requieren pruebas distintas. El texto debe corresponder al paso que realmente se completó.
La especificación HTTP sobre 202 Accepted ilustra la diferencia: aceptar una solicitud para procesarla no significa haber terminado. Aunque la aplicación utilice otro código, necesita definir el significado comercial de su respuesta.
Utiliza una identidad trazable
Prepara una consulta sintética claramente marcada como prueba, sin datos de clientes. Registra referencia interna, hora, destino y responsable esperado. Cuando baste una referencia, evita copiar el contenido a los registros generales.
Sigue esa identidad por cuatro puntos: registro guardado, acuse del destino, tarea visible y siguiente acción asignada. Debe poder detectarse la ausencia de cualquiera. Que un proveedor acepte un correo de aviso demuestra esa aceptación, no su lectura ni la asignación de la consulta.
Si se crea un borrador de respuesta, revísalo en privado. Comprobar la entrada del formulario no requiere enviar un mensaje real a un cliente. La autorización para probar la recepción y la autorización para contactar son distintas.
Prueba un destino no disponible
Con los envíos externos desactivados, simula un destino que no acepta la consulta. El registro guardado debe seguir disponible. El operador necesita ver el fallo o bloqueo, su motivo y el siguiente paso definido.
Después, restablece el destino y recupera el mismo registro según la política acordada. Comprueba que se crea una sola tarea. La guía de recuperación de flujos explica cómo acotar los reintentos y tratar resultados externos inciertos.
Conserva un comprobante breve
Proponemos estos campos: referencia de prueba, hora de guardado, destino, resultado del enrutamiento, referencia de tarea, responsable, siguiente acción y limpieza. Registra aparte la aceptación del aviso. Una casilla genérica de «entregado» oculta qué se observó.
Pide al responsable del negocio que encuentre la consulta sin que el desarrollador le guíe. Si puede localizarla, entender su estado e identificar la siguiente acción, habrás comprobado un recorrido operativo útil. La prueba no mide conversión.
Trae el formulario actual y el equipo que debe recibir sus consultas. Describe la entrega que quieres verificar para acotar una prueba sobre los sistemas existentes.
Fuentes e implementación revisadas el 20 de septiembre de 2026. El ejercicio propuesto utiliza entradas sintéticas.