Speaker script
Nine minute delivery
Nine slides and a separate appendix. The script contains about 949 words. At 130 words per minute, allow 102 seconds for transitions and explaining the visuals, then one minute of breathing room.
This is a pacing model checked against the actual browser sequence, not a recorded human oral rehearsal. The appendix is outside the timed pitch.
0:00 to 0:30 · 30 seconds
AI coordination for hospitality groups
We propose an AI operating layer for independent small and midsize hospitality groups. It connects guest requests, approved property knowledge, existing hotel systems and the people responsible for service. The starting proposition is practical coordination across properties. This is a proposed product, with operator acceptance still to be demonstrated.
0:30 to 1:30 · 60 seconds
One request creates several jobs
Consider a guest who writes, “Please bring fresh towels, and could I stay another night?” This is an illustrative example, not a measured result. One message creates different jobs. Front office needs to understand both requests. Someone checks the reservation system. A dispatcher assigns the towels, and a colleague physically delivers them. A helpful reply does not establish that the work happened. When those steps sit in separate inboxes and tools, staff must reconstruct context and chase the handover. We want the whole request to remain visible until every part is answered, verified or explicitly handed to someone.
1:30 to 2:30 · 60 seconds
People connect the current stack
The opportunity sits in the work between existing systems. Hotel platforms hold reservations and operational facts. Guest tools manage conversations. Task systems organize departmental work. People still connect the records, decide what needs attention and confirm the outcome. We are not assuming that every hotel has the same problem or wants another system. The buyer hypothesis is an independent group with shared operations, enough recurring coordination work and authority to purchase a common workflow service. The value to test is less unresolved work and lower total coordination effort, after including review, corrections and the staff time that remains.
2:30 to 3:45 · 75 seconds
An operating layer across existing systems
The left side shows existing guest channels, reservation records and staff task tools. The proposed layer connects these through supported interfaces and approved property knowledge. It carries request context and ownership across the tools, prepares a reply or next step, and records what happened. Staff review permitted actions and fulfil physical service. Existing systems retain authoritative records. Reading availability never grants booking or payment rights; each action needs its own permission and checks. This diagram describes a proposed architecture, not live integrations. The wider proposal spans operations, commercial work, finance, people and leadership. The first release stays small: reviewed replies, read only reservation enquiries and staff initiated tasks. Staff verify completion. Complaints and sensitive messages go to people without an automatic guest reply. Broader capabilities require later validation and separate action gates.
3:45 to 5:15 · 90 seconds
Everyday service workflows
Here are three everyday examples, all illustrative and proposed. First, a guest asks when breakfast starts. The assistant finds the approved answer for that property and drafts a reply. An agent checks it and sends it. The result is a reviewed answer grounded in the property’s current published information. Second, a guest requests towels. A staff member initiates the service task. The dispatcher accepts it, a colleague delivers the towels and someone records and verifies completion. The platform makes responsibility and unfinished work visible; it does not perform the physical service. Third, a guest asks whether a room is available for an additional night. A permitted connector retrieves current availability and relevant terms. The assistant prepares an enquiry response, and reservations staff check and send it. It creates no booking, hold, change, cancellation or payment link. Private reservation status also requires an identity check and limited disclosure. These distinctions matter because a credible first product must be useful without quietly acquiring broader authority.
5:15 to 6:15 · 60 seconds
Base annual software scenario: USD 262m
The base covered annual software scenario is approximately USD 262m, with low and high scenarios of about USD 53m and USD 787m. These amounts model the wider future full platform, not the narrower first release opportunity. It is not a verified global total addressable market, observed demand or a buyer census. Accommodation stock is the starting point. We then apply assumptions about independent group eligibility and additive software pricing. The model quantifies 158 of 244 eligible reporting areas; 86 remain unquantified. Stock definitions and reference dates vary. Worldwide scope excludes China, Russia and North Korea, with Hong Kong and Macao included in the China exclusion. The appendix shows the regional priorities, pricing bridge and narrower launch and sales capacity models.
6:15 to 7:15 · 60 seconds
Strong alternatives already exist
This is a contested market. Mews and Cloudbeds are strong hotel platforms. HelloShift and Duve overlap guest journeys. Hotelkit and Sweeply support operating work. Aphy is a closer thesis challenge: it markets back office AI orchestration for independent hotels and small groups, including reservation and financial checks. Its broad execution remains vendor claimed; complete action scopes and independently confirmed operating cases are not established. We must compare complete workflows against native platforms, specialists and direct orchestration rivals. Lower coordination effort with clear ownership remains our proposed differentiation, not a proven advantage. We need observed outcomes, workable implementation costs and an accepted commercial offer before claiming one.
7:15 to 8:30 · 75 seconds
Prove a small first release
Start with reviewed guest replies, approved knowledge, read only reservation enquiries and staff initiated service tasks. Learning from an anonymous operator includes developer testing in a demo environment. It does not establish business acceptance or accepted live performance. Most of the wider platform remains proposed. The next proof needs named content and data owners, representative enquiries and business testers with protected time. Customer staff must accept and fulfil tasks. The provider needs reliable integrations, access controls, monitoring and agreed support coverage. Together we would measure useful drafts, errors, unresolved handovers, verified task outcomes and full operating cost against a baseline. Voice, reservation writes, booking creation and payments require separate gates. Timing and resources remain conditional on access, content, staffing and the results of this validation.
8:30 to 9:00 · 30 seconds
Agree the first operator validation
We invite operators and integration partners to define the first validation together. Choose the priority workflows, name the people who own content and testing, confirm system access, and test an actual commercial offer. The next decision is a bounded operator validation, with explicit acceptance criteria and responsibilities. The main pitch ends here; detailed evidence is in the appendix.
End of timed pitch. Open the separate appendix.