Skip to main content

Guest communication virtual concierge

A fast answer is not a fulfilled guest request.

A guest communication virtual concierge answers property questions and prepares service requests from approved information and authorized stay records. The pattern Werkon would validate preserves language preferences, changing operating details and a clear human handoff. Guests review consequential changes, while property staff own access, safety, request acceptance and fulfillment. A conversation or acknowledgment does not confirm service completion.

Property information and stay-specific authority

General information, reservation answers, disclosure, service requests, commercial changes and emergencies need different handling. Verify delegated authority for the requested action or detail. Room, occupancy, itinerary, companion, contact, access, folio, payment and complaint information should not reach an unverified requester.

Preserve original words, guest-selected language, translation version and uncertainty. A valid language tag does not establish translation quality, accessibility or understanding. Current hours, inventory, policy and property facts need approved sources and effective dates, with missing, expired or conflicting information shown clearly.

Requests, messages and help

A request needs the exact property, permitted location, service, quantity, timing, charge disclosure and owner. Track acceptance, assignment, acknowledgment, progress, completion, rejection, cancellation, failure and reopening separately. Reservations, payments and account changes remain with their authoritative systems, and response expectations come from approved operating policy.

Operational messages must not silently become marketing consent. Apply destination, opt-out, quiet-hour, retention and deletion rules. Provide human help and approved local emergency channels; the concierge is not an emergency service. Distress, threats, medical concerns, harassment, safeguarding, discrimination, access failure and repeated complaints need qualified people, with later corrections and guest feedback preserved.

Communication boundary

Answer the guest without inventing the property or the service.

A useful concierge joins approved information to accountable operations. Four boundaries keep a conversation from becoming an unsupported promise.

01

Requester, stay, channel, and disclosure context

Resolve property and tenant, channel, requester, guest or representative role, stay or visit, approved destination, language, accessibility need and the verification level required for the requested information or action.

Required evidence: Property and tenant identifiers, conversation and channel, requester and guest match, delegation source, reservation or visit reference, destination ownership, authentication event, disclosure class, language tag, accessibility preference, consent and request version.

02

Approved answer and live property truth

Retrieve property-scoped content whose owner, source, effective period, locale and approval are known; re-read changing hours, availability, price, status and policy; and expose missing or conflicting evidence rather than filling gaps.

Required evidence: Question and intent candidate, approved source passages, content owner and review state, property and audience scope, effective and expiry time, locale, live-system response, answer draft, citations, uncertainty, translation version and guest correction.

03

Service request, staff task, and commitment

Capture exact service, timing, location allowed for use, quantity, accessibility details and disclosed charges; create one attributable request; route it to the accountable team; and keep acceptance, assignment and actual completion separate.

Required evidence: Request identifier, guest-confirmed details, charge and policy review, deduplication key, destination queue, owner and priority rule, accepted, assigned, acknowledged, in-progress, blocked, completed, rejected or canceled state, timestamps and staff receipt.

04

Escalation, recovery, and observed outcome

Transfer sensitive, ambiguous, urgent, safety, complaint, repeated-failure and compensation cases with the minimum useful context; preserve ownership; and reconcile delivery, service, charge, correction, reopening and recovery evidence.

Required evidence: Escalation reason and severity, safety or emergency route shown, handoff packet and recipient, staff acknowledgment, response and service event, guest reply or correction, charge result, complaint owner, recovery decision, reopened work and final disposition.

Message-to-service path

Keep the answer, request, and actual service in separate states.

The conversation is only the front door. Every changing fact and physical service needs an authoritative source, owner and later outcome.

  1. 01

    Resolve purpose and safe context

    Identify property, tenant, channel, requester role, stay scope, language and accessibility need; classify the request by disclosure and action risk; and ask for proportionate verification only when needed.

    Owner
    Guest-service, privacy, accessibility and identity owners
    Evidence
    Property and tenant, channel, requester, guest or representative, stay reference, destination, verification level, disclosure class, language and accessibility choice, consent, missing context and blocked disclosure.
  2. 02

    Retrieve and qualify the answer

    Search only approved property sources, check scope and effective dates, re-read live facts, preserve supporting passages and translate or simplify without losing source meaning or uncertainty.

    Owner
    Property-content, reservations, operations and language owners
    Evidence
    Source set and query, passages, owner, version, property and locale scope, effective time, live response, conflicting or missing fact, draft, translation, uncertainty and answer citations.
  3. 03

    Confirm and create the service request

    When action is needed, show the exact service, timing, location, quantity, accessibility details, expected policy and any charge; obtain correction or confirmation; then create one request in the operating system.

    Owner
    Front-office, service, finance and accessibility owners
    Evidence
    Normalized request, guest review, service code, property location, timing, quantity, accommodations, disclosed charge and policy, confirmation, deduplication key, task identifier and creation receipt.
  4. 04

    Route, acknowledge, and escalate

    Apply deterministic team, priority and coverage rules, notify the accountable queue, report only observed task state and escalate unavailable, sensitive, repeated, urgent or safety-related work to a person without losing the thread.

    Owner
    Property operations, safety, security and duty managers
    Evidence
    Routing rule, queue, owner, coverage, priority, notification attempt, accepted or rejected state, acknowledgment, escalation trigger, handoff packet, receiving person and response expectation from approved policy.
  5. 05

    Reconcile service and recovery

    Join message delivery to staff work and observed service, preserve guest corrections and reopened tasks, reconcile charges or compensation separately and close only under property-owned evidence and complaint policy.

    Owner
    Guest-service, service teams, finance and quality owners
    Evidence
    Sent and delivery state, task progress, service event, completion evidence, guest response, correction, reopened task, charge outcome, complaint, compensation decision, recovery action and final disposition.

Authority map

Separate language assistance, operating controls, and property judgment.

A model can interpret and draft. It cannot verify a guest by conversation, create property truth, enter a room, declare a hazard safe or decide compensation.

01

Deterministic communication controls

Software owns tenant, property and stay boundaries, authentication, authorization, source filtering, redaction, locale and time handling, request validation, routing, deduplication, delivery state, task transitions, retention and receipts.

  • Requester, guest, representative, property, stay and destination identifiers
  • Disclosure class, approved source, content version, effective time and locale
  • Service, quantity, timing, charge, priority, route and task-state checks
  • Message, handoff, request, staff, fulfillment, correction and recovery receipts
02

Bounded AI assistance

Models can classify intent, retrieve approved passages, draft source-grounded answers, translate with visible uncertainty, summarize context and propose service or escalation routing while tools enforce every disclosure and action boundary.

  • Intent, urgency, language and request-field candidates
  • Grounded property-answer and clarification drafts
  • Source-preserving translation and accessible rewrite candidates
  • Thread summary, task description and handoff-packet drafts
03

Guest and property staff authority

Guests own corrections, communication choices and consequential confirmations; qualified property staff own identity and delegation exceptions, current operations, access, safety, service acceptance, entry, priority overrides, charges, compensation, complaints and recovery.

  • Guest language, accessibility, destination and request confirmation
  • Identity, representative, privacy and disclosure exceptions
  • Safety, security, welfare, maintenance, room-entry and urgent-response decisions
  • Service completion, manual charge, compensation, complaint and recovery decisions

Concierge components

Build a service ledger, not a fluent inbox.

Guest communication crosses identity, content, channels and physical operations. Four components make each answer and request traceable.

01

Guest, stay, channel, and permission registry

Bind property and tenant, requester, guest and representative, reservation or visit, contact destination, channel, verification, disclosure class, language, accessibility need, communication purpose, consent and retention policy.

Operating contract: Name, room number, caller ID, conversation history or destination is not identity; guest is not authority over every companion; booking organizer is not universal delegate; channel availability is not consent; preference is not guaranteed accommodation; and marketing permission is not implied by operational contact.

02

Approved property-knowledge ledger

Version property, amenity, accessibility, transport, dining, event, local-area, safety and policy content by owner, property, audience, locale, source passage, effective period, review and expiry; link changing facts to live systems.

Operating contract: Retrieved text is not current truth, one property's content is not another's, language tag is not translation quality, translation is not guest understanding, local recommendation is not independent verification and absence from a source must remain unknown rather than false.

03

Request, task, and service ledger

Preserve exact guest request, confirmed service details, charge disclosure, deduplication, task creation, queue, owner, priority, acceptance, assignment, acknowledgment, progress, blockage, completion, rejection, cancellation and reopening.

Operating contract: Question is not request, request is not accepted work, task creation is not acknowledgment, acknowledgment is not progress, closed ticket is not physical fulfillment and staff note is not guest satisfaction or independent proof of condition.

04

Message, escalation, and recovery ledger

Link original and translated messages, destinations, sent, delivered, read, failed and replied states, human handoff, urgent route, complaint, correction, charge, compensation, service evidence and recovery disposition.

Operating contract: Sent is not delivered, delivered is not read, read is not agreement, reply is not resolution, safety escalation is not emergency response, apology is not compensation, compensation approval is not settlement and closed complaint is not satisfaction.

Delivery path

Prove one property, channel, and service loop before expanding.

Begin with a narrow set of approved questions and observable requests whose content, staff work and guest-facing outcome can be followed end to end.

  1. 01

    Choose one bounded guest cohort

    Select one property, approved channel, stay phase, language set, information domain and service family with current owned content, named teams, clear disclosure rules and observable fulfillment evidence.

  2. 02

    Map content, identity, and operations

    Inventory guest and representative roles, authentication steps, disclosure classes, property sources, language and accessibility paths, request fields, charges, team routes, task states, safety and complaint escalations and retention.

  3. 03

    Build grounded answer and task paths

    Implement permissioned retrieval, source and locale preservation, uncertainty, guest correction, exact request review, deterministic routing, deduplication, delivery states, staff receipts and complete handoff without exposing unnecessary stay data.

  4. 04

    Test difficult communication cases

    Exercise wrong property, unverified companion, crossed stay, stale hours, missing source, mixed language, failed translation, inaccessible authentication, duplicate request, unavailable team, delayed delivery, safety concern, charge dispute and reopened complaint.

  5. 05

    Release narrowly and reconcile service

    Start with staff visibility and a small guest cohort, compare answers and service handling with the current channel and follow source corrections, tasks, delivery, fulfillment, escalation, complaints, charges and recovery before expanding.

Release controls

Six controls before a guest answer can become an operating promise.

Communication failures can expose a stay, misstate a property or lose urgent work. These controls keep disclosure, service and recovery attributable.

Property, requester, and purpose are scoped
Bind every conversation to a tenant, property, channel and purpose; separate anonymous information from stay-specific disclosure and consequential action; verify identity and delegation proportionately; and collect only the fields needed now.
Property truth is owned and current
Retrieve only approved, property-scoped content with owner, passage, locale, effective time and review state; re-read live hours, availability, price and operational status; and expose missing, conflicting or expired evidence.
Language and accessibility remain explicit
Preserve original text, guest-selected language, BCP 47 tag, translation version and uncertainty; mark language changes, support keyboard, focus, reflow and understandable correction, and provide a reachable staff-assisted path.
Requests use exact operating states
Show the service, timing, location, quantity, accessibility details, charge and policy before confirmation; create one attributable task; and distinguish accepted, assigned, acknowledged, in progress, blocked, completed, canceled, failed and reopened work.
Messages do not overstate delivery or consent
Use channel-provided sent, delivered, read, failed and replied states; keep operational, safety and transactional contact separate from marketing permission; honor approved destinations, opt-out, quiet-hour and retention policy.
Urgency, complaints, and recovery keep human ownership
Escalate sensitive, ambiguous, repeated, urgent and safety cases without diagnosis or delay, show approved emergency routes, preserve a complete handoff and keep property staff responsible for access, safety, service, compensation and complaint closure.

Outcome evidence

Measure grounded answers and observed service, not chat volume.

A quick reply can still be wrong, inaccessible or operationally lost. Evidence must join the guest question to the owned source and each request to actual staff work.

Baseline

  • Properties, stay phases, channels, guest and representative roles, languages, accessibility paths, approved content domains, services, teams, operating hours, escalation routes and complaint owners
  • Current guest and staff time from question through verification, answer, clarification, task creation, routing, acknowledgment, completion, correction, complaint and recovery
  • Current unsupported answers, stale facts, privacy blocks, translation uncertainty, inaccessible steps, duplicate requests, routing failures, delayed work, reopened tasks, delivery failures and lost handoffs
  • Current source corrections, accepted and rejected requests, actual completions, unresolved work, safety escalations, charges, compensation, complaints and recovery outcomes

Outcome evidence

  • Correct property, requester, stay, disclosure, source, effective version, locale, answer, service, timing, charge, route and status handling against authoritative records
  • Grounded-answer coverage, answer correction, guest clarification, successful handoff, task acceptance, observed fulfillment and exception-recovery time by property, channel, language, accessibility path and service
  • Cross-stay disclosure, unsupported fact, stale hour, wrong-language answer, inaccessible path, duplicate task, false delivery, false completion, lost escalation and unowned complaint prevention
  • Staff workload, request completion, reopenings, source defects, charge outcomes, complaints and recovery evidence against the prior channel with season, occupancy, service availability and guest cohort visible

Guardrails

  • Wrong tenant, property, stay, guest, representative or destination; unnecessary personal data; exposed room, occupancy, itinerary, contact, companion, access, folio, payment or complaint detail; and retained data outside approved policy
  • Expired or cross-property content called current, missing fact invented, language tag called translation quality, translation uncertainty hidden, local recommendation presented as verified, unavailable service promised and unsupported response time shown
  • Task creation called acceptance, acknowledgment called fulfillment, closed ticket called service, sent called delivered, read called consent, operational contact reused as marketing permission and duplicate request or message retry
  • Safety concern minimized, emergency help delayed, diagnosis offered, staff handoff lost, room entry authorized by model, compensation promised, complaint closed without authority and chat activity presented as satisfaction or loyalty outcome

Fit test

Use this pattern when property truth and service outcomes are observable.

Good reason to begin

  • One property has approved content with named owners, effective versions and live sources for changing facts, plus clear identity, disclosure, language, accessibility and communication policies.
  • The operating team can distinguish question, answer, service request, accepted task, acknowledgment, progress, completion, correction, complaint and recovery with durable identifiers and owners.
  • A small service family has exact request fields, charge and policy disclosure, deterministic routing, staff coverage, safe escalation and observable physical or system fulfillment.
  • Wrong guest, stale content, translation uncertainty, inaccessible authentication, duplicate task, failed delivery, unavailable team, urgent issue and reopened complaint can be tested without exposing real guest data or disrupting service.

Resolve before beginning

  • Property source ownership, content review, identity and representative rules, disclosure classes, language support, accessible help, service routing, urgent escalation, complaint ownership or outcome evidence is undefined.
  • The process cannot distinguish retrieved content from live truth, answer from promise, request from task, acknowledgment from fulfillment or staff closure from guest-confirmed resolution.
  • Success is defined by conversation count, response speed or generated sentiment without source accuracy, privacy blocks, guest corrections, staff burden, actual service, reopenings and recovery evidence.
  • The concierge is expected to invent property facts, authenticate by conversation, expose stay data, silently market, guarantee availability, authorize access or charges, diagnose emergencies, decide compensation or close complaints autonomously.

Source basis

Sources behind the control model.

  • 01

    International Organization for Standardization

    ISO 22483:2020: Hotels service requirements

    ISO identifies this international standard as confirmed in 2026 and current. Its public abstract covers hotel staff, service, events, entertainment, safety and security, maintenance, cleanliness, supply management and guest satisfaction, including subcontracted services. The abstract does not define a concierge data model, guest identity, communication consent, service inventory, task states, translation quality, fulfillment evidence, certification or any property's compliance or result.

  • 02

    RFC Editor

    RFC 5646: BCP 47 language tags

    This Best Current Practice defines language-tag structure and semantics for identifying human languages in information objects and, with RFC 4647, forms BCP 47. A well-formed or valid language tag does not identify the guest, select the right language variety, prove translation accuracy, preserve meaning, establish cultural appropriateness, address literacy or accessibility, or show that a guest understood an answer.

  • 03

    National Institute of Standards and Technology

    NIST Privacy Framework 1.1 Initial Public Draft

    The April 2025 initial public draft presents voluntary, high-level outcomes for understanding, assessing, prioritizing and communicating privacy-risk management. Its comment period is closed, but it remains a draft rather than a final revision. It does not choose legal basis, consent wording, identity proof, disclosure policy, permitted guest fields, retention period, jurisdictional compliance or acceptable risk for a property.

  • 04

    World Wide Web Consortium

    Web Content Accessibility Guidelines 2.2

    The current W3C Recommendation includes language of pages and parts, consistent help, text error identification, accessible authentication, keyboard, focus and reflow criteria. Conformance is a web-content accessibility baseline. It does not prove translation quality, plain-language understanding, accessible property service, identity, response time, fulfillment, safety, legal compliance or usability for every person and assistive setup.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Tourism information chatbot

Compare destination information with property-specific guest service and escalation needs.

Open path02

Explore governed AI agents

Compare other bounded agent patterns and the evidence, authority and recovery contracts they require.

Open path03

Design hospitality operations

Frame guest communication, reservations, physical service, staff handoffs and recovery around current property truth and accountable owners.

Open path04

Govern multilingual communication

Preserve source text, language identity, translation uncertainty, qualified review and downstream meaning across multilingual workflows.

Open path05

Design customer communications

Coordinate approved outbound and inbound messages through purpose, permission, observable delivery, response and human recovery paths.

Open path