A custom property management system (PMS) can remain the source of booking and stay data while CampaignHQ handles guest conversations and campaigns. Connect the agreed data through APIs and webhooks, run the WhatsApp inbox and chat flows in CampaignHQ, and scope any updates back to the PMS before implementation.

Your team has built software around how your properties operate. Replacing it is not the goal. The problem is what happens around it: reception answers WhatsApp on one screen, marketing exports guest lists, and developers get asked to build another reminder whenever a booking rule changes.

This guide is for hospitality operators connecting their own PMS or internal booking platform to a guest-communication workspace. It covers the operating model, the hospitality-specific integration decisions, and a practical first pilot. It is not a guide to buying or building a PMS.

Keep the PMS in charge of the stay

Separate hotel operations from guest communication. The PMS should remain authoritative for reservations, property, arrival and departure dates, booking status, and any room or payment information included in the integration.

CampaignHQ is the workspace for the communication around those records: a shared WhatsApp inbox, chat flows, agent replies, audience segments, and email + WhatsApp campaigns. Your front-desk and marketing teams should not need to edit PMS code to change approved message copy or run a campaign within the agreed setup.

The connection passes selected data and events between the systems. An API lets software request an action or exchange data. A webhook sends another system a notification when something happens. Neither means that every field, conversation, or booking operation is connected automatically.

CampaignHQ’s published capabilities include a shared WhatsApp team inbox, visual workflows, segmentation, custom attributes, and API functions for contact sync, event tracking, journey triggers, and message sending. CampaignHQ is a Meta Tech Provider on the official WhatsApp Business Platform. AWS supports the infrastructure; the buyer-facing benefit is having conversations and campaigns connected to the hotel’s own systems.

For the wider channel plan, see our Email + WhatsApp customer journey guide. Here, the decision is narrower: which PMS information must reach the people handling a guest’s next request?

Give the inbox the right booking context

A guest asks, “Can we arrive early?” The agent needs to know which property and reservation the guest means. A contact name and phone number are not enough when the same person has several stays.

Agree the minimum context the team needs, where it will appear, and which details require opening the PMS. Ask for a demonstration with your records rather than assuming an inbox displays every PMS field.

• Guest identity: retain the PMS guest ID and the corresponding CampaignHQ contact reference. Do not use a shared family or corporate phone number as the only identity check.
• Reservation identity: preserve a separate booking ID. One guest can have a cancelled reservation, an upcoming stay, and a completed stay.
• Property context: carry a property identifier and define which team may see and answer each conversation. Test access and assignment for your account setup.
• Current stay state: specify which dates and statuses are needed for the workflow, and how an agent recognises stale or missing information.
• Permission: carry the evidence and preferences needed to decide whether a particular message is allowed.

A profile field called “next check-in” may help an agent, but it cannot safely represent every reservation. Decide how overlapping stays and group bookings will be handled before relying on contact-level fields to trigger messages.

Connect chat flows without letting them invent hotel decisions

A chat flow can collect a request and help the team respond. Confirming availability, changing a booking, and taking payment are separate operations that need an authorised path into the relevant hotel system.

Consider this hypothetical early-check-in journey:

1. The guest replies to a pre-arrival message in WhatsApp.
2. The conversation is handled in CampaignHQ. The flow asks which reservation the request concerns if the context is ambiguous.
3. An agent reviews the request and checks the authoritative availability information.
4. The guest receives a confirmed answer only after the hotel has accepted the request.
5. If required and supported, the integration records the agreed outcome against that reservation in the PMS.

For the last step, define the exact update: a note, a service request, an arrival-time field, or a reservation change. These are not interchangeable. Agree who can approve each action and what happens when the PMS rejects an update.

Keep a clear handoff to a person. A request involving a complaint, an uncertain booking match, or an unavailable system should not loop through automated replies. Confirm the handoff and any pause in automated follow-ups during the pilot.

Run bulk campaigns from guest segments, not old exports

The campaign opportunity is not “send to everyone in the PMS.” It is to make a useful audience available to marketing without asking engineering to rebuild the list every time.

Start with one defined segment. For example, a proposed repeat-stay campaign could include past guests from a particular property who are eligible for marketing, while excluding opted-out contacts and guests with an upcoming reservation. Your teams must agree which fields and updates make that segment reliable.

Keep three communication jobs separate:

• Reservation updates: information about an actual booking, using its current state.
• Guest service: requests and replies handled through the inbox and agreed chat flows.
• Marketing: relevant offers sent to eligible audiences, with appropriate templates and opt-out handling.

A reservation record is not, by itself, marketing permission. The WhatsApp Business Messaging Policy requires permission before contacting people and requires businesses to honour requests to stop. Within 24 hours of a guest’s last WhatsApp message, you can reply without a template. Outside that window, send only approved message templates. Meta’s template category guidance treats mixed promotional and utility content as marketing. Keep upgrade offers separate from messages intended only to communicate booking information.

Email can carry longer offer details or a stay guide; WhatsApp can provide a concise next step and a reply route. Neither should become a workaround for a guest’s preferences. For email operations, follow the Gmail sender guidelines, including the requirements that apply to bulk senders.

Test the booking changes that break guest communication

The most useful integration demo is not a successful confirmation. It is a changed booking that would otherwise produce the wrong message.

Use authorised test recipients and synthetic reservation data. Run these cases through the proposed setup:

• Rescheduled stay: move the arrival date after a pre-arrival message has been scheduled. The old reminder must not go out.
• Cancelled booking: cancel one reservation while keeping another for the same guest. Stop the cancelled stay’s messages without losing the valid stay.
• Duplicate event: replay a booking notification. The guest should not receive a second confirmation because the same event was processed twice.
• Late update: deliver an older booking update after a newer one. The workflow must not restore outdated dates or status.
• Opt-out: withdraw permission while a campaign is queued. Check that future eligibility changes before sending.
• PMS unavailable: interrupt access. Confirm which actions stop, who is alerted, and how recovery avoids duplicate communication.

Record expected and actual behaviour for each test. These are acceptance requirements for your integration, not a claim that every custom PMS connection handles them out of the box.

For the broader field-mapping and implementation-ownership checklist, use our WhatsApp integration and support guide. Apply those principles to guest and reservation records, not just a sales contact.

Buy implementation support, not just API access

A custom PMS project needs two accountable owners: someone who can change the hotel software, and someone responsible for the CampaignHQ configuration and agreed connection. Decide where custom integration code will run and who maintains it.

Ask the proposal to state the fields, events, data directions, supported actions, exclusions, and launch tests. For infrastructure, specify expected message volume, traffic peaks, access controls, hosting or data-location requirements, and failure monitoring. Confirm any dedicated setup or service-level commitment separately.

Support should also have a practical definition: who investigates a missing booking event, who fixes a changed PMS field, and how the hotel escalates an issue during guest-service hours. Keep platform access, message usage, implementation work, and ongoing support clear in the commercial scope.

Start with one property or a controlled guest cohort. Connect one reservation event, one inbox/chat-flow handoff, and one permitted campaign segment. Expand when the operations team can run the workflow and the technical owners can trace a failure without guesswork.

Bring a PMS brief to your CampaignHQ demo

Bring the PMS architecture at a high level, its available APIs or webhooks, your internal technical owner, properties and agents involved, approximate email and WhatsApp volumes, and the first guest journey you want to connect. Use anonymised examples, not guest data or production credentials.

Ask the team to separate what is available now, what needs configuration, and what needs custom work. The useful next step is a scoped demonstration of your operating model: PMS-owned stay data, CampaignHQ-managed conversations and campaigns, and clearly defined updates between them.

Frequently asked questions

Does a custom PMS need a prebuilt CampaignHQ connector?

Not necessarily. APIs and webhooks can provide a route for a custom connection. First confirm that both systems expose the required data and actions, then agree who builds and maintains it. API access alone is not a completed integration.

Do guest-service agents work in CampaignHQ or the PMS?

In the model described here, agents handle WhatsApp conversations in CampaignHQ and use the PMS for hotel operations. Decide which reservation context agents need in the inbox and demonstrate how they reach any additional PMS details.

Can we keep the hotel’s existing WhatsApp number?

Assess the current number and account setup before committing to a migration. Eligibility and the onboarding route depend on the existing arrangement. Use our WhatsApp Business API setup guide to prepare the account questions.

Can a chat flow change a room or confirm an upgrade?

Only if the required hotel-system action, permission checks, and confirmation path are included and tested. Collecting an upgrade request is different from checking availability or changing the reservation. Keep those actions separate in the scope.

How should we judge the first pilot?

Check correct booking context, handled replies, suppressed outdated messages, and recoverable failures. Measure staff effort and completed guest actions against a recorded baseline. Message delivery alone does not prove better service or additional bookings.

Written by CampaignHQ Team