Barion Pixel

Guide

Waitlist Automations

The goal of waitlist automations is to handle requests on the waitlist in a consistent, transparent, and fast way. These tools help ensure that newly available spots are automatically assigned to the right participants, and that capacity can be used as efficiently as possible.

Where can you find it?

In the admin interface, waitlist automations are typically available from the automation view of services or events. Here you can decide, per service, what logic and priorities should be used for handling the waitlist.

Waitlist automations in detail

The goal of this section is to be understandable even for someone who is not a developer, does not work with code daily, and simply wants to understand:

  • what waitlist operating modes exist,
  • what they do in practice,
  • when to use each of them,
  • where they appear in the admin interface,
  • under what conditions automatic backfilling starts.

1. What waitlist operating modes exist right now?

The system currently supports four waitlist handling modes.

  1. manual
  2. legacy (shown in the UI as Autopromote)
  3. offer (shown in the UI as Offer backfill)
  4. splitter

It is important to highlight this: autopromote is not a fifth, separate mode.
In the background, the autopromote label always maps to the legacy mode.
So the two names refer to the same behavior, just with different wording.

2. Unified human-readable names

The current interface mixes Hungarian and English terms.
This may be understandable from a developer’s perspective, but from a business, operations, or support point of view it can easily cause confusion.

For this reason, the following clear, unified names are recommended for the four modes (to be introduced later):

  • Manual → Manual handling (automation disabled)
  • Autopromote (legacy) → Automatic waitlist promotion
  • Offer backfill → Offer-based waitlist filling
  • Splitter → Multi-event balancing fill

A short note about the word “backfill”:
this is not a complex technical concept. It simply means that
when a spot becomes available, the system tries to fill it from the waitlist.

3. Where does this appear in the admin, and how do the two views relate?

The two important admin views are:

  • Event manage
  • Event automation

Both are built on the same underlying data logic.
This means they work from the same state, read the same active operating mode, and rely on the same configured algorithm.

In practical terms:

  • On the Event manage page, you can see the currently active waitlist mode.
  • From there, you can navigate to the Event automation page.
  • On the Event automation page, you can configure the detailed rules of the selected mode.
  • Some of the detailed settings depend on the subscription tier.

So one page mainly shows the current state and acts as a navigation point, while the other is the place for detailed configuration.

4. The four operating modes in detail

4.1 Manual handling (manual)

What does it do?

In this mode, the system does not perform automatic waitlist backfilling.
When a spot becomes available, the background process stops and indicates that the mode is manual.

This means:

  • no automatic promotion,
  • no automatic offers,
  • no automatic rebooking from the waitlist.

All decisions are made by a human.

When is it a good choice?

  • If you want a conscious decision for every freed-up spot.
  • If there are many exceptions or special business rules that require manual handling.
  • If the process is sensitive and automatic actions are not acceptable.

Advantages

  • Maximum human control.
  • Very low risk of unwanted automatic bookings.

Limitations

  • Significant manual work.
  • Slower reaction time, since human intervention is always required.
  • Higher workload for the operations team.

4.2 Automatic waitlist promotion (legacy / UI: Autopromote)

What does it do?

When a spot becomes available, the system automatically searches the waitlist and promotes the first suitable person according to the rules.

The selection is mainly based on arrival order:

  • earlier applicants first,
  • if they entered at the same time, a secondary identifier determines the order.

The system immediately creates a booking from the promotion.
The booking status may be confirmed or pending, depending on the account settings.

Several safety rules are also applied (for example limits, state checks, and capacity checks) to prevent incorrect automatic filling.

When does it usually run?

Typically when a spot actually becomes available, for example:

  • an admin deletes a booking,
  • a customer cancels,
  • after a reschedule, a spot is freed in the original time slot.

Important: it only runs if automatic backfill is enabled on the account.

When is it a good choice?

  • If you need fast, automatic filling.
  • If the goal is to leave as few empty spots as possible.
  • If individual customer confirmation is not required for each freed-up spot.

Advantages

  • Very fast.
  • Low administrative effort.
  • Simple, predictable base behavior.

Limitation

Less customer decision freedom, because the system creates a booking directly instead of sending an offer first.

4.3 Offer-based filling (offer / UI: Offer backfill)

What does it do?

In this mode, the system does not book immediately. Instead, it first creates and sends an offer to a suitable waitlist candidate.

The booking is only created if the candidate accepts the offer.

The process:

  1. a spot becomes available,
  2. the system selects a candidate,
  3. the offer is sent,
  4. the system waits for a response,
  5. if accepted, the booking is created.

Additional rules

  • You can set how long an offer remains valid (expiration time).
  • You can define when confirmation happens automatically.
  • You can enable protection so only one active offer process runs per event at a time.

Candidate selection order:

  • first the specific event’s waitlist,
  • if no suitable candidate is found, a broader service-level reserve list,
  • with additional filtering based on time windows.

When is it a good choice?

  • If it is important that the customer actively confirms.
  • If you do not want the system to create bookings automatically.
  • If tracking the full lifecycle of offers is important
    • pending,
    • accepted,
    • rejected,
    • expired.

Advantages

  • More customer-friendly: the participant decides.
  • Better control over acceptance intent.
  • More transparent communication and decision flow.

Limitations

  • Slower filling, because the system must wait for responses.
  • Empty capacity may last longer due to expiration and response times.

4.4 Multi-event balancing fill (splitter)

What does it do?

This mode does not think only within a single event.
It can balance load across multiple related “sibling” events.

In simple terms:

  • it does not only decide who to place into one specific occurrence,
  • it also considers the overall balance across multiple related events.

You can define which events belong to the same group, for example:

  • forward from a root event,
  • same day only,
  • same time slot only.

The process runs in several steps:

  1. plan creation,
  2. offer/distribution step,
  3. finalization.

There is also a simulation mode and a live execution mode:

  • you can first see what would happen,
  • and only then execute it for real.

When is it a good choice?

  • If many related events run in parallel.
  • If the goal is not only local filling, but service-level optimization.
  • If you want to simulate safely before going live.

Advantages

  • More advanced, overall capacity utilization.
  • Better balance across multiple events.

Limitations

  • More complex setup.
  • More parameters and greater professional attention required.

5. When does automatic backfilling start at all?

The automatic process usually starts when an operation frees up a spot.

Most common triggers:

  • admin-side cancellation,
  • customer-side cancellation,
  • customer rescheduling that frees a spot in the original event.

There is also a basic requirement: automatic backfill must be enabled at the account level.
If it is disabled, no automatic filling will run, even after cancellations or reschedules.

6. Subscription tiers and permissions

Not all modes are available in every plan.
The available operating modes in the admin depend on the subscription tier.

Current structure:

  • Starter: manual, legacy
  • Basic: legacy, offer
  • Pro: manual, legacy, offer (with a simplified default view)
  • Enterprise: manual, legacy, offer, splitter

Important reminder: under the name autopromote, the system technically uses the legacy mode.
For this reason, communication should treat the two names consistently.

7. Decision guide: which mode to choose?

Manual handling

Choose this if manual control is the top priority, and the volume is low or moderate so manual decisions are manageable.

Automatic promotion (Autopromote / legacy)

Choose this if speed is the main goal, and you want to fill freed-up spots quickly with minimal admin effort.

Offer-based filling (Offer backfill)

Choose this if customer confirmation is important, and you want to reduce the risk of the system creating bookings too quickly.

Multi-event balancing (Splitter)

Choose this if you need to optimize across multiple related events, not just fill a single event as fast as possible.

8. Everyday usage examples

  • Small yoga or fitness group:
    automatic promotion is usually a good choice because it is fast and simple.
  • Premium workshop where confirmation matters:
    offer-based filling is usually better because the customer actively decides.
  • Educational service with multiple parallel sessions:
    splitter is typically the right choice, because it balances across events.
  • Healthcare or strict approval processes:
    manual mode is often better, because every decision remains under human control.

9. Naming clarity: why is it so important?

The accepted mode names in the backend are:

  • manual
  • legacy
  • offer
  • splitter

In business communication, however, it is easier to use user-friendly names, but always with the same mapping:

  • legacy ↔ Autopromote
  • offer ↔ Offer backfill / offer-based filling

This is important because it avoids the common misunderstanding that “autopromote” would be a separate fifth mode.

It is not.
It is simply the more human-readable name for legacy in the interface.

10. Short summary

If you need to decide very quickly:

  • Need full manual control? → manual
  • Need the fastest automatic filling? → legacy / Autopromote
  • Want the system to fill only after customer confirmation? → offer
  • Want to optimize across multiple related events? → splitter

The core principle is always the same: when a spot becomes available, the system handles the waitlist according to the selected mode— either manually, automatically, through offers, or by balancing across multiple events.

Further details