A complaint arrives in Kustomer or Zendesk. Whoever answers it needs the folio, the guest's tier, and the policy before offering anything. Service Recovery brings those together. It reads the conversation or ticket, finds the reservation, reads the folios and charges from Oracle OPERA Cloud or the bills from Mews, and reads the membership tier from the OPERA Cloud profile or the contact record in HubSpot.
It then proposes one gesture from your recovery policy: a charge adjustment, a credit, or an amenity, sized by the tier and the complaint. The proposal is posted to Slack with approve and decline buttons. The manager who approves is named on the receipt, and a note goes back onto the conversation.
This is a reference listing. It documents what Fibric would read from Service Recovery 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
Conversations, messages, tags, and satisfaction responses in Kustomer, and the notes already on the conversation
Tickets in Zendesk with requester, description, tags, and custom fields such as room or confirmation number
Folios, folio history, and transaction details for the reservation through the OPERA Cloud csh module: getFolio, getFolioHistory, getFolioTransactionDetails
Bills and order items for the customer in Mews through bills/getAll and orderItems/getAll
Membership details and member history on the guest profile through the OPERA Cloud crm module: getProfile, getMembershipDetails, getMemberHistory
Contact properties in HubSpot, where you keep a tier or a lifetime value on the contact record
Button responses on the proposals it posts to Slack, delivered as block_actions payloads
Proposed actions
Target capability: propose a charge adjustment on the folio through OPERA Cloud adjustTransactions, sized by your recovery policy for the complaint and tier
Target capability: propose a credit or amenity posted to the folio through postBillingCharges, or an order in Mews through orders/add, with the reason attached
Target capability: propose the reply to the guest in Kustomer or Zendesk, naming what was found and what is offered
Target capability: propose a note on the conversation or ticket recording the gesture, the policy line it came from, and who approved it
Target capability: propose escalation to a named manager when the gesture the policy allows is below what the complaint warrants
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Adjust the folio for a room that was not ready
A Kustomer conversation says the room was not ready at check-in. The operator reads the OPERA Cloud folio and membership tier and proposes the adjustment your policy allows, posted to Slack for the front office manager.
A Zendesk ticket disputes a minibar charge. The operator pulls the Mews bill items, proposes a credit for the disputed line and a reply, and leaves a note on the ticket naming who approved.
A top-tier contact in HubSpot reports a missed airport transfer. The gesture the policy allows is too small, so the operator proposes an escalation to the general manager in Slack with the folio attached.
A Kustomer or Zendesk connector for the channel where complaints arrive
An Oracle OPERA Cloud connector with the csh and crm API groups subscribed, or a Mews connector with bill and customer read access
A written recovery policy: which complaints qualify, the gesture allowed per membership tier, and who may approve above each amount
A Slack connector with an approvals channel and the managers who approve in it
A way to find the reservation from the complaint: confirmation number, room and date, or the guest's email on the profile
Authentication
Reads conversations through the Kustomer API key or Zendesk API token your connector holds, reads folios and profiles through the OPERA Cloud application key and bearer token or the Mews tokens, and posts proposals through the Slack bot token with chat:write.
Limits
A complaint that names no reservation, and no guest the profile search can match, is left for a person with the search it ran.
The gesture never exceeds the amount your policy allows for that tier. Anything larger becomes an escalation, not a proposal.
Nothing is posted to a folio, and no guest is answered, until a named manager approves in Slack.
Loyalty points and tier changes are not proposed. It reads membership; it does not write to a loyalty program.
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.
Every adjustment, credit, amenity, reply, and escalation. The Slack post shows the complaint, the folio lines involved, the membership tier, the policy line applied, and the exact amount or item. Approve or decline with a button; an edit comes back as a new proposal.
What record is left?
A receipt per complaint: the conversation or ticket, the reservation and folio read, the tier, the policy line, the gesture, the Slack approver and time, and the folio transaction id. The same facts are written as a note on the conversation.
Can it post a credit without a manager?
No. A credit or adjustment is posted once, through the property system connector, only after a named person approves in Slack. Small gestures still need an approver; the policy threshold only decides who that is.
Ask about Service Recovery
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