El diseño de rutas de excepción ayuda a los equipos a gestionar solicitudes rechazadas, documentos faltantes y aprobaciones parciales antes de que la retrabajo ralentice todo el proceso.
La mayoría de los equipos empiezan con la versión limpia de un flujo. Llega una solicitud, alguien la revisa y se aprueba. Parece eficiente, pero oculta donde ocurre el trabajo real.
La ruta feliz suele ser el camino más corto. El formulario está completo, los adjuntos están, y el revisor sabe exactamente qué hacer. En las operaciones reales, rara vez esa es la parte que causa demoras.
Los retrasos comienzan cuando falta algo, está poco claro, llega tarde o sólo es parcialmente aceptable. Un gerente puede aprobar el presupuesto pero rechazar una partida. Finanzas puede necesitar un documento fiscal que nunca se subió. Un responsable de soporte puede devolver una solicitud porque el campo de motivo es demasiado vago. Cada uno de esos momentos crea pasos extra, mensajes adicionales y espera.
Si esas situaciones no se planifican temprano, la gente decide sobre la marcha. Un revisor envía un correo. Otro deja un comentario en la herramienta. Un tercero rechaza la solicitud sin explicación. El solicitante se queda adivinando: ¿debe arreglarlo, empezar de nuevo o pedir ayuda?
Esa confusión tiene un coste. Ralentiza a quien envió la solicitud, al revisor y a cualquiera que se incorpore para explicar qué pasó. Un flujo que en la pizarra parecía simple se convierte en chats de seguimiento, envíos duplicados y traspasos manuales.
Un flujo básico de aprobación es fácil de dibujar:
La versión real es más complicada. ¿Y si falta un documento? ¿Y si solo parte de la solicitud se aprueba? ¿Y si el revisor la rechaza pero el usuario puede corregirla? Estos no son casos inusuales. Para muchos equipos, son los casos normales.
Por eso el diseño de rutas de excepción merece atención antes de dibujar pantallas y nombrar estados. La ruta de excepción define qué pasa cuando la realidad interrumpe el plan, y la realidad lo hace a menudo.
Si estás construyendo una app interna de aprobaciones, incluso en una plataforma no-code como AppMaster, los casos rechazados e incompletos necesitan tanto cuidado como el caso aprobado. Influyen en los mensajes que ven las personas, las acciones que pueden tomar y si el flujo ayuda a recuperar la solicitud o la deja atascada.
La ruta feliz muestra la intención. Las rutas de excepción muestran si el proceso puede soportar el uso real.
Una ruta de excepción es lo que ocurre cuando una solicitud no puede avanzar de la forma normal. No es un caso raro. Es la parte del proceso que maneja el desorden del mundo real: una solicitud se niega, un formulario está incompleto, una parte se aprueba pero otra no, o el trabajo simplemente se queda estancado.
Una ruta de excepción clara usa lenguaje llano. En lugar de un estado vago como "Fallido", di qué pasó: "Rechazado porque el presupuesto supera el límite" o "Esperando documento de identidad". La gente debe saber qué está mal, quién tiene que actuar y qué sucede después.
La mayoría de los flujos fallan de formas previsibles:
La información faltante es uno de los problemas más comunes. Imagina un formulario de alta de proveedor que necesita un documento fiscal y un número de cuenta bancaria. Si falta cualquiera de los dos, el sistema no debería simplemente detenerse. Debe marcar la solicitud como incompleta, mostrar exactamente qué falta y devolverla a la persona indicada.
Las aprobaciones parciales son igual de importantes. Piensa en una solicitud de viaje para vuelo, hotel y presupuesto de comidas. El gerente aprueba el vuelo y el hotel pero recorta el presupuesto de comidas. El proceso ahora necesita reglas. ¿El empleado acepta el cambio, actualiza la solicitud o cancela el viaje?
Los estancamientos también importan. Una solicitud puede quedarse sin movimiento porque el revisor asignado dejó la empresa, el equipo nunca puso un aprobador alterno o el proceso llega a un paso sin siguiente dueño. Técnicamente no hay nada roto, pero la solicitud sigue sin avanzar.
Si no diseñas estas rutas temprano, la gente las gestiona por correo, chat o notas en hojas de cálculo. Pronto nadie sabe qué versión es la final.
Toma una solicitud de viaje para un responsable de ventas que quiere asistir a una conferencia de dos días. En papel, el flujo parece fácil: el empleado introduce las fechas del viaje, el coste estimado y el motivo. El gerente lo aprueba, finanzas confirma el presupuesto y el viaje pasa a reserva.
Ese flujo es limpio, pero también incompleto.
Ahora rompe la misma solicitud. El empleado sube la estimación del vuelo y la entrada a la conferencia pero olvida la cotización del hotel. Si el sistema sólo conoce "enviado" y "aprobado", la gente se atasca rápido. Finanzas puede ver una solicitud incompleta, el gerente puede pensar que está lista y el empleado puede no saber qué falta.
Un mejor flujo le da a esa solicitud su propio estado, como "Esperando documento" o "Necesita actualización". El empleado debería ver un mensaje claro: "Agrega la cotización del hotel antes de que esta solicitud pueda pasar a finanzas." El gerente no debería tener que rechazar todo el viaje solo para pedir un archivo.
Ahora añade un segundo problema. El gerente está de acuerdo en que el empleado viaje, pero no con el monto total. Aprueba el vuelo y una noche de hotel, pero rechaza la tarifa del taller y la segunda noche de hotel.
Aquí es donde muchos equipos descubren que no tienen realmente un proceso de aprobación parcial.
Si el flujo no puede aprobar solo una parte de la solicitud, la gente empieza a usar soluciones improvisadas. Pueden rechazar toda la solicitud y pedir que el empleado la vuelva a enviar. O finanzas puede aprobar por error el monto completo porque el sistema solo guarda una decisión sí/no.
Un modelo más claro rastrea cada partida de coste, o al menos el total aprobado. Una solicitud podría mostrar:
Ese ejemplo muestra por qué los errores en flujos de aprobación a menudo vienen de reglas faltantes, no de personas descuidadas. Si defines esas reglas antes de diseñar las pantallas, el resto del flujo se vuelve mucho más fácil de confiar.
Una buena manera de mejorar un flujo es asumir que la solicitud no pasará limpia. Ese cambio de perspectiva mejora la calidad del diseño rápidamente.
Empieza con los casos desordenados: el formulario está incompleto, la política es ambigua, el aprobador está ausente o sólo parte de la solicitud debe seguir adelante. La mayoría de los equipos puede agruparlos en tres patrones principales:
Eso mantiene el trabajo manejable. En lugar de inventar una respuesta nueva para cada caso límite, defines un pequeño conjunto de patrones y los aplicas a cada tipo de solicitud.
Trabaja en este orden.
Primero, lista cada punto donde la solicitud puede detenerse. Piensa en documentos faltantes, valores inválidos, violaciones de política, plazos expirados, envíos duplicados y revisiones manuales. Si la solicitud puede esperar, fallar o volver al remitente, escríbelo.
A continuación, decide qué pasa en cada caso. Para cada excepción, responde cuatro preguntas simples:
Por ejemplo, imagina que un empleado envía un reclamo de gastos de $600. Falta el recibo del hotel y una comida supera la política. Si solo diseñas la ruta feliz, la solicitud o se queda atascada o se rechaza en bloque. Si diseñas las excepciones primero, el sistema puede pausar el reclamo por el recibo faltante, notificar al empleado con un mensaje claro y aun así marcar los items permitidos como condicionalmente aprobados.
Ahí es donde importan las reglas de aprobación parcial. Debes decidir si el monto aprobado puede avanzar ahora, si el resto queda en espera y si el solicitante puede editar solo la parte disputada o debe volver a enviar todo el reclamo.
Si estás construyendo el proceso en AppMaster, este es el momento de mapear esas ramas en la lógica de negocio antes de pulir la interfaz. Es mucho más fácil confiar en un flujo cuando rechazar, devolver para edición y aprobar con condiciones se tratan como caminos separados en lugar de estar ocultos bajo un estado vago.
Finalmente, prueba un escenario real de principio a fin. Usa números reales, una brecha de documento real y una excepción de política. Si una persona que lee el flujo no puede decir qué pasa después en menos de un minuto, el diseño sigue siendo demasiado vago.
Las pantallas se sienten concretas, así que los equipos a menudo empiezan por ahí. Bocetan botones, formularios y paneles antes de ponerse de acuerdo sobre las reglas. Eso suele crear problemas más adelante, porque la interfaz termina ocultando decisiones que nadie tomó.
Un orden mejor es simple: define los estados, traspasos, plazos y pruebas requeridas para avanzar. Luego construye las pantallas en torno a eso.
El diseño de rutas de excepción se vuelve mucho más sencillo cuando el conjunto de reglas es pequeño y claro. Si una solicitud puede aprobarse, rechazarse, devolverse para correcciones o aprobarse parcialmente, esos estados necesitan nombres sencillos que signifiquen una sola cosa. Evita near-duplicates como "Devuelto", "Reabierto" y "Necesita cambios" a menos que realmente se comporten de forma diferente.
Toma una solicitud de compra. Un gerente la abre y nota que falta la cotización. Si el equipo no decidió qué ocurre después, la gente improvisa. Un gerente la rechaza. Otro la deja pendiente. Un tercero envía un mensaje por chat y no cambia nada en el sistema. Pronto nadie confía en el estado.
Escribe la regla primero. Cuando falta una cotización, la solicitud pasa a "Necesita documentos". El solicitante es el siguiente responsable. La solicitud permanece allí cinco días hábiles. Si no llega nada, cambia a "Expirada" y se requiere una nueva presentación.
Esa regla modela el producto mejor que un mockup. Ahora sabes qué debe ver el usuario, qué recordatorio enviar y qué historial conservar.
Un conjunto de reglas práctico debe responder cuatro preguntas:
Las aprobaciones parciales necesitan el mismo nivel de cuidado. Si el viaje está aprobado pero el coste del hotel no, ¿el solicitante edita el mismo registro o crea uno nuevo? ¿Finanzas revisa solo la parte cambiada o todo de nuevo? Si eso no se decide temprano, la pantalla puede verse ordenada mientras el proceso permanece desordenado.
Cuando los equipos fijan las reglas primero, la interfaz se vuelve más simple. Más importante: los usuarios saben exactamente qué hacer después, incluso cuando la respuesta es "aún no aprobado".
Un mal mensaje de excepción lo ralentiza todo. La gente no solo necesita saber que algo falló. Necesita saber qué pasó, qué afecta y qué hacer después.
Aquí es donde el diseño se vuelve real para los usuarios. Tus reglas internas pueden ser claras, pero si la pantalla solo dice "Error" o "En revisión", la gente adivinará, reenviará archivos equivocados o pedirá ayuda a soporte.
Toma un ejemplo de aprobación de proveedor. Un usuario envía un formulario con documento fiscal, datos bancarios y comprobante de seguros. Los datos bancarios están bien, el documento fiscal está desactualizado y falta el comprobante de seguros. Si el sistema solo muestra "Solicitud no aprobada", el usuario no tiene un siguiente paso claro.
Un mejor mensaje suena así: "Sus datos bancarios fueron aprobados. Aún necesitamos un documento fiscal actualizado y el comprobante de seguros antes de la aprobación final." Esa sola frase ahorra tiempo porque separa lo que ya está hecho de lo que falta.
Los buenos mensajes suelen responder cuatro preguntas pequeñas:
Esa última parte importa. La gente termina la tarea con más probabilidad cuando el siguiente paso es obvio. "Suba el archivo faltante y reenvíe para revisión" es mucho mejor que "Acción requerida."
Las etiquetas vagas también generan ansiedad. "En revisión" puede significar que se espera a una persona, que faltan datos o que hay una comprobación interna. Si conoces la razón, dilo claramente. "Esperando aprobación del gerente" y "Esperando comprobante de domicilio" no son la misma situación y no deberían verse igual.
Si un proceso permite aprobaciones parciales, muéstralo claramente en el propio estado. Un desglose breve suele funcionar mejor que una sola etiqueta:
Ahora el usuario puede arreglar solo lo que importa. No necesita empezar de nuevo.
Aquí también la posibilidad de reenviar debe ser fácil de encontrar. Coloca la acción siguiente cerca del mensaje, no en otra pantalla. Si construyes el flujo en AppMaster, ayuda que el texto visible al usuario coincida con los estados reales del proceso para que la app diga exactamente lo que la lógica de negocio está haciendo.
Los buenos mensajes reducen tickets de soporte, aceleran las aprobaciones y hacen que el proceso se perciba como justo. La gente puede aceptar un rechazo cuando lo entiende.
La mayoría del retrabajo parte de una suposición equivocada: diseñar principalmente la ruta normal. Los equipos mapean solicitud enviada, aprobada, completada y se quedan ahí. Luego aparece la vida real: falta un archivo, un gerente pide cambios o solo parte de la solicitud puede avanzar.
Esa brecha crea trabajo extra rápido. La gente inventa correcciones manuales, envía mensajes paralelos y renombra estados sobre la marcha. Unas semanas después, nadie confía en el flujo porque cada excepción se siente como un caso especial.
Un error común es tratar la ruta ideal como el producto y todo lo demás como limpieza. Imagina un reclamo de gastos que necesita recibo, aprobación del departamento y revisión de finanzas. Si falta el recibo, ¿la solicitud pausa, vuelve al empleado o se rechaza? Si esa regla no está clara desde el principio, el equipo suele parchearla después con emails y comentarios.
Nombres de estado confusos provocan otra ronda de retrabajo. Etiquetas como "En revisión 2" o "Acción pendiente" suenan inofensivas, pero obligan a la gente a adivinar qué pasa después. Nombres claros reducen errores porque muestran el problema, el responsable, el resultado o el siguiente paso.
La propiedad es otro lugar donde los flujos fallan. Una solicitud no debería quedarse en un estado que no pertenece a nadie. Si un caso está esperando, alguien debe ser responsable de moverlo adelante, pedir más información o cerrarlo. Si no, se acumulan retrasos silenciosos y los usuarios asumen que el sistema perdió su solicitud.
La aprobación parcial suele gestionarse mal también. Los equipos la tratan como un rechazo completo porque parece más sencillo. Pero esos resultados significan cosas diferentes. Si una solicitud de viaje pide vuelo, hotel y comidas, finanzas puede aprobar vuelo y hotel pero negar comidas. Ese caso necesita su propia ruta, su propio mensaje y a menudo su propia acción de seguimiento.
Cuando la aprobación parcial se mezcla con el rechazo, la gente vuelve a enviar la solicitud completa, duplica documentos y reinicia revisiones ya hechas. Eso es puro retrabajo.
Una prueba simple ayuda: lee cada estado no feliz y pregunta, "¿Quién es el dueño, qué ve el usuario y qué pasa después?" Si la respuesta es confusa, el proceso probablemente fallará en el mismo punto más adelante.
Antes de construir pantallas o automatizar nada, haz una última pasada por los casos desordenados. Un buen diseño de rutas de excepción suele ser solo unas pocas decisiones claras hechas temprano, antes de que la confusión se vuelva retrabajo.
Si una solicitud es rechazada, pausada o solo parcialmente aprobada, alguien debe saber siempre qué pasa después, quién lo hace y qué información falta.
Usa esta comprobación rápida en cada excepción de tu proceso:
Luego realiza una prueba simple. Entrega el proceso a alguien que no haya ayudado a diseñarlo. Dale una solicitud rechazada y una con un documento faltante. Si no pueden decir qué hacer en menos de un minuto, el proceso sigue siendo demasiado vago.
Un pequeño ejemplo lo demuestra. Imagina que un gerente aprueba una solicitud de software pero rechaza la parte de hardware. Si el estado solo dice "Aprobado parcialmente", el empleado puede asumir que todo puede avanzar. Un estado mejor dice exactamente qué se aprobó, qué se denegó y si el empleado puede reenviar la parte faltante.
Si quieres convertir esas reglas en una app interna funcional, mapea los estados de excepción primero y construye la ruta feliz después. En AppMaster, eso puede significar definir estados, reglas de negocio y campos requeridos antes de preocuparte por pantallas pulidas. Es una forma práctica de crear aplicaciones sin código que manejan trabajo real, no solo su versión ideal.
El siguiente paso es simple: lista tus cinco excepciones principales, asigna un responsable a cada una y escribe el mensaje que debe ver el usuario. Si esas tres partes están claras, la construcción suele resultar mucho más fácil.
¿Por qué no basta con la ruta feliz para un flujo de aprobaciones?Porque los retrasos reales suelen ocurrir cuando falta algo, está poco claro, llegа tarde o sólo se aprueba parcialmente. Si diseñas solo el flujo limpio, la gente acaba solucionando problemas por chat, email y procedimientos manuales.
¿Qué rutas de excepción debo diseñar primero?Empieza por los casos que ocurren con más frecuencia: rechazo, información faltante y aprobación parcial. Luego añade estancamientos, como una solicitud sin responsable o sin siguiente paso definido.
¿Qué estados debe tener una app de aprobaciones?Usa un conjunto pequeño de estados claros que signifiquen una sola cosa. Un conjunto práctico por defecto es: aprobado, rechazado, necesita documentos, necesita cambios, aprobado parcialmente y expirado (si usas plazos).
¿Cómo debe manejarse la falta de documentos?El usuario debe ver exactamente qué falta y qué hacer a continuación. Un buen comportamiento por defecto es mover la solicitud a un estado como "Necesita documentos", nombrar claramente los elementos faltantes y devolverlo a la persona correcta en vez de rechazar toda la solicitud.
¿Cómo manejo las aprobaciones parciales sin crear retrabajo?Trátalo como su propia ruta, no como un rechazo total. Muestra qué se aprobó, qué se negó, el total aprobado si aplica y si el solicitante puede aceptar el cambio, editar la solicitud o reenviar solo la parte en disputa.
¿Qué debe pasar cuando una solicitud se queda estancada sin acción?Asigna a cada estado de espera un responsable y una regla de tiempo. Si un revisor está ausente o una solicitud está demasiado tiempo sin movimiento, el flujo debe escalar, reasignar o expirar en vez de quedarse estancado.
¿Qué hace que un mensaje de excepción sea realmente útil?Sé claro y específico. Dile al usuario qué parte fue rechazada o falta, qué ya se aceptó, qué debe subir, cambiar o confirmar y qué ocurre después de reenviar. Eso facilita que la gente actúe rápido.
¿Debo diseñar las pantallas primero o las reglas del flujo?Define primero las reglas. Pon de acuerdo los estados, responsables, plazos, archivos requeridos y siguientes acciones antes de esbozar botones o paneles, porque la interfaz debe reflejar decisiones ya tomadas.
¿Cómo construiría este tipo de flujo en AppMaster?Mapea los estados de excepción en la lógica de negocio antes de pulir la UI. En AppMaster, eso significa definir estados, campos requeridos, propiedad y ramas como rechazar, devolver para edición y aprobar con condiciones antes de diseñar pantallas.
¿Cómo puedo probar si mi ruta de excepción es lo bastante clara?Prueba un escenario real de principio a fin con números reales y uno o dos problemas, como un archivo faltante o una excepción de política. Si alguien nuevo no sabe qué hacer en menos de un minuto, el flujo sigue siendo demasiado vago.
¿Cuál es el siguiente paso práctico para implementar estas reglas?Mapea tus cinco excepciones principales, asigna un responsable para cada una y escribe el mensaje que debe ver el usuario. Si esas tres cosas están claras, la construcción suele ser mucho más sencilla.
10 mar 2026
10 min
08 mar 202611 min
07 mar 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
