Caso Zorro. Cómo ordenar una app interna de solicitudes
- Salvador Ordóñez Toledo
- hace 1 día
- 5 min de lectura
Una empresa puede digitalizar sus formularios y conservar intacto el desorden. Antes de diseñar la interfaz, necesita definir quién solicita, quién decide, quién ejecuta y qué sucede en cada etapa.
Caso metodológico construido a partir de problemas recurrentes en organizaciones que administran solicitudes mediante correos, mensajes y hojas de cálculo.
El encargo parecía sencillo
La petición inicial podía resumirse así: “Necesitamos una app para que el personal envíe solicitudes y consulte su avance”.
En apariencia, el proyecto requería un formulario, una bandeja de entrada y algunas notificaciones. Sin embargo, detrás de esa lista existía una operación fragmentada. Las solicitudes llegaban por correo electrónico, WhatsApp, llamadas y conversaciones de pasillo. Algunas se registraban en una hoja de cálculo; otras dependían de que alguien recordara atenderlas.
Cada área entendía de manera distinta qué significaba recibir, aprobar, atender o cerrar una petición. Tampoco existía un criterio común para establecer prioridades, asignar responsables o comprobar que el trabajo había concluido.
"Una app interna no corrige un proceso confuso: lo vuelve más rápido, más visible y más costoso de cambiar."
Por eso, el primer paso no fue diseñar pantallas. Fue reconstruir la operación.
Antes de la interfaz, el proceso
El diagnóstico comenzó identificando los canales utilizados para pedir soporte, mantenimiento, compras, materiales o autorizaciones. Después se trazó el recorrido completo: desde que una persona detectaba una necesidad hasta que recibía una respuesta y confirmaba su solución.
El ejercicio mostró los puntos críticos. Los solicitantes no sabían qué información debían entregar; los responsables recibían peticiones incompletas; los supervisores aprobaban sin suficiente contexto, y el equipo operativo perdía tiempo tratando de averiguar quién debía atender cada caso. La dirección, por su parte, carecía de datos confiables sobre cargas de trabajo, atrasos o solicitudes recurrentes.
Este enfoque coincide con el manual de servicios de GOV.UK: antes de comprometer recursos para construir un servicio digital, es necesario comprender el problema, su contexto y las necesidades de los usuarios.
La aplicación debía diseñarse como parte de un servicio completo, no como una colección de formularios.
Definir qué significa “solicitud”
La palabra parecía suficientemente clara hasta que intentamos convertirla en información estructurada. ¿Todas las solicitudes necesitaban autorización? ¿Quién podía declararlas urgentes? ¿Qué debía ocurrir cuando faltaban datos? ¿Quién confirmaría que una petición estaba resuelta?
Las respuestas permitieron definir el elemento central del producto. Cada registro debía incluir categoría, descripción, área solicitante, fecha, prioridad, responsable, archivos adjuntos, condiciones de aprobación e historial de movimientos.
También se definió un ciclo de vida con rutas condicionales. Algunas peticiones podían pasar directamente de revisión a asignación; otras requerían una o varias autorizaciones. Los estados —enviada, pendiente de información, aprobada, asignada, en proceso, resuelta, rechazada o cancelada— quedaron vinculados con responsables, acciones permitidas y reglas de transición.
"La interfaz empezó a ordenarse cuando cada estado dejó de ser una etiqueta y se convirtió en una responsabilidad."
Así se evitó uno de los errores más frecuentes en las aplicaciones internas: construir una bandeja llena de registros sin explicar qué debe hacer cada persona con ellos.
Diseñar por roles, no por pantallas
El sistema necesitaba experiencias diferentes para cinco roles: solicitante, supervisor, coordinador, responsable de ejecución y administrador.
El solicitante requería un formulario adaptado al tipo de petición, confirmación de envío, número de seguimiento y una vista clara del avance. El supervisor debía revisar el contexto y decidir si aprobaba, rechazaba o pedía información. El coordinador necesitaba clasificar y asignar; el responsable operativo, documentar avances y evidencias; el administrador, gestionar categorías, permisos y reglas.
Esta estructura redujo el ruido. Cada persona vería la información y las acciones relacionadas con su responsabilidad, en lugar de navegar por una plataforma organizada según la estructura administrativa de la empresa.
Las reglas de negocio también se documentaron antes de diseñar la solución final: qué solicitudes requerían autorización, qué condiciones activaban una segunda aprobación, cómo se establecía la prioridad, cuándo podía reasignarse un caso y quién tenía permiso para cerrarlo.
Los entregables incluyeron el mapa del proceso actual, la matriz de roles y permisos, el flujo futuro, la arquitectura de información, los esquemas funcionales de las pantallas, un prototipo navegable y una lista priorizada de funcionalidades para desarrollo.
Un MVP para recuperar el control
El producto mínimo viable no tenía que automatizar toda la organización. Su objetivo era establecer una fuente única y confiable para recibir, revisar, aprobar, asignar y rastrear solicitudes.
El alcance prioritario contempló acceso autenticado, formulario dinámico, generación de folio, seguimiento por estado, aprobaciones condicionales, asignación de responsables, historial de actividad, comentarios, archivos adjuntos y notificaciones esenciales.
Las integraciones con otros sistemas, los tableros avanzados, las reglas automáticas y una aplicación móvil nativa quedaron fuera de la primera etapa. La prioridad era comprobar que el flujo central pudiera completarse sin regresar al correo, WhatsApp o la hoja de cálculo.
El prototipo permitiría validar tareas concretas con cada rol antes de programar: registrar una petición, solicitar información, autorizarla, asignarla, documentar su ejecución y confirmar el cierre. Los aprendizajes se incorporarían a la documentación funcional que recibiría el equipo de desarrollo.
Lo que todavía falta resolver
El diseño no elimina automáticamente todas las incertidumbres. Antes de iniciar el desarrollo sería necesario validar el prototipo con usuarios reales, definir los tiempos comprometidos de atención, revisar accesibilidad y protección de datos, establecer políticas para conservar evidencias y confirmar las integraciones con los sistemas existentes.
También deberían acordarse las métricas de éxito: tiempo promedio de atención, porcentaje de solicitudes vencidas, casos devueltos por información incompleta, reincidencias y nivel de adopción. Sin una línea base y mediciones posteriores, no sería responsable prometer resultados cuantitativos.
Una operación que puede explicarse
El resultado más importante del ejercicio no fue una colección de pantallas atractivas, sino una operación que podía entenderse, probarse y entregarse a desarrollo.
La empresa tendría claridad sobre los datos necesarios, las decisiones humanas, los permisos, las excepciones y los indicadores que debía observar. El equipo técnico recibiría un alcance más preciso y los usuarios comprenderían qué se esperaba de ellos en cada momento.
Este Caso Zorro demuestra que diseñar una herramienta interna no consiste en trasladar un formulario a una pantalla. Consiste en transformar una operación dispersa en un sistema comprensible, trazable y preparado para evolucionar.
¿En tu organización las solicitudes todavía dependen de mensajes, hojas de cálculo y personas que recuerdan lo que falta? ¿Tu idea necesita más claridad antes de convertirse en código? En Sr. Zorro App Design Studio te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo.
Escrito por: Editorial
Fuentes consultadas
GOV.UK Service Manual — How the discovery phase works. Explica la importancia de comprender el problema y las necesidades de los usuarios antes de construir un servicio.
GOV.UK Service Manual — User research in discovery. Recomienda estudiar el servicio de principio a fin, incluidos los canales, herramientas, soporte y pasos fuera del sistema.
Nielsen Norman Group — UX Mapping Methods Compared. Describe el uso de mapas de experiencia y service blueprints para representar personas, procesos y puntos de contacto.
Nielsen Norman Group — Mapping User Stories in Agile. Explica cómo el mapeo de historias conecta las necesidades del usuario con la priorización del desarrollo.
Microsoft Learn — Business process flows overview. Documenta cómo los flujos de negocio guían a distintos roles a través de procesos definidos.
Microsoft Learn — Create and test an approval workflow. Presenta la estructura de flujos de aprobación aplicables a documentos, solicitudes y procesos internos.
Comentarios