Joe OviedoHay una pregunta que antes dejaba para el final cuando trabajaba en una página: «¿Quién tiene acceso al dominio?». Me parecía razonable. Primero había que decidir qué íbamos a ofrecer, escribir la página y lograr que todo se entendiera. Ya cerca de publicar, alguien nos daría acceso y conectaríamos lo que hiciera falta.
Ahora me gusta hacerla mucho antes. No porque quiera empezar una conversación sobre ventas hablando de DNS. Es porque a veces la respuesta es «lo compró alguien que ya no trabaja aquí». Y eso cambia lo que puedo prometer para el viernes.
La página carga. ¿Y lo demás?
Imagina que estamos preparando el lanzamiento de un taller. La página ya abre con el dominio del negocio. El formulario guarda los registros. Hago una prueba desde mi computadora, veo mi nombre en la lista y pienso que ya quedó. Pero cuando me registro desde mi correo personal, no encuentro la confirmación. En el panel, el mensaje aparece como enviado.
Antes habría empezado por el correo: revisar el asunto, acortar el texto, mandar otra prueba. Hoy, antes de tocar el mensaje, me haría una pregunta más básica: ¿desde qué dirección se envió y quién tiene acceso para revisar cómo está configurada?
Que la página cargue no contesta eso. El dominio puede llevarte al sitio sin que el servicio que manda las confirmaciones esté bien configurado para enviar en nombre del negocio. Y aunque esté bien configurado, que un mensaje figure como enviado no me dice si la persona lo encontró. Son comprobaciones distintas. Si las doy por resueltas porque vi un registro nuevo en el panel, puedo pasarme la tarde reescribiendo un correo que nadie ha leído.
¿Quién puede arreglarlo sin pedir un favor?
En un proyecto así, lo que me preocupa no es descubrir que falta una configuración. Eso se puede resolver. Lo que me preocupa es descubrirlo con gente ya inscrita y no saber quién puede hacer el cambio.
La persona que puede editar la página no necesariamente puede administrar el dominio. Quien armó el formulario tal vez no tiene acceso al servicio de correo. Y la dirección desde la que salen los mensajes puede verse muy profesional sin que nadie esté pendiente de las respuestas. Desde fuera, todo parece ser el mismo negocio. Por dentro, quizá haya tres cuentas y ninguna persona sepa quién tiene acceso a las tres.
No necesito que todo el equipo pueda tocar todo. Sí quiero que el negocio conserve el control y que cada quien sepa a quién acudir. Si mañana cambia la persona que hizo la página, el dominio no debería irse con ella. Y si alguien responde a la confirmación para avisar que no encuentra el enlace al taller, me interesa que esa respuesta le llegue a alguien que pueda ayudarle, no a una dirección que nadie revisa.
La prueba que haría antes de invitar a nadie
Yo recorrería el camino desde fuera: abrir la dirección que vamos a compartir, registrarme con un correo que no sea del equipo, buscar la confirmación, abrir el enlace y responder al mensaje. Luego comprobaría que esa respuesta llegó a la persona que la va a atender. Si algo falla, anotaría dónde se cortó y quién puede corregirlo. No hace falta convertirlo en una auditoría para que sea útil.
También decidiría qué podemos seguir haciendo mientras se resuelve. Si no tenemos acceso al dominio, podemos terminar la página y probar el formulario en un entorno de trabajo. Lo que no haría es empezar a mandar tráfico para descubrir, con registros reales, si la gente recibió las instrucciones que le prometimos. Ya tendremos suficientes cosas que aprender del lanzamiento. Esta la podemos comprobar antes.
Por eso cuento el dominio y el correo como parte del embudo. Para quien se apunta al taller, la página, la confirmación y la respuesta a su duda no son tres sistemas. Son tres momentos de la misma conversación. Si esa persona tiene que escribirnos por otro lado para averiguar si su registro funcionó, poco importa que el panel diga que todo salió bien.
← Volver al Journal