Recognition depends on someone noticing. VIP Recognition reads tomorrow's arrivals against what the property already knows: membership tier and points from the profile, stay history and spend from past folios, the account or contact record in Salesforce or HubSpot, and the VIP code the property keeps on the profile.
For each arrival that meets the rule you set, it proposes an amenity as a housekeeping note or task, an upgrade where a higher room type is available, and a greeting note in the general manager's voice, drafted from the stay history. The manager approves each, edits the note, or dismisses.
This is a reference listing. It documents what Fibric would read from VIP Recognition and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.
Inputs
Arrivals with a membership on the profile, through getPreArrivalMemberReservations in the OPERA Cloud rsv module and getMemberHistory in crm
Stay history and profile statistics, through getStayHistory and getProfileStatistics in OPERA Cloud, or customers/getAll and bills/getAll in Mews
Preferences on the profile, through getPreferenceForProfile, and traces on the reservation through getTracesByReservation
Contact and account records in Salesforce, through sObject resources and SOQL, or HubSpot contacts with their properties and history
Availability of higher room types, through the par and inv modules in OPERA Cloud or the apaleo Availability API
Upgrade eligibility on the reservation, through putReservationsUpgradeEligibility and getAwardUpgrades in OPERA Cloud
Proposed actions
Target capability: propose an amenity for the room, as a guest housekeeping note through setGuestHousekeepingNotes in OPERA Cloud or a task through tasks/add in Mews
Target capability: propose an upgrade to an available higher room type, through postRoomAssignment in OPERA Cloud or assign-unit in apaleo
Target capability: propose a greeting note drafted from the stay history, for the general manager to edit and sign
Target capability: propose a reservation preference or alert, through postReservationPreference or postBulkReservationAlerts in OPERA Cloud, so the desk sees the flag
Target capability: propose the next day recognition list as a card in Slack or Microsoft Teams, one line per arrival with tier, history, and gestures
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Flag the member arriving tomorrow
getPreArrivalMemberReservations in OPERA Cloud returns tomorrow's members. VIP Recognition reads each tier and stay history, applies your rule, and posts a card to Slack with the proposed amenity note and upgrade for the manager to approve.
A Salesforce account marks the arriving guest as the signatory on a corporate agreement. The operator adds that to the recognition line and proposes a reservation alert in OPERA Cloud so the desk agent sees it at check-in.
apaleo shows a higher unit group available across the stay. VIP Recognition proposes assign-unit to that group for a returning guest who meets your stay-count rule, and withdraws the proposal if availability drops before approval.
Mews customers/getAll shows a guest on a repeat stay who ordered the same product each visit. The operator proposes a tasks/add for the housekeeping department to place it before arrival, with the history quoted, and a note on the HubSpot contact.
A property management connector with profile, membership, and stay-history read: Oracle OPERA Cloud, Mews, or apaleo
A rule for who counts: tier, lifetime stays, spend, or a VIP code, set by you
Optionally a CRM connector, Salesforce or HubSpot, where the account or contact carries context the PMS does not
A Slack or Microsoft Teams channel for the general manager or guest relations, where the list is approved
Authentication
VIP Recognition holds no credentials of any kind. Profiles, memberships, stay history, and CRM records are read through the connectors you connect; notes, tasks, upgrades, and flags are written through the property management connector after approval.
Limits
It reads tiers and history the PMS and CRM hold. A guest known to the staff but not to the systems is not flagged.
An upgrade is proposed only when the higher room type shows available for the whole stay; it never bumps another reservation.
The greeting note is a draft. It is never sent or printed without a person editing and approving it.
Amenity cost and the number of upgrades per night are limits you set; the operator does not decide them.
Access and pricing
Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.
One line per flagged arrival, with the amenity, the upgrade, and the greeting note as separate proposals. Each has its own approve. The note opens for editing before approval. Dismissing one proposal leaves the others standing.
What record does each gesture leave?
A receipt: the tier and history that triggered it, the rule it met, who approved, the note or task the PMS accepted, the room type before and after an upgrade, and how to reverse it. Dismissed proposals are kept with the reason.
Does it ever upgrade a guest or send a note by itself?
No. It reads memberships, history, and CRM records and proposes. An upgrade, a task, or a housekeeping note is written only after approval, once, through the connector. The greeting note is never sent by the operator at all; a person sends it.
Ask about VIP Recognition
Ask about the capabilities and requirements in this listing.
This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy