A hospitality CRM for the businesses hotels and venues hire, from rate card to invoice
The operational CRM of a business whose customers are hotels and venues: client accounts and contacts, venues, rate cards, bookings, client rules, feedback, a client portal that shows each client only what it is entitled to, and invoices raised from the booking into Xero or QuickBooks.
A hospitality CRM is one of two different products, and which one you need depends on who your customer is. If you run a hotel and your customer is the guest, you want guest profiles, stay history, loyalty and marketing fed by your property-management system: buy a guest CRM that integrates with your PMS. We do not build those, and we have no case study of one. If your customers are the hotels and venues themselves (you supply event staff, run catering or events, or provide venue services), your CRM is an account-and-booking system: clients, venues, rate cards, bookings, the rules each client sets, a portal they log into, and invoices. That is what this page is about, and it is where a configured tool often stops fitting.
Our published evidence is one build. A UK event-staffing agency whose customers are hotels and venues has a platform with a read-only client portal that can never read pay, client paperwork produced by the system rather than assembled after the event, and client rules in its auto-assign. It is live with the agency's office, its workers and the hotels and venues it supplies, and it holds client accounts, per-client rate cards, venues, events with PO numbers, per-client qualifications and do-not-return lists, and client feedback. Beyond that write-up, we have delivered CRM, ERP and project-management systems for hospitality and events businesses that are not published as case studies, so this page names no client and gives no figures from them.
One boundary, so two of our pages do not answer the same question. Our staffing agency software page owns the workforce side: recruitment, right-to-work, rostering, check-in and pay. This page owns the client and commercial side: who the client is, what was booked, at what rate, under which rules, what the client can see, and what gets invoiced. In a business that does both, the two share one database, and the hand-off between them is described below. CRM automation in general, across any trade, has its own page.
Which hospitality CRM are you actually looking for?
The same phrase is searched by hotels and by the firms that serve them. Find your row before reading further: for half of these, the honest advice is to buy.
| You are | Your customer is | The CRM has to hold | Our advice |
|---|---|---|---|
| A hotel, resort or group of hotels | The guest | Guest profiles, stays and preferences from the PMS, loyalty, segmentation and marketing | Buy a guest CRM that integrates with your PMS. We have no case study of one and would not be the right firm to build it |
| A short-term-rental or serviced-apartment operator | The guest, and the property owner | Bookings from the platforms and the PMS, owner relationships, reviews, claims | Keep your PMS as the record. Automation around it can help; a new CRM rarely does |
| An event-staffing agency | Hotels, venues and event organisers | Client accounts, venues, rate cards, bookings, client rules, a client portal, invoicing | This page, with our staffing agency software page for the workforce side |
| A catering or events company | Venues, corporate clients and organisers | Enquiries, quotes, bookings with changing headcounts, venue details, invoicing | This page. A configured platform is often enough at first (see the last section) |
| A venue-services firm (AV, cleaning, security, linen) | Hotels and venues, often on a contract | Accounts with many sites, contract rates, recurring and one-off bookings, feedback | This page, if the rate card or the client portal is what hurts |
One booking, from enquiry to invoice
In a B2B hospitality business the record that matters is the booking, not the deal. This is the path we design it to follow. The staffing platform covers parts of it, named in the sections after this one; the rest is the design, not a claim about that build.
- 01
Enquiry, against an account and a venue
A request lands on a client account and a venue, not in someone's inbox. A new client or a new venue is created by a person, once, so the same hotel does not exist three times under three spellings.
- 02
Priced from the rate card in force
Lines are role, headcount and hours (or menu and covers, or service and site), priced from that client's rate card. The version of the rate card used is stored on the booking, so a rate change next month does not quietly reprice work already confirmed.
- 03
Confirmed, with the client's rules attached
Confirmation copies the client's and the venue's standing requirements onto the booking: what the people sent must hold, what they must wear, and who must not be sent. The client receives a confirmation produced from the record.
- 04
Changed before the day, without losing the original
Headcounts move and times shift. Each change is an amendment with who asked, who accepted and when, never an overwrite, so the invoice and any dispute can see what was agreed at each point. Your cancellation terms decide what a late change costs; the system applies them.
- 05
Handed to the workforce side
A confirmed booking becomes shifts or tasks for the people who deliver it. From the CRM side you see whether it is filled, not who is being paid what. In a staffing business this is where our staffing agency software page takes over.
- 06
Delivered, with actuals coming back
Actual hours, covers or quantities come back from delivery (check-in times, a signed sheet, the event lead's count), and the client can confirm them. Disagreements are settled here, before an invoice exists.
- 07
Invoiced from the record
The invoice is computed from the actuals and the stored rate card, then written to Xero or QuickBooks. Nobody types it, and a retry cannot raise it twice.
- 08
Feedback, filed where it belongs
Client feedback and complaints are recorded against the booking and the venue, with an owner and an outcome. Feedback about an individual worker goes to the workforce side, where it can affect allocation, and is not shown to other clients.
What a hospitality services CRM has to hold that a generic one does not
Contacts, companies and deals are the easy part. These are the records that decide whether the system fits.
Client groups, properties and three kinds of contact
A hotel group has properties; each property has someone who books, someone who approves and someone who pays, and they are often three different people at two different addresses. The billing entity is frequently not the venue. Model that on day one, or every invoice query starts with finding out who it should have gone to.
Venues as records, not text
A venue may belong to a client or be a third-party site a client books you into. Access, the contact on the day, loading and arrival instructions live on the venue, so they reach every booking there without being retyped and drifting.
Rate cards with effective dates
Per client, per role or service, with day types (weekend, bank holiday, late finish, short notice) as rules rather than as separate prices someone remembers to pick. Old versions are kept, because a confirmed booking is priced at the card that applied when it was agreed.
Client rules the allocation reads
Requirements, preferred people and do-not-return lists are data with a client and venue attached, not a note on the account that the person rostering has to remember. A rule that lives in a note is how someone the client banned gets sent back.
Paperwork produced by the record
Quotes, confirmations and the client's after-event paperwork are generated from the booking and its actuals, so the document and the record cannot disagree. On the staffing platform, client paperwork is produced by the system rather than assembled after the event.
Feedback and incidents with an owner
A complaint is a record with an owner, a due date and an outcome, linked to the booking, the venue and, where relevant, the account's commercial terms. A thread in someone's inbox cannot be reported on at the next client review.
Client rules are set on the commercial side and enforced at allocation
The commercial side is where a client says what it wants: only people who have worked this venue before, nobody under a given experience level, never this person again. The delivery side is where that has to be true. A CRM that records the rule and a rostering tool that does not read it is two systems and a hope.
On the staffing platform, filling an event runs hard gates before any scoring, and the gates include do-not-return lists, blocked workers, role and requirement matches, double-bookings and the weekly hours cap. Only then does it score what remains (show-up rate, rating, proximity, fair rotation, venue history), with the weights editable in settings. Workers qualified for that client are exhausted before anyone else is considered, and that is an ordering, not a weight, by design. A heavy enough score elsewhere cannot outrank a client's own qualified people.
The lesson for a CRM is that a client rule has to be written in a form the allocation can read, with the client and venue it applies to, and that some rules are gates rather than preferences. Deciding which is which is a commercial decision, made once with the account manager, not a setting someone tunes later.
A client portal is a permission problem before it is a screen
A hotel or venue client wants to log in and see its bookings, venues, confirmations and paperwork without ringing you. What it must never see is just as specific: what a worker is paid, your margin, another client's bookings, a worker's personal details. Build the portal first and add the restrictions later, and one of those leaks.
On the staffing platform the client role has no table policy at all. It reads only through views that each filter themselves to what that client is entitled to see, and a test pins the exact set of policies, views and privileged functions, so adding one without review fails the build. That the client cannot see pay is proved on every merge rather than promised in a specification. The platform is live, and that is the bar we hold a custom portal to.
On a configured platform the question becomes what a guest can see. monday.com's documentation describes guests as external users invited to shareable boards, available from the Standard plan up, so a rate or margin column on a board you share is a column you have shared. Check exactly what your plan exposes before you invite a client in, or keep commercial columns on a board no guest is ever invited to.
The invoice is computed from the booking, then written to Xero or QuickBooks
The staffing platform holds per-client rate cards and events with PO numbers, and every Monday it emails finance the payroll CSV. Invoicing inside the platform is the newest part of that build, added at the agency's request in October 2026, and it does not post to Xero or QuickBooks. So the accounting integration in this section is the design we build, and the section says where our other published work bears on it.
The commercial CRM decides what is owed; the accounting package records it and chases it. So the invoice is built in the CRM from the actuals and the rate-card version stored on the booking, plus any agreed extras, and written to the ledger by API with a key tied to the booking. Corrections after that are made the way the ledger expects, not by editing the CRM and hoping it syncs.
- Xero: a sales invoice is the ACCREC type, and its LineItems collection takes any number of lines, so a booking with several roles, day types and extras can be one invoice with one line each. When updating an invoice, Xero recommends sending the existing LineItemIDs, because lines sent without them are deleted and recreated. Invoices that are paid or part-paid are largely closed to edits, so a correction after payment is usually a credit note.
- QuickBooks Online: an invoice references its customer by ID and needs at least one line, and a sales line references an existing product or service. So your roles, services and day types are mapped to items once, at set-up, and a booking line that maps to nothing is held for a person rather than invented.
- Either way, the customer in the ledger is the billing entity, which is often not the venue. That is why the CRM holds the client group, the property and the payer as separate records.
The failure to design out is the double invoice. One of our published Make flows, for a training provider, raises a Xero invoice when a monday.com status changes and writes the invoice number back onto the record; its write-up states plainly that selecting the trigger label again raises a second invoice. For a business invoicing many bookings a week, the key on each booking is what makes a retry safe, and it is the first thing we build.
Beyond the published work, we have built accounting workflows and integrations for clients, including a Zapier build that takes WooCommerce orders into monday.com and then into Xero invoices with multiple line items. None of that is a published case study, so we give no detail or figures from it.
When monday.com or HubSpot configured is enough, and when it is not
Choose by where revenue stalls, the same rule our monday.com and HubSpot comparison uses. Most hospitality services businesses stall after the booking, not before it.
| monday.com, configured | HubSpot, configured | A custom system | |
|---|---|---|---|
| Fits when | Repeat clients and many bookings: the work is delivering, and a booking is an item with a state and an owner | Winning new hotel and venue accounts is the problem: pipeline, attribution and email | Client rules must hold at allocation, the portal must provably hide pay, and the workforce side shares the data |
| Bookings and rate cards | Bookings as items, rate cards as a board; versioned pricing across boards is where mirrors start to strain | A deal is not a booking. Custom objects for bookings need an Enterprise subscription | Bookings, amendments and rate-card versions as tables, with the rules in the database |
| Client access | Guests on shareable boards from the Standard plan up; check what a shared board exposes | Built for your team, not for a client logging in to see their bookings | A portal that reads only through views scoped to that client |
| Invoicing | Through an integration to Xero or QuickBooks, with a key per booking | Through an integration, after the deal is won | Computed from actuals and written to the ledger by API |
| Where it breaks | Numbers aggregated across relationships (margin per client across venues and months) | Delivery: deals left open for months because closing one loses the work | Cost and ownership: it is your system to maintain |
For a catering or events company with a few dozen regular clients, monday.com configured well is often the right first system: one board owns clients, one owns venues, one owns bookings, and each status column means one thing. If new business is the problem, HubSpot before the win and monday.com after it is a legitimate architecture, provided the handover is one-way and each record has one owner.
A custom system earns its cost when the rules stop being preferences: when a do-not-return list must be a gate the allocation cannot pass, when a client portal must be provably blind to pay, when the rate card has versions that confirmed bookings depend on, and when the workforce and the commercial records have to live in one database because every booking becomes shifts and every shift becomes an invoice line. That combination is what people searching for a hospitality ERP usually mean.
Most of our projects land between $5,000 and $10,000 (US dollars); larger systems cost more; that is a typical range, not a quote. A full commercial and workforce system for an agency is one of the larger ones. The variables that move it are the number of client-facing rules, whether a client portal is needed, the accounting package and how much history has to come across.
Where it has shipped
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
- A UK commercial solar installerOne login for a solar business, in place of a patchwork of toolsNot hospitality. A CRM with a customer portal for a commercial solar installer, live with the client's team, included for the same problem in another trade: the customer reads a quote at an unguessable link, and the cost build is stripped on the server before anything leaves it.Case study
- A fleet-telematics providerOrders that file themselves, and an SLA clock that never forgetsNot hospitality, and the people logging in are installers rather than clients. Included because it is the monday.com version of a portal: each person gets a magic link to a page showing only their own items, with no seat and no password, and a single server-side token holds board access.Case study
The disciplines behind it
Platforms that bear on it
Related reading
Neighbouring solutions
Hospitality CRM, specifically
It means two different things. For a hotel, it is a guest CRM: guest profiles, stays, preferences, loyalty and marketing, fed by the property-management system. For a business that serves hotels and venues (event staffing, catering, events, venue services), it is an account-and-booking system: clients, venues, rate cards, bookings, client rules, a client portal and invoicing. We build the second kind, not the first.
We would advise you not to commission one. Guest CRMs that integrate with your property-management system are an established product category, and the integration with your PMS is most of the value. We have no case study of a PMS-integrated guest CRM. Where we can help is around whatever you buy: automation between it and the rest of your tools, with a person checking anything that reaches a guest.
It depends on where your revenue stalls. If winning new venues and corporate clients is the problem, a sales CRM such as HubSpot is built for pipeline and attribution. If the work is mostly delivering bookings for clients you already have, monday.com configured around clients, venues and bookings often fits better. If you need client rules that must hold, a portal that provably hides pay, and your workforce on the same data, that is when a custom system is worth its cost.
Yes, and the design starts from what they must never see: pay, margin, other clients' bookings and workers' personal details. In a custom build the client role reads only through views scoped to that client, as on the staffing platform we built, which is live. On monday.com, guests can be invited to shareable boards from the Standard plan up, so anything on a shared board is visible to them and commercial columns belong elsewhere.
We design the invoice to be computed from the booking (actual hours or quantities times the rate-card version stored on it) and written to Xero or QuickBooks Online by API, with a key per booking so a retry cannot raise a second invoice. In QuickBooks, roles and services are mapped to items once at set-up. The staffing platform does not post to an accounting package, so this rests on the design and on our other accounting work.
Usually it is the same system with the workforce and finance sides joined on. For a staffing or events business, ERP tends to mean that bookings, shifts, hours, pay and invoices share one database, so a booking becomes shifts and each shift becomes an invoice line without anyone re-keying it. Our staffing agency software page covers the workforce half; this page covers the commercial half.
Most of our projects land between $5,000 and $10,000 (US dollars); larger systems cost more; that is a typical range, not a quote. A commercial CRM on its own is a smaller job than a full commercial and workforce system with a client portal, which is one of the larger ones. For an estimate, send your client and venue structure, a sample rate card, how bookings change before the day, and which accounting package you use.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Invoices · Xero Developer
- Invoice · Intuit Developer
- User types explained · monday.com
- Plan your HubSpot data model · HubSpot
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no