AI HOSPITALITY ALLIANCE · WORKGROUP 2 · VENDOR QUESTIONS
Fourteen questions to answer before buying or building an orchestration layer.
Overview
Before adopting, building or buying an orchestration layer, collect written evidence for fit, stack readiness, operational ownership and vendor commitments. An unanswered item is a readiness finding. A written vendor answer is not automatically an acceptable answer.
Record demonstrated, not demonstrated or not applicable. These are question-level prompts; evaluation methodology and any procurement decision remain the operator’s responsibility with its advisors.
A written answer is not automatically acceptable. These questions do not assess answer quality or rank vendors.
Download PDF ↗| Procedure | Write down, in operational language, what you want AI to do that crosses more than one system: tasks a single vendor's built-in AI cannot do inside its own silo. If every item on the list lives inside one system, record that. |
|---|---|
| Demonstrated when | A written list of intended AI-assisted workflows exists, each naming the systems it touches. At least one workflow touches two or more systems, or the operator has recorded that none does and deferred adoption. |
| Evidence to keep | The workflow list, dated, with the systems named per workflow. |
| Procedure | For the top three workflows from OP-1, walk each step and list every system read or written: PMS, CRS, RMS, POS, locks, messaging, payment. Include the ones staff touch manually today. |
|---|---|
| Demonstrated when | Each workflow has a system-touch list, and the operator can say which touches are reads, which are writes, and which currently require a human. |
| Evidence to keep | Per-workflow touch lists; the read/write/human annotation. |
| Procedure | State whether the layer serves one property, a uniform portfolio, or a mixed estate. Then answer the Framework's four topology questions in Choose the data-plane pattern: (1) is there exactly one product per function across the whole portfolio; (2) do you need to reconcile a guest, or report a figure, across properties or systems; (3) for each entity your use cases depend on, can you name the authoritative source and its key; (4) do any intended actions write to more than one system of record? Yes to 1 and no to 2 points to Pattern A; a no on 1, or a yes on 2, points to Pattern B; a no on 3 is the Pattern C stop signal: fix that first. Question 4 does not change the pattern; it flags that writes span systems, which raises the bar for the allowlist in OP-10 and the traceability answer in OP-13. |
|---|---|
| Demonstrated when | The topology test has been run and recorded a configuration (Pattern A, Pattern B, or the Pattern C stop signal). The buying conversation names that result. |
| Evidence to keep | The four answers and the resulting pattern, dated. |
| Procedure | For each system in the OP-2 lists, record whether it exposes a documented API and an event or webhook feed, and whether your contract lets you use them (see Minimum system interfaces). |
|---|---|
| Demonstrated when | A source inventory exists naming, per system: API yes/no, events yes/no, contractual access yes/no, and the documentation location. |
| Evidence to keep | The source inventory, with contract references for any restricted row. |
| Procedure | For the two most write-heavy systems, ask the vendor (or check the documentation) whether an integration credential can be scoped below administrator: by action type, data class, or property. |
|---|---|
| Demonstrated when | For each of the two systems there is a written vendor answer: scoped credentials available (and how), or not available (recorded as a gap for Evaluate readiness and vendors). |
| Evidence to keep | The vendor answers; the intended scope per credential. |
| Procedure | Describe, in one paragraph, how you would find out if a vendor changed an API or a field's meaning without announcing it, before wrong data reached a guest (the guide, silent drift). |
|---|---|
| Demonstrated when | There is a named mechanism: contract validation, drift monitoring, a vendor notice clause, or an explicit acceptance that detection is the orchestration layer's job and appears in its requirements. |
| Evidence to keep | The paragraph; the contract clause or the requirement line it points to. |
| Procedure | With your counsel or data protection officer, check three things for the systems inventoried in OP-4: whether guest consent as currently collected covers AI-assisted processing; whether data residency requirements constrain where the layer and its model providers can run; and whether your vendor data-processing agreements cover this processing. This item asks for the check, not a legal conclusion (legal conclusions are out of the Framework's scope by design). |
|---|---|
| Demonstrated when | A written note from counsel or the DPO exists stating that consent, residency, and DPA coverage hold for the intended workflows, or naming the gaps to close before go-live. |
| Evidence to keep | The note; the gap list with named owners. |
| Procedure | Write the name or role that owns the layer in production: its configuration, its vendor relationships, its incident response. If the answer is a committee, name the accountable individual within it. |
|---|---|
| Demonstrated when | One accountable owner (role or person) is named and has accepted the role in writing. |
| Evidence to keep | The ownership note; the acceptance. |
| Procedure | Describe who catches an escalation outside business hours, including at the smallest property in scope. If the honest answer is 'no one is watching a queue at 3 a.m.', record which workflows must fail closed, queue, or degrade to manual instead of escalating (the guide, human-handoff triggers). |
|---|---|
| Demonstrated when | Every workflow from OP-1 has a stated out-of-hours disposition: staffed handoff, fail closed, queue for morning, or manual fallback. None assumes a desk that is not staffed. |
| Evidence to keep | The per-workflow disposition table. |
| Procedure | List the actions an agent may take with no human approval, and who in your organization approved that list. Everything not on it is denied by default (adopted position: deny-by-default, Positions and tests). |
|---|---|
| Demonstrated when | A written allowlist exists, approved by a named authority, with a review date. The operator can answer 'what can an agent do without approval?' with 'nothing that has not been granted.' |
| Evidence to keep | The approved allowlist; the approver; the review date. |
| Procedure | Ask each candidate vendor where the layer can run (cloud, on-premise, hybrid) and whether their architecture forces one topology. Compare against your OP-3 result and the residency constraints from OP-7. |
|---|---|
| Demonstrated when | Written vendor answers exist and at least one candidate matches the topology the operator actually has, without a migration precondition the operator has not planned. |
| Evidence to keep | Vendor answers; the match/mismatch note against OP-3 and OP-7. |
| Procedure | Before commitment, obtain in writing what you keep if you leave: data, configurations, workflows, audit history, and the documented exit path (Minimum system interfaces requires one; Deployment profiles makes it procurement evidence). |
|---|---|
| Demonstrated when | A written exit statement exists per candidate, naming what is exportable, in what format, and at what cost. 'The layer exists so you can swap tools; a layer you cannot leave defeats its own purpose.' |
| Evidence to keep | The exit statements; the export format list. |
| Procedure | Ask how an incident is reconstructed: can every AI-initiated action be traced to a specific agent, principal, timestamp, and the systems it touched, across vendors if you run more than one agent (see Multi-agent coordination, unified audit)? |
|---|---|
| Demonstrated when | The vendor demonstrates, on a test action, the full trace from request to affected systems, or states in writing which parts of the trace they cannot produce. |
| Evidence to keep | The demonstration record or the written gap statement. |
| Procedure | Ask for the integration path and its full commercial terms (connection fees, per-call costs, revenue conditions), disclosed and evaluable before you commit (Baseline — any system; Evaluate readiness and vendors). |
|---|---|
| Demonstrated when | All costs of connecting your chosen tools are known in writing before signature. Terms that are undisclosed, conditional, or negotiated case-by-case are recorded as an architectural risk, not only a commercial one. |
| Evidence to keep | The disclosed terms; the risk note for any undisclosed row. |
If the intended work stays inside one system and needs no shared orchestration, recording a decision not to buy this layer is a valid outcome. In the topology test, add a legacy-access check: a source available only through batch or a constrained interface may require a governed served copy and a declared staleness budget even on a uniform estate.