Un fallo, un éxito
· Matt Senter
Un usuario me envió un comentario sobre Premail: recibía un error 404 al intentar pagar. Fue vergonzoso de inmediato. No debería publicar nada que devuelva un 404 donde debería haber una página funcional, y mucho menos en el momento exacto en que alguien intenta darme su dinero.
Tengo pruebas. Tengo alertas. Tengo alarmas de infraestructura. Ninguna lo detectó. La persona que estaba al otro lado de mi proceso de pago roto, sí.
Lo que hizo interesante este incidente, más allá de la frustración de descubrirlo, fue cómo me enteré en realidad. Una función que había añadido a Premail apenas unos días antes sacó a la luz el comentario que todo lo demás no había logrado poner ante mis ojos. Mi producto tuvo un fallo, y luego mi producto me ayudó a afrontarlo.
El cliente no debería haber sido la alarma
Hay algo especialmente doloroso en un fallo durante el pago. Alguien ya ha hecho el trabajo de encontrar tu producto, entender qué hace y decidir que vale la pena pagar por él. Y entonces le pones un callejón sin salida delante.
Habría sido completamente razonable que esta persona cerrara la pestaña y siguiera con su vida. No me debía un informe de error, una captura de pantalla ni una explicación de por qué no iba a conseguir su compra. Intentaba comprar algo, no ofrecerse como voluntaria para control de calidad.
En lugar de eso, se tomó el tiempo de enviar un comentario. Se lo agradecí de verdad y le di un 50 % de descuento como agradecimiento. Me dio la oportunidad de arreglar un problema del que, de otro modo, quizá nunca me habría enterado.
Esa es también la parte incómoda. Sé de la persona que me avisó. No sé si alguien más se encontró con el mismo problema y se fue sin decir nada. Un pago fallido puede parecerse muchísimo a una persona que simplemente decidió no comprar, a menos que estés detectando realmente el fallo.
El mío no se estaba detectando. Fuera cual fuera la confianza que tenía en mis pruebas y mi monitorización, esto fue una demostración bastante inequívoca de que habían pasado por alto algo importante.
El correo que necesitaba ver
Mi formulario de comentarios me envía una breve notificación por correo avisándome de que hay un comentario por revisar. Es una nota corta, no el comentario completo. Para saber qué ha dicho alguien, tengo que fijarme en ese correo e ir a comprobarlo.
Lo había pasado por alto. Pero esa notificación apareció en mi resumen matutino de Premail, y vi de inmediato que había un comentario sobre el que debía actuar. Fui a leerlo, me enteré del problema con el pago y me puse manos a la obra.
Vale la pena hacer esta distinción: Premail no detectó el 404. No inspeccionó mi proceso de pago, no diagnosticó el error ni sustituyó de algún modo la monitorización que debería haberlo detectado. El cliente encontró el problema. Premail sacó a la luz la notificación que me llevó a leer lo que había reportado.
Eso era exactamente lo que quería que hicieran los resúmenes, y ocurrió mientras yo mismo todavía me estaba acostumbrando a usarlos.
Usar lo que acabo de construir
Añadí los resúmenes a Premail hace apenas unos días. Estoy intentando entrenarme para dejar de ir por defecto a mi cliente de correo y usar en su lugar mis resúmenes como síntesis de lo que requiere mi atención. Para mí es un cambio de hábito, no solo el lanzamiento de una función.
Abrir una bandeja de entrada y averiguar qué importa son dos actividades distintas. Puedo mirar el correo sin darme cuenta del mensaje concreto que debería cambiar lo que hago a continuación. En este caso, una pequeña notificación sobre un comentario tenía que convertirse en una tarea real: ve a leer esto y responde.
El resumen matutino hizo esa conexión por mí. Vi algo que había pasado por alto, entendí que tenía que actuar y actué de inmediato. No hubo mucha ambigüedad sobre si había sido útil.
Una cosa es construir una función porque crees que ayudará a la gente. Otra es que esa función saque algo importante de tu propio correo y cambie el rumbo de tu mañana. Habría preferido un ejemplo menos vergonzoso, pero este fue bastante convincente.
Arreglar más que el proceso de pago
El problema del pago ya está arreglado. También arreglé las alertas, las alarmas de infraestructura y las pruebas que no lo detectaron. Hacer que la página funcionara era necesario, pero quedarme ahí me habría dejado dependiendo del próximo cliente amable para enterarme de cuándo algo va mal.
No voy a declarar que algo así no puede volver a ocurrir nunca. Me esforcé en evitarlo la primera vez y aun así ocurrió. El objetivo de estos cambios es evitar que se repita y, si ocurre, enterarme antes de que un cliente tenga que reportarlo o un posible cliente se rinda en silencio.
La lección desde luego no es que un resumen matutino sea un sustituto aceptable de las pruebas y la monitorización. «Espera a que alguien se queje y luego resume la notificación» sería una estrategia de fiabilidad pésima. Tenía que arreglar los sistemas que permitieron que el problema llegara a un cliente en primer lugar.
Pero también pude ver a Premail hacer algo realmente útil después de que esos sistemas fallaran. Puso ante mis ojos un mensaje que había pasado por alto, y ese mensaje condujo directamente a una solución.
El fallo en el pago no se vuelve menos vergonzoso porque mi propia aplicación me ayudara a descubrirlo. Ambas cosas son ciertas: dejé que un cliente se topara con un proceso de pago roto, y una función que acababa de construir me ayudó a responder. Agradezco que el cliente se molestara en avisarme, y me alegra que mi resumen matutino se asegurara de que lo viera.