Approval workflows

Not every booking should auto-approve. The pool, sure — let residents book and go. The clubhouse for a 30-person event? You probably want a board member to take a look first. This article covers the approval flow.

When to require approval

A practical guideline:

Amenity type	Approval recommended?
Pool, gym, courts (drop-in)	Auto-approve
Pavilion, picnic area	Auto-approve for small groups, require for large
Clubhouse / community room	Require for events, auto-approve for casual use
Boat slips, RV storage (long-term)	Require
Guest parking	Auto-approve
Anything with a rental fee	Usually require

Toggle approval per amenity under [Amenity] → Approval Required.

The booking lifecycle (with approval)

When a resident books an amenity that requires approval:

Pending (resident submits)
   │
   ├── Approved (admin signs off)
   │       │
   │       └── eventually Completed (after the booking date)
   │
   └── Rejected / Cancelled

When a resident books an amenity that auto-approves, the booking goes straight to Approved.

For amenities that charge at the start of the rental (deferred-charge mode), there are extra states: Pending Charge (waiting to be charged 24h before the booking), Charged (capture succeeded), or Charge Failed (capture declined; admin resolves).

What the resident sees

For approval-required amenities, when a resident submits a booking they see:

“Your booking has been submitted and is awaiting board approval. You’ll receive an email when it’s approved or if more information is needed.”

They don’t see “approved” until it actually is. They can cancel from their end while pending.

For auto-approved bookings, they see:

“Your booking is confirmed. See you on [date]!”

Where the queue lives

Amenities (in the admin sidebar under Manage) → bookings tab → Pending Approval filter

You’ll see a list of bookings awaiting review, each showing:

• Resident name
• Property
• Amenity
• Date / time
• Number of guests
• Resident’s notes (if they added any)
• Submission timestamp

Click any to see full details and approve / deny.

Approving a booking

1. Open the pending booking
2. Review the request — date, time, guest count, any special notes
3. Click Approve
4. Optional: add a note the resident sees (“Approved — please review the rules attached”)
5. Confirm

What happens:

• Booking status changes to Approved
• Resident gets an email confirmation
• If a deposit was required, the deposit hold is placed on their card
• The slot is reserved on the calendar; other residents can’t double-book

Denying a booking

1. Open the pending booking
2. Click Deny
3. Enter a reason (required) — what the resident sees:
   • “We have a maintenance project on that date — please pick another”
   • “Capacity is already full for that slot”
   • “Your account has overdue dues; please bring current first”
4. Confirm

What happens:

• Booking is cancelled with the reason
• Resident gets an email with the explanation
• They can re-submit (usually with corrections)

Don’t deny without a reason. Even “Sorry, can’t accommodate this one” beats silence.

Speed matters

The longer a booking sits in pending, the worse the resident experience. A practical rule: 24 hours max from submission to decision. Most communities can do faster.

If your queue is consistently slow, options:

• Auto-approve more — anything that’s clearly low-stakes, just turn off approval
• Designate one approver — one board member owns the booking queue
• Set up notifications — every board member gets pinged on new submissions
• Pre-approval rules — see below

Editing an approved booking

A resident occasionally needs to change a booking — date change, guest count update, etc. Significant edits (date, amenity, fee-affecting) typically need to be cancelled and re-booked. Minor edits (notes) can be updated in place.

Common situations

”Two residents booked the same slot”

The system prevents this on auto-approved bookings. For approval-required amenities, it’s possible if both submit before either is approved. The first to be approved wins; the second is auto-denied with “Sorry, slot was just taken — please pick another.”

If you accidentally approve both, the system flags the conflict and you’ll need to manually resolve (usually by canceling the second one).

”A resident keeps no-showing approved bookings”

Build a reputation system informally — note in the resident’s profile after each no-show. After [N] no-shows, you can:

• Require approval on all their future bookings
• Charge a no-show fee per booking (if configured)
• Restrict them from booking high-demand amenities for [N] days

Currently this is manual; future versions may automate.

”I need to cancel an approved booking after the fact”

Open the booking → Cancel. Enter a reason. The resident is notified.

If they paid a rental fee, refund it (see Issuing refunds).

If you placed a deposit hold, release it (the system can do this automatically when you cancel).

”We want to give certain residents auto-approval status”

There’s no per-resident bypass currently. If you want certain residents to avoid approval friction, you’d need to handle it through the amenity’s overall config — most commonly, set the amenity to auto-approve for everyone, and rely on the board reviewing the booking calendar after the fact.

Where to go next

• Setting up amenities — define what can be booked
• Rental fees and deposits — money side
• ARC bookings — bookings tied to architectural reviews