Una clienta está por pagar en su sitio web. Eligió sus productos, ingresó su tarjeta y hizo clic en "Pagar Ahora". La página se congela un segundo y después muestra esto:
Error 500.
Eso es todo. Sin explicación. No sabe si le cobraron. No sabe si el problema es su tarjeta, su conexión o el sitio. No sabe si intentar de nuevo o rendirse. La mayoría de las personas, con razón, se rinde. Cierra la pestaña, y usted nunca se entera de que estuvo ahí.
Multiplique ese momento por cada visitante que se topa con un error confuso en su sitio, su sistema de reservas o su software interno, y empieza a ver un costo que nunca aparece en ninguna factura: la venta que desapareció en silencio, y la confianza que se fue con ella.
Por Qué un Mensaje de Error Confuso Cuesta Más de lo Que Parece
Un mensaje de error parece un detalle técnico menor, así que es fácil asumir que no importa demasiado. Pero piense qué pasa realmente cuando alguien se topa con uno. Estaba en medio de algo, pagándole, reservando un turno, enviando un formulario, y su software lo frenó en seco sin ninguna explicación. Eso no es una molestia menor. Es el momento exacto en el que su cliente decide si confiar en usted o abandonar.
Las investigaciones sobre pagos en línea confirman esto. Estudios de sitios de comercio electrónico encontraron que más de la mitad no muestra mensajes de error claros y específicos cuando algo falla durante el pago, y los errores en el checkout son una de las razones recurrentes por las que la gente abandona un carrito que tenía toda la intención de completar. Otra investigación del Baymard Institute, que estudia específicamente la experiencia de pago en línea, encontró que la gran mayoría de los sitios muestra el mismo error genérico sin importar qué salió mal en realidad, en lugar de decirle al comprador exactamente qué pasó y cómo solucionarlo. Un error vago no solo se ve descuidado. Empuja activamente a clientes que ya estaban por pagarle hacia la salida.
Lo mismo pasa puertas adentro de su negocio, no solo del lado del cliente. Cuando su personal se topa con un error críptico al procesar un pedido o actualizar un registro, no sabe si la acción funcionó, falló o quedó a medias. Entonces, o lo intenta de nuevo, arriesgándose a duplicar algo, o se detiene y pide ayuda. De cualquier forma, ese mensaje vago acaba de convertir una tarea de dos segundos en un problema de cinco minutos.
Qué Incluye Realmente un Buen Mensaje de Error
Un mensaje de error bien escrito hace tres cosas específicas. Si falta alguna, la persona que lo lee queda adivinando.
Dice qué pasó. No "ocurrió un error", sino el problema real: "Su tarjeta fue rechazada." "No pudimos conectar con el procesador de pagos." "Este correo ya está registrado." Lo específico siempre gana, sobre lo vago.
Dice qué hacer a continuación. Un problema sin un próximo paso deja a la persona atascada. "Pruebe con otra tarjeta o contacte a su banco" le da al cliente un lugar adónde ir. "Revise su correo para encontrar el enlace de verificación" le dice exactamente qué sigue ahora. Este es el paso que casi todos los negocios se saltean, y es el que más importa.
Dice cómo pedir ayuda si los dos primeros pasos no resuelven el problema. No todo problema tiene una solución que el cliente pueda hacer solo. Cuando no la tiene, el mensaje debería decirlo con claridad, con una forma de contactar a una persona real, en lugar de dejar que el cliente busque su página de contacto por su cuenta mientras ya está frustrado.
Compare eso con los mensajes que la mayoría del software realmente muestra: "Algo salió mal." "Error 500." "Entrada inválida." Cada uno falla las tres pruebas. Informan que existe un problema sin decir cuál es, qué hacer, o adónde acudir.
Un Ejemplo Concreto
Imaginemos un cliente mío que administra una pequeña plataforma de reservas. Su sistema mostraba un solo mensaje para todo pago fallido: "Transacción fallida. Intente de nuevo." No importaba si la tarjeta estaba vencida, si la dirección de facturación no coincidía, o si su procesador de pagos había fallado por unos minutos. Los clientes veían siempre la misma línea inútil, volvían a intentar con la misma tarjeta, la veían fallar de nuevo, y una cantidad importante simplemente se iba sin reservar.
Reescribimos el mensaje para que revisara el motivo real de la falla y respondiera en consecuencia. Ahora, una tarjeta rechazada muestra: "Su banco rechazó la tarjeta. Pruebe con otra tarjeta, o contacte a su banco para autorizar el cobro." Una falla del procesador de pagos muestra: "Estamos teniendo problemas para conectar con nuestro sistema de pagos. Por favor intente de nuevo en unos minutos, no se realizó ningún cobro." Las consultas de soporte relacionadas con pagos fallidos bajaron notablemente durante el primer mes, porque la mayoría de los clientes ahora podía resolver su propio problema sin escribirle a nadie.
Por Qué Esto Es una Decisión de Diseño, No un Detalle de Último Momento
Este es el patrón que veo una y otra vez: los mensajes de error se escriben al final, muchas veces por quien está corrigiendo un problema a las 11 de la noche y solo necesita que la pantalla muestre algo. Nadie se sienta a preguntar: "¿Qué necesita ver ahora mismo un cliente confundido, quizás frustrado?" Se trata como una nota técnica al pie, en lugar de un momento que define si alguien confía en su negocio.
Pero un mensaje de error es atención al cliente, entregada por software en vez de por una persona. Si un empleado le respondiera a un cliente confundido diciendo "algo salió mal" y se fuera caminando, usted lo corregiría de inmediato. Su software hace exactamente eso cientos de veces al mes, y como nadie lo escucha suceder, casi nunca se corrige. Tratar los mensajes de error como parte de su producto, algo que merece planificarse y revisarse como cualquier otro texto de cara al cliente, es un cambio pequeño que se paga solo con menos consultas de soporte y menos carritos abandonados.
Una Prueba Simple Para Su Propio Software
No necesita conocimientos técnicos para revisar esto usted mismo. Elija un formulario de su sitio web, el checkout, el formulario de contacto, la página de reservas, y provoque deliberadamente un error. Ingrese un número de tarjeta vencido si está probando en un entorno seguro, o simplemente pídale a su desarrollador que le muestre qué ven sus clientes cuando un pago falla, una sesión expira, o un campo del formulario es inválido.
Después hágase tres preguntas. ¿El mensaje dice qué pasó, en lenguaje simple? ¿Dice qué hacer a continuación? Si no lo dice, ¿un cliente real sabría adónde acudir por ayuda? Si la respuesta a cualquiera de estas es no, acaba de encontrar un lugar donde su software está perdiendo clientes en silencio, un visitante confundido a la vez.
Esto está estrechamente relacionado con otra cosa que vale la pena revisar en su propio sitio: si su software pide confirmación antes de hacer algo que no se puede deshacer, algo que explico en por qué importan los mensajes de confirmación y los botones de deshacer. Ambos son piezas pequeñas de texto que cargan mucho peso en el momento en que alguien más las necesita.
Los buenos mensajes de error no van a resolver todos los problemas de su software. Pero son una de las mejoras más baratas y rápidas disponibles, muchas veces basta con reescribir un texto, no con reconstruir nada, y se pagan solas con menos llamadas de soporte y menos clientes que se rindieron en silencio y se fueron.