Messaging customers
Team notifications
Everything else in this section is about messaging customers. This is about messaging your own team — telling a manager the queue is backing up before a customer has to tell them.
Where to set them up
Location settingsTeam notifications. Rules are set per person, per event and per location, which is the point: a manager covering three branches usually wants the long-wait alert for the one they are standing in.
Anybody can manage their own
This page is not permission-gated, because these rules govern only what arrives in your own inbox. Gating it would stop a member of staff switching off their own emails, which nobody wants.
The six events
Two of them are conditions nobody clicks, so they are checked on a schedule rather than fired by an action. The other four happen the moment they happen.
Checked on a schedule
Someone has been waiting too long
When a visitor has been in the queue longer than you'd like.
You set the threshold — minutes waiting — per rule.
The queue is getting long
When more than a set number of people are waiting at once.
You set the threshold — people waiting — per rule.
Sent as they happen
Someone joins the waitlist
Every new walk-in. Best with a cooldown, or a quiet shop.
Someone leaves the waitlist
A visitor cancels their own place in the queue.
A booking is made
Someone books an appointment through your booking page.
A booking is cancelled
A customer cancels an appointment.
The thresholds are per rule rather than per location, because one manager's “too long” is twenty minutes and another's is five.
Cooldowns
Every rule has a cooldown — the shortest gap between two alerts of the same kind. This is the setting that decides whether these are useful or unbearable: telling somebody every single time a visitor joins a busy queue is a hundred emails a day and an inbox rule to delete them.
Defaults differ by event, because the right answer differs by two orders of magnitude. A cancelled booking is worth knowing about immediately; somebody joining the queue is not.
Start with fewer alerts than you think you want
An alert that fires constantly gets ignored, and then the one that mattered gets ignored too. Switch on the two you would actually act on, run for a week, and add more only if you find yourself wishing you had known sooner.
Branch access is enforced
Somebody restricted to particular branches can only create rules for those branches, and only ever receives alerts about them. A notification rule can never be used to widen somebody's reach — the restriction is applied when the alert is sent, not only when the rule is created. See team and roles.
How alerts arrive
By email, to the address on the account. Staff alerts do not count against your customer messaging allowance.
Alerts, or automation?
These two overlap and answer different questions. A team notification tells a person that something is happening and leaves the judgement to them. An automation rule acts on it without waiting for anybody — messaging the customer, or closing the visit out.
Use an alert while you are still learning what the right response is, and an automation once you know it and are tired of doing it by hand.