{ "version": "0.1", "date": "2026-10-15", "status": "Stakeholder discussion draft", "cases": [ { "id": "UC01", "title": "Guest Command Center", "department": "Front office and reservations", "journey": "Enquiry through post stay", "phase": "R1", "origin": "Playbook", "evidence": "Developer reports for component inbox and tasks; no accepted end to end deployment established", "references": "E01 E02 E03 E09", "User and problem": "Reservations agents and duty managers need one accountable queue when a guest contacts several channels and context is scattered.", "Scenario and trigger": "A guest emails after a chat. New inbound activity or a staff search starts a property scoped timeline; a match requires sufficient identity evidence, not a shared surname alone.", "Data and system of record": "Channel threads remain the message record; PMS holds reservations; CRM holds commercial relationships. Store message links, limited identity assertions, property, intent items and task references.", "Workflow": "Ingest once; resolve property; suggest identity links; decompose intents; check permissions; retrieve approved knowledge and permitted live facts; prepare draft or handover; assign owner; staff complete and send; track delivery and reopen on reply.", "AI and human work": "AI summarizes and proposes next actions. An agent checks facts, completes unanswered items and sends. A supervisor manages queue ownership, ageing and coverage.", "Output and authority": "Produce one coherent conversation and review queue. R1 permits internal work records and staff approved messages only. PMS or CRM writes require a separately enabled action permission; viewing a timeline grants no write authority.", "Exceptions and fallback": "Ambiguous identities stay separate. Unknown property requires clarification. Complaints and sensitive messages enter the designated human queue without an automatic guest reply. Failed routing retains an owned exception; no silent discard.", "Audit": "Record source message IDs, identity evidence, property, policy and knowledge versions, proposed and edited replies, approver, send result, timestamps and task links; restrict raw content retention.", "Success measure and acceptance": "Measure eligible draft coverage, whole message completion, handling time and queue ageing. Acceptance: a two intent message retains both items until staff complete or explicitly hand over each; duplicate webhooks create one work item; failed sends remain visible; cross property access tests deny disclosure.", "Dependencies and readiness": "Requires channel ownership, property routing rules, staffed escalation recipients and approved knowledge. Inbox components are reported built; channel and business UAT remain release gates." }, { "id": "UC02", "title": "Guest Issue Resolution and Service Routing", "department": "Guest services housekeeping and engineering", "journey": "In stay and service recovery", "phase": "R1", "origin": "Playbook", "evidence": "Task components developer reported; closed loop service fulfilment unverified", "references": "E01 E07 E09", "User and problem": "A guest services agent and department dispatcher need requests to become owned work, with reliable completion evidence.", "Scenario and trigger": "A guest reports a failed light or requests towels by text or photo. Intake must identify the property and verify the service location internally before disclosure or dispatch.", "Data and system of record": "Use the conversation, verified reservation/location, approved service catalogue, department roster and task system. The task system owns execution status; PMS owns room and stay state.", "Workflow": "Classify request and urgency; check sensitive overrides; create a linked task; dispatcher accepts assignment; staff acknowledge and set an achievable ETA; perform work; record completion; front office verifies outcome and sends the reviewed follow up; reopen if the guest disputes it.", "AI and human work": "AI extracts details, suggests routing and groups repeat faults. People determine safety urgency, perform physical work and confirm resolution. AI cannot infer a completed repair from a photo or a closed chat.", "Output and authority": "Output is an owned service task and visible progress. Enable internal task writes only for configured categories. Guest acknowledgements and completion messages require staff approval in R1; compensation and reservation changes remain separate approvals.", "Exceptions and fallback": "No staff acknowledgement triggers timed reassignment to the duty manager. Offline staff can queue signed updates with conflict handling. Emergencies bypass routine queues to the human emergency procedure, with no AI generated emergency reply.", "Audit": "Preserve task ID, source, location verification, assignee changes, acknowledgement, ETA revisions, completion evidence, follow up and reopening reason.", "Success measure and acceptance": "Measure acknowledgement time, completion time by severity, overdue and reopened tasks, and guest confirmed outcomes. Acceptance: create once on retries; an unacknowledged task escalates; maintenance completion triggers a front office follow up task; the guest is never told work is done before staff evidence.", "Dependencies and readiness": "Requires a service taxonomy, department coverage, responsibility for non chargeable requests and task adapter lifecycle support. Whether such requests become automatic tasks is unresolved in the benchmark; require explicit local adoption." }, { "id": "UC03", "title": "Lost and Found", "department": "Guest services and housekeeping", "journey": "In stay and post stay", "phase": "R2", "origin": "Playbook", "evidence": "Proposed; current communication pilot hands these cases to people", "references": "E01 E03", "User and problem": "Housekeepers and guest services need to match found property to claims without exposing other guests or releasing items to an impostor.", "Scenario and trigger": "A staff member logs a found object or a guest submits a missing item claim. The property must have a custodian and retention/return procedure before enabling intake.", "Data and system of record": "Use the found item register as custody record, claim form, restricted photos and limited PMS stay verification. Courier tracking is a later integration; avoid unnecessary identity documents in the AI context.", "Workflow": "Capture item, location and time; redact photo identifiers; suggest possible matches; custodian compares private distinguishing details; verify claimant; approve release and delivery method; record pickup or shipment; close after confirmed return.", "AI and human work": "AI ranks candidates and drafts updates. Staff validate ownership and custody and handle valuable, hazardous or sensitive items.", "Output and authority": "Create a claim and match recommendation. No automatic declaration of ownership or shipment purchase. Staff approve each disclosure and release; payment or courier expenditure requires a separate process.", "Exceptions and fallback": "Multiple matches remain open. Unverified claimants receive no found item inventory. Missing custody, damaged objects, restricted goods and expired retention go to the property custodian.", "Audit": "Log access to photos, chain of custody, match reasons, identity check outcome, release approver and delivery receipt; apply an agreed disposal and deletion schedule.", "Success measure and acceptance": "Measure match precision, time to verified return and unresolved age. Acceptance: two similar items cannot be released by similarity alone; an unauthorized user cannot view the inventory; a courier failure leaves the claim open and owned.", "Dependencies and readiness": "Requires secure storage, local custody ownership, retention policy and a tested release workflow. This is roadmap scope, not a capability validated by the current pilot." }, { "id": "UC04", "title": "Multilingual Voice Notes", "department": "Guest services and reservations", "journey": "Enquiry and in stay", "phase": "R2", "origin": "Playbook", "evidence": "Proposed voice note workflow; WhatsApp messaging developer tested on Demo does not establish audio support", "references": "E01 E02 E03", "User and problem": "Guests who prefer speech and staff who work across languages need understandable messages without losing the original request.", "Scenario and trigger": "A guest submits an audio note on an enabled channel. The platform must have consent/disclosure settings, an allowed audio type and a usable staff review surface.", "Data and system of record": "Retain restricted original audio and transcript under the channel retention rule; use language detection, approved knowledge and separately authorized reservation lookup. Message and task systems retain their own status.", "Workflow": "Validate upload; transcribe; detect language; expose original and translated text with uncertainty; decompose requests; run the same policy and handover gates as text; staff review text and audio rendering; deliver an approved response or use a supported text alternative.", "AI and human work": "AI transcribes and translates. A staff member checks critical names, dates and instructions and approves delivery. Translation confidence must not override a sensitive intent.", "Output and authority": "Output is a linked transcript, draft and optional synthesized audio. R2 starts with reviewed replies. Audio cannot introduce booking or payment authority absent from the corresponding workflow.", "Exceptions and fallback": "Poor audio, code switching, unsupported language or a low confidence date prompts human clarification. Do not invent content from silence; retain the original for authorized review. Failed audio delivery offers an approved text route.", "Audit": "Record transcription model/version, language, uncertainty, staff corrections and delivery result; do not expose unrestricted audio in analytics.", "Success measure and acceptance": "Measure intent retention, critical field transcription error and reviewer effort by language. Acceptance: a deliberately ambiguous date is flagged; all parts of a mixed language request remain tracked; the audio and text say the same approved thing; blocked intents remain blocked.", "Dependencies and readiness": "Requires accessible playback, audio storage controls, representative accents/languages and channel delivery tests. Support claims must be scoped to tested languages and formats." }, { "id": "UC05", "title": "Live Voice Concierge", "department": "Front office and reservations", "journey": "Enquiry and in stay", "phase": "R2", "origin": "Playbook roadmap", "evidence": "Mostly developed and testable but on hold in latest readiness draft; no business acceptance established", "references": "E01 E02 E09", "User and problem": "Callers and reservation staff need useful after hours intake and a smooth transfer when a person must decide or act.", "Scenario and trigger": "An inbound telephone call starts only on an enabled property number with disclosure and recording settings. The duty rota and transfer destination must be healthy.", "Data and system of record": "Use telephony session state, approved property knowledge, permitted read only availability and a staff call queue. A call transcript is not a reservation record.", "Workflow": "Identify property and language; understand the request; retrieve bounded answers; read back names and dates when needed; offer human transfer; pass a concise summary and unresolved items; if unavailable, capture a callback request with consent.", "AI and human work": "AI handles turn taking and approved information. Staff handle complaints, complex cases and any currently unauthorized action. Live speech cannot wait for an email style approve button, so its allowed autonomous answer scope requires a separate release gate.", "Output and authority": "Output is an answer, transfer or owned callback. Initially allow intake and tested public FAQs only; private lookup requires identity checks. Booking, cancellation and payments are not implied by voice availability.", "Exceptions and fallback": "Transfer failure must create an urgent callback with a clear staff owner. Silence, poor recognition, distress or suspected emergency follows the configured human fallback; voice must not present itself as emergency monitoring.", "Audit": "Log consent, call IDs, tool calls, transfer attempts, handover context and outcome. Redact recordings/transcripts and prohibit card details entering language model logs.", "Success measure and acceptance": "Measure successful handovers, abandoned calls, factual accuracy and end to end turn latency under representative load. Acceptance: callers can request a person; a failed transfer produces an owned item; disallowed writes never execute; latency and interruption tests pass on the actual carrier route.", "Dependencies and readiness": "Requires phone routing, staffed coverage, recorded voice UAT and an approved real time policy. Retrieval benchmarks do not establish acceptable call latency or service quality." }, { "id": "UC06", "title": "Guest Concierge", "department": "Concierge and guest services", "journey": "Pre stay in stay and post stay", "phase": "R2", "origin": "Playbook", "evidence": "Proposed itinerary and local recommendation workflow", "references": "E01 E07", "User and problem": "Concierges need to build relevant plans while respecting accessibility, guest preferences and changing local availability.", "Scenario and trigger": "A guest asks for a local itinerary or a staff member prepares a stay plan. Ask for dates, interests and practical constraints rather than inferring health or family details.", "Data and system of record": "Use approved local content with verification dates, voluntarily supplied preferences, maps and licensed live venue information. External providers own their availability and booking confirmation.", "Workflow": "Clarify needs; retrieve approved options; verify time sensitive facts; assemble a feasible schedule; identify any unverified details; staff review sensitive or bespoke advice; guest chooses; pass booking requests to UC32; collect optional feedback.", "AI and human work": "AI drafts options and travel sequences. People curate providers and handle accessibility confirmation, sensitive wellbeing requests and unusual arrangements.", "Output and authority": "Output is a proposed itinerary with source freshness and clear booked versus suggested status. No promise of transport, tickets, health benefit or external reservation. Outbound offers require approved consent and communication rules.", "Exceptions and fallback": "Closed venues, missing accessibility data or unavailable live feeds generate alternatives with uncertainty. Unsafe or sensitive requests go to staff. No medical personalization based on inferred conditions.", "Audit": "Log preference provenance, content versions, venue verification, suggested options and guest selections; avoid retaining unnecessary travel details.", "Success measure and acceptance": "Measure accepted recommendations, factual freshness and staff research time. Acceptance: an unavailable venue is not described as booked; all schedule legs fit the stated times; unverified access needs are flagged for confirmation; declined personalization does not block ordinary service.", "Dependencies and readiness": "Requires local content stewardship, provider terms and a clear booking handoff. Recommendation usefulness needs guest and concierge validation; no uplift is assumed." }, { "id": "UC07", "title": "Food and Beverage Demand and Inventory Planning", "department": "Food and beverage and procurement", "journey": "Daily operations", "phase": "R2", "origin": "Playbook", "evidence": "Proposed forecasting workflow", "references": "E01 E07", "User and problem": "F&B managers and buyers need credible cover and ingredient forecasts to reduce stockouts and waste without overstaffing.", "Scenario and trigger": "A daily planning run or a material occupancy/event change starts a forecast for specified service windows. Historical sales and stock units must be mapped and sufficiently complete.", "Data and system of record": "PMS owns occupancy and booked inclusions; POS owns sales; inventory system owns stock and recipes; roster owns shifts. External events and weather are optional signals with recorded availability.", "Workflow": "Validate feeds; forecast covers and SKU demand with intervals; compare stock and lead times; propose order quantities and staffing gaps; manager adjusts and approves; record actual covers, consumption and waste; backtest and recalibrate.", "AI and human work": "AI estimates demand and explains drivers. Chefs verify recipes and service constraints; buyers place orders; managers approve staffing within their authority.", "Output and authority": "Output is a forecast and draft replenishment/staffing plan. Begin read only and recommendation only. Supplier orders and roster changes require explicit approvals and their source system workflows.", "Exceptions and fallback": "New properties, events absent from history and bad stock data use a seasonal/simple baseline with a warning. Never infer allergen safety or substitute ingredients automatically.", "Audit": "Retain forecast timestamp, input snapshot IDs, recipe version, interval, adjustments, approver and realized outcomes.", "Success measure and acceptance": "Measure weighted absolute error by service, waste cost and stockout incidents against the existing baseline. Acceptance: a time based holdout beats or matches the agreed simple forecast; leakage from future actuals is excluded; missing POS data is visible; no order is placed from an unapproved forecast.", "Dependencies and readiness": "Requires reliable POS history, recipe/yield units, lead times and manager ownership. Begin with one service before property wide SKU prediction." }, { "id": "UC08", "title": "Campaign Personalization", "department": "Sales and marketing", "journey": "Acquisition and post stay", "phase": "R2", "origin": "Playbook", "evidence": "Proposed; campaign ROI and willingness to pay unvalidated", "references": "E01", "User and problem": "Marketing managers need better supported campaign choices and reviewable creative without duplicating guests or contacting people without permission.", "Scenario and trigger": "A campaign brief or scheduled planning review starts segment analysis for a declared business objective and permitted audience.", "Data and system of record": "CRM owns subscription preferences and campaigns; governed guest links, booking history and engagement data inform analysis. Approved brand content and offer rules constrain drafts.", "Workflow": "Define objective and eligibility; build a consent filtered segment; propose offer and rationale; draft assets; marketing and revenue owners approve; export to the existing campaign system; run a holdout where feasible; measure net outcomes.", "AI and human work": "AI suggests segments and content. People set commercial terms, check inclusivity and consent, and approve the audience and send in the marketing system.", "Output and authority": "Output is a campaign brief, audience definition and creative variants. Initial scope permits drafts and approved exports; no automatic paid spend or campaign send. Permission to send service replies does not permit marketing.", "Exceptions and fallback": "Missing consent excludes a contact. Uncertain identity stays out of personalized audiences. Sparse segments use broad non sensitive criteria; sensitive traits are not inferred from guest messages.", "Audit": "Record data/consent snapshot, exclusions, offer rules, creative versions, audience count, approvals, experiment assignment and send IDs.", "Success measure and acceptance": "Measure incremental net booking contribution, unsubscribe rate and review time. Acceptance: withdrawn consent is rechecked before export; duplicates do not receive duplicate messages; reviewer can trace segment logic; experiment reporting distinguishes correlation from incremental lift.", "Dependencies and readiness": "Requires UC11 governed identity, CRM permission mapping, commercial offer ownership and a marketing operator. Historical uplift percentages are hypotheses." }, { "id": "UC09", "title": "Market Insights", "department": "Revenue management and leadership", "journey": "Commercial planning", "phase": "R2", "origin": "Playbook", "evidence": "Proposed market brief and recommendations", "references": "E01", "User and problem": "Revenue managers need timely market context and an explanation for recommended action rather than another disconnected dashboard.", "Scenario and trigger": "A daily run or licensed market alert starts a property/date/segment brief. The comparison set and relevant rate conditions must be defined.", "Data and system of record": "Use licensed market benchmarks, distribution rates, RMS forecasts, PMS actuals and permitted events data. RMS/channel tools remain the systems of record for rates and restrictions.", "Workflow": "Check feed freshness and comparability; normalize tax/inclusion/currency conditions; summarize demand and share changes; model possible rate or inventory adjustments; show evidence and uncertainty; revenue manager accepts, edits or rejects; observe outcomes.", "AI and human work": "AI explains trends and proposes scenarios. Revenue staff assess local knowledge, price strategy and source comparability before applying changes in the native system.", "Output and authority": "Output is a cited market brief and recommended action list. R2 is read only; any later export to RMS is an approved proposal, not an automatic price push.", "Exceptions and fallback": "Stale benchmark data, missing competitor rates or inconsistent inclusions suppress recommendations or label them incomplete. No bypass of data licensing or access restrictions.", "Audit": "Log source dates, captures, comparison rules, forecast/model version, recommendation rationale and staff disposition.", "Success measure and acceptance": "Measure analyst time, recommendation acceptance and forecast error; commercial gain requires a defensible comparison. Acceptance: unavailable market data is labelled missing rather than zero; each rate comparison uses like conditions; a rejected recommendation cannot be applied by a background retry.", "Dependencies and readiness": "Requires licensed data, a governed market/property mapping and a revenue owner. Vendor coverage and data cost remain discovery questions." }, { "id": "UC10", "title": "Personalized Experience Orchestrator", "department": "Guest services sales and marketing", "journey": "Booking through post stay", "phase": "R2", "origin": "Playbook", "evidence": "Proposed lifecycle orchestration", "references": "E01 E05", "User and problem": "Guest services and marketing teams need coordinated offers and preparation that respect what the guest wants and what the property can deliver.", "Scenario and trigger": "A confirmed stay, guest preference change or in stay milestone starts a permitted experience journey. Identity confidence, consent and current inventory are prerequisites.", "Data and system of record": "Use PMS stay facts, UC11 identity links, CRM preferences/consent, approved offers and service capacity. Task and campaign systems own execution; the platform records orchestration state.", "Workflow": "Evaluate eligibility and frequency limits; select an offer or preparation task; verify current service capacity; prepare message/task; owner approves; obtain guest choice; hand fulfilment to UC02 or UC32; capture actual delivery and feedback.", "AI and human work": "AI ranks relevant options. Staff own commercial and service feasibility; guests choose preferences and can opt out. Human agents resolve conflicting promises across departments.", "Output and authority": "Output is a proposed journey, approved contact or preparation task. Start with reviewed messages; no automatic purchase, upgrade, loyalty award or paid add on. Separate service communications from marketing permission.", "Exceptions and fallback": "Stale identity or withdrawn consent stops personalization. Capacity failure cancels the offer and creates a human recovery item. Sensitive needs are handled privately, without inferred health or family profiling.", "Audit": "Record trigger, consent, identity confidence, inventory check, selected/declined option, approver and fulfilment references.", "Success measure and acceptance": "Measure delivered and accepted offers, incremental contribution and opt outs. Acceptance: one trigger cannot create repeated offers; no unavailable add on is promised; opt out blocks later promotional steps; an accepted request has a named fulfilment owner.", "Dependencies and readiness": "Requires UC11, service catalogue, consent rules and coordinated owners. Room setup and corporate/family journeys are variants requiring locally approved rules, not universal policies." }, { "id": "UC11", "title": "Guest Profile Consolidation", "department": "IT data CRM and guest services", "journey": "All guest stages", "phase": "R2", "origin": "Playbook", "evidence": "Proposed enterprise identity; component guest profiles developer reported separately", "references": "E01 E05 E08 E09", "User and problem": "CRM stewards and guest teams need reliable cross system identity without accidental merging or unrestricted disclosure.", "Scenario and trigger": "A new or changed profile, or a steward review, starts matching. Tenant scope, permitted purpose and field ownership must be configured first.", "Data and system of record": "PMS owns stay identity; CRM owns marketing consent and commercial relations; each source retains its original ID. A governed link table holds a master ID, confidence and provenance, not an uncontrolled copy of every field.", "Workflow": "Normalize permitted keys; generate candidate matches; separate deterministic from uncertain matches; steward reviews ambiguous pairs; publish versioned links; reconcile permitted field updates; support split/unmerge; propagate correction requests through approved owners.", "AI and human work": "AI proposes matches and explains evidence. Stewards decide uncertain links and source corrections. Consent is not inferred from a profile match and must preserve source/purpose restrictions.", "Output and authority": "Output is a governed guest view and matching queue. Begin with analytical links only. Source merges and sync back require field specific ownership, approval and reversible operations.", "Exceptions and fallback": "Shared email, changed phone, transliteration, family bookings and masked intermediary email require caution. Conflicting consent uses the restrictive allowed treatment until reviewed; unresolved matches remain separate.", "Audit": "Log pair evidence, rule/model version, confidence, steward decision, field precedence, source sync and undo lineage. Limit access to identifiable matching data.", "Success measure and acceptance": "Measure false merge rate, unresolved matches and steward effort against a human labelled sample. Acceptance: shared contacts do not automatically merge people; an incorrect merge can be split with downstream corrections; revoked consent cannot be overwritten by an older source.", "Dependencies and readiness": "Requires source permissions, a matching reference set and a data steward. Historical email only matching and near total match targets are unvalidated assumptions." }, { "id": "UC12", "title": "Immersive Event Planner", "department": "Sales events and banqueting", "journey": "Enquiry planning and event delivery", "phase": "R3", "origin": "Playbook", "evidence": "Proposed immersive planning concept", "references": "E01 E07", "User and problem": "Event sales and banqueting teams need a shared visual plan that clients understand and operations can actually deliver.", "Scenario and trigger": "A qualified event enquiry starts a layout proposal for an identified venue and event version. Accurate dimensions and approved capacity rules must exist.", "Data and system of record": "Use venue floor plans, approved layouts, equipment inventory, catering options and event CRM records. Venue/event system owns availability; signed event orders remain authoritative.", "Workflow": "Clarify guest count and requirements; generate compliant candidate layouts; preview in browser/3D with optional AR/VR; client and staff revise; operations verify capacity/access routes/equipment; approve final version; create setup work orders; track changes.", "AI and human work": "AI suggests arrangements and summarizes revisions. Venue professionals check access, capacity and safety; sales staff confirm commercial terms. A rendered scene is not an engineering or safety certificate.", "Output and authority": "Output is a versioned visual proposal and setup specification. No event booking, signed agreement or supplier order without the normal approvals. Device/headset support is optional, not a prerequisite to participate.", "Exceptions and fallback": "Missing measurements, inaccessible layouts, equipment conflicts or changed attendee counts block finalization and return to the event owner. Provide a standard 2D plan when immersive rendering fails.", "Audit": "Record floor plan version, constraints, client edits, staff approval, final layout and downstream task IDs.", "Success measure and acceptance": "Measure proposal revision time, layout acceptance and setup discrepancies. Acceptance: a layout exceeding approved capacity is blocked; every task uses the final approved revision; a browser based alternative exposes the same requirements; no visual output claims certified safety.", "Dependencies and readiness": "Requires digital venue assets, event inventory and operational sign off. Validate demand for immersive tools before investing in AR/VR hardware." }, { "id": "UC13", "title": "Rate and Parity Validation", "department": "Revenue management and reservations", "journey": "Search and commercial operations", "phase": "R2", "origin": "Playbook", "evidence": "Proposed monitoring; distinct from developer tested reservation prices", "references": "E01 E05", "User and problem": "Revenue staff need to find genuine distribution discrepancies without confusing different tax, occupancy or cancellation conditions.", "Scenario and trigger": "A scheduled comparison or staff query starts a check for specified dates, room/rate equivalents and channels with permitted data access.", "Data and system of record": "Use direct booking engine and distribution captures, PMS rate mappings, channel manager restrictions and approved promotion definitions. These source systems remain authoritative for published rates.", "Workflow": "Capture comparable offers with timestamps; normalize occupancy, currency, taxes, inclusions and conditions; apply approved tolerance; group exceptions; suggest cause; revenue owner investigates and corrects in the native system; recheck.", "AI and human work": "AI explains discrepancies and prioritizes patterns. Deterministic arithmetic calculates differences; revenue staff validate comparisons and decide corrective actions.", "Output and authority": "Output is an evidence backed exception list and optional draft correction. Initial access is read only. No automatic rate, channel or promotion change; later writes need explicit field permissions and approval.", "Exceptions and fallback": "Unmatched room names, stale caches, membership conditions and unavailable rates are marked uncomparable. An access failure is not a parity breach. Do not scrape behind access controls.", "Audit": "Retain comparison keys, rate captures, normalization assumptions, tolerance version, reviewer decision and recheck outcome.", "Success measure and acceptance": "Measure verified breach precision, time to correction and false alerts. Acceptance: a refundable breakfast offer is not compared to a non refundable room only offer; unavailable channels are labelled; a currency conversion uses its dated rate; repeated alerts link to one unresolved case.", "Dependencies and readiness": "Requires lawful access, equivalent rate mappings and a revenue owner. A historical discrepancy percentage is an example threshold to configure, not a universal requirement." }, { "id": "UC14", "title": "Housekeeping and Maintenance Planning", "department": "Housekeeping engineering and HR", "journey": "Arrival in stay and daily operations", "phase": "R2", "origin": "Playbook", "evidence": "Proposed prediction and scheduling; basic task components developer reported", "references": "E01 E05 E07", "User and problem": "Housekeeping supervisors and engineering managers need separate but coordinated plans for room readiness, cleaning workload and asset maintenance.", "Scenario and trigger": "A next day planning run or material arrival/fault update starts planning. Valid room statuses, DND rules, staff skills and available hours are prerequisites.", "Data and system of record": "PMS owns occupancy and room state; roster owns availability; maintenance system owns assets and work orders; task history provides durations and repeat faults.", "Workflow": "Path A forecasts cleaning workload and deep clean candidates, then proposes assignment by readiness/arrival priority. Path B identifies recurring faults and preventive work windows. Supervisors reconcile both plans against skills, access and coverage, publish approved tasks, then update from actual work.", "AI and human work": "AI estimates workload and highlights patterns. Supervisors assign people; engineers diagnose faults; authorized staff change room readiness. Predicted failure is not confirmed failure.", "Output and authority": "Output is a capacity plan and proposed task schedule. Recommendation only initially; later approved task writes are permitted. No automatic employee shift changes, room release, physical control or deferred safety inspection.", "Exceptions and fallback": "Late checkout, DND, absent staff and parts shortages trigger replanning with a human owner. When asset history is unavailable, use rules based maintenance. Offline staff work from a dated task list and synchronize with conflict review.", "Audit": "Record planning inputs, model/rule version, priority explanation, supervisor edits, assignments and actual durations; avoid individual productivity rankings without approved workforce use.", "Success measure and acceptance": "Measure forecast error, rooms ready by required time, overdue preventive work and repeat faults. Acceptance: DND prevents entry assignment; incompatible skills block assignment; a failed sensor does not cancel required maintenance; approved changes preserve task ownership.", "Dependencies and readiness": "Requires reliable rosters, room states, asset taxonomy and baseline timings. The two paths remain one catalogue concept but can ship independently; predictive maintenance follows usable history." }, { "id": "UC15", "title": "Housekeeping Quality Verification", "department": "Housekeeping and quality", "journey": "Room turnover", "phase": "R3", "origin": "Playbook", "evidence": "Proposed vision assisted inspection", "references": "E01 E07", "User and problem": "Attendants and supervisors need consistent evidence of cleaning completion without treating a camera as a complete inspection.", "Scenario and trigger": "An assigned room turnover starts a checklist; optional before and after photos are captured only under an approved privacy procedure, with guests and personal possessions excluded.", "Data and system of record": "Use approved cleaning checklist, room type, task ID and permitted images. PMS/housekeeping system remains the room readiness record; supervisor inspection remains the release authority.", "Workflow": "Load checklist; attendant records work; vision suggests visible omissions; attendant corrects or disputes flags; supervisor reviews required inspections and sampled images; authorized person releases room; record feedback for evaluation.", "AI and human work": "AI flags visible missing amenities or defects. People verify cleanliness, inaccessible areas, equipment function and safety. Images cannot prove hygiene, safety or regulatory compliance.", "Output and authority": "Output is an advisory exception checklist and inspection record. No automatic room ready status, staff disciplinary decision or safety certification. Supervisor approval is required for operational release.", "Exceptions and fallback": "Blur, poor lighting, occupied rooms or personal belongings disable image assessment and use the manual checklist. A false flag can be challenged; no photo requirement should prevent reporting a privacy concern.", "Audit": "Log image consent basis, restricted access, model version, flags, staff corrections, inspection result and deletion date. Do not reuse room images for unrelated model training by default.", "Success measure and acceptance": "Measure flag precision/recall against supervisor labels and missed defects by category. Acceptance: low quality images receive no confident pass; privacy exclusions work; a false pass cannot release a room; results distinguish visible assessment from full inspection.", "Dependencies and readiness": "Requires a representative annotated dataset, mobile capture, worker consultation and agreed retention. Begin as a supervised experiment after ordinary task workflows work." }, { "id": "UC16", "title": "Payment Reconciliation", "department": "Finance and revenue operations", "journey": "Settlement and daily finance", "phase": "R2", "origin": "Playbook", "evidence": "Proposed analytical reconciliation", "references": "E01 E08", "User and problem": "Finance analysts need to explain channel settlements and payment mismatches without manually joining every statement.", "Scenario and trigger": "A daily settlement import or finance query starts matching for a property, date range, tender and currency. Completeness and expected settlement delays must be known.", "Data and system of record": "PMS/payment processor owns transaction events; OTA statements own remittances; bank and general ledger own settled cash and postings. AP invoices are relevant only where an explicit relationship exists, not automatically equal to guest revenue.", "Workflow": "Validate totals and identifiers; match deterministic references first; propose ambiguous groups; apply approved fee/FX/timing tolerances; analyst reviews exceptions; record decision; pass an approved journal proposal to the accounting workflow; reconcile next run.", "AI and human work": "AI ranks ambiguous matches and explains differences. Rules calculate amounts; finance validates the accounting interpretation and approves any corrections.", "Output and authority": "Output is a reconciled match set, exception queue and cash visibility report. Read only in the first release. Matching never authorizes capture, refund, bank transfer, supplier payment or ledger posting.", "Exceptions and fallback": "Partial settlements, chargebacks, refunds, duplicates and timing differences stay explicit. Missing bank data is marked incomplete; never force a match to make totals agree.", "Audit": "Record source row IDs, original currency, FX source/date, rule, proposed and confirmed links, reviewer and unresolved age. Preserve a reversible match history.", "Success measure and acceptance": "Measure auto match precision, aged exceptions and active analyst minutes against a baseline. Acceptance: totals tie to each source; a partial remittance can remain partly open; duplicates are not matched twice; replaying a file creates no duplicate matches or money movement.", "Dependencies and readiness": "Requires transaction level access, identifiers, finance tolerances and a controller. Historical savings and near perfect match targets are hypotheses requiring a labelled pilot." }, { "id": "UC17", "title": "Invoice Processing and Approval", "department": "Finance and procurement", "journey": "Procure to pay", "phase": "R2", "origin": "Playbook", "evidence": "Proposed; replaces the historical Zero Touch name with explicit approval", "references": "E01 E05", "User and problem": "AP clerks and budget holders need validated invoice drafts and accountable approvals without a broad automation claim hiding financial controls.", "Scenario and trigger": "An invoice enters the approved inbox or AP system. A known supplier, purchase order and receipt evidence are prerequisites for a clean match.", "Data and system of record": "AP system owns invoice intake; procurement owns PO and goods receipt; supplier master owns approved payment details; general ledger owns posted liabilities.", "Workflow": "Scan and extract fields; verify arithmetic, supplier and duplicate keys; match PO/receipt; propose coding; route to budget holder; finance validates exceptions and separation of duties; approved invoice enters the existing accounting/payment scheduling process.", "AI and human work": "AI extracts and suggests coding. Deterministic controls validate totals and duplicates. People approve expenditure and exceptions; supplier bank changes use an independent verified process.", "Output and authority": "Output is a draft invoice record, approval task and posting proposal. Initial writes are limited to draft AP records after enabled integration. No automatic supplier creation, bank detail edit or payment release.", "Exceptions and fallback": "Missing PO, price variance, duplicate, unreadable scan or suspicious bank change goes to AP. Processing failure preserves the original and an owned exception; no unapproved document is silently posted.", "Audit": "Keep document hash, extraction confidence, source fields, match evidence, coding edits, approval chain and posting result; protect financial attachments.", "Success measure and acceptance": "Measure validated invoice handling time, first pass match quality and duplicate detection. Acceptance: a duplicate image with changed filename is flagged; bank changes cannot be applied by OCR; approval limits and segregation hold; a rejected invoice never reaches payment scheduling.", "Dependencies and readiness": "Requires procurement/finance field mapping, approval limits and accounting adapter. The historical label does not promise zero human work or imply that an AP vendor needs replacing." }, { "id": "UC18", "title": "Guest Ledger Reconciliation", "department": "Night audit and finance", "journey": "Departure and daily close", "phase": "R2", "origin": "Playbook", "evidence": "Proposed folio settlement control", "references": "E01 E05 E08", "User and problem": "Night auditors and financial controllers need to reconcile folio balances, processor settlements and bank postings without confusing operational and cash timing.", "Scenario and trigger": "A nightly cutoff starts a property business date run. Cutoff timezone, tender mapping and settlement lags must be approved.", "Data and system of record": "PMS owns folio line items; processor owns captures/refunds/authorizations; bank owns cash; general ledger owns journal entries. Authorization is distinct from a captured payment.", "Workflow": "Freeze a reproducible input view; reconcile folio charges and tenders; align settlement batches; apply fee/timing rules; queue no show, refund and duplicate exceptions; controller approves clearing journal proposals; verify ledger results on readback.", "AI and human work": "AI explains exception clusters. Finance rules balance entries; auditors validate unusual treatments and control totals before any posting.", "Output and authority": "Output is a nightly reconciliation report and optional journal draft. Initial mode is read only. Approved journal posting is a later bounded permission with accounting period checks; no capture, refund or wallet movement.", "Exceptions and fallback": "Late bank feeds defer final cash conclusions. Closed periods, unbalanced entries, disputed charges and unknown tender mappings remain in the exception queue. Never invent a balancing entry.", "Audit": "Log cutoff, source totals, match lineage, tolerance version, reviewer, proposed journal and actual posting IDs with before/after balance readback.", "Success measure and acceptance": "Measure unexplained variance, exception age and time to a controller approved daily close. Acceptance: preauthorization never counts as cash; a repeated nightly run is idempotent; an unbalanced proposal cannot post; delayed settlements remain separately aged.", "Dependencies and readiness": "Requires UC22 governed financial feeds, agreed cutoff and controller sign off. Shares matching services with UC16 but owns folio completeness and close controls, not just channel settlement matching." }, { "id": "UC19", "title": "Daily Pulse", "department": "HR and leadership", "journey": "Employee experience", "phase": "R2", "origin": "Playbook", "evidence": "Proposed voluntary employee feedback", "references": "E01 E05", "User and problem": "HR leads need timely signals about working conditions while protecting staff from identifiable sentiment monitoring.", "Scenario and trigger": "An approved survey cadence starts a voluntary one question pulse for a defined workforce cohort. HR agrees purpose, anonymity, minimum reporting group and retention first.", "Data and system of record": "Use an authorized staff directory for delivery and a separate response store with access controls. Aggregated feedback is not an HR performance record; free text may identify its author.", "Workflow": "HR reviews suggested question; invite eligible staff; collect optional response; redact identifying text; aggregate only above the approved group threshold; HR reviews themes; assign improvement actions; report back to staff.", "AI and human work": "AI proposes questions and summarizes themes. HR checks privacy and interpretation and leads action; staff choose whether to respond. No inference of individual health or attitude from silence.", "Output and authority": "Output is an aggregate trend and an HR reviewed action plan. Invitations require the approved programme. No automated disciplinary, scheduling or individual performance decision; no individual sentiment score.", "Exceptions and fallback": "Small groups suppress output. Harassment, safety or wellbeing disclosures follow a confidential human route with an explicit explanation of anonymity limits; survey tools do not replace emergency/help channels.", "Audit": "Record question version, eligible/invited counts, suppression rules, authorized aggregate access and action follow up; separate identities from answers where promised.", "Success measure and acceptance": "Measure voluntary response rate, survey burden and action completion; do not call the model summary eNPS unless a valid eNPS question was asked. Acceptance: a small cohort cannot be singled out through filters; opting out works; a critical disclosure reaches the designated HR owner.", "Dependencies and readiness": "Requires HR sponsorship, workforce consultation and a privacy design. A daily frequency is an experiment; choose cadence with staff and test fatigue." }, { "id": "UC20", "title": "Task Keeper", "department": "All departments and team managers", "journey": "Employee work coordination", "phase": "R2", "origin": "Playbook", "evidence": "Proposed cross system action tracking; basic in product tasks separately reported", "references": "E01 E06 E09", "User and problem": "Employees and managers need to track commitments across messages and tools without an agent silently assigning people work they never accepted.", "Scenario and trigger": "A staff member explicitly forwards, mentions or connects an approved work source. The user must have access to that source and a configured team/ownership rule.", "Data and system of record": "Email/chat contains commitments; project and task tools remain task records. Store task references, excerpts with permission, due date provenance and owner acceptance.", "Workflow": "Extract proposed actions; distinguish requests from decisions; confirm owner and deadline; create an approved task in the selected system; deduplicate related actions; nudge by approved business hours; request evidence of completion; roll up open commitments.", "AI and human work": "AI drafts actions and reminders and summarizes status. People accept assignment, set priority and confirm completion; managers resolve ownership disputes.", "Output and authority": "Output is a personal/team queue with source links. Start with proposed tasks and opt in reminders. Ticket creation or internal reminders require configured authority; external follow ups need explicit communication permission.", "Exceptions and fallback": "Missing owner/date stays unassigned for review. Source permission loss revokes excerpts. A completed task in one system is not enough to close unrelated obligations; conflicting due dates require a person.", "Audit": "Log extraction source, consent/connection scope, owner acceptance, date changes, reminder delivery, completion evidence and sync conflicts.", "Success measure and acceptance": "Measure overdue commitments, duplicate tasks and active coordination time. Acceptance: quoted historical requests are not new assignments; repeated mentions do not duplicate tickets; off hours reminders respect timezone rules; revoked access hides source content.", "Dependencies and readiness": "Requires supported task adapters, team ownership and a retention policy. Start with one source/task pair before universal action mining." }, { "id": "UC21", "title": "ESG Optimizer", "department": "Sustainability facilities and finance", "journey": "Building operations and reporting", "phase": "R3", "origin": "Playbook", "evidence": "Proposed monitoring followed by separately gated physical control", "references": "E01 E05", "User and problem": "Facilities and sustainability managers need trusted resource data and practical actions without sacrificing guest comfort or safety.", "Scenario and trigger": "A scheduled meter ingestion or consumption anomaly starts analysis. Meter coverage, units, occupancy context and baseline methodology must be documented.", "Data and system of record": "Meters/BMS own readings and equipment state; waste contractors own collection records; PMS provides permitted aggregate occupancy; finance owns tariffs and invoices.", "Workflow": "Validate readings; normalize for occupancy/weather where justified; flag anomalies; estimate interventions with uncertainty; facilities approves a work order or bounded BMS trial; monitor comfort and consumption; compare with baseline and reverse unsafe settings.", "AI and human work": "AI identifies patterns and recommends changes. Facilities verifies equipment limits; sustainability staff approve reporting claims; finance validates cost calculations.", "Output and authority": "Output is a resource dashboard and intervention proposal. Begin read only. Automated HVAC/lighting control requires a separate engineering approved envelope, local override and tested fail safe; the model cannot redefine safety bounds.", "Exceptions and fallback": "Missing meters, unit errors or occupancy changes invalidate comparisons. Comfort complaints or breached limits stop a control trial. Life safety equipment and critical ventilation are outside autonomous scope.", "Audit": "Log reading lineage, normalization and emission factors, approved settings, manual overrides, control events and baseline changes.", "Success measure and acceptance": "Measure consumption intensity, verified waste and comfort complaints; savings need an agreed counterfactual. Acceptance: invalid readings are excluded visibly; a lost connection restores approved local operation; projected savings are labelled modeled; reports do not assert certified compliance.", "Dependencies and readiness": "Requires metering, BMS integration permissions and engineering stewardship. Environmental reporting may precede optimization; historical savings examples are not results." }, { "id": "UC22", "title": "Data Hub", "department": "IT data and domain stewards", "journey": "All operations and reporting", "phase": "F0", "origin": "Playbook", "evidence": "Proposed governed hub; enterprise deployment and data acceptance unestablished", "references": "E01 E08", "User and problem": "Data stewards and analysts need consistent operational definitions and traceable feeds across the systems they already use.", "Scenario and trigger": "An approved connector onboarding, scheduled extract or source event starts ingestion under a versioned data contract with an assigned domain owner.", "Data and system of record": "PMS, finance, CRM, POS, HR and project tools retain ownership. A minimized raw zone, validated canonical records and approved analytical views serve different purposes and retention rules.", "Workflow": "Declare scope/fields/purpose; ingest via permitted API/event/export; validate schema and control totals; quarantine failures; transform using versioned mappings; publish certified views; expose freshness/lineage; steward corrects the source; reprocess reproducibly.", "AI and human work": "AI may suggest mappings or explain anomalies. Deterministic transformations and owner approved metrics produce reported numbers. Stewards accept data contracts and resolve discrepancies.", "Output and authority": "Output is governed data products, a quality queue and metric definitions. Read access is domain and tenant scoped. The hub cannot silently correct operational sources; separate approved write workflows handle corrections.", "Exceptions and fallback": "Rate limits, missing exports, schema changes and late events create visible freshness failures. Dashboards show stale/as of status; they do not label yesterday's data real time. Keep minimum viable feeds rather than waiting for every vendor.", "Audit": "Track extraction run, row/source IDs, schema/version, transformation lineage, reconciliations, quality decisions, access and deletion propagation. Restrict identifiable raw data.", "Success measure and acceptance": "Measure freshness compliance, source coverage, control total variance and time to resolve quality issues. Acceptance: each certified metric reproduces from declared inputs; failed contracts quarantine records; replay is idempotent; tenant boundary and deletion tests pass.", "Dependencies and readiness": "Requires access audit, source samples, data owners and recovery design. F0 builds only the first release slice; a full warehouse is incremental. Historical multi connector budgets and delivery estimates are not commitments." }, { "id": "UC23", "title": "Cross System Query", "department": "Operations finance revenue and analysts", "journey": "Daily decisions and reporting", "phase": "R2", "origin": "Playbook", "evidence": "Proposed governed analytical query", "references": "E01 E08", "User and problem": "Analysts and managers need understandable cross domain answers with the right definitions and permissions rather than hand assembling exports.", "Scenario and trigger": "A staff question such as pickup versus budget starts a read only query after user, tenant, property and domain access are verified.", "Data and system of record": "Use UC22 certified metrics, semantic definitions and approved live adapters. Each response carries source/as of dates and unit/currency/business date; finance and PMS remain authoritative.", "Workflow": "Clarify metric/date ambiguity; map to an allowed query plan; enforce row/column restrictions before retrieval; execute bounded queries; reconcile joins and denominators; render answer with evidence and missing data; let analyst drill into allowed rows.", "AI and human work": "AI interprets questions and explains results. A controlled query layer computes figures; people resolve ambiguous business definitions and decide action.", "Output and authority": "Output is an answer, chart or export within existing access. No writes, arbitrary database commands or cross system transactions. High sensitivity exports may require additional authorization.", "Exceptions and fallback": "Unsupported joins, ungoverned metrics and missing feeds produce a bounded answer with explicit gaps or a steward request. Never blend unlike occupancy or revenue definitions to fill a gap.", "Audit": "Record question, approved plan, permission scope, data/metric versions, result hash and exports while minimizing raw row logging.", "Success measure and acceptance": "Measure numerical correctness, cited coverage and analyst time. Acceptance: the same governed question agrees with the certified dashboard; a restricted finance row cannot leak in a summary; an ambiguous date prompts clarification; a stale source is visible.", "Dependencies and readiness": "Requires certified semantic models for the chosen question set and representative permission tests. Start with a bounded question library; unrestricted natural language SQL is not the product promise." }, { "id": "UC24", "title": "Enterprise Knowledge Assistant", "department": "All staff and content owners", "journey": "Onboarding daily work and governance", "phase": "R1", "origin": "Playbook", "evidence": "Knowledge Hub components developer reported and tested in bounded guest workflows; enterprise search remains proposed", "references": "E01 E03 E06 E09", "User and problem": "Employees need current policies and working knowledge with clear ownership; content owners need corrections without uncontrolled self learning.", "Scenario and trigger": "A staff search, guest FAQ draft or proposed knowledge correction starts retrieval/publication under the user's role and property context.", "Data and system of record": "Approved documents and Knowledge Hub entries hold policy content; live adapters hold current reservation/stock facts. Track organization/brand/property scope, version, effective date, owner, review date and source ACL.", "Workflow": "Ingest and scan; propose structured entries; owner checks scope/conflicts; reviewer publishes a version; retrieve only authorized current entries; cite evidence; abstain on gaps; staff submits correction; reviewer accepts or rejects; regression tests run before publishing material changes.", "AI and human work": "AI finds and summarizes and proposes improvements. Domain owners approve content and resolve conflicts. A reply edited by staff is a suggestion for knowledge, not an automatically trusted new policy.", "Output and authority": "Output is a cited answer or draft, plus a review queue. Search is read only; approved publication is a separate role permission. No live availability or balance is inferred from a document.", "Exceptions and fallback": "Conflicting property policies, expired entries, source access changes and unsupported questions trigger clarification or human review. Untrusted document instructions cannot change tool authority.", "Audit": "Record retrieval references, versions, access checks, answer/abstention, suggested corrections, reviewer and publication/rollback history.", "Success measure and acceptance": "Measure grounded answer accuracy, gap backlog, review age and permission violations. Acceptance: a property override cannot contaminate another property; an unpublished correction is never served as policy; revoked source access blocks retrieval; missing evidence produces a visible gap.", "Dependencies and readiness": "Requires named owners and a review cadence. Enterprise HR/finance/source search needs separate access testing beyond guest FAQ evidence." }, { "id": "UC25", "title": "Board and Leadership Reporting", "department": "Leadership finance and domain owners", "journey": "Monthly quarterly and annual governance", "phase": "R2", "origin": "Playbook", "evidence": "Proposed governed report production", "references": "E01 E05 E08", "User and problem": "Finance leaders and executive assistants need reproducible reporting packs with accountable commentary and version control.", "Scenario and trigger": "A reporting cutoff or authorized request starts a pack for a defined audience, period and approved template. Each metric must have an owner and reporting definition.", "Data and system of record": "Use certified UC22 metrics, finance close state, approved budgets and domain commentary. Source systems and signed financial reports retain authority; a draft pack is a derived view.", "Workflow": "Freeze data/as of dates; populate template; compare prior period/budget; generate evidence linked draft commentary; ask owners to validate drivers; reviewer reconciles numbers and approvals; publish a locked version to an authorized audience; record subsequent restatements.", "AI and human work": "AI drafts narratives and charts. People validate causal explanations, financial materiality and release. A plausible explanation is marked as a hypothesis until corroborated.", "Output and authority": "Output is a reviewable pack and evidence index. No automatic distribution to boards, lenders or investors. Publishing requires an authorized report owner and audience access check.", "Exceptions and fallback": "Incomplete close, inconsistent definitions and missing owner inputs block finalization or remain prominently qualified. Revisions create a new version; never silently edit a released pack.", "Audit": "Record metric/data snapshots, calculation versions, commentary sources, owner review, release approval, recipients and restatement history.", "Success measure and acceptance": "Measure active preparation time, corrections after review and on time publication. Acceptance: every material figure ties to a certified view; a changed source does not alter a frozen pack; unverified causes are labelled; no unauthorized recipient can access the release.", "Dependencies and readiness": "Requires financial and data stewardship, templates and a reporting calendar. Time savings must include owner review, not just slide generation." }, { "id": "UC26", "title": "Digital Twin Simulator", "department": "Leadership operations and investment teams", "journey": "Strategy and scenario planning", "phase": "R3", "origin": "Playbook", "evidence": "Proposed modeled scenarios; no validated operational twin established", "references": "E01 E05", "User and problem": "Leaders need to explore tradeoffs in capacity, service and capital decisions without presenting uncertain forecasts as guaranteed outcomes.", "Scenario and trigger": "An authorized what if question starts a versioned scenario, such as later checkout affecting cleaning capacity. A defined decision and credible baseline are prerequisites.", "Data and system of record": "Use validated historical occupancy, POS, staffing, costs and optional equipment data. The scenario model is distinct from live systems; source systems retain actual operational truth.", "Workflow": "Define baseline and assumptions; specify interventions; validate relationships against history; run ranges/sensitivity; compare outcomes and constraints; expert reviews plausibility; record decision and later actual outcome; recalibrate.", "AI and human work": "AI helps specify scenarios and explain model output. Domain experts approve assumptions and interpret causal limits. Generated text cannot invent response elasticities or turn correlations into causal effects.", "Output and authority": "Output is a modeled comparison with uncertainty and assumption ledger. Simulation has no write path to PMS, staffing, prices or building controls. Any chosen intervention enters an ordinary approved operational workflow.", "Exceptions and fallback": "Insufficient history or an out of distribution change produces an exploratory model with explicit limits or no estimate. Emergency drills require qualified planning and cannot certify preparedness.", "Audit": "Retain model/version, datasets, parameter changes, calibration results, scenario seeds and human interpretation.", "Success measure and acceptance": "Measure backtest error, interval calibration and decision usefulness. Acceptance: a reviewer can reproduce the scenario; ranges change transparently with assumptions; historical backtesting is separate from scenario projections; no simulated uplift is labelled achieved ROI.", "Dependencies and readiness": "Requires UC22, accepted forecasting baselines and an agreed decision problem. Start with one bounded simulator before a portfolio digital twin." }, { "id": "UC27", "title": "Site Intelligence and Opportunity Matching", "department": "Acquisition and development", "journey": "Sourcing and early screening", "phase": "R2", "origin": "Playbook", "evidence": "Proposed public source screening", "references": "E01", "User and problem": "Development analysts need to discover and triage opportunities with provenance while retaining professional due diligence and investment authority.", "Scenario and trigger": "A scheduled scan or submitted listing starts review for an approved geographic and asset brief. Data source access and screening criteria must be authorized.", "Data and system of record": "Use permitted planning portals, listings and public datasets with timestamps; the acquisition pipeline owns opportunities and analyst decisions. Asking price and inferred ownership require verification.", "Workflow": "Collect changed records; extract location/stage/attributes; deduplicate sites; score against explicit criteria; show evidence, uncertainty and missing fields; analyst qualifies; create an approved pipeline lead; route due diligence tasks.", "AI and human work": "AI structures documents and suggests rankings. Analysts verify planning status, constraints and ownership; investment teams decide whether to progress and commission professional advice.", "Output and authority": "Output is a ranked digest and evidence backed lead. No contact with owners, offer, bid, registration or financial commitment. Underwriting is a separate explicitly modeled extension.", "Exceptions and fallback": "Stale listings, duplicate parcels, unclear planning status and restricted portals stay flagged. Missing evidence does not become a negative or positive investment fact; access restrictions are respected.", "Audit": "Record source captures, extraction confidence, criteria/model version, site deduplication, analyst decisions and changes to ranking.", "Success measure and acceptance": "Measure analyst verified relevance, missed opportunities from a reference sample and screening time. Acceptance: an expired listing is labelled; ranking rationale is reproducible; a planning proposal is not described as permission granted; no automatic outreach occurs.", "Dependencies and readiness": "Requires an acquisition brief, source permissions and a responsible analyst. Historical opportunity and yield estimates do not validate an investment case." }, { "id": "UC28", "title": "Development Oversight Engine", "department": "Development project teams and leadership", "journey": "Design construction and opening", "phase": "R2", "origin": "Playbook", "evidence": "Proposed oversight; P1 and P2 retained as phases of one use case", "references": "E01 E06", "User and problem": "Project directors and managers need an evidence linked view of budgets, programme, RFIs, changes and risks across projects.", "Scenario and trigger": "A scheduled report ingestion or manager query starts a project health review. Each project must have source owners, status definitions and a cutoff date.", "Data and system of record": "Project controls systems and approved budget/change records own operational facts; document repositories own reports; the platform stores links and derived snapshots. Manual submissions remain visible as such.", "Workflow": "P1 gathers and validates updates, compares approved baselines and drafts a health view. Managers resolve contradictions and overdue inputs. P2 adds risk trends, cross project queries and dynamic dashboards; reviewed summaries feed UC25.", "AI and human work": "AI extracts, connects and explains. Project professionals verify progress, risk severity and financial status; authorized officers approve variations and baseline changes outside the AI summary.", "Output and authority": "Output is a project workspace, exception queue and review snapshot. Initially read only with internal review tasks. No automatic approval of budgets, designs, variations, contractor compliance or lender submissions.", "Exceptions and fallback": "Conflicting reports, missing cost data or late photographs appear as unknown/stale. Physical progress cannot be inferred as certified completion; unresolved discrepancies remain assigned.", "Audit": "Log source/version/cutoff, baseline, derived flag rules, reviewer corrections and approved report releases. Respect project and commercial confidentiality boundaries.", "Success measure and acceptance": "Measure overdue inputs, verified risk precision and reporting effort. Acceptance: a superseded budget cannot drive an unqualified variance; an RFI links to its source and owner; missing reports cannot produce a green status; P2 has no broader action authority than P1.", "Dependencies and readiness": "Requires project identifiers, document discipline, baseline ownership and stakeholder capacity. The historical master frame is a requirements input, not proof a complete portal exists." }, { "id": "UC29", "title": "Site Photo Insights", "department": "Development and site management", "journey": "Construction monitoring", "phase": "R2", "origin": "Playbook", "evidence": "Proposed visual reporting", "references": "E01 E06", "User and problem": "Site managers and project directors need organized visual evidence of progress and missing coverage without unreliable certification.", "Scenario and trigger": "A permitted folder upload or weekly deadline starts processing for a project and approved coverage checklist.", "Data and system of record": "Use restricted photo repository, project metadata, capture dates and shot location plan. The repository owns images; professional inspections and project records remain authoritative.", "Workflow": "Validate files and metadata; suggest project/date/stage tags; request confirmation where uncertain; assemble matched viewpoints over time; flag missing uploads/coverage; draft a visual summary; site manager verifies; issue an approved internal report.", "AI and human work": "AI tags and highlights visible differences. Site professionals interpret progress, confirm dates and investigate potential defects; they determine safety and compliance using the proper inspection process.", "Output and authority": "Output is a dated gallery and coverage report. No automatic completion certification, payment milestone, contractor penalty or safety sign off. Publication outside the approved team needs separate release approval.", "Exceptions and fallback": "Missing metadata, repeated old images and viewpoint mismatch are flagged. Blurred or obstructed photos do not receive a clean bill of health. Crop/redact people, plates and confidential displays where required.", "Audit": "Retain original hash, upload/capture dates, tag confidence, edits, comparison selection and reviewer approval; record access and deletion decisions.", "Success measure and acceptance": "Measure coverage completeness, date/tag accuracy and report preparation time. Acceptance: reuploaded images cannot count as new progress; absent views remain visible; reviewers can open original evidence; generated captions never claim certified safety.", "Dependencies and readiness": "Requires a shot plan, secure mobile upload and a site owner. Vision quality must be evaluated against actual site conditions before expanding interpretation." }, { "id": "UC30", "title": "Guest Sentiment and Experience Index", "department": "Guest services quality and leadership", "journey": "In stay recovery and post stay", "phase": "R2", "origin": "Playbook", "evidence": "Sentiment analytics components reported; unified index and business validity proposed", "references": "E01 E09", "User and problem": "Quality managers need to spot recurring experience problems across channels while separating model interpretation from what guests actually reported.", "Scenario and trigger": "A new permitted review/message or scheduled trend run starts analysis for a property and reporting period.", "Data and system of record": "Use licensed public reviews, authorized conversations, survey responses and task outcomes with channel/source labels. Preserve surveyed scores as reported; never replace them with model inferred scores.", "Workflow": "Redact data; deduplicate events; classify themes and sentiment with uncertainty; route negative/sensitive cases to a human owner without automated guest reply; aggregate with source coverage; investigate recurring patterns; assign improvement tasks; evaluate outcomes.", "AI and human work": "AI suggests themes and trend anomalies. People review service recovery, interpret context and validate labels across languages; leaders decide improvements.", "Output and authority": "Output is a theme dashboard and review queue. A composite index is a proposed analytical proxy with published weights and missingness. It is not surveyed CSAT/NPS and does not authorize compensation or guest contact.", "Exceptions and fallback": "Sarcasm, multilingual ambiguity, review spam and small samples require uncertainty/suppression. A sentiment score cannot override an explicit complaint or a safety term. Avoid double counting the same issue across channels.", "Audit": "Record source permissions, deduplication, model/label version, human corrections, aggregation weights and alert dispositions. Restrict raw complaint content.", "Success measure and acceptance": "Measure theme/sentiment agreement against human labels, alert usefulness and issue recurrence. Acceptance: dashboard distinguishes survey scores from inferred sentiment; source mix and missingness are visible; negative cases stay with staff; correlations with revenue are not described as causal impact.", "Dependencies and readiness": "Requires source rights, quality ownership and a validated multilingual labelled set. An overall score should follow validation, not precede it." }, { "id": "UC31", "title": "OKR Updates", "department": "Department heads leadership and executive support", "journey": "Monthly management cycle", "phase": "R2", "origin": "Playbook", "evidence": "Proposed structured collection and reporting", "references": "E01 E05", "User and problem": "Department heads and executive support need comparable progress updates without stale, missing or silently redefined objectives.", "Scenario and trigger": "A reporting cycle opens for a versioned objective set with a named owner, metric definition and due date.", "Data and system of record": "Project/HR/CRM tools and approved departmental submissions hold evidence; a governed OKR registry owns target, baseline, calculation and owner. Leadership pack remains a derived output.", "Workflow": "Request structured submissions; retrieve permitted metrics; validate period and completeness; flag missing evidence or changed definitions; draft deltas/commentary; owners attest; executive reviewer approves; publish the monthly version through UC25.", "AI and human work": "AI summarizes updates and proposes questions. People set targets, verify progress, explain changes and approve publication; no automatic performance assessment of individuals.", "Output and authority": "Output is a completeness queue and versioned update pack. Internal reminders follow the approved programme; no external distribution or automatic target change. An unreviewed draft cannot be labelled final.", "Exceptions and fallback": "Missing submissions remain unknown, not zero progress. Objective changes require versioned approval and explicit comparison breaks. Sensitive HR inputs are aggregated/restricted.", "Audit": "Record objective version, source snapshot, submitter/attestation, definition changes, reminders and final approver.", "Success measure and acceptance": "Measure on time evidenced submissions, reviewer corrections and preparation time. Acceptance: a changed target is visible alongside the original; a missing input is flagged; published figures reproduce from the same cutoff; restricted personnel data does not enter a general leadership pack.", "Dependencies and readiness": "Requires an agreed OKR framework, owners and source mappings. OKR Reporting and OKR Updates are treated as aliases of this same use case." }, { "id": "UC32", "title": "Service Activity and Dining Bookings", "department": "Concierge food and beverage and guest services", "journey": "Pre stay and in stay", "phase": "R2", "origin": "Project plan", "evidence": "Proposed; reconciles restaurant API and in house activity booking entries", "references": "E01 E07", "User and problem": "Concierge and service teams need to convert a guest choice into a confirmed service slot without double booking or promising an unavailable provider.", "Scenario and trigger": "A guest selects a restaurant, treatment or in house activity. Property, party size, date/time, accessibility requests and any charges must be clear.", "Data and system of record": "Service/restaurant booking system owns slots and confirmations; PMS owns stay identity; approved catalogue owns terms. A temporary spreadsheet may be used only with explicit ownership and concurrency controls.", "Workflow": "Clarify request; check live slot/eligibility; present terms and price; request guest confirmation; staff approve a booking proposal; recheck availability; execute once; read confirmation; create fulfilment tasks; send a reviewed confirmation. External providers without APIs receive a staff handoff.", "AI and human work": "AI gathers requirements and drafts options. People confirm provider arrangements and approve commitments; staff perform the service. UC06 handles suggestions, this workflow handles the booking.", "Output and authority": "Output is a confirmed provider reference or explicit pending request. No charge, deposit or cancellation fee is accepted implicitly. Payment uses UC36; paid commitments require its separate gate.", "Exceptions and fallback": "Availability races, provider timeout, missing confirmation and overbooking create an uncertain outcome for staff reconciliation. Do not retry a possibly successful booking blindly or say confirmed without readback.", "Audit": "Log request, terms, consent, approver, availability timestamp, idempotency key, provider result and follow up status.", "Success measure and acceptance": "Measure confirmed booking success, duplicate rate and fulfilment failures. Acceptance: a double click creates one booking; stale availability triggers reapproval if terms change; provider failure is labelled pending; a reservation request never masquerades as confirmation.", "Dependencies and readiness": "Requires a reliable provider adapter, cancellation rules and service owner. Start with a single in house service; expand external integrations after operational proof." }, { "id": "UC33", "title": "Read Only Reservation Enquiries", "department": "Reservations and front office", "journey": "Pre booking and pre stay", "phase": "R1", "origin": "Build extension", "evidence": "Built and developer tested on Demo; business UAT and live price validation outstanding", "references": "E02 E03 E04 E09", "User and problem": "Reservations agents need grounded availability, indicative prices and safe status/policy answers, while the guest receives one complete reviewed response.", "Scenario and trigger": "A new enquiry or booking status question starts handling for an enabled property. Rate/room mappings and approved policy text must be complete.", "Data and system of record": "PMS owns current availability, rate plan and reservation state. Approved knowledge owns policy wording matched to that plan. Only minimized fields enter the model; no local replica of all reservations is required.", "Workflow": "Resolve property and all intents; apply configurable commercial/group/length limits; query allowed availability; for private status require reference, booking name and stay dates; match policy; prepare a complete draft; expose unanswered items; staff finish and send. Missing identity asks only for missing fields.", "AI and human work": "AI understands and explains. Deterministic adapters fetch/validate facts; staff approve replies and handle exceptions. Sender email is supporting identity evidence, not sufficient on its own.", "Output and authority": "Output is a draft quote/status/terms answer with as of time. No booking, hold, modification, cancellation, payment request or payment link. Exclude room number, paid price/balance, payment details, contacts, other guests and internal notes from guest status answers.", "Exceptions and fallback": "Identity mismatch, unconfigured property, complex/commercial requests and stale API results go to staff. Complaints and sensitive messages receive no automatic guest reply. Mixed intents keep the whole message open; invoice requests route to the finance/property owner without an AI draft.", "Audit": "Log identity outcome without unnecessary raw identifiers, data fields disclosed, source/policy versions, query time, unresolved intents, reviewer and delivery result.", "Success measure and acceptance": "Measure eligible usable drafts and errors by scenario. Acceptance: missing or mismatched identity discloses nothing; a read only credential rejects writes; unsupported property pricing hands over; the reviewer sees every unanswered intent; live price checks are distinguished from placeholder demo prices.", "Dependencies and readiness": "Requires production authorization, representative real enquiries, owner approved guardrails and source mapping. Demo tests cannot close production data or business acceptance gates." }, { "id": "UC34", "title": "Approved Reservation Changes and Cancellations", "department": "Reservations and front office", "journey": "Pre stay and in stay", "phase": "R2", "origin": "Build extension", "evidence": "Conflicting developer completion reports; latest readiness draft says in development; acceptance unresolved", "references": "E02 E04 E09", "User and problem": "Reservation staff need reviewable eligible changes without unintended charges, policy exceptions or false confirmations.", "Scenario and trigger": "A verified guest requests an allowed change or cancellation. Property specific rate/channel eligibility, zero financial impact and deterministic deadline rules must be configured and approved.", "Data and system of record": "PMS owns reservation, availability, prices and cancellation policy data; approved knowledge owns explanation; mappings define allowed products/services. Separate service inventory must not be treated as an accommodation add on.", "Workflow": "Verify identity; check booking origin, group/company and plan; compute eligibility and exact property timezone deadline; prepare a field allowlisted diff and reply; staff approves both; recheck identity, current version, availability and price; write once; read back actual state; send the approved result only after success.", "AI and human work": "AI proposes structured changes and wording. Rules enforce eligibility and financial equality; staff decide and approve. Illness, bereavement, disputed charges and policy exceptions go to people.", "Output and authority": "Output is an approved pending change or human handover. Writes require explicit UC34 permission, property flag and write scoped credential. A financial change, fee, rate change or unsupported field cannot be bundled into the approval.", "Exceptions and fallback": "Changed price, expired approval or concurrent edit invalidates the proposal. Timeout after write enters uncertain state and readback reconciliation; no blind retry. Write success with reply failure retries only delivery. Suspected partial write goes to staff; do not promise universal rollback.", "Audit": "Store approver, identity/eligibility checks, expiry, before/after minimized diff, API response/reference, idempotency key and message outcome with restricted audit access.", "Success measure and acceptance": "Measure confirmed successful changes, policy rejects, uncertain outcomes and errors. Acceptance: any price movement blocks execution; double approval performs one mutation; identity is checked again; a failed write never sends success; cutoff boundary/timezone and partial failure tests pass.", "Dependencies and readiness": "Requires reconciled gap closure, approved eligibility rules, product/service maps and dedicated UAT. Current reported implementation is not an accepted production capability." }, { "id": "UC35", "title": "New Reservation Creation", "department": "Reservations and commercial operations", "journey": "Booking", "phase": "R3", "origin": "Historical extension", "evidence": "Proposed higher authority stage; not current validated enquiry scope", "references": "E01 E05 E07", "User and problem": "Reservation teams may later need to turn a qualified enquiry into a booking, while preserving pricing, inventory and contractual control.", "Scenario and trigger": "A guest explicitly chooses an offer and asks to book. Eligibility, booking terms, verified identity and production write approval must already be in place.", "Data and system of record": "PMS/booking engine owns inventory, rates, reservation references and status; approved rate terms come from governed knowledge; payment provider handles financial authorization separately.", "Workflow": "Collect minimum details; check eligibility/live availability; present complete terms and total; obtain guest confirmation; staff approves a structured booking; revalidate inventory and quote; create once; read back reference/status; use UC36 if payment is needed; issue a reviewed confirmation that matches actual state.", "AI and human work": "AI gathers details and prepares proposals. Rules validate inventory/pricing; staff approve commitment and resolve commercial cases. The model never invents inventory, credit or acceptance of terms.", "Output and authority": "Output is a PMS confirmed or explicitly pending reservation. Distinguish quote, optional timed hold and confirmed booking. Holds require their own permission/expiry and are disabled unless separately enabled; enquiry access permits none of these writes.", "Exceptions and fallback": "Quote expiry, duplicate guest identity, sold out inventory, payment failure and API timeout create a staff owned exception. If creation may have succeeded, reconcile by idempotency/reference before another attempt.", "Audit": "Log quoted terms/version/expiry, guest confirmation, staff approval, validation, write key, source result/status and communication.", "Success measure and acceptance": "Measure duplicate/failed bookings, confirmed conversion and manual corrections. Acceptance: stale price prompts fresh approval; a failed or pending reservation is never described as confirmed; retries cannot duplicate bookings; payment failure does not silently release or recreate inventory.", "Dependencies and readiness": "Requires UC33, mature approved write controls, booking API rights and reservation operations capacity. Prototype and historical booking claims do not establish a current live booking service." }, { "id": "UC36", "title": "Payment Facilitation", "department": "Finance reservations and guests", "journey": "Booking settlement and departure", "phase": "R3", "origin": "Historical extension", "evidence": "Proposed separate financial authority; no current payment handling acceptance", "references": "E05 E07", "User and problem": "Finance and reservations teams may later need safe handoffs to hosted payment tools, without exposing card details to an assistant or confusing a sent link with payment.", "Scenario and trigger": "An approved reservation/charge requires payment under a defined purpose, amount, currency and expiry. Finance approves provider, access and reconciliation before enabling any workflow.", "Data and system of record": "Payment provider owns payment status, tokens and transaction IDs; PMS owns charge/folio; bank/ledger owns settlement. The platform stores limited references and statuses, never card credentials or security codes.", "Workflow": "Validate amount/purpose against the authoritative record; staff approves a hosted payment request; generate a scoped link through the approved provider; send a reviewed message; guest completes payment on provider surface; authenticate callback and read status; reconcile with UC16/UC18; staff handles exceptions.", "AI and human work": "AI drafts explanations only. Deterministic provider integration validates requests and callbacks; finance controls money movement; the guest authorizes payment in the provider interface.", "Output and authority": "Output is a tracked payment request and independently verified result. Initial future stage is hosted link facilitation only. Capture, refund, supplier disbursement, bank detail changes and autonomous payment decisions each require separate scope and approval and are disabled here.", "Exceptions and fallback": "Expired/duplicate links, callback spoofing, charge amount changes and uncertain outcomes block success claims. A successful callback without source validation cannot mark a folio paid. Never request card details in chat, voice or email.", "Audit": "Log financial purpose, amount/currency, approver, provider request/reference, expiry, verified events and reconciliation outcome; redact tokens and secrets from logs.", "Success measure and acceptance": "Measure verified request completion, reconciliation lag and failed/duplicate requests. Acceptance: spoofed events are rejected; retry cannot duplicate a charge request; paid status requires verified provider readback; no sensitive card fields enter model, analytics or audit logs.", "Dependencies and readiness": "Requires dedicated payment/security design, finance ownership, provider certification where applicable and operational incident handling. This draft makes no claim that payment compliance is achieved." } ], "candidates": [ { "id": "C01", "title": "Digital arrival and mobile keys", "department": "Front office", "boundary": "Identity verification, lock hardware and native check in approvals; no automatic access credential issuance in this draft.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C02", "title": "Departure folio review and split billing", "department": "Front office and finance", "boundary": "Authoritative folio, verified identity, billing permissions and dispute ownership; financial adjustments need explicit authority.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C03", "title": "Secure guest casting", "department": "IT and guest services", "boundary": "Device pairing and automatic credential/session cleanup; primarily vendor integration rather than an AI differentiator.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C04", "title": "Sold out date waiting lists", "department": "Reservations", "boundary": "Opt in contact, queue fairness and live inventory recheck; a notification is not a hold.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C05", "title": "Room move coordination", "department": "Operations", "boundary": "Room readiness and guest consent, baggage/privacy controls and coordinated PMS updates.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C06", "title": "Corporate and group self service", "department": "Sales and reservations", "boundary": "Account authentication, negotiated rates, rooming list access and complex billing; requires a separate commercial workflow.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C07", "title": "Digital food ordering", "department": "Food and beverage", "boundary": "POS/KDS acceptance, allergens and delivery ownership; payment is a separately approved stage.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C08", "title": "Guest surveys and review management", "department": "Quality and marketing", "boundary": "Valid survey design, platform terms and human response ownership. Historical selective positive review solicitation is not adopted; avoid review gating.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C09", "title": "Gift card administration", "department": "Finance and marketing", "boundary": "Issuer liability, balances, redemption and fraud controls; no automatic issuance or value movement.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C10", "title": "Employee access lifecycle", "department": "HR and IT", "boundary": "Authoritative hire/leaver events, reversible provisioning and verified deactivation; access actions require independent controls.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C11", "title": "Workforce scheduling", "department": "HR and operations", "boundary": "Availability, skills and approved employment/roster constraints; managers publish schedules, with worker consultation.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C12", "title": "Chargeback evidence preparation", "department": "Finance", "boundary": "Verified evidence sources, deadlines and human submission approval; risk controls and representment need provider integration.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C13", "title": "Maintenance parts and housekeeping supplies", "department": "Procurement and operations", "boundary": "Stock units, lead times, usage history and buyer approval; start with draft orders.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C14", "title": "Coaching training and recognition", "department": "HR and managers", "boundary": "Transparent purpose and human review; no individual decisions based solely on automated scores or guest sentiment.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C15", "title": "Receivables and collections", "department": "Finance", "boundary": "Credit policy, aged ledger reconciliation and approved contact rules; no autonomous dunning or credit decision.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C16", "title": "Supplier payment batches", "department": "Finance", "boundary": "Segregated payment approval, verified supplier bank records and bank controls; separate from UC17 invoice approval.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C17", "title": "Paid media and incrementality", "department": "Marketing", "boundary": "Spend limits, audience permission, experiment design and approved campaign controls; ad platform setup is a dependency.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C18", "title": "Commercial inventory and ancillary recommendations", "department": "Revenue", "boundary": "Comparable net contribution, channel rights and source readback; automated pricing or closure needs separate authority.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C19", "title": "Corporate rate synchronization", "department": "Revenue and sales", "boundary": "Contractual rate source, code ownership and safe rollback/reconciliation; no silent overwriting of live rates.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C20", "title": "Group lead triage and displacement analysis", "department": "Sales and revenue", "boundary": "Qualified enquiry, CRM ownership and validated displacement model; final quotes and commitments stay with staff.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C21", "title": "Sales proposal preparation", "department": "Sales", "boundary": "Approved offer templates, versioning and authorized signatory; drafting cannot bind the operator.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C22", "title": "Fit out procurement coordination", "department": "Development and procurement", "boundary": "Approved specifications, budget and supplier authority; software assists coordination without approving expenditure.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C23", "title": "Software license and IT asset intelligence", "department": "IT and finance", "boundary": "Reliable inventory and usage, renewal ownership and human decisions; no automatic license cancellation or device disable.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C24", "title": "Data rights request coordination", "department": "Privacy and IT", "boundary": "Verified requester, source coverage, retention exceptions and privacy owner review; no automatic deletion across systems.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C25", "title": "Document and contractor evidence expiry", "department": "Compliance and development", "boundary": "Qualified reviewers define required evidence and dates. OCR flags missing/expired documents; it cannot certify coverage or legal compliance.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C26", "title": "Property opening and ramp up", "department": "Openings operations and commercial", "boundary": "Stage gates, dependencies and accountable readiness checks; a checklist does not prove a property is safe or ready.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C27", "title": "Operational incident and compliance records", "department": "Safety operations and facilities", "boundary": "A qualified owner must define severity, emergency routes and required inspection evidence; no AI certification or replacement of emergency systems.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C28", "title": "Month end close coordination", "department": "Finance", "boundary": "Approved close checklist, period locks and controller sign off; automation cannot bypass accounting controls.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C29", "title": "Intercompany consolidation", "department": "Finance", "boundary": "Entity/currency policies, reconciled balances and approved adjustments; jurisdictional accounting validation required.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C30", "title": "Fixed asset and capital tracking", "department": "Finance and development", "boundary": "Asset register, depreciation policy and authorized capital approvals; native accounting system remains authoritative.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C31", "title": "Expense review", "department": "Finance and employees", "boundary": "Approved expense policy, evidence and separation of duties; reimbursement is a separate financial action.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C32", "title": "Tax mapping and reporting assistance", "department": "Finance", "boundary": "Qualified tax owner, approved jurisdiction/version rules and native filing controls; no automated legal compliance assertion or filing.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C33", "title": "Financial control evidence", "department": "Finance and assurance", "boundary": "Control matrix, evidence sampling and independent reviewer; automated checks do not constitute an audit opinion.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C34", "title": "Occupancy and demand forecasting", "department": "Revenue", "boundary": "Historical coverage, forecast horizon and reference baseline; measure error before using in commercial decisions.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C35", "title": "Labor and revenue analysis", "department": "Operations HR and finance", "boundary": "Aligned business date, roster/pay data permission and consistent revenue definitions; no automatic staffing cuts.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C36", "title": "Channel contribution and pace", "department": "Revenue and finance", "boundary": "Commission/cost completeness, comparable periods and attribution; recommendations begin read only.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C37", "title": "Loyalty programme operations", "department": "Marketing and finance", "boundary": "Guest consent, reward liability and transparent eligibility; no assumed enrollment or automatic points/value changes.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C38", "title": "Promotion abuse review", "department": "Revenue and security", "boundary": "Validated risk signals, fair review and appeal; automatic code revocation needs separately approved rules.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" }, { "id": "C39", "title": "Overbooking and relocation planning", "department": "Reservations and duty management", "boundary": "Verified availability, commercial agreements and guest communication ownership; staff approve relocation and any spend.", "origin": "Historical candidate", "phase": "Unprioritized", "evidence": "Proposed and unvalidated", "references": "E05" } ] }