Evaluate the handover, not just the profile.
A useful hospitality memory platform changes what the next employee can do. This AFG-authored evaluation guide turns that proposition into observable tests for hotels and cruise lines. It is a proposed buyer method, not a certification standard or a completed benchmark.
Choose a defined operation: one property team, a dining station, a cabin-service group or another manageable service unit. Record the starting workflow and agree which guests, staff roles, languages and departments are in scope.
Seven practical demonstrations to request
Can staff record a useful detail during work?
Try: Have a staff member capture a fictional guest request in their working language using the proposed entry method.
Inspect: Measure entry time and missing detail separately from time spent serving or observing. Check that the report remains understandable after processing.
GuestMemoryOS proposition: One-button voice or text QuickNotes, alongside five daily role-specific prompts.
Does the detail belong to the right person?
Try: Use a fictional group booking in which one traveller requests a particular item for another.
Inspect: The record should identify the intended guest or remain unresolved. It must not silently assign the preference to the payer.
GuestMemoryOS proposition: Guest context and source attribution are central to the workflow.
Can a temporary request stay temporary?
Try: Record a one-evening room-service request, then introduce a later correction.
Inspect: Inspect whether staff can see the original context and the update. A temporary situation should not become an unquestioned lifelong preference.
GuestMemoryOS proposition: Observations, proposed memories and curated retained knowledge have distinct roles.
Does another colleague receive useful context?
Try: Change the on-duty colleague and ask the receiving team to prepare the next relevant interaction.
Inspect: Check relevance, access permissions and whether the employee can explain the service action without seeing unrelated private information.
GuestMemoryOS proposition: Manager oversight and relevant department briefs support continuity.
Does the knowledge improve service?
Try: Follow a recorded meal comment through a proposed change, a chef’s decision and the guest’s response.
Inspect: Separate recommendation, completed action and guest reaction. No complaint is not the same as a positive response.
GuestMemoryOS proposition: Recommendations connect staff input with opportunities to improve the current stay.
Can the next stay build on the last?
Try: Close a fictional stay and prepare a new one at a participating property or ship in the agreed trial scope.
Inspect: Inspect identity matching, retained context, changed preferences and the receiving team’s preparation. A walkthrough is not proof of a live group deployment.
GuestMemoryOS proposition: Retained memory supports a prepared return within agreed group permissions.
Can a return invitation use real service context?
Try: Select an approved, non-sensitive experience the guest enjoyed and draft a relevant invitation.
Inspect: Check attribution and communication permissions. Track actual campaign response rather than assuming a memory caused a booking.
GuestMemoryOS proposition: Approved service context can support the operator’s existing CRM and marketing workflow.
Agree the measures before the trial.
For each measure, record the sample, time window, inclusion rules and source. Compare like service settings where possible. If workload, staffing or guest mix changes, record that change rather than assigning every difference to the software.
- Useful contributions: review a defined sample of notes against guest attribution, clarity, relevance and role. Keep daily-question completion separate from additional note volume.
- Handover continuity: among relevant reviewed items, count those available to the authorised receiving team before the next interaction.
- Completed service actions: count actions recorded as completed; distinguish them from suggestions and opportunities.
- Repeated requests: record instances where guests must restate something already captured, and inspect why.
- Guest response: retain the guest’s direct comments or ratings separately from staff interpretation.
- Staff workload: include capture, review, briefing and follow-up time, not just the seconds used to enter a note.
- Return behaviour: track later actual bookings over an agreed period. A predicted rebooking percentage is a separate estimate.
Build a business case from incremental results.
Use the operator’s own costs and margins. An illustrative structure is: measured additional contribution from repeat or direct bookings + measured operating savings − software, integration, training and ongoing operating costs. Compare against a baseline and include a period long enough to observe returns.
Avoid double-counting the same booking as both retention value and commission savings. Time saved is not automatically a cash saving; show how it is redeployed or reduces actual cost. Keep scenario calculations separate from measured results.
What the operator should receive
The final decision pack should contain adoption evidence by role, a service-action log, a reviewed sample of retained memories, a next-stay preparation example, integration requirements and unresolved governance questions. Agree in advance who can inspect the records and who owns the decision.
Expand where the evidence shows a useful and manageable service improvement. Adjust or stop where identity, relevance, workload or permissions do not meet the agreed standard. A trial earns the next stage through observed results.
Discuss an AFG operator trial · Inspect the supporting evidence · Return to the platform selection case