Les notifications sont le moyen pour votre équipe d'apprendre qu'un événement nécessite son attention — une nouvelle demande arrive, une visite est annulée, un paiement échoue, une demande d'admission est déposée. Si les notifications ne sont pas bien configurées, des choses passent à la trappe ; si elles sont configurées trop largement, votre boîte de réception devient du bruit et les gens commencent à les ignorer.
Cet article passe en revue les types de notifications qui existent, le modèle de préférences à deux niveaux (paramètres par défaut de l'école + remplacements par membre) et les configurations qui fonctionnent réellement pour une équipe scolaire de 1 à 5 personnes.
Le modèle à deux niveaux
La plateforme propose deux niveaux de contrôle :
- Routage au niveau de l'école — défini par le Owner ou un Admin. Détermine quels rôles d'équipe reçoivent quels types de notifications. « Les notifications de demandes vont à toute personne ayant le rôle Admin ou Editor. Les notifications de facturation vont uniquement au Owner. »
- Remplacements par membre — définis par chaque membre de l'équipe pour son propre compte. « Je suis Admin et la configuration de l'école m'envoie les notifications de demandes par e-mail + in-app, mais je veux uniquement l'e-mail. »
Le routage au niveau de l'école constitue la base ; les remplacements par membre l'affinent. Vous ne pouvez pas remplacer un type obligatoire (certains types ne peuvent pas être désactivés pour des raisons de conformité ; voir ci-dessous).
Où le trouver
Tableau de bord → onglet Settings → section Notifications.
La page affiche les 17+ types de notifications regroupés par catégorie, avec des bascules in-app et e-mail par type. Les paramètres par défaut actuels au niveau de l'école sont indiqués ; si vous avez défini des remplacements, ils sont mis en évidence.
Les types de notifications
Il existe 17+ types, regroupés en 5 catégories :
Demandes (3 types)
- inquiry_received — une famille a soumis une nouvelle demande via votre profil public. La notification la plus importante de la plateforme ; ne désactivez jamais.
- inquiry_replied — une famille a répondu à l'un de vos messages dans son fil de demande. Moins important que la demande initiale, mais utile pour le suivi des délais de réponse.
- inquiry_status_changed — quelqu'un de votre équipe a changé le statut d'une demande dans le pipeline (Nouveau → Contacté, etc.). Principalement de la coordination interne — la plupart des écoles n'activent ceci qu'en in-app.
Réservations (5 types)
- booking_requested — une famille a réservé un créneau de visite, statut Pending. Vous devriez confirmer ou refuser dans un jour ouvrable.
- booking_confirmed — la confirmation est partie (généralement déclenchée par votre confirmation). Principalement du bruit pour vous ; utile pour le membre de l'équipe qui n'a pas effectué la confirmation.
- booking_cancelled — la famille a annulé. Déclenche la réouverture du créneau.
- booking_rescheduled — la famille ou vous avez déplacé le créneau.
- booking_reminder — envoyé à la famille le matin précédant sa visite. Vous voyez la version in-app comme trace.
Admissions (6 types)
- application_received — une famille a soumis une demande d'admission. Important en particulier pendant la saison des admissions.
- application_status_changed — le statut interne a évolué (Soumise → En cours d'examen, etc.).
- application_fee_paid — les frais de dossier ont été encaissés (si vous en facturez).
- application_decision — votre équipe a envoyé une décision (offre / liste d'attente / refus). Principalement une trace interne.
- application_interview_scheduled — la réservation d'entretien a été confirmée pour un dossier.
- admission_message_received — la famille a répondu dans le fil de messages du dossier.
Équipe (4 types)
- team_invite_sent / team_invite_accepted / team_role_changed / team_member_removed — activité de gestion de l'équipe. Le Owner + Admin les veulent généralement ; personne d'autre n'en a besoin.
Système + Badge (3 types)
- badge_unlocked — votre école a obtenu un badge de confiance (Verified, Complete profile, etc.).
- platform_announcement — nous (la plateforme) vous envoyons des informations importantes. Ne peut pas être désactivé.
- feature_update — nous avons livré une nouvelle fonctionnalité que vous devriez connaître. Ne peut pas être désactivé.
Contrôle par canal
Chaque type a des bascules indépendantes pour in-app et e-mail. Vous pouvez régler inquiry_received sur les deux (urgent, vous voulez le voir partout), booking_reminder uniquement sur e-mail (in-app serait du bruit — vous avez déjà vu la réservation), badge_unlocked uniquement sur in-app (bon à savoir, pas la peine d'un e-mail).
Trois configurations qui fonctionnent bien :
Configuration 1 : école en solo (un seul utilisateur)
Tout activé, les deux canaux. Vous êtes la seule personne qui le verra de toute façon. Mettez en place un filtre dans votre boîte de réception pour que les e-mails de notification atterrissent dans un dossier « School ops » ; consultez-le matin et après-midi.
Configuration 2 : petite équipe (2-3 personnes)
- Owner : tout activé, les deux canaux. Vous voulez une visibilité complète pour pouvoir escalader.
- Admin (responsable des admissions) : demandes + réservations
- admissions sur les deux canaux. Équipe + système uniquement en in-app.
- Editor (communication / contenu) : seulement les éléments sur lesquels vous travaillez spécifiquement (badge_unlocked pour les mises à jour de succès ; sinon, in-app uniquement).
Configuration 3 : équipe plus grande (5+ personnes)
Utilisez le routage au niveau de l'école de manière offensive. Décidez quels rôles reçoivent quelles catégories, puis laissez les individus affiner. Pour les nouveaux membres de l'équipe, par défaut « in-app pour tout, e-mail pour rien » — ils peuvent s'inscrire à l'e-mail par type au fur et à mesure qu'ils identifient leurs besoins.
Les types obligatoires
Certains types de notifications ne peuvent pas être désactivés. Ils couvrent :
- platform_announcement — nouvelles importantes de notre part (alertes de sécurité, indisponibilités planifiées, changements majeurs)
- feature_update — non urgent mais attendu (« nous avons livré X cette semaine »)
- payment_failed / types critiques liés à la facturation — vous DEVEZ savoir si votre abonnement est sur le point d'expirer
L'interface Settings affiche les types obligatoires sous forme de bascules verrouillées. C'est délibéré. Nous recevons quelques demandes par an du type « puis-je désactiver les e-mails de feature_update » et nous disons non.
Routage e-mail par type
Ce que cela résout : les écoles veulent que différents types de notifications atterrissent dans différentes boîtes aux lettres — « les demandes vers admissions@yourschool.ch, les dossiers d'admission vers admissions@yourschool.ch, les réservations vers la boîte principale de l'école. » Sans cela, les notifications par e-mail de chaque utilisateur vont à l'e-mail de leur propre compte — acceptable pour une équipe administrative d'une seule personne mais brouillon pour une opération à 3+ personnes avec des responsabilités réparties.
La fonctionnalité se trouve en bas de Settings → Notifications, dans la section « Per-type email routing ». Pour chacun des 6 types de notifications routables, vous pouvez définir une adresse e-mail dédiée :
inquiry_received— généralement admissions@inquiry_replied— généralement la même que ci-dessusbooking_requested— admissions@ ou un visits@ dédiébooking_confirmed— idemapplication_received— admissions@application_decision— admissions@
Laissez vide pour utiliser l'e-mail de compte du destinataire (le comportement par défaut).
Ce que cela affecte : uniquement le canal e-mail. La notification in-app continue d'aller aux membres de l'équipe que les règles de routage désignent comme destinataires — c'est voulu, la boîte de réception in-app est une surface par utilisateur, pas une boîte partagée.
Pourquoi seuls 6 types sont routables : les notifications d'équipe, système et badge sont personnelles au destinataire (quelqu'un a changé votre rôle ; votre école a obtenu un badge). Les router vers une boîte partagée n'a pas de sens opérationnel.
Ce qui N'EST PAS encore dans le système
Quelques fonctionnalités que les écoles recherchent parfois :
- Heures de silence — « n'envoyez pas d'e-mails entre 20h et 7h. » Pas implémenté. La plateforme se déclenche au moment où l'événement se produit.
- Mode digest — « envoyez-moi un e-mail récapitulatif par jour au lieu d'un par événement. » Pas implémenté. Chaque événement déclenche son propre e-mail.
- Bouton de notification de test — « envoyez-moi un exemple de ce à quoi ressemble une notification de demande, pour vérifier le routage. » Pas implémenté. La façon de vérifier : envoyez une demande de test depuis votre profil public dans une fenêtre de navigation privée.
Aucun de ces éléments ne bloque les opérations quotidiennes. Si l'un d'entre eux devient réellement gênant, faites-le-nous savoir.
E-mails rejetés
Si une notification par e-mail est rejetée (la boîte aux lettres du destinataire est pleine, l'adresse est invalide, l'e-mail est refusé par son serveur), la plateforme marque la livraison comme échouée côté serveur. Vous ne verrez pas d'avertissement in-app pour le moment — le tableau de bord des rejets pour les admins d'école n'est pas encore exposé.
Si vous soupçonnez que des notifications n'arrivent pas (par exemple « j'aurais dû recevoir l'e-mail de demande mais ne l'ai pas reçu ») :
- Vérifiez d'abord votre dossier spam — la classification spam en faux positif représente 80 % des signalements « e-mail manquant »
- Vérifiez le routage au niveau de l'école — votre rôle est-il réellement inclus dans ce type de notification ?
- Vérifiez vos remplacements par membre — avez-vous accidentellement désactivé le canal e-mail pour ce type ?
- Écrivez-nous — nous pouvons consulter le journal de livraison pour vous
Erreurs courantes
- Router des notifications critiques vers une boîte de réception personnelle. « Je vais surveiller » tient jusqu'à ce que vous partiez en vacances. Utilisez une adresse basée sur un rôle (admissions@yourschool.ch) pour que les changements de personnel ne cassent pas le flux de travail.
- Désactiver inquiry_received. Il est activé par défaut pour une raison. Si vous le désactivez, vous manquerez des demandes. Ne le faites pas.
- Régler tout sur e-mail + in-app pour tout le monde. La fatigue de notification tue la discipline de la boîte de réception. Soyez sélectif — la plupart des gens n'ont besoin que de 3 à 5 types par e-mail.
- Sauter le test à blanc. Après avoir configuré les notifications, envoyez une demande de test depuis votre profil public en navigation privée. L'e-mail est-il arrivé ? Dans la bonne boîte ? Si non, corrigez maintenant.
Quand nous escalader la situation
Écrivez à admin@swissprivate-schools.ch si :
- Une notification attendue n'arrive pas — nous pouvons consulter le journal de livraison et déterminer s'il s'agit d'un problème de routage ou d'un rejet
- Vous voulez que le routage e-mail par type soit priorisé (nous suivons ces demandes ; 2-3 = priorité)
- Vous soupçonnez qu'un type de notification se déclenche incorrectement (par exemple « je reçois booking_reminder pour des réservations annulées ») — c'est un bug, signalez-le
- Vous avez besoin d'une reconfiguration en masse des notifications lors d'une transition d'équipe (nouveau directeur d'école qui prend ses fonctions) — nous pouvons mettre à jour le routage en une seule opération
Nous répondons sous 2 jours ouvrables.