
A group reservation is one person, the reservation lead, booking several spots on a shift on behalf of guests. A group reservation policy is where you decide whether that is allowed and under what rules.
Nothing about group reservations is on by default. A shift with no group reservation policy attached takes individual reservations only. This article walks through every section of the policy builder in the order you meet it. This article is for administrators.
Group reservation policies live with your other shift policies. Open Manage policies from the Schedule module, or reach them while building shifts, then choose Group reservation policies and click New group reservation policy.
Give it a Policy name, which is required, configure it, and save. Then attach it to shifts, either in the shift generator as you build them or by editing an existing shift.
One policy can serve many shifts, so build a small number of policies that describe the kinds of group visits you host rather than one per shift.
The Policy details section controls party size. Party size means the whole party, the reservation lead included, so a lead plus four guests is a party size of five.
There is one more toggle here that catches people out: Enforce minimum party size for individual reservations.
Off is the usual answer. Turn it on only when the shift genuinely does not work for a lone attendee.
Finally, Allow group reservation leads to update the party size after submitting lets a lead adjust their numbers after the fact, which notifies the shift coordinator. Leave it on if you would rather hear about a change than have somebody quietly not show up.
Vome recognises four age groups: Infants, Children, Adults and Seniors. For each one you control two things independently:
You also set the minimum and maximum age for each band, so "child" means whatever it means at your organization. The bands have to stay in order: infants cannot run past where children start, children cannot run past where adults start, and seniors have to start above adults.
Turning an age group off is how you say "no children on this shift" without writing it in the description and hoping.
Yes, with one exception.
Every person in the party takes a spot, so a party of five consumes five of the shift's capacity. Infants are the exception, and do not consume a spot. They are treated as accompanying attendees rather than participants.
That means the minimum and maximum party sizes you set are also counted without infants. A reservation is refused if the party needs more spots than the shift has left.
Three options, from tightest to loosest:
The loosest option is the right one for a public community event where you want turnout. The tightest is right when a group visit is something you arrange in advance.
This section is what connects a reservation to a named group, and it is the difference between having a partnership history and not having one. It needs Enterprise.
Most organizations should turn both on. Requiring a link means no reservation slips through unlabelled, and allowing creation means a new partner is not blocked at the door.
If you leave both off, group reservations still work. They simply arrive with no group name, and there is nothing to total them by afterwards.
Three levels:
The fields available are first name, last name, email, phone number and age.
One detail worth planning around: email is what makes an invitation possible. A guest with an email address can be sent an invitation to claim their own spot, and the lead and administrators can also generate a shareable link that anybody can use to claim a spot. If you never collect emails, guests stay as names on a reservation.
Collecting emails is also what feeds the auto-add setting in the next section, so the two decisions are connected.
Automatically add guests to your database creates a profile for any guest who has a first name, last name and email. A guest whose email matches an existing profile is linked to it rather than duplicated.
Alongside it you can have those guests automatically receive:
There is also a backfill button that applies the setting to guests from existing reservations under this policy, past and upcoming. It runs in the background and notifies you when it is done. Save the policy with the setting enabled first, then run it.
Full detail is in How Auto-Add Guests to Database Works on Vome.
Worth knowing before you touch anything, because the default surprises people.
If the shift has a form submission policy and you add no group reservation rules, that policy applies only to the reservation lead. Guests who claim a spot are asked for nothing. If your form is a waiver, that is almost certainly not what you want.
You have three ways to change it:
Each rule pairs a form submission policy with the people it applies to.
You have to save the policy once before the form rules section will accept anything, so save, reopen, then configure.
That comes from the rules inside the form submission policy you picked:
The common shape is a waiver required either when a guest claims their spot or when they check in, so nobody works a shift without one on file.
The lead is the person who created the reservation, or the profile an administrator assigned to it. They hold the reservation, invite guests, and complete whatever is asked of the lead.
The reservation can be transferred to another guest, provided that guest has claimed their spot and has an active Vome account. Reporting, check-in records and the reservation history all stay intact, which is why transferring is better than cancelling and rebooking when a lead does not turn up.