Shift policies on Vome: waitlist, notifications, group reservations and forms

What are shift policies, and which do I need?

Info
Plan required: shift policies rely on people being able to reserve shifts, which needs Vome Pro or above. Two specific parts of a group reservation policy also need Enterprise, and section 7 says exactly which.

Overview

A shift policy is a reusable rule you attach to a shift, rather than a setting you re-enter every time you create one.

There are four of them, they do genuinely different jobs, and most organizations need one or two rather than all four. This article is for administrators setting up their schedule.

1. What is a shift policy, really?

A named set of rules that lives on its own and gets attached to shifts.

You define it once and point many shifts at it. Change the policy later and every shift using it changes with it, which is the whole reason they exist. The alternative is re-deciding the same thing on every shift you create and then having no way to update them all at once.

2. What are the four?

  • Waitlist policy. What happens when a shift is full.
  • Shift notification policy. Which reminders and updates go out, and when.
  • Group reservation policy. Whether one person can book for several.
  • Form submission policy. A form somebody has to complete in connection with the shift.

3. Waitlist policy

Decides what happens when a shift fills up.

Without one, a full shift is simply closed and interested people go away. With one, they can join a queue, and when somebody drops out the place is offered onward rather than sitting empty. If you regularly fill shifts, this is the policy that quietly recovers the cancellations.

4. Shift notification policy

Decides which reminders and updates go out for that shift, and when.

This is the one people skip and then regret, because the cost of getting it wrong is invisible. Too few reminders and you get no-shows. Too many and people mute you, which costs you the reminder that actually mattered.

Setting it as a policy rather than per shift means you make that judgement once, and you can adjust it everywhere after a season of seeing what happens.

5. Group reservation policy

Decides whether one person can book several spots, and on what terms.

It controls guest minimums and maximums, which age groups are allowed, who is permitted to lead a reservation, and what information guests have to give. This is the policy that turns "a team of eight from a local company" from eight separate bookings into one.

6. Form submission policy, and the two ways to attach it

A form somebody has to complete in connection with the shift, most often a waiver.

Where you attach it decides who fills it in, and this catches people out:

  • Attached directly to the shift. The person leading a group reservation follows the same steps as any individual, and guests who claim a spot fill in nothing.
  • Attached inside a group reservation policy. Groups get their own workflow, which can ask each guest for their own information rather than only the lead.

If you need a waiver from every attending person and not just the organiser, the second one is what you want.

7. Which parts need Enterprise?

Group reservations themselves work on Pro. Two things inside a group reservation policy do not.

  • Linking a reservation to a named group, so a company, school or congregation shows up on your schedule, on the check-in kiosk and in your reports. This uses the Groups module.
  • Form submission rules inside the group reservation policy, which is what gives groups their own workflow instead of the standard shift one.

Everything else here is available on Pro, including attaching a form straight to the shift. If you are on Pro and want waivers from group attendees, attach the form to the shift and accept that the lead completes it.

8. Do I need all four?

Almost certainly not.

Start with the problem you already have. If shifts fill and people ask to be told when a place opens, you need a waitlist policy. If you get no-shows, look at notifications. If organizations bring teams, you need a group reservation policy. If there is paperwork, you need a form submission policy. A policy you set up for a problem you do not have is a thing to maintain for no return.

Summary

  • A shift policy is a reusable named rule, defined once and attached to many shifts.
  • Waitlist policy decides what happens when a shift is full.
  • Shift notification policy decides which reminders go out and when. It is the most commonly skipped and the one that causes no-shows.
  • Group reservation policy decides whether one person books for several, with guest limits, age groups and who can lead.
  • Form submission policy attaches a form. On the shift, only the lead completes it. Inside a group reservation policy, guests can be asked too.
  • Linking a reservation to a named group, and form rules inside a group reservation policy, both need Enterprise. Everything else works on Pro.

Where to go next