.webp)
En este número, Ben Waymark aborda las difíciles cuestiones relacionadas con la entrega basada en pedidos: cómo gestionar los estados del ciclo de vida del servicio, resolver conflictos entre sistemas, gestionar las interrupciones sin colas de la era PNR y qué se necesita para funcionar desde el primer día en un entorno híbrido de aerolíneas.
En los tres primeros números de esta serie de preguntas frecuentes sobre la prestación de servicios, hemos abordado el cambio de las operaciones basadas en PNR a la prestación de servicios basada en pedidos, explorando lo que significa en la práctica la «prestación con pedidos» y por qué es mejor que los enfoques tradicionales. Hemos analizado cómo las aerolíneas pueden iniciar esta transición incluso con sistemas PSS heredados, cómo el estado «listo para volar» pasa de DCS a Pedidos y cómo se transfieren los servicios a los sistemas operativos. Hemos examinado la gestión del equipaje, los interlíneas ad hoc, los medios enriquecidos en los flujos de compras y los beneficios prácticos que las aerolíneas ya están viendo, desde la mejora del servicio al cliente hasta la visibilidad en tiempo real y la venta más rápida de servicios complementarios. También hemos explorado cómo las aerolíneas gestionan el estado de la prestación de servicios en los viajes interlínea, garantizando una visión coherente sin necesidad de integraciones directas entre los sistemas de las aerolíneas.
Ahora abordamos las preguntas más difíciles: ¿cómo se mantiene el control cuando las cosas salen mal? ¿Cómo se define la verdad cuando los sistemas discrepan? ¿Y qué se necesita realmente para gestionar las entregas basadas en el orden desde el primer día?
¿Cuál es el ciclo de vida de la entrega por artículo del pedido y cuáles son las transiciones de estado no negociables?
Cada artículo del pedido tiene un servicio (vuelo, asiento, equipaje, comida, etc.) que sigue un ciclo de vida de entrega definido. Este ciclo de vida se supervisa mediante actualizaciones de estado intercambiadas entre el sistema de gestión de pedidos (OMS), el sistema de gestión de entregas (DMS) —el control de salidas (DCS) es una función del DMS— y los proveedores de entrega. Necesitamos un modelo de estado práctico que cubra todas las etapas críticas: facturación, embarque, entrega, entrega fallida, sustitución, reembolso, compensación y cumplimiento parcial.
Por el momento, esto no está muy bien definido por la IATA, pero lo ideal sería avanzar hacia algo como esto:
Creado: El derecho está reservado en el pedido, pero aún no se ha entregado.
Listo para la entrega: el cliente puede utilizar el servicio (por ejemplo, puede facturar o dejar su equipaje).
Facturado: El control de salida confirma la facturación. Se asigna el asiento, se acepta el equipaje, etc.
Embarque: El pasajero embarca físicamente y comienza el servicio (por ejemplo, el vuelo).
Entregado: Se ha prestado el servicio. El pasajero ha viajado, se ha transportado el equipaje y se ha servido la comida.
Entrega fallida: el servicio no se prestó (por ejemplo, no se presentó, problema técnico, bolsa rechazada).
Sustituido: El servicio original se cambió por otro (por ejemplo, nuevo tipo de asiento, vuelo con ruta alternativa).
Reembolsado: El servicio no prestado se cancela y se reembolsa.
Compensación: Se concede una compensación monetaria o en forma de servicios por el fallo del servicio.
Cumplido parcialmente: se prestó una parte del servicio (por ejemplo, se completó parte del trayecto o solo se cargó una de las dos maletas).
Estas transiciones deben reflejarse en los mensajes ServiceStatusChangeNotif y registrarse en el registro de auditoría del pedido. Este modelo admite una gestión avanzada de las interrupciones sin recurrir a la reemisión de artefactos.
¿Quién tiene la razón cuando la entrega, la gestión de pedidos y los socios no están de acuerdo?
Cuando intervienen varios sistemas, los conflictos son inevitables. Por lo tanto, debemos tener claro qué sistema origina cada evento, cómo se resuelven los conflictos y cómo es el registro de auditoría.
En el modelo basado en pedidos:
- OMS es el sistema de registro de derechos y su estado. Determina lo que se ofreció, confirmó, canceló, sustituyó o reembolsó.
- El DMS/Control de salidas origina eventos operativos como el check-in, el embarque y el estado de la carga. Estos se comunican a través de ServiceStatusChangeNotif.
- Los proveedores de servicios de entrega (como los operadores de tierra) también aportan actualizaciones de estado, por ejemplo, acceso a la sala VIP concedido o peso del equipaje confirmado.
- El sistema de gestión de entregas (DMS) proporcionará funciones de control de salidas junto con los estados de estos proveedores de entrega.
La resolución de conflictos sigue esta jerarquía:
- Si un servicio no está marcado como entregado en el OMS, se considera no entregado, independientemente de lo que indiquen los registros de control de salida (DC/DCS).
- Si el OMS ha recibido una actualización de estado de una fuente fiable (DC o socio), esa se convierte en la verdad canónica.
- Las discrepancias se registran y se marcan para flujos de trabajo de resolución manuales o automatizados.
El registro de auditoría está centralizado en la Orden y contiene todas las actualizaciones de estado con el sistema de origen, la marca de tiempo y los detalles del evento. Esto permite una trazabilidad completa y la gestión de disputas.
¿Cómo funciona la gestión de interrupciones en un modelo de entrega basado en pedidos sin colas de la era PNR?
Veamos un caso completo de principio a fin para ver cómo funciona en la práctica. Abordaremos una conexión fallida con complicaciones con el equipaje, reubicación, reasignación de asientos, transferencia de servicios complementarios y mensajes al cliente, haciendo un seguimiento de las actualizaciones en cada paso.
- Conexión fallida: el pasajero llega tarde y pierde su conexión. DC envía un ServiceStatusChangeNotif al OMS indicando: «Vuelo no embarcado».
- Reubicación: OMS activa un flujo de reubicación a través de OrderReshop para ofrecer nuevas opciones de ruta. El cliente selecciona su nuevo vuelo.
- Reasignación de asientos: El nuevo asiento forma parte de la oferta de reubicación y se actualiza en el pedido mediante OrderChange.
- Traspaso de servicios complementarios: los servicios complementarios válidos (como una comida prepagada) se reasignan o reembolsan según la lógica de asignación.
- Equipaje: La maleta ya está cargada en el vuelo original. El sistema de seguimiento de equipajes actualiza el OMS, que señala la discrepancia.
- Mensajes al cliente: OMS inicia el envío de mensajes mediante notificaciones push o el flujo de trabajo del agente, enviando el nuevo itinerario y las actualizaciones.
- Compensación (si es necesario): si el cliente cambia a un servicio inferior o pierde un servicio, OrderChange u OrderQuote reflejan el ajuste y se emite un reembolso o un vale.
Todas las actualizaciones se reflejan en el pedido en tiempo real. No es necesario realizar colas ni sincronizaciones manuales entre los sistemas de emisión de billetes, reservas o inventario.
¿Cómo gestionamos las entregas parciales, las sustituciones de servicios y las compensaciones sin volver a crear billetes y EMD?
La pregunta clave aquí es cómo representar el cumplimiento, el incumplimiento y la solución directamente en la Orden sin caer en la creación de nuevos artefactos con un nombre diferente.
No es necesario volver a crear billetes o EMD. El registro de pedidos se encarga de todo:
- Entrega parcial: cada artículo del pedido tiene su propio estado de entrega. Si parte del trayecto se realiza en avión o solo se consume parcialmente un servicio, se registra por separado.
- Sustitución: El pedido muestra qué servicio se sustituyó y por cuál. Por ejemplo: el asiento 12A se sustituyó por el 14C, con un reembolso si el valor difiere.
- Compensación: Se refleja como un nuevo artículo del pedido (como un vale), un ajuste al total pagado o un valor almacenado asociado al pedido.
Todos los eventos se registran con actualizaciones de estado (ServiceStatusChangeNotif), entradas en el registro de auditoría y, cuando procede, acciones OrderChange. Los reembolsos, las sanciones o los gestos de buena voluntad se incorporan directamente en el pedido, sin necesidad de duplicar los artefactos.
¿Cuáles son las integraciones y controles mínimos necesarios para ejecutar la entrega basada en pedidos en una aerolínea híbrida?
Para una aerolínea que opera con un modelo híbrido (front-end basado en pedidos con sistemas heredados en el back-end), es necesario definir el conjunto mínimo viable de interfaces y controles. Esto incluye la ingesta de eventos, las comprobaciones de derechos, el manejo de excepciones y la semántica compartida «lista para volar».
Así es como se ve:
Ingesta de eventos: su OMS debe recibir eventos del DCS, los sistemas de equipaje, las salas VIP, el catering y el check-in a través de ServiceStatusChangeNotif.
Comprobaciones de derechos: los sistemas de entrega deben consultar el OMS (o recibir mensajes push ServiceDeliveryNotif ) para verificar qué se debe entregar.
Gestión de excepciones: su OMS debe gestionar las respuestas de error y los indicadores de conflicto (como cuando se entrega una bolsa pero el pedido ha sido cancelado).
Semántica compartida «lista para volar»: todos los sistemas de entrega deben alinearse con las definiciones basadas en pedidos de «facturado», «embarcado» y «entregado».
Proceso alternativo: Necesitas poder registrar o anular el estado manualmente a través de las herramientas del agente, manteniendo al mismo tiempo la integridad de la auditoría de pedidos.
Esta configuración le permite admitir el cumplimiento de NDC y ONE Order además de la infraestructura heredada, al tiempo que se desacopla progresivamente de las dependencias de PSS.
Autor
