Reducción de casos de soporte
Los tickets de soporte eran un mapa de deuda UX. Los leí como datos y rediseñé el flujo: hasta −90%.
Medido con ventanas comparables: base sep 2025–ene 2026 vs. abr–ago 2026 (5 meses cada una) · −675 casos = −494 (flujos de aprobación) + −181 (autogestión de usuarios y accesos).
El problema
El sistema convertía tareas operativas rutinarias en tickets de soporte: habilitar una remisión o una orden de compra no se podía hacer dentro del sistema. Cada bloqueo era una espera y una carga para soporte; nadie había mirado los tickets como patrón, solo como cola de atención.
Mi rol · equipo · organización
Definí el enfoque de mirar los tickets como datos, impulsé el análisis, diseñé los flujos de autogestión + aprobación y su modelo de estados, y definí y medí la comparación pre/post.
Desarrollo implementó los flujos; Compras y Contabilidad validaron las reglas de aprobación.
Aportó el histórico de tickets y la decisión de permitir la autogestión con control.
Research
Análisis de casos de soporte en una ventana base (Sep 2025–Ene 2026) para identificar qué acciones generaban más tickets.
- Dos acciones concentraban la mayoría del volumen: habilitar remisión y habilitar orden de compra.
- El bloqueo era legítimo (requiere aval); lo que faltaba era un camino para pedirlo sin salir del sistema.
Ventanas comparables: base Sep 2025–Ene 2026 vs post Abr–Ago 2026 (5 meses cada una). Medir así, en vez de un antes/después difuso, es lo que blinda el número frente a un hiring manager.
Insights
- Los tickets de soporte son un mapa de deuda UX.
- El bloqueo no era el problema — la falta de un camino lo era.
- Autogestión no significa perder control: la aprobación del área responsable se mantiene.
Decisiones de diseño
Modelo de estados explícito
Solicitar → Solicitud en curso (bloqueada) → Aprobada / Rechazada → continuar. El usuario siempre sabe qué sigue.
Bloqueo con propósito
La orden queda bloqueada para edición hasta la decisión — protege la integridad del proceso.
Escalamiento claro por área
El modal indica a dónde va la solicitud (Contabilidad / Compras) con un comentario opcional de contexto.
Recuperación de error
El estado Rechazada incluye "Volver a solicitar" — no es un callejón sin salida.
Resultados
Aprendizajes
- El mejor research a veces ya está en la base de datos.
- Diseñar el proceso, no solo la pantalla.
- Medir con rigor cambia la conversación: de "creo que mejoró" a "cayó hasta 90%".
Support case reduction
Support tickets were a map of UX debt. I read them as data and redesigned the flow: up to −90%.
Measured with comparable windows: baseline Sep 2025–Jan 2026 vs. Apr–Aug 2026 (5 months each) · −675 cases = −494 (approval flows) + −181 (user & access self-service).
The problem
The system turned routine operational tasks into support tickets: enabling a delivery note or a purchase order could not be done inside the system. Every block meant waiting and a burden on support; nobody had looked at the tickets as a pattern, only as a queue to attend.
My role · team · organization
I defined the approach of looking at tickets as data, drove the analysis, designed the self-service + approval flows and their state model, and defined and measured the before/after comparison.
Development implemented the flows; Purchasing and Accounting validated the approval rules.
Provided the ticket history and the decision to allow self-service with control.
Research
Analysis of support cases over a baseline window (Sep 2025–Jan 2026) to identify which actions generated the most tickets.
- Two actions concentrated most of the volume: enabling a delivery note and enabling a purchase order.
- The block was legitimate (it requires approval); what was missing was a way to request it without leaving the system.
Comparable windows: baseline Sep 2025–Jan 2026 vs post Apr–Aug 2026 (5 months each). Measuring this way, instead of a fuzzy before/after, is what makes the number hold up in front of a hiring manager.
Insights
- Support tickets are a map of UX debt.
- The block was not the problem — the lack of a path was.
- Self-service does not mean losing control: approval from the responsible area is kept.
Design decisions
Explicit state model
Request → Request in progress (blocked) → Approved / Rejected → continue. Users always know what comes next.
Blocking with a purpose
The order stays locked for editing until the decision — it protects the integrity of the process.
Clear escalation by area
The modal shows where the request goes (Accounting / Purchasing) with an optional comment for context.
Error recovery
The Rejected state includes "Request again" — it is not a dead end.
Results
Learnings
- The best research is sometimes already in the database.
- Design the process, not just the screen.
- Measuring rigorously changes the conversation: from "I think it improved" to "it dropped by up to 90%".