Cómo crear una app web para solicitudes internas de servicio

Define el problema y los objetivos

Antes de diseñar pantallas o elegir stack tecnológico, aclara qué está resolviendo la app de solicitudes internas. La mayoría de los equipos ya tienen un “sistema”: está esparcido entre hilos de email, mensajes de chat, hojas de cálculo y conversaciones informales. Ese montaje oculta trabajo, crea solicitudes duplicadas y dificulta responder a una pregunta simple: “¿Quién se encarga y cuándo estará listo?”.

Empieza escribiendo una declaración del problema concisa y un objetivo v1, por ejemplo: “Proveer un único portal de solicitudes para empleados para acceso IT y reparaciones de Facilities con responsabilidad clara, aprobaciones cuando sean necesarias y visibilidad de SLA”.

Tipos de solicitudes comunes a soportar

Las solicitudes internas suelen agruparse en unas pocas categorías:

• IT: nuevo portátil, acceso a herramientas, restablecimiento de contraseñas, instalaciones de software
• RR.HH.: cartas laborales, preguntas sobre beneficios, tareas de onboarding
• Facilities: traslados de puesto, reparaciones, solicitudes de limpieza, problemas con salas de reuniones
• Finanzas: dudas sobre gastos, alta de proveedores, aprobaciones de compras
• Seguridad: acceso con tarjeta, reportes de incidentes, excepciones de política

No necesitas resolver todos los casos extremos el primer día, pero sí elegir un alcance inicial claro (por ejemplo: “acceso IT + reparaciones de Facilities”).

Qué está roto hoy (captura el dolor)

Escribe los puntos de fallo actuales en lenguaje llano:

• Las solicitudes se entierran en largos hilos de email
• Las hojas de cálculo quedan obsoletas en cuanto se comparten
• La responsabilidad no está clara, así que los empleados hacen seguimientos repetidos
• Las aprobaciones ocurren en mensajes privados, sin rastro de auditoría

Esta lista será tu estrella del norte sobre qué debe arreglar la app.

A quién sirve la app

Define tus usuarios principales y qué necesita cada uno:

• Empleados: un portal sencillo para enviar, rastrear y aclarar solicitudes
• Aprobadores: decisiones rápidas con contexto (y un registro del motivo)
• Agentes/fulfillers: una cola limpia, prioridades y traspasos
• Admins: configuración, reportes y aplicación de políticas

Métricas de éxito (hazlas medibles)

Fija objetivos que puedas seguir tras el lanzamiento: tiempo de resolución más rápido, menos seguimientos por ticket, mayor velocidad de primera respuesta y responsabilidad más clara (p. ej., “cada solicitud tiene un responsable dentro de 1 hora hábil”). Estas métricas guiarán decisiones de producto y te ayudarán a demostrar que la app funciona.

Mapea usuarios, roles y responsabilidades

Antes de diseñar pantallas o flujos, aclara quién usa la app y qué puede (y debe) hacer cada persona. La mayoría de los sistemas de solicitudes internas fallan porque los roles son difusos: la gente no sabe quién es responsable del siguiente paso y las solicitudes rebotan.

Roles de usuario centrales

Empleado (solicitante)

Los empleados deben poder enviar una solicitud en minutos y tener la confianza de que no desaparecerá.

• Enviar una solicitud en la categoría correcta (p. ej., IT, Facilities, People Ops)
• Adjuntar archivos (capturas, PDFs, fotos) y añadir contexto
• Consultar el estado y ver qué se necesita de su parte

Aprobador

Los aprobadores mantienen el gasto, los accesos y las decisiones de política bajo control.

• Revisar solicitudes asignadas a ellos
• Pedir cambios o detalles adicionales (sin rechazar prematuramente)
• Aprobar o denegar con un motivo claro y sello temporal

Agente / Resolutor

Los agentes son quienes hacen el trabajo y comunican el progreso.

• Triage: validar categoría, urgencia y completitud
• Trabajar la solicitud, hacer preguntas y publicar actualizaciones
• Cerrar la solicitud con notas de resolución (y una encuesta de satisfacción opcional)

Admin

Los admins mantienen el sistema organizado y seguro.

• Gestionar categorías, formularios y campos obligatorios
• Definir permisos (quién puede ver qué) y asignaciones de roles
• Configurar SLAs, horarios operativos y reglas de escalado

Haz la propiedad explícita

Para cada tipo de solicitud, define:

• Quién es responsable de la entrega final (equipo o persona)
• Quién aprueba (y cuándo se requiere aprobación)
• Quién puede reasignar o cambiar la prioridad
• Quién puede ver solicitudes sensibles (p. ej., RR.HH. o seguridad)

Una tabla RACI simple en tu spec previene confusiones y facilita decisiones de flujo posteriores.

Elige funciones centrales para v1

Un portal de solicitudes interno v1 debe hacer pocas cosas extremadamente bien: permitir que los empleados envíen solicitudes claras, llevarlas al equipo correcto rápidamente y mantener a todos informados hasta la finalización. Si intentas incluir cada caso extremo en el día uno, ralentizarás la entrega y aún así perderás lo que los usuarios realmente necesitan.

1) Envío de solicitudes (haz difícil enviar "malas" solicitudes)

Comienza con un pequeño conjunto de categorías (por ejemplo: Ayuda IT, Facilities, RR.HH., Compras). Cada categoría debe soportar campos dinámicos para que el formulario solo pregunte lo relevante.

Incluye:

• Básicos obligatorios: título, descripción, solicitado‑por, ubicación/departamento
• Campos por categoría (p. ej., “modelo de portátil”, “sistema de acceso”, “motivo de urgencia”)
• Adjuntos (capturas, PDFs) con límites de tamaño claros

2) Reglas de enrutamiento (llegar a la cola correcta)

Tu v1 necesita asignación predecible: por categoría, departamento, ubicación o reglas por palabras clave. Añade prioridad (baja/media/alta) y un único camino de escalado simple (p. ej., “sin asignar 24 horas” o “alta prioridad inactiva 4 horas”). Mantén el editor de reglas mínimo; siempre puedes hacerlo más flexible después.

3) Aprobaciones (solo donde sean necesarias)

Soporta aprobación de un solo paso primero (manager o responsable de presupuesto). Si las aprobaciones son críticas, añade aprobaciones condicionales (p. ej., “más de $500 requiere Finanzas”). Las cadenas multi‑paso pueden esperar a menos que sean tu tipo de solicitud principal.

4) Notificaciones (reduce el rastreo de estado)

Incluye notificaciones por email y en la app para: solicitud recibida, asignada, necesita info, aprobada/denegada, completada. Añade recordatorios para aprobadores y asignados en elementos vencidos.

5) Búsqueda + autoservicio ligero

Antes de enviar y en la lista de solicitudes, ofrece búsqueda con filtros (categoría, estado, solicitante). Añade “solicitudes similares” y enlaces a páginas de conocimiento para que los usuarios resuelvan problemas comunes sin abrir un ticket.

Diseña el modelo de datos de la solicitud

Un modelo de datos claro hace que todo lo demás sea más fácil: los formularios se mantienen consistentes, los flujos se pueden automatizar y los informes son confiables. Empieza por decidir qué es una “solicitud” en tu organización y qué detalles deben capturarse siempre.

Define los campos de intake

Mantén el formulario inicial ligero, pero lo suficientemente completo para que el equipo receptor actúe sin idas y vueltas. Una base práctica incluye:

• Título: resumen corto (“Reemplazo de portátil”)
• Descripción: qué se necesita, contexto, restricciones
• Categoría + subcategoría: dónde debe enrutar
• Urgencia/prioridad: cuán sensible es (aunque v1 use baja/media/alta)
• Información del solicitante: identidad, equipo/departamento, ubicación, método de contacto preferido

Estandariza categorías para reducir confusión

Las categorías deben reflejar cómo se organiza el trabajo (IT, Facilities, RR.HH., Finanzas), mientras que las subcategorías reflejan tipos de trabajo repetibles (por ejemplo, IT → “Solicitud de acceso”, “Hardware”, “Software”). Mantén los nombres amigables y evita duplicados (“Onboarding” vs “Configuración de nuevo empleado”).

Si las opciones de categoría crecen con el tiempo, versionalas en vez de renombrarlas silenciosamente—esto protege la reportabilidad y reduce la confusión.

Validación y valores por defecto que mejoran la calidad

Usa validación para evitar tickets vagos y datos faltantes:

• Exige una longitud mínima de descripción (o indicaciones guiadas como “¿Cuál es el objetivo?”)
• Proporciona valores por defecto (p. ej., urgencia por defecto a “Normal”)
• Autocompleta campos del solicitante desde tu directorio
• Muestra campos dinámicos solo cuando sean relevantes (p. ej., “Edificio” solo para Facilities)

Modelo de estado (y qué significa)

Elige un ciclo de vida simple que los equipos no reinterpreten y define qué significa cada estado:

• New → In Triage → Waiting for Info → Pending Approval → In Progress → Done
• Incluye Canceled para solicitudes retiradas o inválidas

Escribe las reglas de transición (¿quién puede mover a Pending Approval? ¿cuándo es permitido Waiting for Info?) y guarda un rastro de auditoría de cambios de estado, asignaciones, aprobaciones y ediciones clave.

Planifica la experiencia de usuario y las pantallas

Una app de solicitudes de servicio tiene éxito o fracasa en qué tan rápido los empleados pueden enviar una solicitud y qué tan fácil es para los equipos procesarla. Antes de construir, bosqueja las pantallas centrales y el “camino feliz” para cada rol: solicitante, aprobador y asignado.

1) Formulario de solicitud (envío)

Trata el formulario como un flujo guiado, no una página intimidante. Usa secciones paso a paso (o divulgación progresiva) para que los empleados solo vean lo que importa para la categoría elegida.

Muestra expectativas explícitas: qué información es obligatoria, tiempos típicos de respuesta y qué ocurre después del envío. Los tooltips y textos de ayuda pueden evitar idas y vueltas (“¿Qué cuenta como ‘urgente’?” “¿Qué archivos debo adjuntar?”).

2) Lista de solicitudes (inbox / cola)

Quienes procesan solicitudes necesitan una lista tipo bandeja que permita ordenar y hacer triage rápido. Incluye filtros que correspondan al trabajo real:

• Estado (new, waiting on requester, pending approval, in progress, done)
• Categoría (IT, Facilities, RR.HH., Finanzas, etc.)
• Asignado o equipo
• Rango de fechas (creación / vencimiento)

Diseña las filas para responder “¿qué es esto y qué debo hacer ahora?” de un vistazo: título, solicitante, prioridad, estado actual, indicador de vencimiento/SLA y próxima acción.

3) Página de detalle de la solicitud (fuente única de la verdad)

La página de detalle es donde ocurre la colaboración. Debe combinar:

• Una línea temporal de cambios de estado y aprobaciones (tu rastro de auditoría en lenguaje claro)
• Comentarios visibles para el solicitante
• Notas internas para contexto del personal
• Adjuntos con permisos claros (quién puede ver/descargar)

Mantén las acciones principales prominentes (aprobar/denegar, asignar, cambiar estado) y haz las acciones secundarias descubiertas pero no distractoras.

Fundamentos de accesibilidad (no lo postergues)

Planifica accesibilidad desde los primeros wireframes: navegación por teclado para todas las acciones, contraste de color suficiente (no dependas solo del color para estados) y etiquetas legibles que funcionen con lectores de pantalla.

Construye flujos de trabajo y lógica de aprobación

Los flujos convierten un simple “formulario + bandeja” en una experiencia de servicio predecible. Defínelos temprano para que las solicitudes no se queden estancadas, las aprobaciones no sean arbitrarias y todos sepan qué significa “hecho”.

Flujo de envío: crear → confirmar → rastrear

Comienza con un camino de envío limpio que reduzca las idas y vueltas:

• Crear: el empleado selecciona un tipo de solicitud y responde solo lo necesario.
• Confirmar: muestra un resumen con los detalles clave (categoría, urgencia, ubicación, adjuntos) antes de enviar.
• Rastrear: después del envío, proporciona un ID de solicitud, estado actual y el próximo paso esperado (p. ej., “triage en 4 horas”).

Flujo de triage: auto‑asignar → priorizar → clarificar

El triage evita que el sistema se convierta en un buzón compartido.

• Auto‑asignar según tipo, ubicación, departamento o rotación on‑call.
• Priorizar usando una regla clara (impacto × urgencia), no por impresión subjetiva.
• Clarificar moviendo a Waiting for Info con una plantilla de preguntas estructurada. No reinicies el reloj en silencio—regístralo.

Flujo de aprobación: quién aprueba qué y cuándo esquivar

Las aprobaciones deben ser consistentes y basadas en políticas:

• Define matrices de aprobación (p. ej., “Nueva compra de software > $200 requiere Manager + Finanzas”).
• Usa roles para que solo aprobadores autorizados puedan decidir en categorías específicas.
• Añade reglas de bypass para ítems de bajo riesgo (p. ej., restablecimiento de contraseña) o emergencias con razón explícita.
• Mantén siempre un rastro de auditoría: quién aprobó, cuándo, qué cambió y comentarios.

Flujo de escalado: avisos de SLA, traspasos, reasignaciones

El escalado no es castigo; es una red de seguridad.

• Envía avisos de SLA antes del incumplimiento (p. ej., al 75% del tiempo límite) al asignado y al líder de equipo.
• Soporta traspasos (cambio de turno) con transferencia de propiedad más una nota.
• Permite reasignaciones con códigos de motivo obligatorios, para detectar problemas de personal o enrutamiento.

Bien hechos, estos flujos mantienen las solicitudes en movimiento y dan resultados predecibles y responsabilidad clara.

Crea el esquema de la base de datos

Un buen esquema facilita el mantenimiento, el reporte y la evolución de la app. Apunta a un conjunto “core” limpio de tablas y añade tablas de soporte para flexibilidad y analítica.

Entidades core (la columna vertebral)

Comienza con las tablas que tocarás en casi cada pantalla:

• users: id, name, email, status, created_at
• roles: id, name (p. ej., Employee, Approver, Agent, Admin)
• user_roles: user_id, role_id (many‑to‑many)
• teams: id, name; más team_members (team_id, user_id)
• requests: id, requester_id, category_id, title, description, status, priority, assigned_team_id/assigned_user_id, created_at, updated_at, resolved_at
• comments: id, request_id, author_id, body, visibility (internal/public), created_at
• attachments: id, request_id, uploaded_by, file_name, storage_key, size, created_at

Mantén requests.status como un conjunto controlado de valores y almacena timestamps para reportes de ciclo de vida.

Entidades de soporte (estructura y flexibilidad)

Para soportar distintos tipos sin crear tablas nuevas cada vez:

• categories: id, name, default_team_id, active
• form_fields: id, category_id, key, label, type, required, sort_order
• request_field_values: request_id, field_id, value (a menudo text/JSON)
• approvals: id, request_id, step, approver_id, decision (pending/approved/rejected), decided_at
• sla_policies: id, category_id, priority, response_due_minutes, resolve_due_minutes

Eventos de auditoría y reporting

Para rastro de auditoría, crea audit_events con request_id, actor_id, event_type, old_value/new_value (JSON) y created_at. Registra cambios de estado, asignaciones y aprobaciones explícitamente.

Para reporting, puedes usar vistas (o tablas dedicadas más adelante) como:

• Tiempos de resolución y respuesta (seguimiento de SLA)
• Backlog por equipo/asignado
• Volumen por categoría y prioridad

Indexa requests(status, created_at), requests(assigned_team_id) y audit_events(request_id, created_at) para mantener rápidas las consultas comunes.

Elige un stack tecnológico y arquitectura

Una app de solicitudes tiene éxito cuando es fácil de cambiar. Tu primera versión evolucionará conforme los equipos añadan nuevos tipos, pasos de aprobación y reglas de SLA—así que elige tecnología que tu equipo pueda mantener, no solo lo más trendy.

Empieza con lo que tu equipo ya conoce

Para la mayoría de solicitudes internas, las opciones “aburridas” ganan:

• Frontend: React o Vue con una librería de componentes (Material UI, Ant Design, Vuetify). Acelera formularios, tablas y modales—ideal para un portal de empleados.
• Backend: Node/Express, Django, Rails o .NET. Elige lo que tu equipo ya domina para construir la lógica de automatización y ticketing más rápido y con menos sorpresas.

Si quieres avanzar aún más rápido (especialmente para una herramienta interna), considera generar una base funcional con Koder.ai. Es una plataforma donde describes el portal en chat y se itera en características (formularios, colas, aprobaciones, notificaciones) con flujos basados en agentes. Koder.ai suele apuntar a React en frontend y Go + PostgreSQL en backend, soporta exportación de código, despliegue/hosting, dominios personalizados e incluye snapshots con rollback—útil cuando afinas automatizaciones de flujo. Los planes van de Free, Pro, Business a Enterprise, por lo que puedes pilotar antes de comprometerte.

Estilo de API y forma de la app

• Estilo API: Usa REST para endpoints sencillos como /requests, /approvals y /attachments. Considera GraphQL solo si la UI necesita muchas vistas flexibles del mismo dato y estás listo para más complejidad.

Para arquitectura, un monolito modular suele ser ideal para v1: una única app desplegable con módulos bien separados (requests, approvals, notifications, reporting). Es más sencillo que microservicios y mantiene límites claros.

Archivos, adjuntos y seguridad básica

Las solicitudes internas suelen incluir capturas, PDFs o documentos de RR.HH.

• Almacenamiento de archivos: usa object storage (compatible con S3) con signed URLs para que la app no sirva archivos directamente desde el backend.
• Añade escaneo antivirus si la política lo exige, especialmente para adjuntos ingeridos por email.

Opciones prácticas de despliegue

Containerizar (Docker) mantiene los entornos consistentes. Para hosting, elige una plataforma gestionada que tu organización ya use (PaaS o Kubernetes). Sea lo que sea, asegúrate de que soporte:

• Control de acceso por roles y rastro de auditoría
• Migraciones de base de datos para formularios que evolucionan
• Observabilidad (logs + métricas) para diagnosticar flujos de aprobación lentos

Si comparas opciones, documenta criterios cortos—los mantenedores futuros lo agradecerán.

Seguridad, privacidad y aspectos de cumplimiento

La seguridad no es una tarea “para después”. Aunque solo la usen empleados, la app manejará datos de identidad, detalles de solicitudes y a veces adjuntos sensibles (RR.HH., finanzas, accesos IT). Unos fundamentos tempranos evitarán rework doloroso.

Autenticación: usa el proveedor de identidad de la empresa

Prefiere Single Sign‑On (SSO) vía SAML u OIDC para que los empleados usen su cuenta corporativa y evites almacenar contraseñas. Si la org usa un directorio (Entra ID/Active Directory/Google Workspace), intégralo para actualizaciones automáticas de joiner/mover/leaver.

Autorización: define quién puede ver qué

Haz el acceso explícito con control por roles (RBAC): solicitantes, aprobadores, agentes y admins. Añade visibilidad por equipo para que un grupo de soporte vea solo las solicitudes asignadas a ellos, mientras los empleados vean solo las propias (y, opcionalmente, las de su departamento).

Protege datos en tránsito y en reposo

Usa HTTPS en todo (encriptación en tránsito). Para datos almacenados, encripta campos sensibles y archivos si procede, y mantiene credenciales fuera del código. Usa un gestor de secretos (store en la nube o vault) y rota claves regularmente.

Rastro de auditoría: prueba lo que pasó

Para aprobaciones, cambios de acceso o solicitudes relacionadas con nómina, mantén un rastro de auditoría inmutable: quién vio, creó, editó, aprobó y cuándo. Trata los logs de auditoría como append‑only y restringe su acceso.

Reducir abuso y vulnerabilidades comunes

Añade limitación de tasa a login y endpoints claves, valida y sanea entradas, y protege uploads (chequeo de tipo, límites de tamaño, escaneo de malware si se requiere). Estos básicos mantienen el sistema fiable ante errores y uso indebido.

Integraciones y notificaciones

Una app de solicitudes solo funciona si la gente ve las solicitudes y actúa. Las integraciones hacen que el portal encaje en las rutinas diarias en vez de convertirse en “otra pestaña más”.

Notificaciones por email y chat

Empieza con un conjunto pequeño de notificaciones que impulsen la acción:

• Asignación: avisar al asignado (y opcionalmente a su backup) cuando se le asigna una solicitud.
• Comentarios y menciones: notificar a participantes cuando alguien responde o lo @menciona.
• Aprobaciones: alertar a aprobadores con un CTA claro para aprobar/denegar.
• Riesgo de SLA: avisar a responsables cuando un ticket se aproxima al incumplimiento y escalar si pasa.

Mantén los mensajes cortos e incluye enlaces profundos a la solicitud. Si la org usa Slack o Teams, envía notificaciones allí, pero sigue soportando email para auditabilidad y usuarios fuera del chat.

Sincronización de directorio (usuarios, departamentos, managers)

Relaciona solicitudes con la estructura real mediante sincronización desde el proveedor de identidad (Okta, Azure AD, Google Workspace). Esto ayuda con:

• Auto‑enrutamiento por departamento o ubicación
• Aprobaciones por manager (usa el campo manager en vez de aprobadores codificados)
• Acceso basado en roles que se mantiene al moverse la gente

Ejecuta la sincronización por horario y al iniciar sesión, y mantén un override admin simple para casos límite.

Hooks de calendario (opcional)

Si las solicitudes implican visitas onsite, entrevistas o entrega de equipo, añade integración con calendario para proponer franjas y crear eventos una vez aprobados. Trata los eventos de calendario como derivados de la solicitud; la solicitud sigue siendo la fuente de la verdad.

Enlaza con herramientas relacionadas

Si estás decidiendo entre construir o comprar, compara tus necesidades de integración contra una opción empaquetada en /pricing, o consigue contexto sobre patrones comunes en /blog/it-service-desk-basics.

Reportes, SLAs y seguimiento de desempeño

Si la app no mide desempeño, no puede mejorarlo. El reporting te permite detectar cuellos de botella, justificar plantilla y demostrar fiabilidad al negocio.

Define SLAs que reflejen la realidad

Empieza con un pequeño conjunto de métricas SLA que todos entiendan.

Tiempo de primera respuesta: tiempo desde el envío hasta el primer contacto humano (un comentario, petición de aclaración, asignación o actualización de estado). Es útil para gestionar expectativas y reducir “¿alguien vio esto?”.

Tiempo de resolución: tiempo desde la creación hasta la finalización. Refleja la entrega end‑to‑end.

Haz reglas de SLA explícitas por categoría y prioridad (p. ej., “Solicitudes de acceso: primera respuesta en 4 horas hábiles, resolución en 2 días hábiles”). Decide también qué pausa el reloj—espera del solicitante, aprobaciones externas o información faltante.

Vistas operativas para el día a día

Los reportes no deben vivir solo en dashboards. Agentes y leads necesitan pantallas operativas que les ayuden a actuar:

• Cola del agente: “mis tickets” con próximas acciones, tiempos de vencimiento y quién espera más
• Backlog del equipo: agrupado por categoría/prioridad con señales de capacidad (cuántos abiertos por agente)
• Tickets envejecidos: ordenados por tiempo abierto y riesgo de SLA (aproximándose a incumplimiento, incumplidos)

Estas vistas convierten el seguimiento de SLA en trabajo práctico, no en una hoja mensual.

Dashboards para tendencias y cuellos de botella

Usa un dashboard ligero para responder preguntas de gestión:

• Tendencias de volumen en el tiempo (semanal/mensual)
• Categorías principales y origen de las solicitudes
• Cuellos de botella: pasos o aprobaciones donde más tiempo se acumula

Haz gráficas clicables para que los líderes indaguen en las solicitudes detrás de los números.

Exportación y compartición

Aunque la UI sea buena, algunos interesados querrán análisis offline. Ofrece exportaciones CSV para listas filtradas (por equipo, categoría, rango de fechas, estado de SLA) para que finanzas, operaciones o auditores trabajen sin necesidad de acceso admin.

Plan de lanzamiento, pruebas e iteración

Un buen lanzamiento es menos un gran anuncio y más un aprendizaje controlado. Trata v1 como un producto de trabajo que mejorarás rápido, no como un sistema final.

MVP rollout: comienza pequeño y expande

Pilota con un departamento (o tipo de solicitud) donde el volumen sea significativo pero el riesgo manejable—ej.: solicitudes de acceso IT o reparaciones Facilities. Define criterios de éxito para el piloto: tiempo de envío a resolución, tasa de completado y frecuencia de correcciones manuales.

Una vez estable el piloto, expande por olas: más departamentos, más formularios, luego más automatización. Mantén una página simple de “qué cambió” o notas de versión dentro de la app para que los usuarios no se sorprendan.

Pruebas que reflejen flujos reales

Enfoca las pruebas en los caminos que rompen la confianza:

• Tests unitarios para reglas de validación (campos obligatorios, adjuntos, reglas de fecha).
• Tests de integración para flujos (enrutamiento, aprobaciones, notificaciones, timers de SLA).
• UAT con solicitantes y aprobadores reales usando escenarios realistas.

Haz que UAT sea una checklist alineada a tus flujos clave: crear solicitud, editar/cancelar, aprobar/denegar, reasignar, cerrar y (si se permite) reabrir.

Plan de migración: no pierdas el pasado

Si las solicitudes viven en hojas o email, decide qué importar (items abiertos, últimos 90 días o historial completo). Importa al menos: solicitante, categoría, timestamps, estado actual y notas necesarias para continuidad. Etiqueta los items migrados en el rastro de auditoría.

Crea un bucle de feedback accionable

Añade una encuesta in‑app en solicitudes cerradas (“¿Se resolvió esto?” y “¿Problemas con el formulario?”). Haz una revisión corta semanal con stakeholders para priorizar feedback y luego groom del backlog con prioridades claras: fiabilidad primero, usabilidad segundo, nuevas funciones al final.