El costo de un dropdown genérico: Diseñando para incidentes complejos

¿Usar la herramienta interna es fácil o requiere un "doctorado en la NASA"?

Hace poco me enfrenté al reto de rediseñar un flujo de la plataforma interna que los agentes de soporte utilizan para gestionar reembolsos e incidencias complejas. El sistema original era terrible, consistía únicamente en un dropdown que se alineaba a la versión vieja de Soporte, esa en donde tenías que elegir el peor problema y reportarlo. Sin embargo, el equipo de OPS trabajó arduamente para mejorarlo, era una maravilla de la ingeniería: increíblemente robusto y técnicamente perfecto. Sin embargo, tenía un gran problema: casi exigía tener un dominio increíble sobre el flujo, la terminología y una imaginación desbordante para resolver problemas.

La pantalla principal estaba tan saturada de botones, microinteracciones y variables que la carga cognitiva de los agentes era insostenible. En este artículo, quiero reflexionar sobre cómo la simplificación de la interfaz no es un tema de "estética", sino una decisión financiera y de negocio.

Cuando la realidad supera a la interfaz

Anteriormente, cuando un pedido llegaba con problemas, la herramienta limitaba al agente a un solo dropdown para reportar una única incidencia por pedido, devolviendo de forma automática el dinero en créditos. Pero las incidencias reales no son genéricas y son mucho más complejas dependiendo del pedido:

• ¿Qué pasa si un usuario pide un Combo y el problema es únicamente que la dona llegó de fresa en lugar de mora?

• ¿Qué pasa si un panal de 18 huevos llega con 4 unidades rotas?

• ¿O si un filete de pechuga llega en mal estado en un 25% de su peso?

  
  

Forzar a un agente a encasillar un problema complejo en un menú rígido genera fricciones inmediatas: error en las quejas reportadas al aliado, pérdidas millonarias por reembolsos excesivos (devolver todo el combo por culpa de una sola dona) y, por consecuencia, un incremento en el DSAT (Customer Dissatisfaction).

Anatomía del Rediseño: Separar para dar claridad

Tras evaluar el funcionamiento de la herramienta y separar las actividades del agente en tres momentos, logré reducir la carga cognitiva y guiar la toma de decisiones paso a paso:

1. Selección de productos ➔ 2. Agregar detalles ➔ 3. Confirmación y Reembolso

1. Selección visual de productos

En lugar de procesar el pedido completo como un bloque abstracto, el agente ahora visualiza de manera granular los componentes del mismo. Si es un combo, puede desagregarlo; si es un producto pesable, puede interactuar con su proporción real.

2. Diagnóstico granular (Agregar detalles)

El agente asocia el problema exacto al producto seleccionado (ej. producto dañado, faltante, o insatisfacción) y responde preguntas de contexto rápidas para entender a profundidad qué pasó con el pedido.

3. Flexibilidad financiera

Una vez calculada la compensación exacta sobre la parte afectada, el agente puede elegir el método de reembolso ideal para el usuario (créditos o retorno directo a su método de pago original), devolviendo el control real de su dinero al cliente.

Reflexión de diseño: El impacto del "Diseño Invisible"

Aunque el rediseño se encuentra en fase de implementación y no cuento aún con la data final de producción, la hipótesis de impacto es clara: la granularidad del diseño protege no solo a la empresa, sino también a sus aliados y repartidores.

Al permitir devoluciones proporcionales y precisas (por el 25% de un filete o por 4 huevos específicos), evitamos la compensación desmedida por órdenes completas. Al mismo tiempo, reducir la carga cognitiva del agente, disminuye el tiempo de manejo por ticket (AHT), permitiendo que el soporte humano sea más rápido y eficiente.