Integrations
We read your systems into a warehouse that belongs to you. Each tool is connected by the role it plays, so the PMS is the PMS whether it is Guesty or Hostaway, and swapping one for the other later is a connector, not a rebuild. Read only, every day, with the account verified before a single row moves.
How it is organised
Every report and detector reads from the role. That is what makes the system portable across stacks, and what keeps a change of tool from turning into a rebuild.
| Role | What we read from it | Live today | Next |
|---|---|---|---|
| Property management system | Listings and the daily roster, reservations of every status, folio lines, nightly fares, payments, the money model | Guesty | Hostaway |
| Pricing and revenue management | Recommended rates, market context, minimum stay by date, daily availability snapshots | Wheelhouse | PriceLabs |
| CRM | Deals and full stage history, contacts, owners, tasks, email metadata. Never email bodies | HubSpot | |
| Guest messaging and operations AI | Conversation metadata, escalations, response times, task events. Never message content | Conduit | |
| Field operations | Cleaning, inspection and maintenance tasks, durations, issues raised | Breezeway | |
| Ancillary revenue and experiences | Orders per stay, attach rate, commission, what sells where | Epicurate | |
| Email marketing | Campaigns, audiences, send and engagement metadata | Mailchimp | |
| Guest data capture | Capture volume by property, consent state, downstream campaign metadata | StayFi | |
| Accounting | Owner statements, receivables, the cash side of every booking | QuickBooks, Xero |
Every tool
A tool gets its own page when its connector has shipped and there is something real to say about it. Until then it is listed here with its role and its status, and nothing more, because a page with nothing behind it helps nobody.
Reservations of every status, folio lines, nightly fares, payments. And eight things the API does that the documentation does not mention.
LiveDeals with full stage history, contacts, owners, tasks. Email metadata only. Sensitive identifiers refused by name before any request is made.
Daily availability and rate snapshots per listing, recommended rates, market context. Pricing facts come from here; booking facts never do.
Same role as Guesty, same staging contract downstream. One connector, and every report and detector works unchanged.
Same role as Wheelhouse. Recommended rates, market data and minimum-stay rules by date.
Conversation and escalation metadata, response times, and the operational tasks its agents raise. Never the message content.
Tasks, durations, issues. One caution from experience: field-ops tools rarely carry labour cost, so measure fill before building a metric on it.
What sells per stay, attach rate by property and season, commission earned. The revenue between a reservation and checkout.
Campaigns, audiences and engagement metadata, so a repeat-guest offer can be measured from send to booking.
Capture volume and consent by property, and what the downstream campaigns did. Contact details stay where the AI cannot reach them.
The cash side of every booking, so recovered revenue can be confirmed as collected, not just booked.
What a connector is
Tell us what it is and what role it plays. If it has an API, it is a connector and a staging model, not a project. If it does not, we will say so.