Benachrichtigungen sind der Weg, auf dem Ihr Team erfährt, dass etwas Aufmerksamkeit braucht — eine neue Anfrage ist eingegangen, eine Führung wurde abgesagt, eine Zahlung ist fehlgeschlagen, eine Bewerbung ist eingetroffen. Sind Benachrichtigungen nicht gut konfiguriert, gehen Dinge unter; sind sie zu breit konfiguriert, wird Ihr Posteingang zu Rauschen und die Leute ignorieren sie.
Dieser Artikel führt Sie durch die vorhandenen Benachrichtigungstypen, das zweistufige Einstellungsmodell (Schul-Standards + Mitglieder-Overrides) und die Muster, die für ein 1–5-köpfiges Schulteam tatsächlich funktionieren.
Das zweistufige Modell
Die Plattform bietet zwei Steuerungsebenen:
- Schulweite Verteilung — wird vom Owner oder einem Admin festgelegt. Entscheidet, welche Team-Rollen welche Benachrichtigungstypen erhalten. "Anfragebenachrichtigungen gehen an alle mit der Rolle Admin oder Editor. Abrechnungsbenachrichtigungen gehen nur an den Owner."
- Mitglieder-Overrides — werden von jedem Teammitglied für das eigene Konto festgelegt. "Ich bin Admin, und die Schul-Konfiguration sendet mir Anfragebenachrichtigungen per E-Mail und In-App, aber ich möchte nur E-Mail."
Die schulweite Verteilung ist der Mindeststandard; Mitglieder-Overrides verfeinern. Pflichttypen können Sie nicht überschreiben (manche Typen lassen sich aus Compliance-Gründen nicht deaktivieren; siehe unten).
Wo Sie es finden
Dashboard → Tab Settings → Bereich Notifications.
Die Seite zeigt die 17+ Benachrichtigungstypen gruppiert nach Kategorie, mit Schaltern für In-App und E-Mail pro Typ. Die aktuellen schulweiten Standards werden angezeigt; wenn Sie Overrides gesetzt haben, sind diese hervorgehoben.
Die Benachrichtigungstypen
Es gibt 17+ Typen, gruppiert in 5 Kategorien:
Anfragen (3 Typen)
- inquiry_received — eine Familie hat eine neue Anfrage über Ihr öffentliches Profil eingereicht. Die mit Abstand wichtigste Benachrichtigung auf der Plattform; niemals deaktivieren.
- inquiry_replied — eine Familie hat auf eine Ihrer Nachrichten im Anfrage-Thread geantwortet. Weniger wichtig als die Erstanfrage, aber nützlich zur Verfolgung von Antwortzeiten.
- inquiry_status_changed — jemand in Ihrem Team hat den Pipeline-Status einer Anfrage verschoben (New → Contacted, etc.). Hauptsächlich interne Koordination — die meisten Schulen haben diesen Typ nur In-App aktiviert.
Buchungen (5 Typen)
- booking_requested — eine Familie hat einen Führungstermin gebucht, Status Pending. Sie sollten innerhalb eines Werktags bestätigen oder ablehnen.
- booking_confirmed — Bestätigung wurde versendet (in der Regel ausgelöst durch Ihre Bestätigung). Für Sie meist Rauschen; nützlich für das Teammitglied, das die Bestätigung nicht vorgenommen hat.
- booking_cancelled — Familie hat abgesagt. Löst die Wiederöffnung des Slots aus.
- booking_rescheduled — Familie oder Sie haben den Slot verschoben.
- booking_reminder — wird der Familie am Morgen vor ihrer Führung zugestellt. Sie sehen die In-App-Version als Nachweis.
Bewerbungen (6 Typen)
- application_received — eine Familie hat eine Bewerbung eingereicht. Wichtig insbesondere in der Bewerbungssaison.
- application_status_changed — interner Status wurde verschoben (Submitted → Under Review, etc.).
- application_fee_paid — Bewerbungsgebühr wurde verrechnet (sofern Sie eine erheben).
- application_decision — Ihr Team hat eine Entscheidung versendet (Zusage / Warteliste / Absage). Hauptsächlich interner Nachweis.
- application_interview_scheduled — Interviewtermin für eine Bewerbung bestätigt.
- admission_message_received — Familie hat im Nachrichten-Thread der Bewerbung geantwortet.
Team (4 Typen)
- team_invite_sent / team_invite_accepted / team_role_changed / team_member_removed — Aktivitäten der Teamverwaltung. Owner + Admin wollen diese meist; sonst braucht sie niemand.
System + Badge (3 Typen)
- badge_unlocked — Ihre Schule hat ein Vertrauens-Badge erhalten (Verified, Complete profile, etc.).
- platform_announcement — wir (die Plattform) senden Ihnen wichtige Neuigkeiten. Kann nicht deaktiviert werden.
- feature_update — wir haben ein neues Feature ausgeliefert, von dem Sie wissen sollten. Kann nicht deaktiviert werden.
Kanalweise Steuerung
Jeder Typ hat unabhängige Schalter für In-App und E-Mail. Sie können inquiry_received auf beidem aktivieren (dringend, Sie wollen es überall sehen), booking_reminder nur per E-Mail (In-App wäre Rauschen — Sie haben die Buchung bereits gesehen), badge_unlocked nur In-App (schön zu wissen, aber keine E-Mail wert).
Drei Muster, die gut funktionieren:
Muster 1: Einzelschule (Einzelnutzer)
Alles an, beide Kanäle. Sie sind ohnehin die einzige Person, die es sieht. Richten Sie einen Posteingangsfilter ein, damit Benachrichtigungs-E-Mails in einen Ordner "Schul-Ops" wandern; prüfen Sie ihn morgens und nachmittags.
Muster 2: Kleines Team (2–3 Personen)
- Owner: alles an, beide Kanäle. Sie wollen volle Sicht für Eskalationen.
- Admin (Bewerbungsverantwortlicher): Anfragen + Buchungen + Bewerbungen auf beiden Kanälen. Team + System nur In-App.
- Editor (Kommunikation / Inhalte): nur die Dinge, an denen Sie konkret arbeiten (badge_unlocked für Erfolgs-Updates; sonst nur In-App).
Muster 3: Grösseres Team (5+ Personen)
Nutzen Sie die schulweite Verteilung konsequent. Entscheiden Sie, welche Rollen welche Kategorien erhalten, und lassen Sie Einzelpersonen nachjustieren. Setzen Sie neue Teammitglieder standardmässig auf "In-App für alles, E-Mail für nichts" — sie können sich pro Typ für E-Mail entscheiden, sobald sie herausgefunden haben, was sie brauchen.
Die Pflichttypen
Manche Benachrichtigungstypen lassen sich nicht deaktivieren. Diese decken ab:
- platform_announcement — wichtige Neuigkeiten von uns (Sicherheitshinweise, geplante Ausfälle, Breaking Changes)
- feature_update — nicht dringend, aber erwartet ("wir haben diese Woche X ausgeliefert")
- payment_failed / abrechnungskritische Typen — Sie MÜSSEN wissen, wenn Ihr Abonnement auszulaufen droht
Die Settings-UI zeigt Pflichttypen als gesperrte Schalter. Das ist Absicht. Wir bekommen pro Jahr einige Anfragen "kann ich feature_update-E-Mails deaktivieren" und sagen Nein.
E-Mail-Routing pro Typ
Was das löst: Schulen wollen, dass unterschiedliche Benachrichtigungstypen in unterschiedlichen Postfächern landen — "Anfragen an admissions@yourschool.ch, Bewerbungen an admissions@yourschool.ch, Buchungen an den Hauptposteingang der Schule." Ohne diese Funktion gehen die E-Mail-Benachrichtigungen jeder Person an ihre eigene Konto-E-Mail — für ein einköpfiges Admin-Team in Ordnung, aber unübersichtlich für einen Betrieb mit 3+ Personen und geteilten Zuständigkeiten.
Die Funktion finden Sie am unteren Ende von Settings → Notifications im Bereich "Per-type email routing". Für jeden der 6 routbaren Benachrichtigungstypen können Sie eine dedizierte E-Mail-Adresse festlegen:
inquiry_received— typischerweise admissions@inquiry_replied— typischerweise dieselbe wie obenbooking_requested— admissions@ oder eine dedizierte visits@booking_confirmed— dasselbeapplication_received— admissions@application_decision— admissions@
Leer lassen, um die Konto-E-Mail des Empfängers zu verwenden (das Standardverhalten).
Worauf sich das auswirkt: nur auf den E-Mail-Kanal. Die In-App-Benachrichtigung geht weiterhin an die Teammitglieder, die laut Verteilungsregeln empfangsberechtigt sind — das ist Absicht, der In-App-Posteingang ist eine personenbezogene Oberfläche, kein gemeinsames Postfach.
Warum nur 6 Typen routbar sind: Team-, System- und Badge-Benachrichtigungen sind persönlich für den Empfänger (jemand hat Ihre Rolle geändert; Ihre Schule hat ein Badge erhalten). Diese in ein gemeinsames Postfach zu routen, ergibt betrieblich keinen Sinn.
Was noch NICHT im System ist
Einige Features, nach denen Schulen manchmal suchen:
- Ruhezeiten — "keine E-Mails zwischen 20 Uhr und 7 Uhr." Nicht implementiert. Die Plattform feuert, wenn das Ereignis eintritt.
- Digest-Modus — "schickt mir eine Zusammenfassungs-E-Mail pro Tag statt einer pro Ereignis." Nicht implementiert. Jedes Ereignis löst seine eigene E-Mail aus.
- Test-Benachrichtigungs-Button — "schickt mir ein Beispiel, wie eine Anfragebenachrichtigung aussieht, um die Verteilung zu prüfen." Nicht implementiert. So prüfen Sie es: senden Sie eine Testanfrage über Ihr öffentliches Profil in einem Inkognito-Fenster.
Keines davon ist ein Showstopper für den Tagesbetrieb. Wird etwas davon zum echten Schmerzpunkt, melden Sie sich.
Zurückgewiesene E-Mails
Wenn eine E-Mail-Benachrichtigung zurückgewiesen wird (Postfach des Empfängers voll, Adresse ungültig, E-Mail vom Server abgewiesen), markiert die Plattform die Zustellung serverseitig als fehlgeschlagen. Sie sehen aktuell keine In-App-Warnung — das Bounce-Dashboard für Schul-Admins ist noch nicht freigeschaltet.
Wenn Sie vermuten, dass Benachrichtigungen nicht ankommen (z. B. "ich hätte die Anfrage-E-Mail bekommen müssen, habe sie aber nicht"):
- Prüfen Sie zuerst Ihren Spam-Ordner — fälschliche Spam-Einstufung erklärt 80 % der "fehlende E-Mail"-Meldungen.
- Prüfen Sie die schulweite Verteilung — ist Ihre Rolle für diesen Benachrichtigungstyp wirklich vorgesehen?
- Prüfen Sie Ihren Mitglieder-Override — haben Sie versehentlich den E-Mail-Kanal für diesen Typ deaktiviert?
- Schreiben Sie uns — wir können das Zustellprotokoll für Sie prüfen.
Häufige Fehler
- Kritische Benachrichtigungen an einen persönlichen Posteingang routen. "Ich passe schon auf" hält bis zu Ihrem nächsten Urlaub. Verwenden Sie eine rollenbasierte Adresse (admissions@yourschool.ch), damit Personalwechsel den Workflow nicht brechen.
- inquiry_received deaktivieren. Es ist nicht ohne Grund standardmässig aktiviert. Deaktivieren Sie es, verpassen Sie Anfragen. Lassen Sie es.
- Alles für alle auf E-Mail + In-App stellen. Benachrichtigungs-Müdigkeit ruiniert die Posteingangs-Disziplin. Seien Sie selektiv — die meisten Leute brauchen nur 3–5 Typen per E-Mail.
- Den Rauchtest auslassen. Nachdem Sie Benachrichtigungen konfiguriert haben, senden Sie eine Testanfrage über Ihr öffentliches Profil im Inkognito-Modus. Ist die E-Mail angekommen? Im richtigen Postfach? Wenn nicht, beheben Sie es jetzt.
Wann Sie uns eskalieren sollten
Schreiben Sie an admin@swissprivate-schools.ch, wenn:
- Eine erwartete Benachrichtigung nicht ankommt — wir können das Zustellprotokoll prüfen und feststellen, ob es ein Routing-Problem oder ein Bounce ist.
- Sie E-Mail-Routing pro Typ priorisiert haben möchten (wir tracken diese Anfragen; 2–3 = Priorität).
- Sie vermuten, dass ein Benachrichtigungstyp fälschlich auslöst (z. B. "ich bekomme booking_reminder für stornierte Buchungen") — das ist ein Bug, melden Sie es.
- Sie eine grosse Umkonfiguration der Benachrichtigungen während eines Teamwechsels brauchen (neuer Schulleiter übernimmt) — wir können die Verteilung in einem Schritt aktualisieren.
Wir antworten innerhalb von 2 Werktagen.