Aprende a planificar, diseñar y construir una app web que recoja solicitudes internas, gestione aprobaciones, haga seguimiento de SLAs y reporte rendimiento de forma segura.
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”.
Las solicitudes internas suelen agruparse en unas pocas categorías:
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”).
Escribe los puntos de fallo actuales en lenguaje llano:
Esta lista será tu estrella del norte sobre qué debe arreglar la app.
Define tus usuarios principales y qué necesita cada uno:
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.
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.
Empleado (solicitante)
Los empleados deben poder enviar una solicitud en minutos y tener la confianza de que no desaparecerá.
Aprobador
Los aprobadores mantienen el gasto, los accesos y las decisiones de política bajo control.
Agente / Resolutor
Los agentes son quienes hacen el trabajo y comunican el progreso.
Admin
Los admins mantienen el sistema organizado y seguro.
Para cada tipo de solicitud, define:
Una tabla RACI simple en tu spec previene confusiones y facilita decisiones de flujo posteriores.
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.
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:
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.
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.
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.
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.
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.
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:
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.
Usa validación para evitar tickets vagos y datos faltantes:
Elige un ciclo de vida simple que los equipos no reinterpreten y define qué significa cada estado:
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.
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.
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?”).
Quienes procesan solicitudes necesitan una lista tipo bandeja que permita ordenar y hacer triage rápido. Incluye filtros que correspondan al trabajo real:
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.
La página de detalle es donde ocurre la colaboración. Debe combinar:
Mantén las acciones principales prominentes (aprobar/denegar, asignar, cambiar estado) y haz las acciones secundarias descubiertas pero no distractoras.
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.
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”.
Comienza con un camino de envío limpio que reduzca las idas y vueltas:
El triage evita que el sistema se convierta en un buzón compartido.
Las aprobaciones deben ser consistentes y basadas en políticas:
El escalado no es castigo; es una red de seguridad.
Bien hechos, estos flujos mantienen las solicitudes en movimiento y dan resultados predecibles y responsabilidad clara.
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.
Comienza con las tablas que tocarás en casi cada pantalla:
Mantén requests.status como un conjunto controlado de valores y almacena timestamps para reportes de ciclo de vida.
Para soportar distintos tipos sin crear tablas nuevas cada vez:
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:
Indexa requests(status, created_at), requests(assigned_team_id) y audit_events(request_id, created_at) para mantener rápidas las consultas comunes.
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.
Para la mayoría de solicitudes internas, las opciones “aburridas” ganan:
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.
/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.
Las solicitudes internas suelen incluir capturas, PDFs o documentos de RR.HH.
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:
Si comparas opciones, documenta criterios cortos—los mantenedores futuros lo agradecerán.
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.
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.
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).
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.
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.
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.
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”.
Empieza con un conjunto pequeño de notificaciones que impulsen la acción:
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.
Relaciona solicitudes con la estructura real mediante sincronización desde el proveedor de identidad (Okta, Azure AD, Google Workspace). Esto ayuda con:
Ejecuta la sincronización por horario y al iniciar sesión, y mantén un override admin simple para casos límite.
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.
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.
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.
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.
Los reportes no deben vivir solo en dashboards. Agentes y leads necesitan pantallas operativas que les ayuden a actuar:
Estas vistas convierten el seguimiento de SLA en trabajo práctico, no en una hoja mensual.
Usa un dashboard ligero para responder preguntas de gestión:
Haz gráficas clicables para que los líderes indaguen en las solicitudes detrás de los números.
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.
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.
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.
Enfoca las pruebas en los caminos que rompen la confianza:
Haz que UAT sea una checklist alineada a tus flujos clave: crear solicitud, editar/cancelar, aprobar/denegar, reasignar, cerrar y (si se permite) reabrir.
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.
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.
Empieza por elegir un alcance estrecho y de alto volumen (por ejemplo, solicitudes de acceso IT + reparaciones de Facilities). Documenta qué falla hoy (emails enterrados, propiedad poco clara, sin rastro de auditoría), define tus usuarios principales (solicitantes, aprobadores, agentes, administradores) y establece métricas de éxito medibles (como “cada solicitud tiene un responsable dentro de 1 hora hábil”).
La mayoría de las solicitudes internas caen en categorías repetibles:
Comienza con las categorías frecuentes y dolorosas, y amplía cuando los flujos estén estables.
Usa un conjunto pequeño y explícito de roles con permisos claros:
Añade una RACI simple en tu especificación para que la propiedad y las transferencias no queden ambiguas.
Enfócate en dificultar la presentación de tickets "malos":
Una entrada de mayor calidad reduce seguimientos y acelera el enrutamiento y las aprobaciones.
Haz el enrutamiento predecible y mínimo en v1:
Mantén sencillo el editor de reglas; la complejidad puede venir después al ver patrones reales.
Empieza con aprobación de un solo paso (manager o responsable de presupuesto) y solo exige aprobaciones donde la política lo requiera.
Para escalar:
Evita cadenas multi‑paso a menos que sean el tipo de solicitud principal desde el día uno.
Usa un ciclo de estados pequeño y compartido con significados claros, por ejemplo:
Documenta las reglas de transición (quién puede cambiar qué) y almacena un rastro de auditoría de cambios de estado, reasignaciones y aprobaciones para que las decisiones sean trazables.
Trátalo como tres pantallas centrales más una vista de detalle fuerte:
Incorpora accesibilidad desde el inicio (soporte de teclado, contraste, etiquetas para lectores de pantalla).
Un esquema práctico incluye:
Prioriza las bases empresariales:
users, roles, user_roles, teams, requests, comments, attachmentscategories, form_fields, request_field_valuesapprovals, sla_policiesaudit_eventsIndexa consultas comunes (como requests(status, created_at) y audit_events(request_id, created_at)) para que las colas y líneas de tiempo sigan rápidas.
Estas decisiones evitan rehacer trabajo cuando lleguen solicitudes de RR.HH./finanzas/seguridad.