Group reservation policies on Vome: a full settings reference

Group reservation policies: every setting explained

Info
Plan required: group reservations need Vome Pro or above. The Groups module section of the policy (section 6 below) also needs Enterprise, since it links reservations to named groups.

Overview

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.

1. Where do I create a policy, and how does it reach a shift?

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.

2. Policy details: how big can a party be?

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.

  • Minimum party size. The smallest party the shift will accept.
  • Maximum party size. The largest.

There is one more toggle here that catches people out: Enforce minimum party size for individual reservations.

  • On, and with a minimum of 4, nobody can reserve on their own. A party size of 1 is refused outright, so this shift becomes groups-only.
  • Off, and individuals can still reserve normally. The minimum of 4 only kicks in once somebody starts adding guests.

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.

3. Age groups: who can be in a party?

Vome recognises four age groups: Infants, Children, Adults and Seniors. For each one you control two things independently:

  • Show age group, whether the lead sees it at all.
  • Allow age group, whether the lead can include people in it.

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.

4. Do guests consume shift spots?

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.

5. Eligibility: who is allowed to create a group reservation?

Three options, from tightest to loosest:

  • Only users assigned to the opportunity. They must be approved for the opportunity, but they do not need to belong to any group.
  • Only users assigned to the opportunity and assigned to a group. Both conditions. This is the setting for a partner-only shift, and it needs the Groups module.
  • No restrictions. Anybody who can see the shift can make a group reservation.

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.

6. Groups module: should the reservation carry a group name?

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.

  • Require users to link their reservation to an existing group. The lead has to pick a group they already belong to before they can confirm. Cleanest data, and it only works if your groups and their memberships are already set up.
  • Allow users to create a new group during the reservation. The lead can name a new group on the spot and link the reservation to it. Far less admin work up front, at the cost of an occasional "Acme" next to "ACME Inc." for you to merge later.

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.

7. Guest information: how much do you need to know about each guest?

Three levels:

  • Not allowed. The lead gives you a party size and age groups, nothing more. You get counts, not names.
  • Optional. The lead can name their guests but does not have to.
  • Required. The lead must fill in the fields you mark as required before the reservation can be confirmed.

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.

8. Auto-add guests: turning guests into profiles

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:

  • Profile tags
  • Sites
  • Opportunities, either the opportunity for that shift or every opportunity in your database

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.

9. Form policies: what does the default do if I change nothing?

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:

  • Add one or more rules. Your rules then override the shift-level policy entirely for group reservations. The shift-level policy is ignored.
  • Disable form submissions for group reservations. No form is required for group reservations at all, regardless of the shift-level policy or any rules below it.
  • Leave it alone, and get the lead-only default described above.

10. How do I build a form rule?

Each rule pairs a form submission policy with the people it applies to.

  • Applies to. The reservation lead, and any of the age groups. A rule needs at least one target.
  • Policy. Pick an existing form submission policy, or create one specifically for group reservations.
  • Enforcement. Whether the form is required or optional at that point.
  • Allow form submission by a guardian. Lets the reservation lead complete the form on behalf of minors, which you will want on any rule that targets children.

You have to save the policy once before the form rules section will accept anything, so save, reopen, then configure.

11. When exactly is each person asked for a form?

That comes from the rules inside the form submission policy you picked:

  • Upon reservation, applied to the lead. The lead completes it during the reservation, before confirming.
  • Upon reservation, applied to guests. Each guest completes it when they claim their spot. If a guest never claims their spot in time, it falls back to check-in and they complete the same form there.
  • Upon check-in, upon check-out or claiming hours, or when the shift ends. The person is prompted at that moment, and where the form is required, they cannot complete the action until it is submitted.

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.

12. Who is the reservation lead, and can that change?

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.

Summary

  • No policy on a shift means no group reservations on that shift. Policies are reusable across shifts.
  • Party size counts the lead. The individual-reservation toggle decides whether the minimum makes the shift groups-only.
  • Four age groups, each shown and allowed independently, with age ranges you define.
  • Every attendee consumes a spot except infants.
  • Eligibility runs from "assigned to the opportunity and to a group" through to no restrictions at all.
  • The Groups module section is what puts a group name on the reservation. Requiring a link plus allowing creation is the usual pairing.
  • Guest information can be blocked, optional or required. Email is what makes invitations and auto-add possible.
  • Auto-add turns qualifying guests into profiles, with optional tags, sites and opportunities, plus a backfill.
  • By default a shift-level form policy applies to the lead only. Add rules to override it, or disable forms for group reservations entirely.
  • A reservation can be transferred to a guest who has claimed their spot and has an account.

Where to go next