Viajes que acompañan el ciclo de vida de sus empleados.
Aprovisionamiento automático con SCIM desde su IdP. SSO con Okta, Azure AD y Google Workspace. Acceso basado en roles que refleja su organigrama. Un offboarding fluido que revoca el acceso a la plataforma y recupera los saldos de crédito. Onboarding de viajes en minutos, no en semanas.
El onboarding de viajes no debería frenar su proceso de contratación.
La mayoría de las plataformas de viajes corporativas siguen exigiendo un onboarding manual. RR. HH. da de alta al nuevo empleado en el HRIS. El travel manager crea el perfil en la plataforma de viajes. Finanzas asigna una tarjeta. Tres sistemas, tres formularios, tres aprobaciones. Los nuevos empleados esperan de 5 a 10 días antes de poder reservar un viaje, mucho después de su primer día.
El offboarding es aún peor. Cuando alguien se va, ¿quién recupera sus créditos de vuelo sin usar? ¿Quién elimina su acceso? ¿Quién cancela las reservas en curso? La mayoría de las empresas no tiene un proceso definido. Los créditos quedan sin usar y caducan. Los empleados que se marchan conservan el acceso a la plataforma durante semanas.
Travel Code aprovisiona y desaprovisiona mediante SCIM 2.0 con su IdP. Un nuevo empleado aparece en su HRIS y su acceso a viajes está listo en segundos, no en días. Cuando un empleado causa baja, se recuperan los créditos, se revoca el acceso y las reservas en curso se marcan para su revisión. La gestión de viajes sigue a la gestión de personas, de forma automática.
Retraso habitual del onboarding de viajes entre la fecha de incorporación y la primera reserva en plataformas tradicionales.
Valor medio de los créditos de vuelo sin usar en el offboarding cuando la recuperación no está automatizada.
Tiempo medio que conservan el acceso a la plataforma los empleados dados de baja sin SCIM.
Viajes que reflejan su organización.
SCIM 2.0: alta automática.
Sincronización SCIM 2.0 en tiempo real con Okta, Azure AD, Google Workspace, JumpCloud, OneLogin y cualquier endpoint SCIM estándar. Los nuevos usuarios se aprovisionan automáticamente con asignación de roles. La pertenencia a grupos determina la política asignada. Latencia media de aprovisionamiento: 3,6 s p95.
SSO con su IdP.
Compatible con SAML 2.0 y OIDC. Inicio de sesión único desde su IdP, con la misma experiencia de acceso que el resto de su stack. Las políticas de acceso condicional (MFA, dispositivo, red) se aplican en la capa del IdP. Sin contraseñas de Travel Code adicionales que gestionar u olvidar.
Acceso basado en roles.
Cinco niveles de rol predeterminados (Viajero / Manager / Admin / Finanzas / Propietario) más roles personalizados. Asigne grupos del IdP → rol + política + codificación contable (GL) automáticamente. Cambios de departamento, ascensos y traslados se reflejan al instante. Sin actualizaciones manuales de roles.
Offboarding sin fricciones.
El flujo de offboarding se ejecuta automáticamente cuando el IdP marca al usuario como inactivo: se revoca el acceso a la plataforma, las reservas en curso se marcan para su responsable, los gastos enviados se finalizan automáticamente y los saldos de crédito se recuperan y se reasignan a la empresa. El registro de auditoría se conserva según su política de retención.
Del primer al último día, sin intervención de RR. HH.
Cuando se incorpora un nuevo empleado, su acceso a viajes está listo antes de su primera reunión diaria. Cuando alguien cambia de puesto, la política le sigue. Cuando se marcha, el acceso se cierra y los créditos se recuperan. Todo desde su IdP, sin pasos manuales.
Activado en segundos.
El HRIS da de alta al nuevo empleado → el IdP lo propaga → el evento SCIM activa el aprovisionamiento en Travel Code. El perfil se crea con rol, departamento, manager y codificación contable (GL) heredados de los atributos del IdP.
El rol cambia con el ascenso.
Cuando alguien cambia de rol o departamento, se actualiza su pertenencia a grupos en el IdP → la política de Travel Code se actualiza en segundos. Se asigna un nuevo aprobador. Se aplican nuevos umbrales de fuera de política. Sin reconfiguración manual.
Acceso revocado, créditos recuperados.
El IdP marca al usuario como inactivo → Travel Code revoca el acceso a la plataforma, marca las reservas en curso para revisión del manager, finaliza los gastos pendientes de envío y recupera los créditos de vuelo sin usar.
Auditoría conservada.
El registro de auditoría se conserva según su política de retención de datos (por defecto: 7 años). Configurable por región para cumplir con el RGPD o con normativas sectoriales. Historial completo de eventos exportable por usuario, por reserva y por transacción.
Preguntas habituales de RR. HH. y Operaciones.
¿Qué IdP son compatibles?
Conectores SCIM 2.0 nativos para Okta, Azure AD (Microsoft Entra ID), Google Workspace, JumpCloud y OneLogin. Endpoint SCIM 2.0 genérico disponible para IdP personalizados. Compatible con SAML 2.0 y OIDC para SSO. La configuración suele llevar entre 30 y 60 minutos con su equipo de TI.
¿Cómo funciona la asignación de roles entre los grupos del IdP y Travel Code?
Usted asigna los grupos del IdP a roles y políticas de Travel Code en los ajustes de administración. Patrones habituales: grupos de departamento → asignación de política; grupos por antigüedad → umbral de gasto fuera de política; atributos de centro de coste → codificación contable. Las asignaciones se pueden actualizar sin cambios de código.
¿Qué ocurre con las reservas en curso cuando un empleado causa baja?
Las reservas con salida en los próximos 30 días se notifican al responsable con tres opciones: cancelar y reembolsar, transferir a otro empleado (cuando las normas de la aerolínea lo permitan) o convertir en crédito. Las reservas con más de 30 días de antelación siguen la política configurada por la empresa. El registro de auditoría recoge cada decisión adoptada.
¿Cómo se recuperan los créditos al dar de baja a un empleado?
Se identifican los créditos de vuelo no utilizados a nombre del empleado dado de baja. Cuando las normas de la aerolínea permiten la transferencia (la mayoría de las aerolíneas nacionales de EE. UU., algunas tarifas de Lufthansa), los créditos se reasignan a la bolsa de la empresa. Cuando no la permiten, los créditos se registran y se utilizan en la siguiente reserva a nombre del mismo empleado dentro del período de validez del crédito.
Vea el aprovisionamiento con su IdP.
Demo de 30 minutos con su equipo de TI: traiga su IdP y configuraremos SCIM en directo durante la llamada.