Travel and hospitality data teams: stop chasing feed changes, start shipping pricing inputs

Key takeaways

• •Who this is for. The team that owns bookings, stays and traveller identity as a data product at an airline, hotel group, OTA or cruise line.
• •The problem today. A distribution partner changes a feed layout on a Friday night, rates and availability go stale before the Saturday reprice, and the same guest sits in the booking engine, the property system and the loyalty platform as three different people.
• •What changes. GDS, NDC and channel-manager feed changes are mapped into the warehouse the day they happen, with the downstream tables listed before anything breaks. Duplicate guest and loyalty profiles are found, tested on a copy and merged with a rollback point.
• •What stays with your people. Anything that moves a price input, a member's points or tier, or the scope of payment and special-category data: the revenue systems owner, the loyalty owner and the security owner approve with the before-and-after numbers in front of them.
• •The result. A travel data team that ships trustworthy demand and pricing inputs, loyalty analytics and personalised offers instead of chasing feed changes and explaining why two reports disagree.

The PRD for agentic travel and hospitality data teams

This is the requirements document we would write with you for your team. Everything below expands on it.

What going fully agentic and autonomous means for travel and hospitality data teams

• •Put your data pipeline on autopilot. GDS, NDC and channel-manager layout changes are mapped into the warehouse the day they happen, so the Saturday reprice never reads stale rates because of a Friday release at a partner.
• •Run the data back office without the busywork. The work that fills the week today moves to agents: feed breaks before peak season, hand-checked profile merges, access requests from revenue managers and quarter-end reconciliation of bookings to revenue.
• •Scale data without scaling headcount. Every new channel, property, route or acquired brand adds feeds and identities. Agents land, map and verify them, so the data you manage grows without the team having to.
• •Get the plumbing off your plate. A travel data team that ships demand and pricing inputs, loyalty analytics and personalised offers instead of rebuilding feeds and answering "which booking number is right".

Who this is for

The team that owns the booking and guest domain as a data product. At an airline, it sits between commercial, revenue management and loyalty, and works with data from the reservation system, the departure control system, ticketing and flown-revenue accounting. At a hotel group it is the team behind the central reservation system, the property management systems at each hotel, the channel manager and the guest profile. At an OTA it handles supplier feeds, search and shop logs, bookings, cancellations and refunds from hundreds of suppliers. At a cruise line it ties reservations, manifests, onboard spend and repeat-guest programmes together.

The titles: Head of Travel Data Products, Director of Revenue Management Systems and Data, Guest 360 Product Lead, Loyalty Analytics Lead, Director of Distribution Data, and the product owners who report to them. They often run several platforms at once, each feeding reporting, revenue management, marketing and, increasingly, AI agents that recommend offers or answer questions for guests and staff.

This playbook is one of the marketing, ads and customer data teams pages; the rest of that group covers the neighbouring teams you share data with.

The product you ship

• •The booking and stay data mart: reservations, PNRs and orders, tickets and coupons, stays and folios, cancellations and changes, as governed, reusable data products.
• •One guest or traveller view: a single profile across the booking engine, the property or departure systems, the loyalty platform and customer service, with consent attached.
• •Demand and pricing inputs for revenue management: pickup, pace, forecasts, competitor rate shops, rate-plan and fare data, and displacement inputs, delivered on time and tied to the source systems.
• •Loyalty analytics: points liability, earn and burn, tier movement, status match and partner earn.
• •Personalised offers: next-best-offer, ancillary and upsell models, and the audiences behind email and app campaigns. See the personalisation and recommendations data playbook.
• •Leadership reporting: RevPAR, ADR and occupancy; load factor, yield and ancillary revenue per passenger; channel mix and distribution cost.

Where the week goes

• •Partners change feeds without warning. A channel manager adds a nested restrictions block, a GDS or NDC connection starts returning orders as well as PNRs, an OTA supplier renames a field. Every table and model downstream breaks quietly.
• •Guests are duplicated everywhere. The same traveller books through an OTA, the brand site and the front desk, and joins the loyalty programme under a slightly different name and email. Corporate travel arrangers book for executives under their own details.
• •Peaks punish every weakness. School holidays, summer schedules, cruise wave season and big events multiply volumes, and a late or partial feed is a pricing error that lasts until the next load.
• •Definitions are contested. Revenue management, finance and marketing each have a version of ADR, net revenue, a "stay" and an active member.
• •Personal and payment data spread. Free-text notes, special service requests such as meal and mobility requests, passport details and card fragments end up in tables built for analytics.
• •Offer engines amplify bad data. A personalisation model that treats one guest as two, or sends an offer for a stay already cancelled, loses trust fast.
• •Access is sensitive. Revenue managers, property teams, call centres and agencies each need different views of guests, rates and loyalty balances.

Add it up and upkeep is most of the team's week. Here is how a typical week splits today, and once agents own the back office:

Time spent on new data products moves from 18% of the week to 48%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.

Then and now

These are the impact metrics we move for travel and hospitality data teams:

• •Channel-manager or NDC feed change mapped: from about a week to 30 min
• •Duplicate loyalty profile batch reviewed and merged: from about two weeks to 2 hours
• •Bookings tied to PMS and ticketing revenue: from about two days to 12 min

Across the routine work in this domain:

The biggest change is duplicate loyalty profile batches: from about two weeks to 2 hours. Work that waited in queues finishes in minutes or hours, because agents detect, fix and verify in one pass.

Use cases, in depth

A channel-manager or NDC feed layout change, mapped before rates go stale

Today. The channel manager ships a new version of its rate and availability feed. Tax and fees are split into separate fields, length-of-stay restrictions move into a nested block and three new rate-plan codes appear. The nightly load still succeeds, because the file is valid. The rate table quietly fills with nulls, the forecast input drops rows and revenue management finds out when a property is priced off yesterday's data. The same pattern hits an airline when a carrier adds an NDC connection and offers and orders arrive beside the PNRs the models were built on.

With Data Workers. The Schema Evolution agent detects the new layout in the first file it sees, in staging, and the Data Context & Catalog agent lists every table, model, report and campaign that reads the affected fields. The migration is generated and tested in staging with a rollback point, and the Quality Monitoring agent ties the staged rates to the property management system before anything reaches the tables revenue management reads. Because rate-bearing fields feed pricing, the change is held for the revenue systems owner with the full diff and the tie-out results.

What changes. The Saturday reprice runs on correct inputs. A partner's release is a reviewed change, not an incident. For the engineering view of column-level impact, see how to automate column-level impact analysis for schema changes, and the group's schema change management transformation.

Merging duplicate guest and loyalty profiles safely

Today. The guest profile is rebuilt from the booking engine, the property systems, the loyalty platform and customer service. Duplicates are everywhere: a nickname on one record, a travel arranger's email on another, a family sharing one address. Clean-ups happen as projects. Each merge is a risk, because a wrong merge combines two travellers' points, tier status and stay history, and exposes one person's details to the other. So teams merge cautiously, leave the duplicates in place, and every campaign, loyalty report and personalisation model inherits them.

With Data Workers. The Quality Monitoring agent finds likely duplicate members across the sources on a schedule. The Data Context & Catalog agent shows what reads each profile, from points liability reports to audience exports, so the effect of a merge is known before it happens. The Pipeline Building agent builds the merge as a tested change and runs it on a copy first, checking that points, tier status and stay counts are conserved. The batch then goes to the loyalty owner as one decision, with the proposed merges, the checks and the exceptions that need a person, such as shared emails and corporate arrangers. Every applied merge keeps a rollback point.

What changes. One traveller view people can rely on, and a merge that can be undone if someone rings to say it was wrong. For the identity side of the problem in depth, see the entity resolution and unified profiles playbook and the sibling Customer 360 and CDP data playbook.

Peak season and the move from PNRs to orders

Today. Summer schedules, wave season and a stadium event all land at once, and the data team is also adding distribution connections. An airline that adds NDC channels receives bookings as orders as well as PNRs, so counts of "a booking" differ by channel. A hotel group acquires a brand and inherits another property system. Volumes spike, partner files arrive late, cancellations and changes reverse yesterday's numbers and nobody has time to rewrite definitions.

With Data Workers. The Connectors and Data Ingestion agents land the new feeds and profile every load. Data Context Wizard holds one governed definition of a booking, a stay, a cancellation and net revenue across the old and new shapes, so the executive dashboard and the offer engine count the same thing. The Quality Monitoring agent sets freshness targets for the feeds revenue management reads and ties bookings to ticketing and property revenue every day. The Autonomous Data-Conductor keeps reporting current through the peak and escalates only what needs a person.

What changes. Peak is a volume problem, not a data-trust problem. Leaders see the same bookings number whichever channel it came through.

For airlines, hotel groups, OTAs and cruise lines

The same swarm covers each shape of travel business, with different feeds at the edges.

• •Airlines. Reservation and ticketing data from the reservation system and GDS connections, NDC offers and orders, departure control and flown revenue, loyalty earn and burn. The hard parts are the mix of PNR and order shapes, flown versus ticketed revenue, and passenger data with special service requests.
• •Hotel groups. Central reservation system, property management systems across owned, managed and franchised hotels, channel managers, rate shops, and the revenue management system. The hard parts are inconsistent property systems, rate and restriction feeds, and the guest profile.
• •OTAs. Supplier feeds from airlines, hotels and car providers, search and shop logs, bookings, cancellations and refunds. The hard parts are supplier layout changes and the volume of small, constant schema drift.
• •Cruise lines. Reservations, manifests, onboard spend, port and shore-excursion partners, and repeat-guest programmes. The hard parts are long booking windows, group bookings and onboard-to-shore identity.

Measure the product, not just the pipeline

Travel data product leaders are judged on whether revenue management trusts the inputs, whether loyalty analytics ties to the finance liability and whether marketing's audiences are right, not on table counts. The Autopilot dashboard shows how much of each data product's upkeep runs on its own and at what token cost, so the team can show leadership where its time now goes: new pricing inputs, better offers and a guest view that holds up.

Agents working together: A channel manager changes its feed

Every hotel data team knows this night. A channel manager rolls out a new version of its rate and availability feed to hundreds of properties, valid by its own specification and different from the layout your pipelines expect. Revenue management reprices at six. Anything stale at that point is a wrong price on the busiest weekend of the quarter. This is the same night run by Data Workers.

The setup

A hotel group runs a central reservation system, property management systems at each hotel, a channel manager and a revenue management system, with Snowflake, dbt and Airflow in the middle. The warehouse feeds the revenue management system's forecast inputs, ADR and RevPAR reporting, the loyalty analytics mart and an offer engine. Autonomy in Autopilot:

• •Staging, feed mapping for non-price fields, catalog and docs: L2 today; a candidate for L3 on evidence.
• •Rate-bearing fields, restrictions and forecast inputs: L2, held for the revenue systems owner.
• •Loyalty points and tier status: L2, held for the loyalty owner.
• •Payment and special-category data scope: L0 for any change; people only.

The team scheduled one standing routine: "Map partner feed changes into staging and prove they tie before anything reaches revenue management."

01:10: the new feed layout arrives

The channel manager begins sending the nightly rate and availability feed in its new layout. The same release adds a free-text notes field to the reservations feed.

01:12: detect and map the change

Connectors agent lands the file in staging and confirms the load. Schema Evolution agent compares the layout with the one the pipelines expect: tax and fees are now two fields, length-of-stay restrictions have moved into a nested block and there are three new rate-plan codes.

01:20: list what it touches

Data Context & Catalog agent runs a blast radius analysis on the changed fields. Fourteen tables and models read them, including the forecast input model, the ADR and RevPAR reports and a campaign audience that filters on rate plan.

01:35: generate and test the mapping

Schema Evolution agent generates the migration in staging with a rollback point, mapping the split tax and fee fields to the totals the models expect and unpacking the nested restrictions. Pipeline Building agent updates the forecast input model and writes tests that prove last night's rates under the old layout equal last night's rates under the new one.

01:50: prove it ties

Quality Monitoring agent runs the checks the team relies on:

• •Staged rates by property and rate plan tie to the property management system.
• •Inventory and restrictions match the central reservation system.
• •Every property reported; two properties show tax double-counted and are flagged.

02:05: fix what does not tie

Incident Debugging agent traces the double-counted tax at the two properties to a tax-inclusive setting that the new layout represents differently. It proposes the corrected mapping and lists both properties for the revenue systems owner.

02:20: keep personal data out

Data Access & Governance agent scans the new notes field in the reservations feed. It finds email addresses and phone numbers typed into the free text, flags the field as personal data and keeps it out of the analytics tables until a named person approves how it is handled.

03:00: update meaning, then verify

Data Context Wizard updates the governed definitions of net rate, ADR and restriction with provenance, so the revenue management system and the offer engine read the new meaning. Autonomous Data-Conductor recomputes ADR and the forecast inputs against the prior night's values and checks them against the property systems. Because rate-bearing fields sit at L2, Conductor sends one decision to the revenue systems owner: the diff, the tie-out results and the two flagged properties.

05:20: approved

The revenue systems owner approves the mapping and changes the treatment of one of the two properties. Conductor applies it and publishes.

06:00: the reprice runs

Revenue management reads current rates and restrictions. The ADR report matches the property systems. Nobody files a ticket, and the partner's release is a reviewed change with a receipt.

What stays behind

• •A tested mapping from the old layout to the new, so a rollback is one step.
• •A receipt for every change: who proposed it, who approved it and how to reverse it.
• •Updated Spellbook pages for every affected data product.
• •A reusable routine. The next partner release runs the same way, and the team can move the routine parts to L3.

Minute by minute

This is an illustrative example. The hotel group runs on Snowflake and dbt under Airflow; revenue management reads at 06:00. Rate-bearing fields are at L2.

The agents on the job

Data Context Wizard holds one governed definition of a booking, a stay, a cancellation, net revenue, ADR, an active member and a loyalty tier. Revenue management, loyalty reports, personalisation models and every AI agent that talks to guests answer from the same definitions, so the offer a guest sees and the number a leader reads never disagree. Autonomous Data-Conductor verifies the numbers that matter before the reprice and before offer engines read them. Spellbook Data Catalog makes each travel data product discoverable for revenue managers, marketers and analysts, in plain English.

What goes on autopilot

Once a domain has earned it, this work runs on its own, and each item removes a problem your team deals with today:

• •Partner layout changes are mapped into staging the day they happen, so the Saturday reprice never reads stale rates because of a Friday release.
• •Bookings are tied to property and ticketing revenue every morning, so finance, revenue management and the executive dashboard stop disagreeing.
• •Freshness targets on the feeds revenue management reads are watched and fixed, so a late file in peak season is repaired before the reprice, not discovered after it.
• •New fields are checked for personal data on arrival, so a free-text notes field does not become a data protection finding months later.
• •Catalog and documentation upkeep runs by itself, so a new property, route or brand shows up documented.

Where your people stay in charge

Agents never get blanket access. Each domain has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as reruns, staging fixes, documentation and cleanup is usually first to run on its own.

• •Rate-bearing fields, restrictions and forecast inputs always go to a named approver: they set prices, so the revenue systems owner approves every change with before-and-after numbers per property or route.
• •Loyalty points, tier status and profile merges that touch them go to the loyalty owner, with the proposed merges and exceptions in one decision.
• •Payment data and special-category data scope go to the security and privacy owners. Any change to what is allowed to land in analytics is theirs to make.
• •Pricing strategy, loyalty rules and offer eligibility stay entirely with people.

Once a deployment has matured, here is how that ladder plays out across task classes:

Catalog and docs upkeep closes autonomously 88% of the time. For rate and fare-bearing changes, autonomous closure is 10% at most by design, and loyalty points and tier status stays with people: every change is proposed with a full diff and approved by a named person.

What happens when an agent is wrong

• •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the blast radius and how to roll it back. Unanswered requests expire and escalate.
• •L3 and L4 are where a domain can go next, on its own review record: acting on its own, with a rollback point on every change. Only the domain's owner raises its level, and if people start reverting the agents' changes, the domain pauses itself.
• •A wrong profile merge can be reversed. Each applied merge keeps a rollback point, so a guest who rings to say two people were combined is a fix, not an investigation.
• •No agent approves or promotes its own work. Autonomy only grows on evidence, domain by domain, and repeated reverts pause the domain.
• •One org-wide stop halts all autonomous dispatch, and every action lands in a tamper-evident audit trail you can export with generate_audit_report.

How it fits your stack

Data Workers connects to what you already run: GDS and NDC booking feeds; channel managers and central reservation systems; property management systems; your loyalty platform; the revenue management system; Snowflake or Databricks; dbt; Airflow or Dagster; Tableau or Looker; personalisation and offer engines. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates.

• •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows, so guest and payment data stay where they are.
• •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
• •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
• •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.

Governance and regulation

Travel data is personal data by default: names, contact details, passport and document numbers, travel patterns and the special service requests that can reveal health or religion. In Europe and for any guest from it, the GDPR applies, and the access, erasure and purpose-limitation obligations land on exactly the tables that duplicate profiles pollute. Card data brings the PCI Data Security Standard into scope wherever it lands. Data Workers scans new fields for personal data with scan_pii, keeps role and property access scoped with provision_access and check_policy, holds changes to what is allowed into analytics for a named approver and records every change in a tamper-evident trail. It works beside your consent platform; see what to do if you are on OneTrust, how to handle PII in data pipelines and GDPR for data engineers. For peak-season controls in a related consumer sector, see data governance for ecommerce, and for detection and masking in depth the PII detection and masking transformation.

Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.

The alternatives travel and hospitality data teams weigh

Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing approvals to the revenue systems owner and the loyalty owner, blast radius, rollback, receipts, and current context about every other system.

Distribution and CDP vendors. GDS and NDC aggregators, channel managers, hospitality CDPs and loyalty platforms each give you a view of their own slice. Data Workers keeps the warehouse underneath correct as their formats change, and works across them rather than replacing any of them. The Customer 360 playbook covers the CDP side.

Observability, catalogs and point tools. Observability alerts, catalogs document, and quality tools test. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt.

Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; this work crosses the partner feeds, property and reservation systems, orchestrator, warehouse and BI, and Data Workers works across all of them.

In this space specifically. Revenue management systems, rate-shop tools and loyalty analytics products reason over the data they are given; Data Workers keeps what they are given correct, current and governed.

The case for your CTO

What this replaces. Feed breaks found after a reprice, one-off profile clean-ups that nobody trusts enough to apply, hand-checked access requests and the quarter-end scramble to tie bookings to revenue.

What your team gets back. A travel data team that ships demand and pricing inputs, loyalty analytics and personalised offers instead of chasing feed changes and explaining why two reports disagree.

Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, orchestrator, dbt project and source systems you already run, under the roles you already govern, inside your own infrastructure. Your engineers can read every tool the agents call in the open-source core.

Risk and control. Autonomy is set per domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; rate-bearing fields and loyalty points stay at L2 with a named approver; payment and special-category scope stays with people; and one org-wide stop halts all autonomous work.

Why now. Offer engines and guest-facing AI agents multiply the cost of a duplicate profile, and distribution is moving: NDC adds order-shaped data next to the PNR-shaped data your models were built on. The IATA NDC programme describes the standard behind it.

The first win. One distribution feed and the guest profile merge at L2. The pilot below lays out the scope, what you see each week and the cost.

The climb: from assisted to autonomous to agentic

Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For travel and hospitality data teams, the climb looks like this:

• •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; rate-bearing fields, loyalty points and payment scope always go to a named approver.
• •Autonomous, under your governance. Routine work runs on its own: partner layout changes are mapped into staging the day they happen, bookings are tied to property and ticketing revenue every morning and new fields are checked for personal data on arrival. Your team governs the agents instead of doing the upkeep.
• •The agentic enterprise. A travel data team that ships demand and pricing inputs, loyalty analytics and personalised offers instead of chasing feed changes. People set direction, and the platform carries it out.

You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.

The pilot: how travel and hospitality data teams start

The pilot is how your team proves the value on its own data before committing.

• •What we connect. A GDS, NDC or channel-manager feed; the property management or reservation system; your loyalty platform; Snowflake or Databricks; dbt; Airflow or Dagster; Tableau or Looker, over MCP, inside your infrastructure. Nothing migrates.
• •Scope. One distribution feed and the guest profile merge, at L2.
• •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
• •By week two. Partner layout changes are mapped into staging and bookings are tied to property and ticketing revenue every morning on reversible work. Rate-bearing fields and loyalty points stay at L2 with a named approver.
• •At day 30. We review the impact metrics against your baseline:

• •Channel-manager or NDC feed change mapped: from about a week to 30 min
• •Duplicate loyalty profile batch reviewed and merged: from about two weeks to 2 hours
• •Bookings tied to PMS and ticketing revenue: from about two days to 12 min
• •the share of catalog and docs upkeep closed autonomously, targeting 88% as the deployment matures

• •What you decide. Whether to expand to the next feed, brand or region. The pilot fee is credited in full against the first year.
• •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.

The pilot is the start of a longer curve:

By month 12, more than 40% of agent actions run fully autonomously and manual work falls below 10%, while price-bearing and points-affecting changes stay with a named approver.

FAQ

Does it work with GDS and NDC data? Yes, through the files, APIs and warehouse tables you already receive. Agents map layout changes and verify the numbers; they do not replace the connection to your distribution partners.

Will agents change prices? No. Rate-bearing fields and revenue management inputs are L2: proposed with the full diff and approved by the revenue systems owner.

Can it merge loyalty profiles? It finds likely duplicates, tests the merge on a copy, checks that points and tier status are conserved and sends the batch to the loyalty owner. Applied merges keep a rollback point.

Where does guest and payment data go? Nowhere new. Agents run in your infrastructure with your credentials and model key. The hosted Conductor sees workflow metadata only.

Can it ground our offer engine and guest-facing AI agents? Yes, through governed definitions in Data Context Wizard, so recommendations read the same booking, stay and member definitions as your reports.

Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog and BI stay where they are.

Sources

• •Data Workers pricing: https://dataworkers.io/pricing/
• •Regulation (EU) 2016/679, General Data Protection Regulation (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2016/679/oj
• •PCI Security Standards Council, document library (PCI DSS): https://www.pcisecuritystandards.org/document_library/
• •IATA, New Distribution Capability (NDC): https://www.iata.org/en/programs/airline-distribution/ndc/
• •Snowflake, managed MCP server and Cortex Agents GA release note (Nov 4, 2025): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
• •Databricks, Genie One launch (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team