A suite that sits empty tonight earns nothing, and the guest arriving in a standard room might have paid for it if asked. Upgrade Offer reads tomorrow's arrivals, availability by room type, and what the guest's profile and loyalty record say about past stays and preferences. It sets a price inside the bounds you give it and an expiry before the arrival time.
The offer is proposed to the front office for approval and sent to the guest by text or WhatsApp, with a payment link. When the guest pays, the operator proposes the room-type change on the reservation. Nothing is charged and no room moves without those approvals.
This is a reference listing. It documents what Fibric would read from Upgrade Offer 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 for the next day with booked room type and rate, from OPERA Cloud, Cloudbeds, Mews, or apaleo
Available room types and remaining inventory above the booked type, through getAvailableRoomTypes in Cloudbeds or the par and inv modules in OPERA Cloud
Guest profiles and preferences through the crm module in OPERA Cloud, and loyalty fields on the contact in Salesforce or HubSpot
Past offers to the same guest and their outcome, so a guest who declined last week is not asked again
Payment link and checkout session events from Stripe, including checkout.session.completed
Delivery status of each offer message from Twilio or the WhatsApp Cloud API
Proposed actions
Target capability: propose an upgrade offer per arrival: from and to room type, price within your bounds, and expiry, for the front office to approve
Target capability: propose a Stripe payment link for the approved price, created through POST /v1/payment_links
Target capability: propose the offer message to the guest by SMS through Twilio or as an approved WhatsApp template
Target capability: propose the room-type change on the reservation once the payment is confirmed: putReservation in Cloudbeds, amend in apaleo, putReservation in OPERA Cloud
Target capability: propose deactivating the payment link at expiry or when the room type sells out
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Sell the empty suite the night before
Cloudbeds shows suites open for tomorrow and a guest booked in a standard room. The operator proposes a priced offer with a noon expiry, a Stripe payment link, and the SMS through Twilio, for the desk to approve.
Salesforce marks the arriving contact as a repeat guest who prefers high floors. The operator proposes the upgrade that matches from OPERA Cloud availability and drafts the WhatsApp template message.
Stripe reports the checkout session complete. The operator proposes the amend action on the apaleo reservation with the new unit group, and the desk confirms it before the guest arrives.
A property management connector with arrivals and availability by room type: Oracle OPERA Cloud, Cloudbeds, Mews, or apaleo
A Stripe account with the Payment Links API in use and a webhook for checkout session events
A Twilio number or a WhatsApp Business Platform number with an approved template for offers
Price floors and ceilings per room-type pair, the earliest send time, and the guests who are never offered, set by you
Optionally, a CRM connector such as Salesforce or HubSpot carrying loyalty tier and stay preferences
Authentication
Upgrade Offer holds no credentials. It reads arrivals and profiles through your property management and CRM connectors, creates links through your Stripe connector, sends through your messaging connector, and amends reservations through the property management connector, each after approval.
Limits
Price stays inside the bounds you set. It does not run revenue management or read competitor rates.
The payment link is a Stripe hosted page. Money is taken by Stripe when the guest pays, not by the operator.
A WhatsApp offer outside the 24 hour service window needs an approved template; the operator proposes only from templates you have.
Where the guest has already been upgraded at the desk, the offer is withdrawn and the link proposed for deactivation.
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.
What does the front office approve for an upgrade offer?
The offer itself: guest, room types, price, and expiry, with the availability and profile that justify it. Then the message text. Then, after payment, the change to the reservation. Each is a separate approval, and a person can edit the price before it goes.
What record is kept for an offer?
A receipt per offer: the availability at the time, the profile fields used, the price and expiry, who approved it, the message and its delivery status, the payment link and its outcome, and the reservation change with how to undo it.
Does it charge a guest or move a room on its own?
No. Payment happens on a Stripe page the guest chooses to open. The reservation changes only after payment is confirmed and a person approves the amendment. It never sends an offer or creates a link without approval.
Ask about Upgrade Offer
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