Building an end-to-end group booking CRM and automation system

The challenge

Group travel isn't an individual booking. A single enquiry involves a requester, an organization, group size, dates, route, requirements and — usually — a quote that needs negotiation before anyone books. Managing that manually across a large airline operation creates delays, fragmented information, inconsistent follow-up and no shared visibility between sales and operations.

aibrevo designed and implemented an end-to-end CRM and automation ecosystem for Spirit Airlines' group-booking workflow, connecting customer acquisition, sales, communication, workflow automation, integrations, internal operations and reporting into a single system rather than a set of isolated automations.

Three properties of group travel make it harder than it looks. First, the data arrives incomplete: requesters submit what they know, which is often a rough date range and a headcount that will change. A system that assumes clean input either rejects real requests or accepts bad ones. Second, the sales cycle is negotiated and stretches over days or weeks, so follow-up has to be persistent without being intrusive, and has to yield immediately when a person replies. Third, the sale isn't the end. A confirmed group booking creates a second body of work, collecting passenger details and documentation, that belongs to a different team who need the sales context without asking for it again.

Each of those is a place where information gets lost between people or systems. The design goal was to remove the gaps rather than speed up individual steps: every record has one owner and one next action at all times, and every handoff carries the full history with it.

The architecture: four connected layers

Seven pipelines, one booking lifecycle

A group inquiry, a qualified opportunity and a confirmed booking aren't the same record moving through one flat list — treating them that way is where most CRM builds for group travel fall apart. An inquiry is an unvalidated request. An opportunity is a qualified deal with a quote being negotiated. A booking is a commitment with operational obligations attached. Each has different owners, different required data and a different definition of "done," and forcing them into one stage list produces a pipeline where half the columns mean different things depending on who is looking.

This build runs seven connected pipelines instead, each with explicit entry and exit criteria so a record only advances when the data the next stage needs actually exists:

Make.com as the integration layer

GoHighLevel stays the customer-facing operational hub while Make.com handles the orchestration between it and connected systems — a new group inquiry triggers a webhook, Make.com processes and validates the data, applies routing logic, and writes the result back into GoHighLevel as an opportunity with the correct owner, tags and notifications. Complex business logic runs outside the CRM instead of being forced into it.

The split is a deliberate design choice. CRM workflow builders are good at stage-driven, contact-centered automation: send this message when this status changes. They get awkward when logic involves matching against existing records, branching on several conditions at once, or reshaping data arriving from different sources in different formats. Putting that in Make.com keeps the CRM's own workflows short and readable, and makes the complicated logic visible in one place rather than scattered across dozens of nested workflow branches.

A typical inquiry passes through the orchestration layer in five steps:

1. 01

   Trigger

   A new inquiry from a web form, email parser or other source fires a webhook into a Make.com scenario. The scenario receives the raw payload exactly as submitted, before any interpretation.

2. 02

   Validate and normalize

   Required fields are checked, dates and group sizes are normalized into consistent formats, and free-text request types are mapped to the defined categories the pipelines expect. Bad or partial data is caught here rather than polluting the CRM.

3. 03

   Match and route

   The scenario looks for an existing contact or open opportunity, then applies routing logic — request type, group size, route or market — to pick the correct owner. This is the logic that would be awkward and brittle inside CRM workflow builders alone.

4. 04

   Write back

   The result is written into GoHighLevel: contact and organization created or updated, opportunity created in the right pipeline and stage, tags applied and internal notification sent.

5. 05

   Log and recover

   Each run is logged. Failed runs route to an error handler that records what failed, alerts the team and queues the record for manual resolution, so nothing is dropped silently.

Webhooks and API calls are treated as contracts. The fields Make.com sends into GoHighLevel, and the status values it expects back, are documented and kept stable, so a change on one side doesn't silently break the other. When a source system changes its format, the fix lives in one normalization step instead of rippling through every downstream workflow.

Automation that removes the manual handoff

Every stage transition above is backed by an automation, not a person remembering to move a record. The governing rule is that an automation either advances a record or explains why it can't. A workflow that quietly does nothing when a precondition fails is worse than no workflow at all, because the team assumes the step happened. Each one therefore has a defined trigger, defined preconditions and a defined fallback, usually a notification or a queued manual task. A few of the load-bearing ones:

The data model underneath it

Separate, related object types instead of one flat contact record carrying every detail of a group request:

The relationships carry the logic. One Contact (the requester) can belong to an Organization and can make several Group Requests over time. Each Group Request can carry an Opportunity with more than one Quote as terms are negotiated, and a request that converts produces a Booking, which in turn owns the passenger roster and its completion status. Activity records hang off all of them, so the complete history of a trip, from first email through post-travel follow-up, is reconstructable from one place.

The reason to separate Group Request from Contact is repeat business. An organization that books a group this quarter and another next year is the same customer with two distinct requests. On a flat contact record the second request overwrites the first, and the history that would make the second quote faster and more accurate is lost. Related objects keep both, and let reporting distinguish new organizations from returning ones without manual tagging.

Tagging that drives automation

Tags are organized into four families: source, customer type, lifecycle stage and priority. The discipline is that a tag must be read by something. A source tag feeds reporting on which channels produce qualified requests. A customer-type tag selects the right communication template. A lifecycle-stage tag controls which automations a record is eligible for. A priority tag changes routing and follow-up timing. Tags that no workflow or report consumes are removed rather than accumulated, because an unmaintained tag list becomes noise that nobody trusts and nobody filters on.

Lifecycle-stage tags matter most for suppression. A record marked as mid-negotiation is excluded from nurture and reminder sequences, and a record marked as booking-confirmed is excluded from anything sales-oriented. That prevents the failure customers notice most: a sales follow-up arriving after they have already booked.

Reporting across sales and operations

Reporting spans four views: sales pipeline and conversion by stage, operations workload and handoff status, customer activity and communication history, and automation health. The last one is easy to overlook and is what keeps the whole system trustworthy. The error-handling logs from the orchestration layer feed a view showing which automations ran, which failed and which records are waiting on manual resolution, so a broken integration surfaces within days instead of being discovered when a customer complains.

Because sales and operations share one record, the questions that usually require stitching together two systems can be answered directly: which confirmed bookings are still missing passenger information, which quotes have gone longest without a response, and which owners are carrying the most open requests.

Design decisions and what to watch for

The useful part of any build is the set of decisions that shaped it and the failure modes it was designed around. These are the ones that mattered most on the group-booking system, and the ones worth planning for on any similar project.

• Validate at the edge. Checking and normalizing data before it enters the CRM is far cheaper than cleaning it afterward. Once malformed dates or ambiguous request types are inside pipelines, every downstream automation inherits the problem.
• Make human replies the highest-priority event. Any inbound response pauses scheduled automation. Without that rule, reminders collide with live conversations and damage exactly the relationships the sequence was meant to protect.
• Separate the record types early. Retrofitting a Group Request or Quote object onto a CRM that has run for a year on flat contacts means untangling history that was never structured. Modeling them at the start costs a little design time and saves a migration.
• Design failure paths deliberately. Integrations fail: webhooks time out, source systems change format, a field arrives empty. Logging the error, alerting a person and queuing manual resolution turns a silent data loss into a visible, fixable task.
• Guard against duplicates. Group requests are especially prone to arriving through more than one channel. Matching against existing records before creating a new one prevents two owners quoting the same group at different prices.
• Keep automation ownership documented. With this many workflows reading the same tags and stages, each needs a named purpose and a suppression rule. Otherwise two automations respond to the same event and the customer receives conflicting messages.
• Review the automation set periodically. Business rules change. Workflows that were correct at launch drift out of date, so a scheduled review of triggers, tags and timing windows keeps the system matching how the team really operates.