Diseño de sistema de solicitudes de tiempo libre simplificado: define políticas, gestiona cálculos de acumulación, enruta aprobaciones de managers y mantiene calendarios precisos sin flujos confusos.
La gente espera que pedir tiempo libre sea como reservar una reunión: elegir fechas, ver tu saldo, recibir un sí o un no claro y que aparezca donde debe. Cuando no funciona así, los equipos vuelven al “mándamelo por mensaje” y el sistema se convierte en una tarea de registro en lugar de una herramienta fiable.
Las solicitudes suelen atascarse en los traspasos: un hilo de correo que no llega al manager correcto, una hoja de cálculo que nadie actualiza o una aprobación por chat imposible de auditar después. El empleado piensa que está cubierto, el manager cree que RR.HH. lo manejará y RR.HH. lo descubre en nómina cuando el saldo está mal.
El objetivo real del diseño del sistema de solicitudes de tiempo libre es aburrido pero importante: saldos correctos, aprobaciones claras y una sola fuente de verdad. Si tu saldo es correcto pero las aprobaciones no están claras, los managers seguirán preguntando “¿Ya aprobé esto?” Si las aprobaciones son perfectas pero el calendario está mal, los equipos seguirán duplicando reservas.
Cuatro grupos dependen del mismo flujo, pero por razones diferentes:
Un “flujo legible” significa que puedes mirar los pasos y explicarlos en lenguaje claro: qué dispara la solicitud, quién aprueba, qué sucede en caso de rechazo y qué se escribe de vuelta (saldo, estado, calendario). Si no puedes explicarlo rápido, la gente lo eludirá.
Herramientas como AppMaster pueden ayudar manteniendo la lógica visual y centralizada, para que los cambios de política no se conviertan en un laberinto de correos y excepciones.
Una buena herramienta de tiempo libre es, sobre todo, un conjunto limpio de registros y unas pocas relaciones claras. Si aciertas lo básico, el resto del diseño del sistema de solicitudes de tiempo libre se mantiene legible, incluso cuando las políticas y aprobaciones crecen.
Empieza con un pequeño conjunto de objetos centrales que puedas explicar en un minuto:
Para las solicitudes, los campos que previenen dolores del mundo real no son sofisticados. Son específicos. Guarda fecha/hora de inicio y fin, si es un día parcial y la zona horaria del empleado al momento de la solicitud. Añade una razón corta y permite adjuntos si el proceso de RR.HH. necesita pruebas (por ejemplo, una nota médica). Mantén los adjuntos opcionales para no bloquear el PTO normal.
Los estados deben ser pocos y predecibles: borrador (guardado pero no enviado), enviado, aprobado, rechazado y cancelado. Evita estados extra como “pendiente RR.HH.” salvo que realmente los necesites.
No te saltes la pista de auditoría. Incluso un mínimo “quién cambió qué y cuándo” te salva en disputas. Como mínimo, registra envío, aprobación, rechazo, cancelación y cualquier edición de fechas.
Para equipos, ubicaciones y departamentos, trátalos como datos de referencia separados. Enlaza empleados a estos grupos y enlaza políticas a los grupos a los que aplican. Así, cuando alguien cambia de oficina, actualizas un registro de empleado, no cada política.
Si lo construyes en AppMaster, mantén cada objeto simple al principio y añade validaciones y pasos de flujo una vez que los datos sean estables.
Las buenas políticas son aburridas a propósito. La gente debería poder predecir el resultado antes de hacer clic en Enviar. En el diseño del sistema de solicitudes de tiempo libre, la forma más rápida de perder confianza es cuando la misma solicitud se aprueba una semana y se rechaza la siguiente.
Empieza por nombrar tus tipos de permiso y escribir una frase en lenguaje sencillo para cada uno. Vacaciones o PTO es tiempo planificado fuera. Baja por enfermedad es tiempo no planificado relacionado con la salud. Permiso sin sueldo es tiempo sin pago. La licencia parental suele tener fechas y documentos especiales. El tiempo compensatorio (comp time) se gana por horas extra y se gasta como PTO.
Las reglas de elegibilidad deben leerse como una lista de verificación, no como un documento legal. Sé explícito: quién puede usarlo (tiempo completo, medio tiempo, contratistas), cuándo comienza (tras el periodo de prueba, después de X días) y si depende de la antigüedad. Si una regla tiene excepciones, escríbelas como su propia regla, no como una nota al pie.
Las reglas de solicitud son donde normalmente empieza la confusión. Sé específico sobre períodos de aviso, fechas bloqueadas y la unidad mínima permitida. Por ejemplo: “Las solicitudes de vacaciones deben presentarse con 5 días hábiles de antelación, excepto emergencias aprobadas por RR.HH.” es comprobable. “Presentar con antelación” no lo es.
Las reglas de acumulación y expiración deben caber en una frase. Ejemplo: “Hasta 40 horas se trasladan al siguiente año y expiran el 31 de marzo.” Si necesitas una segunda frase, es una señal de que la política está haciendo demasiado.
Una forma simple de mantener el texto de la política y la lógica de las reglas sincronizados:
Ejemplo: un empleado en periodo de prueba solicita 2 horas de PTO para mañana. El sistema debería bloquearlo por dos razones fáciles de leer: “PTO comienza después de 60 días” y “PTO requiere 5 días hábiles de aviso.” Si lo construyes en AppMaster, mantiene esos mensajes cerca de los nodos de regla para que las actualizaciones no se separen con el tiempo.
La acumulación es donde el diseño del sistema de solicitudes de tiempo libre suele volverse enrevesado, porque las reglas pequeñas se suman. El objetivo no es matemática sofisticada. El objetivo es resultados predecibles que coincidan con lo que RR.HH. y los empleados esperan cuando consultan un saldo.
Una confusión común es mezclar estilos de acumulación. Algunas empresas añaden horas cada periodo de pago, otras mensual, algunas acumulan por hora trabajada y otras otorgan el monto anual completo en una fecha fija. Los problemas empiezan cuando solo almacenas “saldo” y olvidas “cómo se ganó”. Mantén un registro claro de eventos: concesión, acumulación, ajuste y uso.
La prorrata es otra trampa. Un nuevo empleado que empieza a mitad de mes o un empleado que pasa de medio tiempo a tiempo completo no debería necesitar una hoja de cálculo manual. Decide una regla y cúmplela. Por ejemplo: prorratear por días del calendario en el periodo o por horas programadas. La que elijas, escríbela en palabras sencillas y codifícala igual en todas partes.
Los topes y saldos negativos causan tickets de “parece que está mal”. Si permites traslado hasta un tope, aplica el tope en un momento específico (fin de año, fin del periodo de acumulación o después de cada acumulación). Si se permiten saldos negativos, define el límite y qué pasa en la terminación.
Las reglas de redondeo crean deriva silenciosa. Elige un nivel de redondeo (minutos, cuartos de hora o medios días) y aplícalo consistentemente tanto a la acumulación como al uso. Si acumulas en minutos pero las solicitudes son en medios días, los empleados sentirán que el sistema está desajustado.
Las solicitudes con fecha retroactiva y las correcciones necesitan pista de auditoría. Si alguien presenta una solicitud para la semana pasada, el sistema debería recalcular desde la fecha de la solicitud hacia adelante y registrar el cambio.
Una lista de verificación simple que previene la mayoría de disputas:
En AppMaster, esto suele mapearse limpiamente a una tabla de Transactions más un pequeño proceso de negocio que recompone saldos cuando se aprueba o corrige una solicitud.
Un flujo de aprobación de manager debe responder una pregunta: ¿quién puede decir “sí” con confianza? Si intentas modelar cada detalle del organigrama, el diseño del sistema de solicitudes de tiempo libre se vuelve difícil de leer y aún más difícil de arreglar.
Empieza con una regla por defecto: aprueba el manager directo del empleado. Luego añade solo las excepciones que cambian el riesgo o la responsabilidad. Mantén el orden de las reglas explícito, para que puedas explicar resultados sin hurgar en la configuración.
La mayoría de los equipos pueden usar un paso de aprobación único para PTO estándar. Añade pasos solo cuando la solicitud afecta nómina, cumplimiento o la cobertura entre equipos.
Patrones comunes que se mantienen legibles:
Las aprobaciones fallan cuando el aprobador está fuera. Haz de la delegación una regla de primera clase, no una solución manual. Si el manager está marcado como fuera de la oficina, enruta al delegado; si no hay delegado, enruta al manager del manager (o a RR.HH. como recurso). Registra siempre qué regla eligió al aprobador.
Los rechazos y las ediciones son donde los sistemas se vuelven enrevesados. Manténlo simple: un rechazo cierra la solicitud con una razón obligatoria. Si el empleado edita fechas o tipo de permiso, trátalo como un reenvío y vuelve a ejecutar el enrutamiento desde cero. Eso previene solicitudes “medio aprobadas” que ya no coinciden con lo que fue aprobado.
Un ejemplo práctico: Alex solicita 3 días de baja por enfermedad. El sistema lo enruta al manager, pero como es un tipo de permiso controlado por política, RR.HH. recibe un segundo paso solo después de la aprobación del manager. Si el manager está fuera, el delegado aprueba y la pista de auditoría muestra por qué.
Si lo construyes en AppMaster, mantén la lógica de enrutamiento en un único proceso visual con un pequeño conjunto de reglas en orden claro, para que cualquiera pueda leerlo y mantenerlo.
Una buena validación mantiene legible el diseño del sistema de solicitudes de tiempo libre porque evita que los casos especiales se filtren a las aprobaciones. Apunta a reglas fáciles de explicar y de probar.
Empieza con reglas de reserva. Las comprobaciones de solapamiento deben detectar conflictos con permisos aprobados y solicitudes pendientes. Sé explícito sobre días parciales: guarda la fecha más una unidad simple como AM, PM o horas para que los medios días no se conviertan por error en días completos. También decide qué hacer con fines de semana y festivos: bloquearlos o permitirlos pero ignorarlos en el recuento de días.
Las comprobaciones de saldo son más complicadas de lo que parecen. Muchos equipos validan el saldo al enviar (para que no se acumulen envíos) y lo vuelven a verificar al aprobar (porque las acumulaciones u otras aprobaciones pueden cambiar el saldo). Si haces ambas cosas, muestra al usuario en qué punto falló.
Aquí hay un conjunto limpio de validaciones que cubre la mayoría de los casos:
Las comprobaciones de cobertura del equipo pueden ayudar, pero evita bloqueos rígidos salvo que sea imprescindible. Un mejor predeterminado es una advertencia que deje decidir al manager. Ejemplo: “Dos personas de tu equipo ya están fuera ese día. ¿Enviar igual?”
Haz que los mensajes de error sean justos y solucionables. Indica a los usuarios qué falló, dónde y cómo corregirlo. Por ejemplo: “Tu solicitud se solapa con un PTO aprobado el 12 de mar (PM). Elige otro horario o edita la solicitud existente.”
Si lo construyes en AppMaster, mantén las validaciones cerca del formulario de solicitud y reutiliza las mismas comprobaciones en el paso de aprobación, para que las reglas no se desvíen con el tiempo.
Un buen diseño del sistema de solicitudes de tiempo libre se siente aburrido en el mejor sentido: cada solicitud sigue el mismo camino y cada decisión tiene una razón clara. La forma más sencilla de mantenerlo legible es separar los datos de política (qué reglas hay) de la lógica de flujo (qué sucede cuando alguien pulsa Enviar).
Aquí tienes una secuencia que permanece simple incluso si añades más tipos de permiso después:
Mantén el flujo legible registrando cada decisión en lenguaje claro (por ejemplo: “Rechazado: se solapa con permiso aprobado existente”). Si usas una herramienta visual de flujo como el Business Process Editor de AppMaster, etiqueta los pasos tal y como los leería una persona.
Antes del lanzamiento, prueba con escenarios reales: solicitudes con fecha retroactiva, manager de vacaciones, cambio de política a mitad de año y una edición después de la aprobación. Si el resultado sorprende a RR.HH., la regla aún no es lo bastante clara.
Un calendario debe responder una pregunta rápido: quién está fuera y cuándo. No intentes convertir el evento de calendario en todo el registro de la solicitud. Pon solo lo que ayuda a la programación y guarda el resto dentro de tu sistema de RR.HH.
Para el contenido del evento, manténlo consistente. Un buen predeterminado es un título corto como “Fuera de la oficina - Alex Kim” más el tipo de permiso si importa (“PTO”, “Enfermedad”). Mantén los detalles mínimos por privacidad. Muchos equipos prefieren mostrar el evento como “Ocupado” y almacenar razones, saldos y notas solo en la solicitud.
Cada solicitud necesita un ID interno estable y cada evento de calendario debería almacenar ese ID (por ejemplo en un campo personalizado o en la descripción). Así puedes crear, actualizar y eliminar con seguridad el evento correcto cuando las solicitudes cambien.
Manejar el estado es donde los sistemas se desvían. Decide de antemano si las solicitudes tentativas aparecen o no. Si las muestras, haz la diferencia obvia (por ejemplo, prefijo en el título “Pendiente” y una configuración de disponibilidad distinta). Cuando una solicitud está aprobada, actualiza el mismo evento en lugar de crear uno nuevo. Si una solicitud se cancela o rechaza después de ser visible, elimina el evento para que los calendarios no mientan.
Las zonas horarias atacan con fuerza en permisos de día completo y de medio día. Guarda inicio y fin como marcas de tiempo exactas en la zona horaria local del empleado y guarda también esa zona horaria en la solicitud.
Usa eventos de todo el día solo para permisos realmente de día completo. Para medios días, crea eventos con horario (por ejemplo 13:00-17:00) para que colegas en otras zonas vean la superposición correcta.
Si la sincronización de calendario falla, no lo ocultes. Encola el trabajo, reintenta con backoff y muestra un estado claro “Calendario no actualizado” con una acción manual de “reintentar sincronización”. En herramientas como AppMaster, esto suele ser un proceso en segundo plano más una pantalla de admin que lista intentos de sincronía fallidos para que RR.HH. pueda arreglar problemas sin editar solicitudes.
La mayoría de fallos en el diseño del sistema de solicitudes de tiempo libre ocurren cuando las reglas crecen en silencio con el tiempo. El sistema aún “funciona”, pero nadie confía en los saldos y cada caso raro se convierte en un ticket de soporte.
Si la acumulación se divide en muchos casos especiales (nuevos empleados, traslado, permiso sin sueldo, medio tiempo), la gente no puede predecir su saldo.
Mantén un modelo de acumulación claro por tipo de permiso y añade excepciones como reglas nombradas y comprobables. Escribe algunos empleados de ejemplo y saldos esperados para fechas específicas y vuelve a comprobarlos cuando cambien las políticas.
Aprobaciones con ramificaciones infinitas son imposibles de probar y los managers no saben por qué una solicitud fue a otra persona.
Un patrón más seguro es:
El texto de la política es para humanos (qué cuenta, quién es elegible). Las reglas matemáticas son para el sistema (tasa, topes, redondeo, traslado). Guárdalos separados para poder actualizar la redacción sin cambiar cálculos y probar cálculos sin reescribir el manual.
Si sobrescribes solicitudes, pierdes el “por qué” detrás de un cambio de saldo.
Siempre guarda una pista de auditoría: quién cambió qué, cuándo y los valores previos. En AppMaster, esto es sencillo de modelar como una tabla de historial de solicitudes más las transiciones de estado en un Business Process.
El tiempo libre abarca fechas, pero las aprobaciones y las entradas de calendario usan marcas de tiempo. Normaliza a una “zona horaria de política” y guarda también la zona horaria local del empleado. También decide pronto si los festivos públicos reducen los días solicitados y aplica esa regla de forma consistente.
Antes de anunciarlo a todos, pasa por un conjunto corto de comprobaciones con un empleado real, un manager y alguien de RR.HH. Quieres confirmar que el sistema se siente obvio, no solo que funciona.
Usa esta lista como puerta de go/no-go para tu diseño del sistema de solicitudes de tiempo libre:
Una prueba práctica: crea una solicitud, apruébala, edita las fechas y luego cancélala. Si algún paso deja un saldo equivocado, un evento de calendario obsoleto o un estado sin explicar, arregla eso antes del lanzamiento.
Si lo construyes en AppMaster, mantén el flujo legible nombrando cada paso según la acción del usuario (Enviar, Validar, Enrutar al Manager, Actualizar Saldo, Crear/Actualizar Calendario, Registrar Evento) para que el comportamiento siga claro a medida que evolucionan las políticas.
Una nueva contratada, Maya, comienza el 10 de marzo. Tu sistema de solicitudes de tiempo libre admite acumulación mensual, así que Maya gana PTO el primer día de cada mes. El 12 de abril solicita medio día: 3 horas el próximo viernes para una cita médica.
Lo que ve cada persona es distinto:
Maya envía la solicitud. Su manager está de vacaciones, así que el sistema comprueba la configuración de delegación y la dirige al manager interino. El manager interino aprueba.
Al aprobar, suceden dos cosas: la solicitud se bloquea a la versión de política usada y se crea un evento de calendario llamado “Maya - PTO (3h)” en la fecha y franja horaria correctas. Maya ve inmediatamente “Aprobado” y el estado del calendario “Añadido”.
En junio, RR.HH. actualiza la política a mitad de año (por ejemplo, la acumulación aumenta tras 90 días). Hay que recalcular saldos, pero las solicitudes aprobadas en el pasado no deben cambiarse en silencio. El sistema recalcula el saldo actual de Maya desde la fecha efectiva hacia adelante, conservando un registro de auditoría con valores antes/después.
Una semana después, Maya edita la fecha (la cita se mueve). Como el permiso ya estaba aprobado, el cambio se convierte en una nueva “Solicitud de cambio” que vuelve al aprobador delegado. Una vez aprobado de nuevo, el evento del calendario existente se actualiza (mismo ID de evento), no se duplica.
Esto es fácil de modelar en una herramienta como AppMaster manteniendo el flujo legible: un camino de aprobación, una comprobación de delegación, un paso de crear/actualizar calendario y una acción de recálculo separada que RR.HH. puede ejecutar cuando cambian políticas.
La forma más segura de finalizar el diseño del sistema de solicitudes de tiempo libre es lanzar una versión pequeña en la que la gente confíe y luego ampliar. Comienza con una política (por ejemplo, PTO) y un camino de aprobación (empleado -> manager). Cuando eso sea rutinario y fiable, añade el siguiente tipo de permiso, región o caso límite.
Antes de añadir más reglas, decide dónde vive la fuente de verdad. Si tu sistema de RR.HH. es el registro maestro, tu app debería validar, enrutar aprobaciones y sincronizar resultados. Si tu app es la fuente maestra, necesitas registros de auditoría más claros y un plan para qué pasa cuando cambian datos de RR.HH. (nuevo manager, cambio de departamento, fechas de terminación).
Un plan práctico para la primera versión:
Escribe de 5 a 10 casos de prueba reales y repítelos tras cada cambio. Usa casos de tu propio equipo, no ejemplos inventados. Por ejemplo: alguien pide el viernes el jueves, alguien cambia su solicitud tras la aprobación, o un manager aprueba mientras el empleado está en otra zona horaria.
Si construyes sin código, la visibilidad importa tanto como las funciones. En AppMaster puedes mantener el modelo de datos (tipos de permiso, saldos, aprobaciones) y el flujo de aprobación en editores visuales, para que RR.HH. y operaciones revisen qué hace realmente el sistema. También puedes exponer APIs para sincronía de calendario y regenerar código fuente limpio a medida que las políticas evolucionan, sin apilar arreglos desordenados con el tiempo.
Cuando la primera versión sea estable, expande una dimensión a la vez: más políticas, más reglas de enrutamiento y luego más integraciones.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
