Joe OviedoA finales de julio, en una llamada sobre una plataforma que estábamos construyendo, salieron varias cosas que queríamos mejorar: cómo dar seguimiento a las sesiones, qué avisos convenía enviar y por dónde debía reportar alguien un problema técnico. En medio de esa lista apareció una idea más pequeña: poner un botón para solicitar una factura desde el panel del usuario.
Me gustó lo acotada que era. Podíamos explicar en una frase quién usaría el botón, en qué momento y para qué. Alguien ya había pagado y necesitaba pedir su factura. No tenía por qué averiguar a quién escribirle.
La decisión de esa llamada fue incorporar el botón. Todavía quedaba la parte que no se ve en la pantalla: decidir qué debía ocurrir después de que alguien lo presionara.
El botón es la parte fácil de dibujar
Imagina que ya pagaste. Entras a tu cuenta, encuentras el cargo y ves «Solicitar factura». Haces clic. ¿El sistema sabe para qué pago la estás pidiendo? ¿Necesita datos que todavía no tiene? ¿Te confirma que recibió la solicitud? ¿Hay alguien que pueda verla y resolverla?
Si esas preguntas siguen abiertas, podemos terminar con un botón que solo abre un correo vacío. Es un avance pequeño: al menos ya sabes a quién escribirle. Pero todavía tienes que explicar de qué pago hablas, y alguien del otro lado tiene que buscarlo.
Lo primero que intentaría es que la solicitud nazca junto al pago. Si el sistema ya sabe cuál es, no le pediría a la persona que copie una referencia o adjunte una captura para identificarlo. Le pediría solo lo que falta para tramitarla. Y al final le diría algo que el sistema pueda sostener: «Recibimos tu solicitud», si eso es todo lo que ha pasado hasta ese momento.
Qué dejaría manual en la primera versión
En una primera versión me bastaría con que la persona pueda hacer la solicitud sin perseguir a nadie y que el equipo reciba el contexto necesario para atenderla. La revisión y la emisión pueden seguir siendo manuales mientras entendemos qué casos llegan.
Eso también me permite aprender qué parte merece automatizarse. Tal vez lo lento era identificar el pago. Tal vez era conseguir un dato que siempre faltaba. O quizá el trabajo más repetitivo empieza cuando todo eso ya está resuelto. Si automatizo la emisión antes de entender el recorrido, puedo invertir tiempo en la parte equivocada.
Con las excepciones haría lo mismo. Si alguien necesita corregir datos o no encuentra el pago, debe haber una forma clara de pedir ayuda. La primera versión no tiene que resolver todos los casos para ser útil; sí tiene que saber qué hacer con los que quedan fuera.
Qué miraría después de ponerlo en uso
Revisaría unas cuantas solicitudes de principio a fin. ¿La gente encontró el botón? ¿El equipo pudo atenderlas sin pedir otra vez los mismos datos? ¿Alguien volvió a escribir porque no sabía qué había pasado con su solicitud?
Esas preguntas me ayudan a distinguir entre añadir una opción al panel y resolver un problema. También me dan una pista sobre qué construir después: a veces falta un dato, a veces falta una confirmación y a veces lo que hace falta es dejar el flujo en paz.
De esa llamada me quedé con una pregunta para revisar otras tareas de soporte: ¿qué le estamos pidiendo a una persona que explique y que el sistema ya sabe? Ahí suele haber un buen lugar para empezar.
← Volver al Journal