Notifications are how your team learns that something needs attention — a new inquiry landed, a tour got cancelled, a payment failed, an admission application came in. If notifications aren't configured well, things slip; if they're configured too broadly, your inbox becomes noise and people start ignoring them.
This article walks through the notification types that exist, the two-layer preferences model (school defaults + per-member overrides), and the patterns that actually work for a 1-5 person school team.
The two-layer model
The platform has two levels of control:
- School-level routing — set by the Owner or an Admin. Decides which team roles receive which types of notification. "Inquiry notifications go to anyone with Admin or Editor role. Billing notifications go to Owner only."
- Per-member overrides — set by each team member for their own account. "I'm an Admin and the school config sends me inquiry notifications by email + in-app, but I want email only."
School-level routing is the floor; per-member overrides fine-tune. You can't override a mandatory type (some types are non-disable-able for compliance reasons; see below).
Where to find it
Dashboard → Settings tab → Notifications section.
The page shows the 17+ notification types grouped by category, with toggles for in-app and email per type. The current school-level defaults are shown; if you have overrides set, those are highlighted.
The notification types
There are 17+ types, grouped into 5 categories:
Inquiries (3 types)
- inquiry_received — a family submitted a new inquiry through your public profile. The single most important notification on the platform; never disable.
- inquiry_replied — a family replied to one of your messages in their inquiry thread. Matters less than the initial inquiry, but useful for response-time tracking.
- inquiry_status_changed — someone on your team moved an inquiry's pipeline status (New → Contacted, etc.). Mostly internal coordination — most schools have this on in-app only.
Bookings (5 types)
- booking_requested — a family booked a tour slot, status Pending. You should confirm or decline within a business day.
- booking_confirmed — confirmation went out (usually triggered by you confirming). Mostly noise for you; useful for the team member who didn't do the confirming.
- booking_cancelled — family cancelled. Triggers re-opening the slot.
- booking_rescheduled — family or you moved the slot.
- booking_reminder — sent to the family the morning before their tour. You see the in-app version as a record.
Admissions (6 types)
- application_received — a family submitted an admissions application. Important especially during admissions season.
- application_status_changed — internal status moved (Submitted → Under Review, etc.).
- application_fee_paid — application fee cleared (if you charge one).
- application_decision — your team sent a decision (offer / waitlist / reject). Mostly internal record.
- application_interview_scheduled — interview booking confirmed for an application.
- admission_message_received — family replied in the application message thread.
Team (4 types)
- team_invite_sent / team_invite_accepted / team_role_changed / team_member_removed — team management activity. Owner + Admin usually want these; nobody else needs them.
System + Badge (3 types)
- badge_unlocked — your school earned a trust badge (Verified, Complete profile, etc.).
- platform_announcement — we (the platform) sending you important news. Cannot be disabled.
- feature_update — we shipped a new feature you should know about. Cannot be disabled.
Per-channel control
Every type has independent toggles for in-app and email. You can set inquiry_received to both (urgent, you want it everywhere), booking_reminder to email only (in-app would be noise — you've already seen the booking), badge_unlocked to in-app only (nice to know, not worth an email).
Three patterns that work well:
Pattern 1: solo school (single user)
Everything on, both channels. You're the only one who'll see it anyway. Set up an inbox filter so notification emails go into a "School ops" folder; check it morning and afternoon.
Pattern 2: small team (2-3 people)
- Owner: everything on, both channels. You want full visibility for escalation.
- Admin (admissions lead): inquiries + bookings + admissions on both channels. Team + system on in-app only.
- Editor (comms / content): only the things you specifically work on (badge_unlocked for the achievement updates; otherwise in-app only).
Pattern 3: larger team (5+ people)
Use the school-level routing aggressively. Decide which roles get which categories, then let individuals fine-tune. Default new team members to "in-app for everything, email for nothing" — they can opt in to email per type as they figure out what they need.
The mandatory types
Some notification types cannot be disabled. These cover:
- platform_announcement — important news from us (security alerts, planned downtime, breaking changes)
- feature_update — non-urgent but expected ("we shipped X this week")
- payment_failed / billing-critical types — you NEED to know if your subscription's about to lapse
The Settings UI shows mandatory types as locked toggles. This is deliberate. We get a few "can I disable feature_update emails" requests a year and we say no.
Per-type email routing
What this solves: schools want different notification types to land in different mailboxes — "inquiries to admissions@yourschool.ch, applications to admissions@yourschool.ch, bookings to the school's main inbox." Without it, every user's email notifications go to their own account email — fine for a single-person admin team but messy for a 3+ person operation with split responsibilities.
The feature lives at the bottom of Settings → Notifications, in the "Per-type email routing" section. For each of the 6 routable notification types you can set a dedicated email address:
inquiry_received— typically admissions@inquiry_replied— typically the same as abovebooking_requested— admissions@ or a dedicated visits@booking_confirmed— sameapplication_received— admissions@application_decision— admissions@
Leave blank to use the recipient's account email (the out-of-the-box behaviour).
What this affects: only the email channel. The in-app notification still goes to whichever team members the routing rules say should receive it — that's by design, the in-app inbox is a per-user surface, not a shared mailbox.
Why only 6 types are routable: team, system, and badge notifications are personal to the recipient (someone changed your role; your school earned a badge). Routing those to a shared mailbox doesn't make operational sense.
What's NOT in the system yet
A few features schools sometimes search for:
- Quiet hours — "don't send emails between 8pm and 7am." Not implemented. The platform fires when the event happens.
- Digest mode — "send me one summary email per day instead of one per event." Not implemented. Each event triggers its own email.
- Test notification button — "send me a sample of what an inquiry notification looks like, to verify routing." Not implemented. The way to verify: send a test inquiry from your public profile in an incognito window.
None of these are blockers for daily operations. If any becomes a real pain, let us know.
Bounced emails
If an email notification bounces (the recipient's mailbox is full, the address is invalid, the email is rejected by their server), the platform marks the delivery as failed server-side. You won't see an in-app warning right now — the bounce dashboard for school admins isn't surfaced yet.
If you suspect notifications aren't landing (e.g. "I should have gotten the inquiry email but didn't"):
- Check your spam folder first — false-positive spam classification accounts for 80% of "missing email" reports
- Check the school-level routing — is your role actually included in that notification type?
- Check your per-member override — did you accidentally turn off the email channel for that type?
- Email us — we can check the delivery log on your behalf
Common mistakes
- Routing critical notifications to a personal inbox. "I'll watch it" lasts until you go on vacation. Use a role-based address (admissions@yourschool.ch) so personnel changes don't break the workflow.
- Disabling inquiry_received. It's enabled by default for reason. If you disable it, you'll miss inquiries. Don't.
- Setting everything to email + in-app for everyone. Notification fatigue kills inbox discipline. Be selective — most people only need 3-5 types on email.
- Skipping the smoke test. After you configure notifications, send a test inquiry from your public profile in incognito. Did the email land? In the right inbox? If not, fix it now.
When to escalate to us
Email admin@swissprivate-schools.ch if:
- An expected notification isn't arriving — we can check the delivery log and identify whether it's a routing issue or a bounce
- You want per-type email routing prioritised (we track these requests; 2-3 = priority)
- You suspect a notification type is firing incorrectly (e.g. "I'm getting booking_reminder for cancelled bookings") — that's a bug, report it
- You need bulk notification reconfiguration during a team transition (new head of school taking over) — we can update routing in one operation
We respond within 2 business days.