agentic-ai

6 Beiträge mit dem Stichwort „agentic-ai“

The Hospitality Industry Is Looking at Agentic Commerce the Wrong Way

15.08.2026

The industry is asking the wrong question

Most conversations about AI and hotel distribution are focused on visibility. Will ChatGPT find my hotel? Will Gemini recommend my property? Will Perplexity show my brand? Will my content be optimized for AI search?

These questions matter, but they are not the core issue. Discovery is not where the real battle will be won. The real question is this: when an AI agent finds the right hotel, who controls the transaction?

That is the point the industry is not taking seriously enough. Agentic commerce is not only about being recommended by AI. It is about being bookable by AI, in real time, under hotel-controlled rules, with direct payment, confirmation, attribution and settlement. If hotels solve discovery but fail to solve transaction control, they will have optimized for visibility while losing the booking.

Discovery was never the hardest part

AI will become very good at finding hotels. It can understand location, guest intent, budget, trip purpose, reviews, amenities, family needs, loyalty preferences and travel context. It can compare options faster than any human browsing session. That is not the hard part. The hard part is what happens after the recommendation.

Can the AI access live rates and availability? Can it understand which rooms are actually bookable? Can it respect cancellation rules, occupancy rules, rate plans and restrictions? Can it take secure payment? Can it confirm the booking instantly? Can it attribute the transaction correctly? Can it settle funds to the right parties? Can it service the booking after purchase?

This is where hotel distribution becomes infrastructure. AI describing a hotel is search. AI completing a hotel booking directly — with hotel-controlled inventory, rules and economics — is commerce. And commerce requires a transaction layer.

The OTA risk repeats in a new form

The hotel industry has seen this movie before. When digital demand moved online, hotels needed distribution, reach and conversion. OTAs filled that gap with technology, payment flows, customer trust and transactional infrastructure. They solved the booking problem at scale — but the cost was high: commissions, dependency, data leakage, weaker direct relationships and reduced control over the guest journey.

Agentic commerce could repeat the same pattern in a new form. If AI agents cannot complete a booking directly with the hotel, they will route the guest to whoever can — usually Booking.com, Expedia or another platform with the rails already in place. The AI may recommend the hotel. The guest may like the hotel. The final transaction may still happen somewhere else.

That is the danger. The winner in AI travel will not only be the company that appears in the answer. It will be the company that can execute the booking.

Independent hotels have the most to lose

Large hotel groups have more resources, stronger direct channels, loyalty programs, central reservation systems and technology budgets. Independent hotels do not.

For independent hotels, AI discovery could look like an opportunity at first. A guest asks an AI assistant for a boutique hotel in Bangkok, a family-owned resort in Bali, or a design hotel in Lisbon. The AI may surface excellent independent properties that would never have won a traditional paid-search battle.

That sounds positive. But if the booking cannot be completed directly, the value still leaks away. The guest relationship moves to the platform that can transact. The payment moves through someone else’s infrastructure. The data sits outside the hotel’s control. The economics are shaped by the intermediary. The hotel becomes content in someone else’s commerce flow. Being discoverable is not enough — hotels must become transaction-ready for AI.

What AI agents actually need

AI agents do not need brochures. They need structured supply — hotel inventory that can be read, priced, filtered, booked, paid for, confirmed and serviced programmatically. That means real-time access to room types, rates and availability, rate rules, cancellation policies, occupancy rules, taxes and fees, payment requirements, booking confirmation, guest details, attribution, settlement and post-booking servicing.

This is not a marketing problem. It is not just an SEO problem. It is not only a content problem. It is a systems problem. For an AI agent to book directly, the hotel’s commercial logic needs to be exposed in a secure, structured and controlled way. That is the infrastructure gap.

The missing layer is the transaction layer

The next layer of hotel distribution will not simply be search. Search finds options. Commerce executes decisions. Agentic commerce requires the ability to turn intent into a confirmed booking without pushing the guest into a separate, OTA-controlled environment.

That means the industry needs a transaction layer built for hotel-controlled commerce — a layer where hotels expose inventory directly, where rates and rules remain controlled by the hotel, where payment happens securely, where bookings are confirmed instantly, where attribution and settlement are handled correctly, and where new demand interfaces connect without every hotel building custom technology. This is the missing infrastructure, and it is where the conversation should be focused.

Wink has built it

This is what Wink has built. Wink connects hotel-controlled supply to the new demand layer through APIs, MCP, Booking Engine, payment, attribution and settlement.

That demand layer is not only AI agents. It includes platforms, developers, creators, publishers, travel apps, embedded maps, bookable cards, conversion banners, storefronts and any interface where travel intent appears.

The principle is simple. Hotels control the supply. Wink makes that supply programmable, bookable and payable. Demand partners can transact without becoming OTAs. AI agents can book without redirecting everything through legacy platforms. Creators and publishers can turn content into booking points. Developers can build travel commerce without rebuilding hotel infrastructure from scratch.

Wink is not trying to become the consumer destination. Wink is the invisible transaction infrastructure that lets hotel bookings happen wherever demand is created. The future of hotel commerce will not live only on hotel websites or OTA search pages. It will happen inside AI assistants, creator content, bank apps, travel platforms, maps, chat interfaces and embedded digital experiences. Hotels need to be bookable there directly.

What this means for hotels

For hotels, the goal should not be only to “rank” in AI. The goal should be to remain commercially in control when AI becomes a booking interface — keeping control over rates, availability, rules, guest data, payment flow, attribution, economics and the direct relationship.

If a guest asks an AI agent to book a hotel, the hotel should not be forced to surrender the transaction to an OTA simply because the OTA has better booking rails. The hotel should be able to transact directly, inside the interface where the guest intent already exists. That is what transaction readiness means. It does not replace the hotel website or existing channels. It extends hotel-controlled commerce into every new demand surface.

This is not anti-OTA

This is not an anti-OTA argument. OTAs are valuable. They create demand, package supply, serve travelers, invest heavily in conversion and will remain an important part of hotel distribution. The issue is not whether OTAs should exist. The issue is whether every AI-driven booking should default to OTA-controlled rails simply because hotels were not ready with their own transaction infrastructure.

Hotels need choice. If an OTA creates the demand, it should be compensated. If a creator drives the booking, that should be attributed. If a platform embeds hotel commerce, that transaction should be supported. If an AI agent recommends a hotel directly, the hotel should be able to complete that booking directly. The future should not force all demand through the same few intermediaries. It should allow hotel-controlled supply to transact wherever the guest is ready to book.

The next battle in hotel distribution is not “Will AI find my hotel?” It is “Can AI book my hotel directly?” That is what hotels should focus on.

The Booking Button Is Moving

11.08.2026

Yann Gouriou

Co-founder & COO

Where hotel booking moves next · Part 1

The booking moment is leaving its old home

For years, the hotel booking button had a clear home.

It lived on the hotel website, inside the booking engine, or on an OTA page. The guest searched, clicked into a booking flow, selected dates, chose a room, entered payment details and received a confirmation.

That model still matters. The hotel website is not disappearing. OTAs are not disappearing. Booking engines are not disappearing.

But the booking moment is starting to move.

Travel intent is no longer forming only on hotel websites, OTA search pages or metasearch results. It is forming inside AI chats, creator content, destination guides, maps, bank apps, loyalty platforms, event apps, newsletters, membership communities and embedded travel experiences.

The traveler may be ready to book before they ever reach a traditional hotel page.

That is the shift: the booking button is moving from a fixed destination to the place where intent already exists.

The old model was built around traffic capture

The traditional direct booking strategy was built around a simple sequence.

Create demand. Drive traffic to brand.com. Convert that traffic in the booking engine.

That sequence created the modern hotel website playbook: SEO, paid search, metasearch, email, retargeting, content, offers, conversion optimization and booking engine performance.

It was a rational model because the website was the commercial destination.

If the hotel could bring the traveler back to brand.com, the hotel had a chance to control the transaction, capture the guest relationship and reduce dependency on intermediaries.

The problem is that travel demand is now less linear.

A traveler can move from inspiration to decision inside a creator itinerary, from comparison to booking intent inside an AI conversation, or from location discovery to purchase intent inside a map or partner app.

In that world, asking every guest to leave the surface where intent exists and restart somewhere else creates friction.

The new model is built around distributed intent

Distributed intent means demand appears across many trusted surfaces rather than one controlled destination.

A creator may influence a traveler through a weekend guide. A bank app may surface hotel offers to cardholders. An AI agent may recommend a property based on trip context. A map may help a guest choose the right neighborhood. A publisher may turn a destination article into a planning moment. A platform may embed hotel options inside a broader travel workflow.

Each surface can create real booking intent.

But intent is fragile.

If the surface can only send the traveler away, the booking moment is exposed to leakage. The traveler may bounce, compare again, get redirected into OTA rails, lose the original context or abandon the purchase entirely.

The next distribution challenge is therefore not only how to be visible across more surfaces.

It is how to make the booking moment executable inside those surfaces without losing hotel control.

Moving the button does not mean losing control

This is where precision matters.

Moving the booking button does not mean every surface should become an OTA. It does not mean hotels should surrender guest data, rate control, payment logic or commercial rules to every partner that can generate traffic.

A booking button is only valuable if the infrastructure behind it protects the hotel.

The hotel still needs control of rates, availability, room rules, cancellation policies, taxes, fees, payment requirements, confirmation logic, attribution, settlement and operational sync.

The visible booking surface can change.

The commercial control should not.

That is the difference between distributed booking and uncontrolled channel sprawl.

What actually has to move

The button itself is the easy part.

A button is just an interface. The hard part is the transaction layer behind it.

For a booking button to move safely into AI chats, creator pages, partner apps or embedded maps, the underlying commerce stack has to move with it: live rates and availability, room and package logic, hotel-controlled rules and restrictions, secure payment, booking confirmation, source/creator/partner/agent attribution, settlement logic, booking and operational sync, and post-booking servicing paths.

Without those components, the button is not really a booking button.

It is a redirect.

And redirects are where control often leaks.

Why this matters for hotels

For hotels, this shift changes the meaning of direct commerce.

Direct can no longer be defined only by where the guest started. A guest may start in an AI assistant, a creator guide, a map or a partner app. What matters is whether the hotel keeps control of the transaction.

The hotel needs to know: Was the rate controlled by the hotel? Were the rules respected? Was the guest relationship protected? Was payment handled through a hotel-controlled booking path? Was attribution clear? Were the economics transparent? Did the booking sync correctly?

If yes, the booking surface can extend direct commerce. If no, the hotel may gain visibility while losing control.

This is why the future of hotel distribution cannot be solved only by more traffic, more channels or more content. It has to be solved by infrastructure.

Why this matters for partners and creators

For partners and creators, the moving booking button creates a new opportunity.

Many trusted travel audiences already influence decisions, but they are not built to complete bookings. Their commercial options are usually weak: affiliate links, generic redirects, sponsored posts, manual partnerships or traffic sent into someone else’s marketplace.

That leaves money on the table for the audience owner and weakens the path for the traveler.

A creator should be able to make a guide bookable without becoming a travel technology company. A publisher should be able to turn a destination article into a booking surface without building hotel infrastructure. A partner app should be able to add hotel commerce without rebuilding inventory, payment, confirmation and settlement logic from scratch.

The booking button moving closer to trusted intent is good for partners — but only if the transaction layer is already built.

Why this matters for AI agents

AI agents make the shift even more obvious.

An AI agent can recommend a hotel inside a conversation. It can compare options, explain trade-offs and understand guest intent. But a recommendation is not a reservation.

If the agent cannot access live supply, apply hotel rules, initiate payment and confirm the booking, it will need to hand the traveler to another surface that can transact. That creates the risk that AI discovery becomes another path back to OTA-controlled rails.

For AI agents, the booking button is not a visual button. It is a permissioned transaction capability. Agents need to know what they are allowed to quote, book, modify, confirm and service. That means the infrastructure behind the booking button matters more than the button itself.

Where Wink fits

This is the problem Wink is built to solve.

Wink is not trying to become the place every traveler starts. The travel audience will keep fragmenting across hotel websites, creators, platforms, AI agents, maps, apps and embedded experiences.

Wink’s role is to make hotel-controlled commerce work across those surfaces. That means giving hotels a controlled supply and transaction layer, while giving demand surfaces the right access mode: no-code primitives for creators, hotel teams and partners, and programmable access through APIs and MCP servers for developers, platforms and AI agents.

The visible interface can be a link, card, map, conversion banner, embedded component, agent action or API-driven checkout. The infrastructure underneath remains the same: inventory, rules, payment, booking confirmation, attribution and sync — all resolving in the hotel’s own Booking Engine.

That is how the booking button can move without the hotel losing control.

The new question for hotel distribution

The old question was: How do we bring more travelers back to our booking engine? That question still matters. But it is no longer enough.

The new question is: Can our booking capability appear wherever trusted travel intent already exists?

Not as a redirect. Not as an uncontrolled channel. Not as another dependency layer. As hotel-controlled commerce infrastructure.

The booking button is moving. The hotels that prepare for that shift will not only be easier to discover. They will be easier to book, on their own terms.

Every Travel Audience Can Become a Booking Surface

08.08.2026

Yann Gouriou

Co-founder & COO

Travel demand no longer lives in one place

For years, hotel distribution was described through channels: brand.com, OTAs, metasearch, GDS, wholesalers, corporate platforms and direct sales. That language still matters, but it no longer captures where travel intent is forming.

A traveler may now be influenced by a creator itinerary, a newsletter, a bank app, a map, an AI assistant, a chat interface, a destination guide, a loyalty platform or an embedded travel experience inside another product.

The guest may not begin on a hotel website. They may not begin on an OTA. They may not even think of themselves as shopping for a hotel yet. They are inside an audience environment where trust, context and intent already exist.

That is the shift. The future of hotel distribution will not be one destination. It will be many trusted surfaces where travel intent appears.

An audience is not distribution until it can book

A travel audience can create inspiration, attention and demand. But inspiration is not a booking.

If a traveler reads a hotel recommendation in a blog, sees a property inside a creator guide, asks an AI agent for a stay, or discovers a hotel inside a partner app, the commercial moment is still fragile. If the next step is a generic link, a search page, a redirect loop or an OTA-controlled checkout, the original audience may have created intent without controlling the booking moment.

That is why audience alone is not the infrastructure layer. The real value begins when an audience can become a booking surface — an interface where a traveler can move from intent to a confirmed reservation through controlled rates, rules, payment, confirmation, attribution and operational sync.

Direct is about control, not where the guest started

The industry often confuses channel location with commercial control. A booking does not become direct simply because it happened outside an OTA. A booking does not become hotel-controlled simply because a hotel name or rate appeared inside another interface.

The real question is who controls the transaction. Does the hotel control the rate and the rules? Does the hotel keep the guest relationship and usable guest data? Is payment connected to the hotel-controlled booking process? Is attribution clear and the economics transparent? Is the booking confirmed and synced back into the hotel’s operating workflow?

If the answer is yes, a new surface can extend hotel-controlled commerce. If the answer is no, it is only another place where demand can leak into someone else’s rails.

Why creators and publishers matter

Creators, publishers and independent travel curators are becoming increasingly important because they hold something many transactional platforms do not: trust.

A well-written destination guide, a niche hotel newsletter, a creator itinerary or an expert city map can influence high-intent travel decisions long before the traveler reaches a booking engine. But most of these audiences are structurally under-monetized. They can inspire, recommend and send traffic. They usually cannot transact.

The problem is not that creators lack audience. The problem is that creators lack hotel commerce infrastructure. Without no-code booking primitives, they are forced into weak affiliate links, generic redirects or manual commercial work — friction for the guest, poor attribution for the creator, leakage for the hotel. The opportunity is to turn trusted content into bookable points without asking every creator or publisher to become a travel technology company.

Why platforms and apps matter

The same logic applies to platforms, bank apps, loyalty products, membership communities, event apps and consumer marketplaces. Many already have large audiences, strong user relationships and contextual travel intent. What they usually do not have is hotel booking infrastructure.

To add hotel commerce properly, they need access to live inventory, booking rules, secure payment, confirmation flows, attribution, settlement logic and post-booking synchronization. Building that from scratch is difficult, slow and operationally heavy.

That is why the future does not belong only to platforms with traffic. It belongs to platforms that can connect traffic to hotel-controlled transaction infrastructure.

The infrastructure under the surface

A booking surface looks simple to the traveler. Behind the scenes, it requires a full commerce stack: live rates and availability; room, package and policy logic; hotel-controlled rules and restrictions; secure payment; instant booking confirmation; attribution by source, creator, partner or interface; settlement logic; and booking and operational sync.

This is the part of distribution that is easy to underestimate. The visible surface can be a link, card, map, banner, chatbot, API endpoint or embedded checkout. The infrastructure underneath must still be serious.

No-code and programmable access are two sides of the same layer

Different audiences need different access modes.

A travel creator should not need engineering resources to make a guide bookable. A hotel marketing team should not need a developer to create a campaign link or embedded booking point. A publisher should not need to build a booking engine to monetize intent. That is the role of no-code primitives: bookable links, maps, cards, storefront-style pages and embeddable conversion components.

Developers, platforms and AI agents need a different access mode — APIs, MCP servers and structured commerce endpoints that let them query inventory, apply rules, initiate booking, handle payment and confirm reservations programmatically.

These are not separate strategies. They are two ways into the same hotel-controlled commerce layer.

Where Wink fits

Wink is not trying to be another consumer travel destination. The goal is not to own the travel audience. The goal is to make hotel supply bookable wherever trusted travel intent already exists.

Wink connects hotel-controlled supply to demand surfaces through no-code primitives for creators, partners and hotel teams, and through programmable access for developers, platforms and AI agents. Links, maps, cards, conversion banners, storefronts, APIs and MCP-enabled access can all connect back to the same underlying booking, payment, attribution and sync infrastructure — the Booking Engine.

The hotel keeps commercial control. The demand surface becomes transactional. The traveler gets a shorter path from intent to booking. That is infrastructure, not another destination.

The next distribution advantage

The next advantage in hotel distribution will not come from being present everywhere without control. It will come from making every relevant audience bookable without surrendering the transaction.

Hotels need more than visibility. Creators need more than links. Platforms need more than content feeds. AI agents need more than recommendations. They all need the same thing underneath: hotel commerce infrastructure that can execute.

Every travel audience can become a booking surface — but only if the transaction layer exists.

AI Agents Will Not Book Hotels Without Commerce Infrastructure

06.08.2026

Bjorn Harvold

Co-founder & CTO

The hospitality industry is right to pay attention to AI agents.

Agents will change how travelers search, compare, decide and ask for recommendations. They will become a new interface between traveler intent and hotel supply. But the industry is still at risk of focusing on the wrong part of the problem.

The hard part is not whether an AI agent can mention a hotel. The hard part is whether that agent can book the hotel — directly, accurately and under hotel-controlled rules.

A recommendation is not a reservation. Discovery creates intent. Commerce infrastructure turns that intent into a confirmed booking.

AI can find hotels. That does not mean it can book them.

AI systems are already good at interpreting intent. A traveler can ask for a quiet boutique hotel near a beach, a family property with connecting rooms, or a last-minute city stay with flexible cancellation. The agent can compare options, summarize reviews and explain trade-offs.

That is useful. But it is not yet hotel commerce.

Hotel commerce starts when the agent needs to know what is actually available, at which price, under which rules, with which policy, and whether the booking can be paid, confirmed, attributed and synced back to the hotel’s workflow. That is a different problem from discovery. It is an infrastructure problem.

The booking moment has more parts than search

A hotel booking is not a simple content answer. It requires live rates and availability. It requires room type logic, occupancy rules, taxes, fees, cancellation policy, payment handling, fraud and security controls, guest details, confirmation, servicing, attribution and operational sync.

If any of those pieces are missing, the agent may still recommend the hotel, but it cannot safely complete a direct booking.

This is why hotels should not confuse AI visibility with AI bookability. Visibility gets the hotel into the answer. Bookability gets the booking into the hotel’s commercial system.

Agents will use the rails that can complete the transaction

AI agents are not sentimental about distribution strategy. When a traveler asks an agent to book, the agent needs a reliable route to complete the task. If a direct hotel route is not structured, current and transaction-ready, the agent will look for a route that is.

That creates a familiar risk in a new interface: a hotel may win the recommendation but lose the transaction. The guest may have intended to book the hotel, but the completed transaction may still move through a platform that controls the economics, the data relationship and the post-booking experience.

This is not because the agent is hostile to hotels. It is because the hotel was not commerce-ready for the agent.

Independent hotels have the most to lose

Large brands can invest in technical infrastructure, loyalty ecosystems and direct distribution tools. Independent hotels usually have less room for complexity.

They still need to be accessible to new interfaces. They still need to serve modern traveler behavior. They still need to work with partners, creators, apps and AI agents without giving away control of the booking relationship.

The risk is that AI becomes another layer where independent hotels are visible but not directly bookable — repeating an old distribution pattern in a new format. The hotel appears in the journey. Someone else completes the booking.

What AI agents actually need

For an AI agent to book a hotel directly, it needs more than descriptive content. It needs structured supply, live availability, price and policy logic, booking rules, a secure payment route, confirmation, attribution, servicing paths and booking sync.

In other words, the agent needs hotel commerce infrastructure — readable by machines, stable enough for platforms, and controlled enough for hotels.

This is where APIs and MCP servers matter. APIs give platforms and developers structured system access. MCP servers give agents a tool-based way to understand and execute booking workflows. But the technology only matters if the underlying commercial layer is hotel-controlled.

The missing layer is commerce infrastructure

The next hotel distribution layer is not another search layer. Search is already abundant. The missing layer is the infrastructure that turns AI intent into a direct, controlled transaction.

That layer has to connect the hotel’s approved supply to the agent’s booking workflow. It has to preserve hotel rules, payment flow, attribution and operational sync. It has to make direct booking executable outside the hotel website, without turning every new interface into another uncontrolled intermediary.

This is why the conversation should move from AI discovery to AI commerce readiness. The question is not only, “Can AI find my hotel?” The question is, “Can AI book my hotel directly?”

What this means for hotels

Hotels should prepare for AI agents by making their supply transaction-ready: structured inventory, clear rules, reliable booking paths, payment readiness, confirmation logic, attribution and sync.

It also means thinking beyond the hotel website. Direct booking will increasingly happen through distributed interfaces — AI agents, partner apps, creator content, maps, chat interfaces and embedded experiences. But direct booking should still mean control: control of rates, rules, guest data, attribution, economics and the booking relationship.

Wink’s view

At Wink, our view is that AI agents will not transform hotel booking through discovery alone. They need a transaction layer.

Wink connects hotel-controlled supply to modern demand interfaces through booking, payment, attribution, sync, APIs and MCP-enabled access. That allows hotels to become bookable inside new AI and platform environments without forcing every transaction through someone else’s rails.

The goal is not to make AI another channel that hotels have to manage manually. The goal is to make hotel commerce infrastructure-ready for the interfaces where demand is moving.

The new question

The next battle in AI hotel distribution will not be visibility alone. It will be execution. For any agent, the test is whether it can:

access live hotel-controlled supply;
understand the rules;
handle payment;
confirm the booking;
attribute the demand; and
sync the reservation back to the hotel’s workflow.

If the answer is no, the agent may still recommend the hotel. But it will not book it directly. That is why AI agents will not book hotels without commerce infrastructure — and it all resolves in the hotel’s own Booking Engine.

Hotel Commerce Needs to Be Programmable and Shareable

04.08.2026

Bjorn Harvold

Co-founder & CTO

The last wave of hotel distribution was about adding channels. The next wave is about making hotel commerce accessible wherever demand appears.

That does not mean giving every surface its own disconnected booking flow. It means exposing one controlled hotel commerce layer through the right access mode for each audience.

For developers, platforms and AI agents, access needs to be programmable: APIs, MCP servers, structured inventory, rules, payment, confirmation, attribution and sync. For hotels, partners and creators, access needs to be shareable: bookable links, maps, cards, embedded components and storefront-style tools that can be placed into content, campaigns and partner surfaces without engineering work.

The mistake is to treat those as separate products. They are not. They are two access modes into the same hotel-controlled transaction layer.

Controlled supply is only step one

A controlled supply layer is the foundation. It gives the hotel one trusted place for rates, availability, rules, policies, content and commercial permissions. But a supply layer only creates value if demand can reach it.

That is where the next infrastructure question begins: how should different demand surfaces access hotel-controlled supply without breaking the hotel’s control of economics, guest data, rules, attribution and operational flow?

The answer is not one interface for everyone. A developer building a travel product does not need the same access mode as a travel creator publishing a guide. An AI agent does not need the same access mode as a hotel marketer sharing a campaign link. The access mode changes. The transaction layer underneath should not.

Not every user is a developer

Hotel commerce cannot be API-only. Most of the people who can create demand for hotels are not going to build against an API.

A hotel revenue team may want to publish a package in seconds. A creator may want to turn a destination article into bookable content. A destination partner may want to share a curated route. A marketing team may want to place a map or conversion card inside a campaign page.

Those users need no-code primitives — links that can be shared anywhere online, embeddable cards, dynamic maps, and simple components that turn travel intent into a controlled booking path (this is what Studio and WinkLinks are for). The goal is not to make them learn hotel connectivity. The goal is to make hotel-controlled supply usable by the people and partners already creating demand.

Not every interface is human

At the same time, hotel commerce cannot be no-code-only. The most important new demand surfaces will increasingly be software surfaces.

Travel platforms, fintech apps, loyalty products, itinerary tools, AI agents and agentic commerce systems need structured technical access. They need to query supply, understand rules, price stays, initiate payment, create confirmation, carry attribution and sync the booking back into the hotel’s operating workflow.

This requires programmable infrastructure. APIs matter because platforms need stable system-to-system access. MCP servers matter because AI agents need a reliable way to understand and execute tool-based commerce workflows. Structured booking logic matters because a recommendation without execution is not commerce. If the technical layer is weak, AI agents and platforms will default to rails that can complete the transaction — and that is where hotels risk losing control.

Separate products create fragmented commerce

Many hotel technology stacks separate these problems. The booking engine is one system. The website widget is another. Partner links sit somewhere else. Developer APIs are treated as a technical add-on. Attribution becomes a reporting problem after the fact. Payment and settlement sit in another layer again.

That fragmentation creates a strategic issue: each demand surface may look connected, but the hotel does not get one coherent commerce system.

The future needs a different pattern. No-code primitives and programmable access should not be disconnected products. They should be different doors into the same transaction layer. That is what makes the model scalable.

Programmable supply

Programmable supply is about making hotel commerce usable by machines and software teams. A platform should be able to ask what is available, under which rules, at which price, and complete the booking through controlled infrastructure. An AI agent should be able to move from intent to transaction without sending the guest to a third-party platform simply because that platform is easier to book. A developer should be able to integrate hotel commerce into a product without rebuilding inventory, payment, confirmation and attribution logic from scratch.

That is the value of APIs and MCP servers: they make hotel-controlled supply executable.

Shareable supply

Shareable supply is about making hotel commerce usable by humans without engineering work. A hotel should be able to publish a bookable offer as a link. A creator should be able to embed a bookable map or card in a guide. A partner should be able to place hotel inventory into a relevant surface without becoming a hotel technology company.

This matters because demand is increasingly distributed. Travel inspiration happens in articles, social content, newsletters, maps, communities, bank apps, chat interfaces and niche platforms. If those surfaces can only inspire but not transact, the booking will often leak elsewhere. Shareable primitives close that gap — they turn intent into a controlled booking route.

One transaction layer underneath

The important point is that programmable and shareable access should not create two versions of the truth. There should be one hotel-controlled transaction layer underneath: the same approved supply, the same rules and policies, the same payment readiness, the same confirmation logic, the same attribution, the same booking sync.

That is what allows hotels to expand access without losing control. The surface can be a website, a creator guide, a map, a partner app, an API or an AI agent. The commerce layer remains consistent.

Why this matters for hotels

Hotels need new demand — but they should not have to choose between reach and control. A hotel should be able to work with creators without handing over the guest relationship, power partners without recreating OTA economics, serve AI agents without letting the transaction default to someone else’s platform, and give developers access without turning every integration into a bespoke project.

When hotel commerce is programmable and shareable, the hotel can be bookable across more surfaces while keeping its commercial rules, rates, attribution, payment flow, guest data and operational sync under control. The prize is not more channels for the sake of more channels. The prize is controlled distribution at internet scale.

Wink’s view

At Wink, our view is simple. Hotel commerce needs to be both programmable and shareable — programmable for developers, platforms and AI agents; shareable for hotels, partners and creators. Both connect to the same hotel-controlled booking, payment, attribution and fulfillment layer.

That is what makes Wink infrastructure rather than another isolated demand channel. Wink is not trying to replace every interface where travel demand appears. Wink is building the commerce infrastructure that lets those interfaces transact directly against hotel-controlled supply.

The next distribution question

The next question for hotels is not only, “Where should we be visible?” It is, “Can every relevant surface access our supply in the right way and complete a controlled booking?”

For some surfaces, the answer will be API access. For others, MCP-enabled agent access. For many, a link, a map, a card, an embedded component or a storefront-style experience. The same layer carries all of it — supply, rules, payment, confirmation, attribution and sync all resolving in the Booking Engine.

The winning model is not API-only. It is not no-code-only. It is one hotel-controlled transaction layer with many access modes. Programmable for machines. Shareable for humans. Bookable everywhere control matters.

Being Discoverable Is Not the Same as Being Bookable

18.07.2026

Bjorn Harvold

Co-founder & CTO

The hotel industry is starting to ask an important question: will AI find my hotel? That question matters. But it is incomplete.

In the age of AI search, LLMs and agentic commerce, being discoverable is only the first step. The more important question is: can AI complete a hotel-controlled booking?

Visibility is not conversion

Hotels have spent years learning how to appear in search results — SEO, metasearch, OTA ranking, Google Hotel Ads, review optimization, content strategy, social media, influencer campaigns and brand.com performance. All of these disciplines were built around one objective: make the hotel visible when demand appears.

AI changes the interface, but not the commercial truth. A guest may no longer search through ten browser tabs. They may ask an AI assistant for a quiet boutique hotel in Paris, a family-friendly resort in Phuket, or a business hotel near a conference venue in Singapore.

The AI can summarize options, compare locations, read reviews, understand intent and recommend a property. But recommendation is not the same as booking. A hotel can be perfectly described by AI and still lose the transaction.

AI discovery will become a commodity

Over time, AI discovery will become very good. LLMs will understand hotel content better, read structured data more efficiently, interpret guest preferences with more nuance, and combine location, price, amenities, reviews, policies and context into increasingly useful recommendations.

This will help travelers. It may also help independent hotels appear in more relevant conversations. But discovery alone does not solve distribution.

If an AI assistant recommends a hotel but cannot complete a hotel-controlled booking, the guest will still be pushed somewhere else. The transaction will move to the platform that has the infrastructure to execute it — an OTA, a super app, a travel marketplace, any intermediary that can complete the booking while taking commission, owning the customer relationship or controlling the data.

The risk is simple: AI may find the hotel, but another platform may own the booking, the economics and the guest relationship.

Bookability requires infrastructure

To be bookable by AI, a hotel needs more than good content. It needs commercial infrastructure that can answer and execute in real time: live rates and availability, room types and restrictions, cancellation policies, occupancy rules, taxes and fees, secure payment, booking confirmation, attribution, settlement, PMS or booking sync, and post-booking servicing.

This is not traditional marketing. This is not just SEO for AI. This is transaction infrastructure. A hotel website can show content to a human. A booking engine can convert a brand.com visitor. But agentic commerce requires something broader: hotel supply that can be read, understood and transacted by software across many interfaces.

Human-readable is not enough

Most hotel content was built for people — photos, descriptions, amenities, reviews, packages and destination copy that help guests decide. They are important, but they are not enough for AI commerce.

AI agents need structured, machine-readable supply. They need to know not just what a hotel is, but what can be booked, under which rules, at what price, with which payment flow and with what confirmation process. A beautiful hotel profile is not the same as a bookable commercial endpoint.

This distinction matters because the next generation of travel interfaces will not always send users to a hotel website first. The booking moment may happen inside a chat interface, a travel planning assistant, a creator article, a map, a bank app, a loyalty platform or another embedded digital experience.

That does not automatically make the booking direct. A booking is direct only when the hotel keeps control of the commercial relationship — no commission-taking intermediary, hotel-controlled rules and rates, and guest data owned by the hotel. If the hotel is not transaction-ready in those environments, the booking will flow through whoever is.

Independent hotels are especially exposed

Independent hotels have a real opportunity in AI discovery. AI can surface more nuanced recommendations than traditional paid search. It can understand why a traveler may prefer an independent hotel over a large brand, matching guest intent to personality, location, design, service style and experience. That could be powerful — but only if the hotel can capture the transaction.

Otherwise, independent hotels risk becoming AI-visible but commercially dependent. They may be recommended more often, but still lose the guest relationship, payment flow, attribution, data and economics to platforms that can complete the booking. This is the same structural problem the industry has faced before: distribution shifts create opportunity, but if hotels do not control the transaction layer, the value concentrates elsewhere.

The new question for hotels

Hotels should still care about AI visibility. They should make their content accurate, structure their data, keep rates, policies and amenities clear, and ensure AI systems can understand who they are and what they offer. But that is only the beginning. The real test is whether the hotel can move from being recommended to being booked.

Can an AI agent access live inventory? Can it respect hotel-controlled rules? Can it take payment securely? Can it confirm the booking instantly? Can it attribute the source of demand? Can it settle the transaction correctly? Can the hotel keep control of the guest relationship and guest data? That is the difference between discoverability and bookability.

Wink’s view

At Wink, our view is that the future of hotel distribution will not be defined only by where guests search. It will be defined by where travel intent can be converted into a confirmed booking. That requires hotel-controlled supply to become programmable, bookable and payable across new demand interfaces.

AI agents are one of those interfaces. But they are not the only one. Creators, publishers, developers, platforms, bank apps, maps, social content and embedded digital experiences are all becoming places where travel demand can appear.

The infrastructure challenge is the same across all of them. Hotels need to expose their supply in a controlled way. Demand partners need a way to transact without becoming commission-taking intermediaries or owning the guest relationship. Guests need a smooth booking experience. Payments, confirmation, attribution and settlement need to work behind the scenes.

That is the layer Wink has built. Not a consumer destination. Not another OTA. Not only a booking engine. A transaction infrastructure layer for hotel commerce.

The future is not just search

The next era of travel distribution will not be won by visibility alone. Hotels will need to be discoverable, yes. But more importantly, they will need to be bookable wherever intent appears. That is the shift.

The question for hotels is no longer only: will AI find me? It is: when AI finds me, can the guest book in a way where the hotel keeps the economics, the rules and the guest relationship?