📄️ Policies
A policy is the set of rules Nexa uses to decide which hotels are acceptable for a given case. Policies are versioned, activated explicitly, and matched to cases by context (airport / airline / country).
📄️ Cases
A case is the unit of work. This page is the operator's field manual for creating, monitoring, modifying, and closing cases.
📄️ Demand Management
Demand is the bridge between a case and its allocations. Operators (or the policy's auto-approver) translate a passenger manifest into a rooms requested number and approve that request before any hotel search runs.
📄️ Allocation Engine
The allocation engine turns an approved demand into a concrete assignment of groups → hotels with explicit, auditable reasoning for every decision.
📄️ Booking & Vouchers
Once allocation picks a hotel for each group, the booking worker reserves rooms with the provider, generates a voucher, and hands off to notifications.
📄️ Notifications
Passenger notifications close the loop. Nexa sends two kinds of email per case:
📄️ Manual Review
Manual review is Nexa's escape hatch. When automation cannot resolve a case, a review item is created with everything an operator needs to decide — including recommendations from the exception agent.
📄️ Operations & SLA
Nexa is mission-critical for an airline during a hub-shutdown event. This page documents the operational commitments behind the platform: support tiers, incident response, throughput, data freshness, and recovery objectives.
📄️ Ground Transport
Many disruptions need more than a room — passengers have to get from the airport to the hotel and back. Nexa's transport module plans, assigns, and tracks ground transport alongside the hotel booking.
📄️ Compliance & Privacy
Nexa operates as a data processor for its airline customers. This page documents the regulatory regimes the platform addresses, the data we process (and don't process), the rights of data subjects, and the certifications we hold.