The Internal AI Assistant: Turning SOPs Into an Answer Engine for Staff
Every hotel runs on knowledge that is not written down, or is written down in six places that disagree. This is the operator's guide to building an internal assistant that answers staff questions from your own procedures: what to ingest first, how to measure whether it is right, how to serve a team that speaks four languages, how to make shift handover a document instead of a conversation, and how to prove it is deflecting the questions that currently interrupt your supervisors forty times a shift.
Ask any general manager who on the property knows how to reset the boiler controller, which suite has the door that needs to be lifted to latch, what the brand standard says about a rollaway in a king, or how to re-run a folio after a split payment fails on the night audit. The answer is usually a name, not a document. Sometimes two names. Occasionally a name and a caveat: "but she is off until Thursday." That is institutional knowledge, and in most hotels it is stored in the least durable medium available, which is the memory of long-tenured employees in an industry where annual turnover runs between 70 and 80 percent.
The written version exists, in theory. There is a brand standards manual, a set of departmental SOPs somebody wrote during the last renovation, an HR handbook, an emergency response binder at the front desk, a chemical safety sheet in the housekeeping closet, and a shared drive with four versions of the group resume template. The trouble is not that the knowledge is absent. It is that it is scattered, unsearchable, partly out of date, and written in a register that a new room attendant with limited English is not going to sit down and read at the end of a nine-room shift. So the knowledge stays in people's heads, and the people get asked. Supervisors in a full-service hotel field dozens of questions a shift by radio, text, and interruption, most of which have a written answer somewhere that nobody is going to look up.
This article is about turning that written material into something staff will actually use: an internal assistant that answers questions from your own procedures, in the employee's language, on the device already in their pocket, and that says "I do not know, ask your supervisor" when the answer is not in the documents. The technology behind it, retrieval-augmented generation over a curated document set, is mature and inexpensive. The hard parts are the ones that have always been hard in hotel operations: deciding what the standard actually is, keeping it current, and measuring whether anything changed. What follows covers SOP ingestion and content readiness, retrieval accuracy and how to test it, multilingual access, shift-handover summarization, and an adoption metric set that will tell you within 60 days whether the thing is working.
The Cost of Knowledge That Lives in Three People
Start with what the current arrangement costs, because the business case for an internal assistant is not the software. It is the recovered time and the errors that stop happening. The broad knowledge-work number, from McKinsey research collected by Cottrill, is that employees spend about 1.8 hours a day, or 9.3 hours a week, searching for and gathering information. Hotel line staff are not desk workers and their number is lower, but the mechanism is worse: when a room attendant cannot find the answer, she does not search a drive, she stops working and calls a supervisor, and now two people are not working.
The second cost is onboarding. AHLA's most recent member survey found 65 percent of hotels short-staffed, with housekeeping and front desk the most-cited gaps, and the industry is projected to add more than 30,000 jobs in 2026. Every one of those hires goes through a period, usually four to eight weeks, of asking where things are and what the rule is, and hotels that raised wages are still reporting the same gaps, so the ramp is being run more often, not less. SHRM's benchmark puts the direct replacement cost of an hourly worker at $5,475, and the larger, less visible cost is the ramp: the weeks in which a new associate is a net consumer of supervisor time rather than a contributor.
The third cost is inconsistency, and it is the one owners feel in reviews and brand audits. When the standard lives in memory, it drifts. The evening desk agent handles a late checkout request one way, the morning agent another, and both believe they are following policy. Accor's data and AI leadership described the purpose of their team-facing assistants in exactly these terms in a June 2026 interview: the assistant "drives consistency via AI assistants and shared practices, supporting teams with content and standards." Consistency is not a training problem you solve once. It is a retrieval problem you solve every shift.
| Hidden cost | Typical daily volume | Time consumed | Annualized cost |
|---|---|---|---|
| Supervisor interruptions for procedural questions | 25 to 45 per supervisor shift | 3 to 5 min each, both parties | $95,000 to $190,000 |
| New-hire ramp (asking instead of doing) | 6 to 10 new hires per month at 75% turnover | 4 to 8 weeks at reduced output | $60,000 to $120,000 |
| Rework from wrong or inconsistent answers | 2 to 5 incidents per day | 15 to 45 min each plus guest recovery | $30,000 to $75,000 |
| Shift-handover losses (missed promises, open tickets) | 1 to 3 per handover, 3 handovers per day | Guest recovery, comped items, callbacks | $20,000 to $50,000 |
| Total addressable | $205,000 to $435,000 |
The assistant will not recover all of that. In practice a well-run deployment recovers a third to a half of the interruption and ramp costs in the first year, which for the property above is $50,000 to $150,000 against a software and implementation cost that rarely exceeds $25,000 to $40,000 in year one. The point of the table is not the precise totals. It is that the money is real, it is already being spent, and it is spent in a form (supervisor minutes, slow ramps, comped breakfasts) that never appears as a line item.
What an Internal Assistant Actually Is
Strip the vendor language away and an internal knowledge assistant is four components. A document store holds your SOPs, standards, and reference material, broken into passages and indexed for semantic search. A retrieval layer takes an employee's question, finds the handful of passages most likely to contain the answer, and hands them to a language model. The model writes an answer constrained to those passages and cites them. A chat surface (a web app, a Teams or Slack bot, a WhatsApp number, a kiosk in the housekeeping office) delivers the answer and captures feedback. The pattern is called retrieval-augmented generation, and the enterprise platform market for it is now crowded enough that a property has real choices at every price point.
Hospitality-specific versions are arriving. Apaleo's Copilot lets a hotel upload plain-text SOPs and process documentation so the assistant follows the property's own way of doing things when it answers or acts. Accor's AI Assistant for Oracle OPERA Cloud gives hotel teams natural-language access to PMS information and operational guidance; the group expects it to cut PMS support requests by 25 percent and onboarding time by 30 percent. Marriott is rolling Microsoft 365 Copilot from a 100-associate pilot to thousands. Accor's own internal generative tool, AccorGPT, is saving an average of 2.5 hours a week across 7,000 users. The brands are building this because the economics work at scale, and because daily use of generative tools among knowledge workers has roughly tripled in two years, so the associates they hire increasingly expect one. An independent property can build the same thing with off-the-shelf components and a disciplined content process, and the content process is where the leverage is.
The assistant is only as good as the document it retrieves. Every hour spent on the model is an hour not spent on the one thing that actually determines whether the answer is right: deciding which version of the procedure is the procedure.
That is the central discipline. A retrieval system will faithfully find and summarize whatever you gave it. If you gave it the 2019 housekeeping manual and the 2024 revision and a memo from last spring that changed the amenity standard again, it will find all three, and the model will do its best to reconcile them, which is a polite way of saying it will produce an answer that matches none of them. Content readiness is not a preliminary step. It is most of the project.
Content Readiness: What to Ingest and What to Fix First
The mistake most properties make is to point the tool at the shared drive and ingest everything. The result is an assistant that is confidently wrong about a third of the time, staff who learn within a week not to trust it, and a pilot that is quietly abandoned. The correct approach is to curate a small, authoritative set, launch on that, and expand as the feedback loop tells you what people are actually asking.
Begin with the questions, not the documents. Ask each department head to list the 20 questions their team asks most often. Ask supervisors to log, for two weeks, every procedural question they answer by radio, text, or interruption, with a category. You will end up with a list of 150 to 250 questions, heavily clustered: where is the thing, what is the standard, how do I do the rare task, what do I do when the system fails, who do I call. Then find the document that answers each one. Where there is no document, that is a writing task, usually a short one. Where there are three documents, that is a decision, and it needs an owner.
| Content type | Launch priority | Readiness test | Common fix required |
|---|---|---|---|
| Brand standards and service SOPs (front office, housekeeping, F&B) | Wave 1 | One current version, dated, with a named owner | Retire superseded versions; rewrite long narrative sections as numbered steps |
| Emergency and safety procedures (fire, medical, evacuation, chemical handling) | Wave 1 | Matches the posted physical binder exactly; reviewed by security or engineering lead | Reconcile binder and digital copy; add floor plans as images with text descriptions |
| HR policies (scheduling, PTO, uniform, conduct, timekeeping) | Wave 1 | Approved by HR; jurisdiction-specific rules flagged | Split multi-property handbooks by location |
| System how-tos (PMS, POS, key encoder, PBX, ticketing) | Wave 1 | Screenshots match the current software version | Re-capture after every vendor upgrade; assign to the system's super-user |
| Current menus, allergen sheets, wine list, room amenity lists | Wave 1 | Updated within 30 days; auto-refreshed from source if possible | Connect to the POS or menu-management system rather than uploading PDFs |
| Property facts (hours, parking, pet policy, local directions, partner discounts) | Wave 2 | Single "property fact sheet" maintained by front office manager | Consolidate from website, in-room compendium, and desk cheat sheets |
| Engineering and preventive maintenance procedures | Wave 2 | Equipment-specific; includes manufacturer manuals and property quirks | Capture tribal knowledge in short "known issues" notes per asset |
| Group resumes, BEOs, VIP profiles | Wave 3 | Time-bound; access restricted by role | Ingest from the sales and catering system daily with an expiry date |
| Historical memos, old training decks, previous management company docs | Do not ingest | Not current; will contradict Wave 1 material | Archive outside the assistant's index |
Three practical rules for the documents themselves. First, short procedural steps retrieve better than narrative prose; a 40-page manual with a section titled "Guest Recovery Philosophy" will produce worse answers than a two-page document titled "How to handle a noise complaint at night." Second, every document needs metadata the retrieval layer can use: department, role, property, effective date, owner. Third, and least glamorous, someone has to own the calendar. A document with no review date becomes wrong silently, and the assistant will keep serving it with perfect confidence.
Properties beginning this work often find that the content audit itself, before any AI is involved, surfaces contradictions that have been generating guest complaints for years. That is a feature. The assistant forces a decision about what the standard is, and the decision is worth having regardless of what tool serves it afterwards.
Retrieval Accuracy: Testing Before You Trust
Everything a vendor says about accuracy should be treated as a claim to be tested on your documents with your questions. The reason is not that vendors lie. It is that retrieval accuracy is a property of the document set and the question distribution, not of the model, and nobody has your document set. The cautionary example comes from a field with far more resources than hospitality: Stanford's RegLab ran the first preregistered evaluation of commercial legal research tools that had been marketed as hallucination-free because they used retrieval, and found hallucination rates between 17 and 33 percent. The errors were not only fabrications; they included mischaracterizing real sources and citing inapplicable ones, which is exactly the failure mode that matters when the question is whether a guest with a shellfish allergy can eat the risotto.
The remedy is a golden question set. Before launch, assemble 100 to 150 real questions drawn from the supervisor logs, and for each one record the correct answer and the document that contains it. Run the assistant against the set and score three things separately. Retrieval accuracy: did the system surface the right document among its top results? Answer faithfulness: does the written answer stay within what the retrieved document says, without adding or inventing? Citation: does the answer point to a source the employee can open and check? Score each dimension by hand for the first run; it takes an afternoon and it is the most valuable afternoon of the project. The evaluation frameworks now standard in enterprise RAG automate this later, but the first pass should be human, because it is also how the project owner learns what the corpus actually contains.
| Metric | How to measure | Launch threshold | What a miss usually means |
|---|---|---|---|
| Retrieval accuracy | Correct source document in top 3 results for each golden question | 90% or higher | Poor chunking, missing metadata, or the document does not exist |
| Answer faithfulness | Answer contains nothing not supported by the retrieved passage | 95% or higher | Model is filling gaps; tighten the prompt and lower creativity settings |
| Citation rate | Answer links to an openable source | 100% for procedural answers | Configuration; citations should be mandatory, not optional |
| Correct refusal | For 15 to 20 questions with no answer in the corpus, assistant declines and routes | 90% or higher | Assistant is guessing; this is the most dangerous failure and must be fixed before launch |
| Contradiction handling | For questions where two documents conflict, assistant flags the conflict | Flag, never reconcile silently | Content readiness incomplete; retire the superseded document |
| Multilingual parity | Golden set run in Spanish (or your second language); native-speaker review | Within 5 points of English scores | Translation drift on procedural verbs; add a bilingual glossary |
Two of these deserve emphasis. Correct refusal is the behaviour that makes the assistant safe to deploy. An assistant that says "I could not find this in our procedures; please ask your supervisor and I will log the question" is useful even when it fails, because the logged question becomes a content task. An assistant that guesses is worse than no assistant, because staff will act on the guess. Configure for refusal, test for refusal, and monitor the refusal rate in production; a rising refusal rate is a content backlog, not a model problem.
The second is contradiction handling. When two ingested documents disagree, the right output is not a blended answer. It is a flag: "Two documents address this and they differ; the 2024 housekeeping standard says X and the March memo says Y. Confirm with your supervisor." That flag is a gift to whoever owns the content, and it is the mechanism by which the assistant pays for its own maintenance.
Multilingual Access: The Benefit Most Properties Underestimate
Roughly 31 percent of the US traveler accommodation workforce is foreign-born, the fourth-highest share of any large private-sector industry, and in housekeeping, stewarding, and laundry the share is far higher. Hospitality trainers have documented properties where more than a third of staff worked in Haitian Creole with limited English. A property's SOPs are almost always written in English by people whose first language is English, and then delivered to a team for whom reading dense English procedure is a genuine barrier. The knowledge gap that the assistant closes is not primarily a search problem for this group. It is a language problem, and it has been quietly degrading standards compliance and safety for as long as the documents have existed.
The right architecture holds one version of the truth and many ways to read it. The source documents stay in English (or whatever the property's governance language is), maintained by their owners. The assistant accepts a question in Spanish, Haitian Creole, Tagalog, Portuguese, or Mandarin, retrieves from the English source, and answers in the language of the question, with a citation back to the English document. There is no second corpus to maintain, no translated SOP that falls out of date, and no ambiguity about which version governs. Modern models handle this well for procedural content; where they struggle is specialized vocabulary, which is why a short bilingual glossary of property terms (room status codes, chemical names, equipment names, brand-specific service language) ingested alongside the SOPs improves parity measurably.
Voice matters as much as language. A room attendant with gloved hands and a cart in the corridor is not going to type a question. She will hold a button and ask, and expect a spoken answer. Any assistant serving line staff should support speech-to-text in the team's languages, and the deployment plan should include a quiet test of how the microphone performs over the sound of a vacuum. Test the translated answers with native speakers on your own team before launch, and for chemical handling and safety procedures, have those answers reviewed by someone who would be accountable if they were wrong.
| Design choice | Recommended approach | Why it matters |
|---|---|---|
| Source language | Single governance language; never maintain parallel translated SOPs | Translated documents drift out of sync and create a second version of the truth |
| Answer language | Match the language of the question automatically; allow manual override | Removes the step of choosing a language, which is itself a barrier |
| Glossary | Bilingual property glossary ingested as a document: codes, chemicals, equipment, brand terms | Largest single driver of translation accuracy on procedural content |
| Input mode | Voice input on mobile as the default for housekeeping, stewarding, engineering | Hands are busy; typing on a phone in a second language is slow |
| Safety content review | Native-speaker sign-off on translated chemical, fire, and medical answers before launch | These are the answers where a translation error carries real liability |
| Reading level | Instruct the assistant to answer in short steps at a plain-language level | A correct answer that is too dense to follow is not a useful answer |
Shift Handover: From Conversation to Document
Most properties do not know they have a handover problem. They know they have a guest complaint problem, a maintenance response problem, or a room-readiness problem, and they treat each as its own failure. The pattern underneath, as the operational literature on handovers describes it, is that when teams rely on verbal updates alone, the details most likely to affect the next shift are precisely the ones most likely to be dropped: the open request, the promise made to the guest in 1412, the room that was walked but not released, the contractor who is coming back at seven.
The internal assistant fixes this by reading sources that already exist and writing the handover that nobody has time to write. At the end of a shift it pulls from the PMS trace log, the open ticket queue in the service-request or maintenance system, the previous shift's notes, the arrivals and VIP list for the next period, and any flagged messages in the guest messaging platform, and produces a short structured summary for the incoming team: what is open, what was promised and to whom, what is out of order, what changed since the last briefing. The outgoing supervisor reviews and adjusts it in two minutes. The incoming supervisor reads it, confirms, and starts the shift with the same picture the last one had.
A handover that lives in a document can be searched at three in the morning by a night auditor who was not in the room when the promise was made. A handover that lives in a conversation cannot.
The searchability is the underrated half. Once handovers are generated as documents and indexed into the same assistant, the question "what did we tell the guest in 1412 about the late checkout?" has an answer at any hour, from anyone with the right role. That closes the loop between handover and knowledge: the handover becomes part of the property's memory rather than something that evaporates at the end of the briefing. Over time the pattern data (which categories of open item recur, which departments generate the most cross-shift promises) becomes an operations dashboard that no one had to build.
The prerequisites are integrations, and this is the part of the project where properties most often need help. The assistant has to read the PMS, the ticketing system, and the messaging platform, and it should write the finished summary back to wherever the team already looks (a Teams channel, a printed sheet at the desk, the ticketing system's shift log). Properties that treat the handover module as a standalone chat window get standalone results; those that wire it into the systems the team already uses get the compliance and the time savings. This is typically where a custom integration and automation build earns its cost several times over, because the integration work is modest relative to the labor it recovers, and it is the same integration layer that later powers task dispatch, guest messaging, and reporting.
Measuring Deflection and Adoption
An internal assistant that is used is easy to spot. One that is working is harder, because the benefit shows up as things that stop happening: supervisor interruptions, repeated questions, wrong answers, slow ramps. You have to measure the absence, which means you have to measure the baseline first. The two-week supervisor question log you built for content readiness is also your deflection baseline. Keep it.
The metric set below is what we recommend for the first 90 days. It is deliberately small. Adoption tells you whether people use it. Deflection tells you whether it is replacing supervisor time. Quality tells you whether it is right. Speed tells you whether it is faster than the alternative. Onboarding tells you whether new hires become independent sooner, which is where the largest single financial return usually sits. Accor's team-facing assistant, piloted across Fairmont and Middle East and Asia Pacific properties, reports a 76 percent satisfaction rate, an expected 25 percent reduction in PMS support requests, a 30 percent reduction in onboarding time, and 30 to 60 minutes saved per employee per day. Those are the right categories of number to hold yourself to, at whatever scale you operate.
| Metric | Definition | Baseline source | 90-day target |
|---|---|---|---|
| Weekly active users | Associates who asked at least one question this week, as a share of scheduled headcount | Zero at launch | 60% or higher; 80% in housekeeping and front office |
| Supervisor deflection | Procedural questions answered by supervisors per shift, before versus after | Two-week pre-launch log | 40 to 60% reduction |
| Thumbs-down rate | Share of answers rated unhelpful or wrong by the user | Golden-set faithfulness score | Under 5%, trending down |
| Escalation and refusal rate | Share of questions the assistant declined and routed | Golden-set refusal test | 10 to 15% at launch, falling as content backlog closes |
| Time to answer | Median seconds from question to answer, versus median minutes to reach a supervisor | Supervisor log timestamps | Under 15 seconds versus 4 to 12 minutes |
| Days to independent shift | Days from start date until a new hire works a shift without supervisor assist | HR and department records for prior 12 months | 25 to 30% reduction |
| Content backlog | Logged unanswered questions awaiting a document or a decision | Zero at launch | Under 20 open items, each with an owner and date |
| Monthly golden-set re-run | Retrieval and faithfulness scores on the original test set plus 20 new questions | Launch scores | No regression; catches content drift and vendor model changes |
Two cautions on reading the numbers. First, usage without deflection is a sign the assistant is answering questions that were never going to reach a supervisor, which is fine but not the business case; look at the deflection figure before you declare success. Second, a falling refusal rate is good only if the thumbs-down rate is also falling. If refusals drop while complaints rise, the assistant has started guessing, and that is a configuration regression to catch in the monthly golden-set re-run rather than in a guest incident.
Implementation: A 90-Day Sequence
The sequence below is what a full-service independent or small-group property can execute with a project owner (usually the director of rooms or the hotel manager), one super-user per department, and outside help for integrations. Select-service properties compress it; resorts with many outlets extend Wave 2.
Weeks 1 to 3: questions and content. Run the supervisor question log. Collect the top 20 questions per department. Map each question to a document, a writing task, or a decision. Retire superseded versions. Assign owners and review dates. Write the bilingual glossary. Build the golden question set of 100 to 150 items with correct answers and sources, including 15 to 20 questions that have no answer in the corpus.
Weeks 4 to 5: platform and ingestion. Select the platform against your requirements: role-based access, multilingual voice input on mobile, mandatory citations, configurable refusal, an audit log, and data residency terms you can sign. Ingest Wave 1 only. Run the golden set. Iterate on chunking, metadata, and prompts until retrieval clears 90 percent and faithfulness clears 95 percent. Run the multilingual parity test with native-speaker review. Do not launch until refusal behaviour is correct.
Weeks 6 to 8: pilot with two departments. Housekeeping and front office are the usual choice because they generate the most questions and have the clearest standards. Train supervisors first, then line staff, in short sessions on the floor rather than in a classroom. Make the assistant the first place to ask, and make supervisors the second, explicitly. Log every refusal as a content task. Publish the weekly active user and deflection numbers to department heads.
Weeks 9 to 12: handover module and Wave 2. Connect the PMS, ticketing, and messaging integrations. Launch the shift-handover summary for the pilot departments, with supervisor review required. Ingest Wave 2 content. Expand to F&B and engineering. Run the first monthly golden-set re-run. Review the metric set against targets and decide on Wave 3 scope.
Governance runs alongside all of it. The assistant should be covered by the property's AI policy: what it may answer, what it must refuse (medical advice beyond first-response procedure, legal questions, anything about a named guest's personal data outside role), who reviews the logs, and how staff report a wrong answer. If the property does not yet have such a policy, our guide to writing a hotel AI policy covers the structure, and the internal assistant is the ideal first system to govern under it, because its failures are visible, low-stakes, and correctable.
Where Properties Go Wrong
Five failure patterns account for most abandoned deployments. Ingesting everything, so the assistant contradicts itself from the first week. Skipping the golden set, so nobody knows whether it is accurate until a guest finds out. Launching without refusal configured, so it guesses. Treating it as an IT project rather than an operations project, so nobody owns the content calendar and the corpus rots. And measuring usage instead of deflection, so leadership sees an adoption chart and never sees whether supervisors got their time back.
Each of these is avoidable, and none of them is a technology problem. The technology is the easy part now. The properties that get real value from an internal assistant are the ones that treat it as what it is: a forcing function for deciding what the standard is, writing it down once, keeping it current, and delivering it to the person who needs it in the language she reads and at the moment she asks. That was always the job. The assistant just makes it possible to do at the scale of every shift.
Frequently Asked Questions
Do we need to rewrite all our SOPs before an internal AI assistant is useful?
No, but you need to triage them. Most properties can go live on a curated set of 40 to 80 documents that answer the questions staff actually ask most often: brand standards, front-office procedures, housekeeping room specs, emergency response, HR policies, and the current F&B menus and allergen sheets. The readiness checklist above separates documents that can be ingested as-is from those that need a single owner, a version date, and a rewrite into short procedural steps. Ingesting everything at once, including outdated and contradictory versions, is the most common reason a pilot fails.
How accurate does the assistant have to be before we trust it with staff?
Measure it against a golden question set before launch, not after. Build 100 to 150 real questions collected from supervisors and line staff, write the correct answer and the source document for each, and score the assistant on retrieval accuracy (did it find the right document), answer faithfulness (did the answer stay within what the document says), and citation. A practical launch threshold is 90 percent retrieval and above 95 percent faithfulness on that set, with the assistant configured to say it does not know and route to a supervisor rather than guess. Retrieval-augmented systems still hallucinate; Stanford's evaluation of commercial legal research tools found rates between 17 and 33 percent, which is why the refusal behaviour and the citation matter more than the model.
Can the assistant serve staff who do not read English well?
Yes, and for many properties this is the single largest benefit. Roughly a third of the US accommodation workforce is foreign-born, and a large share of housekeeping and stewarding teams work more comfortably in Spanish, Haitian Creole, Tagalog, or Portuguese than in English. A well-built assistant accepts questions in the employee's language and answers in that language while retrieving from the English source document, so there is one version of the truth and many ways to read it. Voice input matters as much as translation for teams that are working with their hands. Test the translated answers with native speakers on your own team before launch, especially for safety and chemical-handling procedures.
What does the assistant actually do at shift handover?
It reads the sources that already exist (the PMS trace log, the open ticket queue in the service-request system, the previous shift's notes, arrivals and VIPs for the next period) and produces a short structured summary for the incoming team: what is open, what was promised to which guest, which rooms are out of order, what changed since the last briefing. The incoming supervisor still reads and confirms it. The point is to stop relying on a verbal handover that loses the details most likely to affect the next shift, and to make the summary searchable afterwards so a night auditor can ask what was promised to the guest in 1412.
How do we prove the assistant is worth what we pay for it?
Track deflection, not just usage. Before launch, have supervisors log for two weeks the questions they answer by radio, text, or in person, by category. After launch, compare. The metric set above covers adoption (weekly active users as a share of headcount), deflection (supervisor questions per shift, before and after), quality (thumbs-down rate, escalation rate, golden-set accuracy re-run monthly), speed (time to first answer versus time to reach a supervisor), and onboarding (days to independent shift for new hires). Accor's assistant for hotel teams reports a 76 percent satisfaction rate and an expected 30 to 60 minutes saved per employee per day; a property of 120 associates that recovers even 20 minutes a day is recovering roughly 40 hours a day of capacity.
Peter Mack is a hospitality technology strategist and founder of HospitalityOS, helping independent hotels and resorts implement AI systems that drive revenue and reduce operational costs. With 25 years in hospitality operations and technology, he has worked with properties of all types and in every region as both a General Manager, Founder, Operator, Asset Manager, and Owner.