Agentic AI in Hotels: When Software Stops Recommending and Starts Doing
A copilot that is wrong wastes a minute. An agent that is wrong has already moved the inventory, sent the message, or issued the refund. The capability upgrade is incremental; the risk model change is not.
For three years the hotel industry's relationship with artificial intelligence has been fundamentally advisory. The revenue system proposed a rate and a human accepted it. The messaging platform drafted a reply and a human sent it. The forecasting tool produced a number and a director of finance decided whether to believe it. In every case the software's output was language, and the consequential act — the keystroke that changed something in a system of record — belonged to a person. That arrangement was comfortable, and it was comfortable for a reason: it meant the worst thing a model could do was waste somebody's time.
That arrangement is now dissolving, and not gradually. Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from fewer than 5% a year earlier. That is not a forecast about a new category of software a hotel might choose to buy. It is a forecast about the software a hotel already owns. The PMS, the CRM, the messaging platform, the accounting stack and the work-order system are all shipping agents into products that properties licensed when those products were passive. The decision facing most operators is not whether to adopt agentic AI. It is whether to govern it before or after it is already executing inside their systems of record.
This article is about that governance, but it is not a compliance lecture. The premise is that agentic capability in hotels is genuinely valuable — that there are back-office workflows in every property consuming hundreds of management hours a year that an agent can absorb entirely — and that the reason so few operators are capturing that value has almost nothing to do with model quality. McKinsey's analysis of agentic economics found that while roughly two-thirds of organisations have experimented with autonomous agents, fewer than one in ten have scaled them into tangible business returns. That gap is not a technology gap. It is the gap between a demo, which needs an agent to succeed once, and an operation, which needs it to fail safely a thousand times.
What Actually Changes When Software Gets Write Access
The word "agent" has been applied to enough different things in the past eighteen months that it has nearly stopped carrying information. For an operator's purposes the definition can be made precise and useful with two criteria. An agent is software that (a) holds credentials to write to systems of record, and (b) selects its own sequence of steps rather than executing a fixed script. Both criteria matter, and the second is the one people underestimate.
Robotic process automation had the first property for two decades. A scripted bot with database credentials can post a night audit journal entry perfectly well, and hotels have been running exactly that for years. What it cannot do is decide what to do when the ledger does not balance. It fails, it stops, and a human picks up the pieces — which is, in its way, a safety property. An agent in the same position reads the variance, forms a hypothesis, queries three other systems to test it, and takes corrective action. That is enormously more capable and it removes the failure mode that used to guarantee a human got involved. The bot's brittleness was doing safety work nobody had accounted for.
A brittle script fails loudly and a human intervenes. A capable agent fails quietly and confidently, having already acted. Most hotel control environments were designed around the first behaviour and have never been tested against the second.
This is why the copilot-to-agent transition is not a capability upgrade with a bit of extra risk attached. It is a change in what the control environment has to do. Under a copilot regime, the human in the loop is the control: every consequential act passes through a person who can be held accountable and who, at minimum, saw what was about to happen. Under an agentic regime that control is gone by design — the entire value proposition is that the person no longer has to be there — and it has to be replaced by something the property builds deliberately. The table below sets out the dimensions that shift.
| Dimension | Copilot model | Agent model | Control that closes the gap |
|---|---|---|---|
| Cost of an error | Wasted attention; suggestion discarded | State already changed in a system of record | Reversibility screening before deployment; defined rollback path |
| Detection | Immediate — a human read the output | Deferred — nobody was watching the step | Action log with anomaly thresholds and daily exception review |
| Accountability | The person who clicked accept | Ambiguous between vendor, configurer and operator | Named human owner per agent, documented in the runbook |
| Scope of blast radius | One decision, one moment | Every record the credential can reach, at machine speed | Least-privilege scoped credentials; per-agent rate and volume caps |
| Failure signature | Visibly wrong or obviously useless | Plausible, confident and internally consistent | Independent verification against a second source before high-tier action |
The last row is the one that catches experienced operators off guard. Legacy automation failed in ways that looked like failure. Agentic systems fail in ways that look like work. An agent that has misread a rate-parity condition does not produce a garbled output; it produces a well-reasoned adjustment, logs a coherent rationale, and moves on. Gartner's May 2026 guidance makes a related and important point: applying uniform governance across all agents is itself a driver of failure, because it forces either paralysing friction on low-risk tasks or unacceptable looseness on high-risk ones. Governance has to be tiered to the action, which is where a practical framework starts.
The Autonomy Tier Framework
Every conversation about agentic deployment in a hotel gets more productive the moment it stops being about "should we use agents" and becomes about "at what tier, for which workflow." Tiering does two things. It gives the property a vocabulary for the trade-off between speed and control that is precise enough to write into a runbook, and it gives a workflow a place to start and a path to graduate. Nothing should be commissioned at its final tier. Everything should earn its way up.
| Tier | What the agent does | Human checkpoint | Reversal window | Representative hotel workflow |
|---|---|---|---|---|
| Tier 0 — Observe | Reads systems, surfaces anomalies, writes nothing | None required | Not applicable | Overnight variance detection across PMS, POS and ledger |
| Tier 1 — Recommend | Proposes a specific action with rationale and evidence | Human executes the action manually | Not applicable | Rate change proposals; upsell targeting lists |
| Tier 2 — Act on approval | Prepares and stages the action; executes only after approval | Explicit approval per action | Pre-execution | Vendor invoice coding and posting; group block adjustments |
| Tier 3 — Act and notify | Executes immediately, notifies the owner with an undo path | Post-hoc review within a defined window | Minutes to hours | Guest messaging replies; work-order routing and escalation |
| Tier 4 — Act autonomously | Executes within policy bounds; only exceptions surface | Aggregate review on a scheduled cadence | Bounded by policy caps | Housekeeping sequence optimisation; folio reconciliation within tolerance |
Three rules make the framework operational rather than decorative. The first is that tier is a property of the action, not of the agent. A single guest-messaging agent can sit at Tier 4 for answering a question about pool hours, Tier 3 for confirming a late checkout inside policy, Tier 2 for anything that touches the folio, and Tier 1 for a rate quote outside published parameters. Vendors will resist this framing because it complicates their configuration model, and operators should insist on it anyway. An agent granted a single blanket autonomy level is an agent whose blast radius is defined by its most dangerous permitted action.
The second rule is that promotion between tiers is evidence-based and documented. A workflow moves from Tier 2 to Tier 3 when it has accumulated a defined volume of approvals at Tier 2 with an override rate below an agreed threshold — a hundred actions with fewer than two corrections is a reasonable starting bar, adjusted for how expensive an error is. The point is not the specific numbers. It is that promotion becomes a decision supported by the property's own operating data rather than by fatigue with clicking approve.
The third rule is that every tier above 1 requires a named human owner, recorded in the runbook, who is accountable for that agent's behaviour and who receives its exceptions. This sounds bureaucratic and is the single highest-value control on the list. Agentic deployments fail into ambiguity: something goes wrong, the vendor points at configuration, the configurer points at the model, and the property discovers nobody was actually watching. A name in a document prevents most of that.
Human-in-the-Loop, and How It Quietly Stops Working
Every vendor deck contains the phrase "human in the loop," and it functions as a reassurance rather than a design. In practice, approval checkpoints degrade in three predictable ways, and a property should design against all three before the first agent goes live.
The first is approval fatigue. A checkpoint that fires forty times a shift will be approved without inspection by the third week; this is not a failure of staff diligence but a well-documented property of human attention under repetitive load. Guidance on enterprise agent guardrails makes the point directly: approvals degrade under time pressure and volume, producing a false sense of safety that is arguably worse than no checkpoint at all, because the organisation believes it has a control it does not have. The design response is to make checkpoints rare and consequential. If a checkpoint fires on more than roughly one in ten agent actions, the tier is set wrong or the policy bounds are drawn too narrowly.
The second is context starvation. An approval request that says "Agent proposes to adjust rate for 14 Nov, approve?" is not a control, because the approver has no basis on which to say no. A checkpoint has to carry the evidence the agent used, the alternatives it considered, and the specific condition that triggered the escalation. If the approver would have to open three other systems to evaluate the request, they will not, and the checkpoint has become a rubber stamp with extra steps.
The third is escalation asymmetry. Most implementations escalate on uncertainty — the agent asks when its confidence is low. This is exactly backwards for the failure mode that matters, because the expensive errors are the confident ones. Escalation should be driven primarily by the consequence of the action, not the agent's self-assessed certainty. Any action above a monetary threshold, any action touching a VIP or a contracted account, any action that cannot be reversed within the shift: these escalate regardless of how sure the agent is.
Confidence is not a safety signal. The agent errors that cost a hotel money are not the ones where the model hesitated — they are the ones where it was certain, coherent, and wrong.
The Action Log Is the Product
If a property builds only one thing before deploying agents, it should be the action log. Not the dashboard, not the integration, not the prompt library — the immutable record of what each agent did, when, on whose authority, with what inputs, and what changed as a result. This is the substrate for incident investigation, for tier promotion decisions, for vendor accountability, and increasingly for regulatory obligation. It is also the artefact that survives when the vendor is replaced.
The regulatory dimension is no longer theoretical. The EU AI Act's high-risk obligations, with enforcement arriving in August 2026, require logging and auditability of AI decisions alongside documented human oversight mechanisms, with penalties at the top of the scale reaching €35 million or 7% of global annual revenue. Most hotel workflows will not be classified high-risk, and operators should resist the vendor tendency to invoke the Act as a scare tactic. But an international operator with European properties, or one running agents against employment-adjacent workflows such as scheduling, should assume the documentation burden applies and build for it now, when it is a configuration choice, rather than later, when it is a remediation project. Enterprise audit trail practice is converging on routing agent logs into the same monitoring infrastructure as other system events rather than leaving them inside vendor consoles, and that principle transfers cleanly to hospitality.
| Log field | What it must capture | Why it matters | Practical retention |
|---|---|---|---|
| Actor identity | Which agent, which version, which credential scope | A model update changes behaviour; without version you cannot correlate a defect to a release | Life of the agent + 2 years |
| Authority | Tier, policy bounds in force, approving human if any | Establishes whether the action was permitted, separate from whether it was correct | 7 years |
| Inputs and evidence | The records read and the specific values that drove the decision | Enables root-cause analysis distinguishing bad data from bad reasoning | 90 days full, then summarised |
| Action and delta | The call made, the prior state, the resulting state | The only reliable basis for rollback and for financial reconstruction | 7 years |
| Outcome and reversal | Success, failure, retry, and any subsequent undo with its actor | Distinguishes an agent that was corrected from one that was never checked | 7 years |
Two operating disciplines make the log useful rather than merely large. The first is that rollback must be a designed capability, not an improvised one. For each agent action type, the property should be able to answer three questions before go-live: what is the undo procedure, who can execute it, and how long is it viable? Some actions are genuinely irreversible — a message sent to a guest, a commitment made on a call — and for those the correct control is not rollback but a lower tier and a tighter policy bound. Confusing "we can fix it afterwards" with "we can undo it" is how properties end up honouring rates they never intended to offer.
The second is a standing exception review. The log should feed a short daily or weekly review of overrides, retries, escalations and near-misses, owned by the named human owner. This is the mechanism by which the property learns; without it, the log is an archive that gets opened once, during an incident, when it is too late to have prevented anything.
Screening Workflows: The Readiness Matrix
Not every hotel workflow is a candidate, and the ones that get automated first are too often the ones that demo well rather than the ones that are safe. Three screens do most of the work. Reversibility: can the action be undone within the shift at trivial cost? Guest visibility: does a failure reach a guest directly, or does it stay internal where it can be caught? Data sufficiency: does the agent have access to a complete, current, machine-readable picture of the state it is acting on, or is it inferring from partial data?
That third screen fails more hotel workflows than the other two combined, and it fails them for infrastructural reasons. An agent needs write APIs with granular scopes, idempotency so a retried call does not double-post, and event streams so it knows when state changed underneath it. A 2026 review of thirteen major hospitality PMS platforms found exactly one shipping an official Model Context Protocol server and only three publishing an llms.txt index for agents. Apaleo's MCP server was the first from a hospitality PMS, wrapping existing API endpoints as standardised tools so that any protocol-compatible assistant can connect without a bespoke integration. That is the direction of travel, and it is early.
| Workflow | Reversibility | Guest visibility | Data sufficiency | Starting tier |
|---|---|---|---|---|
| Overnight variance detection and exception flagging | Total — writes nothing | None | High | Tier 0–1 |
| AP invoice capture, coding and posting | High — reversing entry | None | High | Tier 2 |
| Work-order creation, routing and escalation | High — reassign or close | Indirect | Medium–high | Tier 3 |
| Pre-arrival and in-stay guest messaging | Low — a sent message cannot be unsent | Direct | Medium | Tier 3 with tight bounds |
| Housekeeping sequencing and reassignment | High — re-sequence | Indirect | Medium | Tier 3–4 |
| Rate and inventory changes | Medium — distribution lag | Direct via channels | Medium | Tier 1–2 |
| Refunds, comps and folio adjustments | Low — financial and reputational | Direct | High | Tier 2, hard caps |
| Group and contract negotiation correspondence | Very low — commitments bind | Direct | Low | Tier 1 only |
The bottom two rows deserve emphasis because they are where enthusiasm most often outruns judgment. Financial adjustments and contractual correspondence are precisely the workflows where an agent's fluency is most seductive and its errors most expensive. A refund agent operating at Tier 3 with a generous cap is a control weakness dressed as an efficiency gain. Keep both at low tiers indefinitely; the value in these workflows is in preparation and drafting, not execution.
The First Five Workflows Worth Automating End to End
Applying the screens above to a typical full-service property produces a consistent short list. These five share a profile: internally contained, reversible, sitting on data the property already has in machine-readable form, and consuming a quantity of management time that makes the integration work pay for itself before any strategic benefit is counted.
| # | Workflow | Why it qualifies | Indicative time recovered | Failure mode to instrument |
|---|---|---|---|---|
| 1 | Overnight reconciliation and morning exception brief | Read-heavy, zero guest exposure, immediate management value | 60–90 min per day of supervisor time | Silent omission — a variance the agent failed to surface at all |
| 2 | AP invoice capture, coding and three-way match | Structured inputs, reversible entries, clean audit trail | 15–25 hours per month in accounting | Confident miscoding to a plausible but wrong GL account |
| 3 | Work-order intake, routing, escalation and closure chasing | Internal, reversible, high volume of low-value coordination | 8–12 hours per week across engineering and front office | Premature closure without verified completion |
| 4 | Pre-arrival messaging and in-policy request handling | High volume, tight policy bounds, strong ancillary upside | Majority of routine inbound inquiries deflected from staff | Commitment outside policy that the property must then honour |
| 5 | Housekeeping sequencing against live arrival and stay-over state | Continuously re-optimisable, internal, materially better than static boards | Reduced turn wait and fewer manual re-sequences per shift | Optimising throughput at the expense of a VIP or accessibility need |
The fourth is the only guest-facing entry, and it is on the list because the economics are hard to ignore and because the policy bounds can be drawn tightly. Published benchmarks put AI-initiated upsell conversations in the range of eight to fifteen dollars of incremental ancillary revenue each, with strong operators reporting materially more, and 2026 messaging benchmarks show a substantial majority of routine inbound inquiries resolved without human involvement. Those numbers are real, and they are also vendor-sourced; treat them as an upper bound and baseline your own property before deployment so you are measuring a delta rather than arguing about one.
What connects all five is that the hard work is not the agent. It is the plumbing underneath: reconciling identifiers so the same room, folio, asset and guest can be joined across four systems; wiring the write APIs and the event streams; standing up the action log; and building the rollback path for each action type. That integration layer is consistently the most under-budgeted line in an agentic programme and consistently the one that determines whether it works. Properties approaching this stage often benefit from designing the integration and logging architecture once, against the full workflow roadmap, rather than assembling it incrementally from whatever three vendors happened to sell them — explore our Custom AI Integrations & Automations service → for the approach we use with operators making this transition.
The Distribution Question Nobody Asked For
There is a second agentic story running in parallel, and it is not about the hotel's own agents. It is about the guest's. IDC forecasts that 30% of travel bookings will be executed by AI agents by 2030, and the infrastructure for that is being assembled now: a February 2026 partnership between Sabre, PayPal and MindTrip set out to build an end-to-end agentic booking pipeline in which a traveller describes a trip in natural language, an assistant queries live inventory across airlines and hotel properties, and payment completes inside the conversation without a browser ever opening.
For an individual property the implication is uncomfortable and simple. An agent that cannot access a hotel's live availability, or that finds inconsistent descriptions of the property across sources, or that cannot resolve what the room actually includes, will not recommend it — and the guest never learns the hotel existed. This is not a ranking penalty of the kind hoteliers learned to manage in the OTA era. It is absence. Industry analysis of 2026 agentic trends is fairly consistent that a two-tier world is forming between properties whose data is machine-legible and those whose is not.
The practical response is unglamorous and largely within a property's control: structured, consistent, current property data across every surface an agent might read. Accurate room-type attributes and inclusions. Consistent amenity descriptions between the brand site, the channel manager and the CRS. Machine-readable policies. Rate plans whose conditions are expressed as data rather than as prose in a footnote. This is not an AI project. It is the content and data hygiene work that has been deferred at most properties for a decade, now carrying a direct revenue consequence. Independent properties in particular should treat this as the higher-priority half of their agentic agenda, because the internal efficiency work can be sequenced over years while the distribution shift is not waiting.
A Twelve-Month Sequence
The pilot-to-production gap McKinsey identified is a sequencing failure more than a technology one. Properties commission an impressive agent, discover it cannot be trusted at the tier the business case assumed, and quietly retire it. The sequence below inverts that by building the control environment first, when it is cheap, and letting capability follow.
Months 1–3 — Instrument before you automate. Deploy Tier 0 and Tier 1 agents only. Stand up the action log, even though nothing is writing to it yet. Reconcile identifiers across the PMS, work-order system, accounting stack and messaging platform. Baseline the workflows on the shortlist: how many hours, how many errors, how long to resolve. This is the measurement discipline that separates the programmes that scale from the ones that stall, and skipping it is why so many properties end up unable to prove a benefit they probably achieved.
Months 4–6 — First write access, tightly bound. Promote one back-office workflow to Tier 2 — AP invoice handling is the usual right answer. Name its owner. Run the exception review weekly from day one, not from the first incident. Track the override rate as the primary metric; it is the signal that governs every subsequent promotion decision.
Months 7–9 — Graduate and add. Promote the first workflow to Tier 3 if and only if the evidence supports it. Add work-order routing at Tier 3 and the overnight brief at Tier 1–2. Begin guest messaging at Tier 3 with narrow policy bounds and a hard escalation on anything touching the folio. In parallel, complete the structured property-data work for agentic distribution, which has no dependency on any of the above and should not wait for it.
Months 10–12 — Consolidate rather than expand. Resist the pull toward a sixth and seventh workflow. Use this quarter to harden what exists: test the rollback paths for real, run a deliberate incident exercise, review credential scopes against what the agents actually used, and rewrite the runbooks against what was learned. Then produce the honest measurement against the Month 1 baseline. Organisations that establish agentic capability early do accumulate compounding advantages in data and process, but that compounding starts from a controlled deployment, not from a collection of pilots.
The Owner's Case
For an owner or asset manager the argument reduces to three propositions. The first is that this is not a discretionary technology decision, because Deloitte expects as many as 75% of companies to invest in agentic AI by the end of 2026 and the property's existing vendors are shipping agents into products it already licenses. The choice is between governed and ungoverned, not between adopting and abstaining.
The second is that the economics are unusually favourable at this specific moment. US hotel labour cost is forecast at $131 billion in 2026 against RevPAR growth under 1%, with around 65% of North American hotels reporting staffing shortages in AHLA data. When top-line growth cannot fund the operation, the margin has to come from work that stops being done by hand. Agentic automation is the first technology in a decade that addresses coordination overhead — the reconciling, chasing and transcribing that consumes management hours without producing anything a guest can perceive — rather than merely making individual tasks faster.
The third is that the gap between experimentation and return is a governance gap, and governance is cheap to build early and expensive to retrofit. With only 32% of hotel owners reporting AI embedded across most operations despite near-universal experimentation, the differentiator over the next three years will not be which properties tried agents. It will be which ones built the tiering, the logs and the rollback paths that let them keep the ones that worked and switch off the ones that did not — and could tell the difference.
Frequently Asked Questions
What actually distinguishes an agent from the AI tools we already have?
The distinguishing feature is not intelligence, it is write access combined with the ability to choose its own sequence of steps. A copilot reads your data and produces language: a rate recommendation, a draft reply, a summary of last night's arrivals. A human then decides whether to act, and the act itself is a human keystroke in a system of record. An agent holds credentials to those systems and executes the sequence itself, deciding at each step what to do next based on what the previous step returned. That difference means the failure surface moves. A copilot that is wrong costs you the minute it takes to notice and discard the suggestion. An agent that is wrong has already moved the rate, sent the message, issued the refund, or reassigned the room, and the cost is whatever it takes to unwind that in a system that was not designed to be unwound. Everything else about agentic deployment — tiering, checkpoints, logging, rollback — exists to manage that single structural change.
Is our PMS ready for this, and what do we do if it is not?
Most are not, and honesty about that saves a great deal of wasted money. An agent needs three things from a system of record that a dashboard does not: a write API with granular scopes, an idempotency mechanism so a retried call does not double-post, and a webhook or event stream so the agent knows the state changed. A 2026 review of thirteen major hospitality PMS platforms found exactly one shipping an official Model Context Protocol server, and only three publishing an llms.txt index for agents, which is a fair proxy for how thin the ground still is. If your PMS lacks write APIs, the correct sequence is not to abandon the programme but to invert it: start with agents in the systems that do have good APIs — the messaging platform, the work-order system, the accounting stack, the CRM — and treat PMS write access as a procurement requirement at your next renewal rather than an engineering project now. Never let a vendor bridge the gap with screen-scraping or robotic process automation against a user interface. It works in the demo, it breaks silently on the next UI release, and it produces no usable action log.
How do we handle it when an agent makes a mistake that reaches a guest?
Decide in advance, in writing, because the moment itself is the worst possible time to invent a policy. Three things need to be settled before the first agent is switched on. First, the standing commitment: the property honours what the agent committed to the guest, even when the agent was wrong, and absorbs the cost. Arguing with a guest about whether the system that answered them was authorised to do so is an unwinnable conversation and a reputational cost far exceeding the honoured rate. Second, disclosure: staff should know which channels are agent-handled so they never contradict a commitment they did not know had been made, and the escalation path from agent to human should be visible to the guest at any point. Third, the feedback loop: every guest-visible error is a defect with a root cause, and it should be logged, categorised, and reviewed on the same cadence as any other service failure. Properties that treat agent errors as embarrassments to be smoothed over rather than as data lose the only mechanism they have for making the system better.
Does an agent replace headcount, and how should we talk to the team about it?
In hotels, in 2026, almost never — and framing it that way is both inaccurate and self-defeating. The honest arithmetic is that most properties are already running below the staffing they would prefer, with a majority of North American hotels reporting shortages, and the work agents absorb is overwhelmingly the reconciliation, transcription, and status-chasing that nobody was ever hired to enjoy. The realistic outcome is a reallocation: hours move from the back office to the guest, and the shift supervisor stops spending the first ninety minutes of the day assembling a picture of what happened overnight. That is a genuine improvement in the work, and it is the argument that gets adoption. It is also worth being straight with the team about the second-order effect, which is that agentic capability makes the remaining roles more judgment-intensive rather than less, because the routine cases stop reaching a human at all and what arrives is the exception. Hire and train for that. The property that promises nothing will change is making a promise it cannot keep, and the credibility cost of that lands on the next initiative.
What does a realistic first-year agentic programme cost and return?
For a single full-service property, budget in three buckets rather than one line. Software is the smallest: agent-capable guest messaging and workflow tooling for a mid-sized property generally runs in the range of a few hundred to a couple of thousand dollars a month depending on volume and integrations. Integration and instrumentation is the bucket owners consistently under-fund — the connectors, the identifier reconciliation, the action log, the rollback tooling — and it typically exceeds the first-year software spend. The third bucket is management attention, which is real cost even though it never appears on an invoice. On the return side, the credible near-term line items are recovered labour hours in back-office workflows, incremental ancillary revenue from consistent upsell conversation coverage, and faster response times in messaging channels. Published benchmarks put AI-initiated upsell conversations in the range of eight to fifteen dollars of ancillary revenue each, with strong operators reporting materially more. Treat vendor case studies as an upper bound, model your own baseline before deployment so you can measure a delta rather than argue about one, and be sceptical of any business case whose payback depends on headcount reduction you have no intention of executing.
Peter Mack is a hospitality technology strategist and founder of HospitalityOS, helping independent hotels and resorts implement AI systems that drive revenue and reduce operational costs. With 25 years in hospitality operations and technology, he has worked with properties of all types and in every region as both a General Manager, Founder, Operator, Asset Manager, and Owner.