Una persona envía el formulario de una web y ve «Gracias, te contactaremos». La empresa no recibe el aviso. Días después, el visitante llama y descubre que nadie conocía su consulta. El diseño del formulario funcionó; el recorrido de recepción falló.
Al conectar una web con correo, CRM y calendario, cada paso necesita una señal de que se ha completado. Este recorrido es un ejemplo ilustrativo de diseño para una empresa de servicios; no atribuye resultados a un cliente concreto.
Confirmar la recepción cuando existe una referencia
La web debe validar los campos y conservar una referencia de la solicitud. El mensaje que ve el visitante debe corresponder al estado real: una petición preparada en su navegador todavía no ha llegado a la empresa.
Si el proveedor de correo rechaza el envío, el sistema puede guardar la solicitud para recuperarla y ofrecer una vía alternativa. Lo que no debe hacer es mostrar éxito para ocultar el problema. La empresa necesita poder localizar la incidencia sin pedir al visitante que reconstruya todo.
Separar el aviso del seguimiento comercial
El correo avisa. El CRM permite asignar una persona responsable, registrar el servicio solicitado y decidir el siguiente paso. En una empresa pequeña puede haber una sola persona para ambas cosas; siguen siendo funciones distintas.
Si falla la conexión con el CRM, la consulta debe quedar marcada como pendiente de sincronizar. Al reintentar, la misma referencia debe actualizar el registro existente, sin crear oportunidades repetidas. También conviene reconocer cuándo un contacto vuelve a preguntar por otro proyecto: deduplicar a la persona no significa borrar una necesidad nueva.
Conectar las reservas a una disponibilidad común
Cuando una persona tiene dos webs, ambas deben consultar la agenda que realmente organiza su trabajo. Mostrar el mismo calendario es el principio: al confirmar una cita hay que volver a comprobar el hueco, porque otra reserva puede haber entrado entre la consulta y el envío.
Si hay varios canales capaces de reservar simultáneamente, deben compartir una forma de resolver esos conflictos. Dos comprobaciones independientes pueden dar por libre el mismo horario antes de que cualquiera de las dos cree la cita.
También hay que definir los eventos de día completo, el margen entre reuniones, la zona horaria y la antelación mínima. Para una reunión con dos profesionales, la disponibilidad debe ser la intersección de ambas agendas, con los permisos necesarios.
Probar los fallos que un visitante puede encontrar
| Prueba | Resultado esperado |
|---|---|
| Pulsar enviar dos veces | Una única consulta y una referencia estable. |
| Interrumpir la respuesta del proveedor | Estado pendiente comprobable; reintento sin duplicar. |
| Reservar el mismo hueco desde dos canales | Una confirmación y una alternativa para la otra persona. |
| Cambiar de horario de verano a invierno | La cita mantiene la hora local que se mostró al reservar. |
| Enviar una consulta fuera del servicio | Orientación clara, sin crear una expectativa falsa. |
Revisar lo que ocurre después de la confirmación
Una prueba termina cuando la consulta aparece donde debe, tiene responsable y conserva su origen. En una reserva, comprueba además que la cita existe y que el enlace de reunión corresponde a ella. Recibir una respuesta correcta de una API no demuestra que la persona haya visto el correo en su bandeja de entrada.
Para revisar tu propia web, envía una consulta identificada como prueba y sigue su referencia de principio a fin. Esa comprobación suele aportar más información que revisar únicamente la portada. Si necesitas reconstruir el recorrido, podemos analizar tus formularios y conexiones como parte de un proyecto de consultoría y desarrollo.