Le notifiche sono il modo in cui il Suo team viene a sapere che qualcosa richiede attenzione: è arrivata una nuova richiesta, una visita è stata annullata, un pagamento è fallito, è stata inviata una candidatura di ammissione. Se le notifiche non sono configurate bene, le cose Le sfuggono; se sono configurate in modo troppo ampio, la Sua casella di posta diventa rumore e le persone iniziano a ignorarle.
Questo articolo illustra i tipi di notifica esistenti, il modello a due livelli delle preferenze (impostazioni predefinite della scuola
- override per singolo membro) e gli schemi che funzionano realmente per un team scolastico di 1-5 persone.
Il modello a due livelli
La piattaforma offre due livelli di controllo:
- Routing a livello di scuola — impostato dall'Owner o da un Admin. Decide quali ruoli del team ricevono quali tipi di notifica. "Le notifiche di richiesta vanno a chiunque abbia il ruolo Admin o Editor. Le notifiche di fatturazione vanno solo all'Owner."
- Override per singolo membro — impostati da ciascun membro del team per il proprio account. "Sono un Admin e la configurazione della scuola mi invia le notifiche di richiesta via email + in-app, ma io voglio solo l'email."
Il routing a livello di scuola è la base; gli override per singolo membro permettono di affinare. Non può sovrascrivere un tipo obbligatorio (alcuni tipi non sono disattivabili per motivi di conformità; vedi sotto).
Dove trovarlo
Dashboard → tab Settings → sezione Notifications.
La pagina mostra i 17+ tipi di notifica raggruppati per categoria, con interruttori per in-app ed email per ogni tipo. Sono mostrate le impostazioni predefinite correnti a livello di scuola; se ha impostato degli override, questi sono evidenziati.
I tipi di notifica
Esistono 17+ tipi, raggruppati in 5 categorie:
Richieste (3 tipi)
- inquiry_received — una famiglia ha inviato una nuova richiesta attraverso il Suo profilo pubblico. La notifica più importante della piattaforma; non disattivarla mai.
- inquiry_replied — una famiglia ha risposto a uno dei Suoi messaggi nel thread di richiesta. Conta meno della richiesta iniziale, ma è utile per monitorare i tempi di risposta.
- inquiry_status_changed — qualcuno del Suo team ha spostato lo stato pipeline di una richiesta (New → Contacted, ecc.). Principalmente coordinamento interno: la maggior parte delle scuole lo tiene attivo solo in-app.
Prenotazioni (5 tipi)
- booking_requested — una famiglia ha prenotato uno slot per una visita, con stato Pending. Dovrebbe confermare o rifiutare entro un giorno lavorativo.
- booking_confirmed — la conferma è stata inviata (di solito attivata dalla Sua conferma). Per Lei è perlopiù rumore; è utile per il membro del team che non ha effettuato la conferma.
- booking_cancelled — la famiglia ha annullato. Riapre lo slot.
- booking_rescheduled — la famiglia o Lei ha spostato lo slot.
- booking_reminder — inviato alla famiglia la mattina prima della visita. Lei vede la versione in-app come traccia.
Ammissioni (6 tipi)
- application_received — una famiglia ha inviato una candidatura di ammissione. Importante soprattutto durante la stagione delle ammissioni.
- application_status_changed — lo stato interno è cambiato (Submitted → Under Review, ecc.).
- application_fee_paid — la tassa di candidatura è stata liquidata (se ne addebita una).
- application_decision — il Suo team ha inviato una decisione (offerta / lista d'attesa / rifiuto). Principalmente traccia interna.
- application_interview_scheduled — prenotazione del colloquio confermata per una candidatura.
- admission_message_received — la famiglia ha risposto nel thread di messaggi della candidatura.
Team (4 tipi)
- team_invite_sent / team_invite_accepted / team_role_changed / team_member_removed — attività di gestione del team. Owner + Admin di solito le vogliono; nessun altro ne ha bisogno.
Sistema + Badge (3 tipi)
- badge_unlocked — la Sua scuola ha ottenuto un badge di fiducia (Verified, Complete profile, ecc.).
- platform_announcement — noi (la piattaforma) Le inviamo comunicazioni importanti. Non disattivabile.
- feature_update — abbiamo rilasciato una nuova funzionalità di cui dovrebbe sapere. Non disattivabile.
Controllo per canale
Ogni tipo ha interruttori indipendenti per in-app ed email. Può impostare inquiry_received su entrambi (urgente, lo vuole ovunque), booking_reminder solo via email (in-app sarebbe rumore: ha già visto la prenotazione), badge_unlocked solo in-app (bello da sapere, non vale un'email).
Tre schemi che funzionano bene:
Schema 1: scuola solitaria (utente singolo)
Tutto attivo, su entrambi i canali. Tanto sarà l'unico a vederlo. Imposti un filtro nella casella di posta in modo che le email di notifica vadano in una cartella "School ops"; la controlli al mattino e al pomeriggio.
Schema 2: team piccolo (2-3 persone)
- Owner: tutto attivo, entrambi i canali. Vuole visibilità totale per le escalation.
- Admin (responsabile ammissioni): richieste + prenotazioni + ammissioni su entrambi i canali. Team + sistema solo in-app.
- Editor (comunicazione / contenuti): solo le cose su cui lavora direttamente (badge_unlocked per gli aggiornamenti sui riconoscimenti; per il resto solo in-app).
Schema 3: team più grande (5+ persone)
Usi il routing a livello di scuola in modo aggressivo. Decida quali ruoli ricevono quali categorie, poi lasci che i singoli affinino. Per i nuovi membri del team imposti come default "in-app per tutto, email per nulla": potranno attivare l'email per tipo man mano che capiscono di cosa hanno bisogno.
I tipi obbligatori
Alcuni tipi di notifica non possono essere disattivati. Coprono:
- platform_announcement — comunicazioni importanti da parte nostra (avvisi di sicurezza, interruzioni pianificate, breaking changes)
- feature_update — non urgente ma atteso ("abbiamo rilasciato X questa settimana")
- payment_failed / tipi critici di fatturazione — DEVE sapere se il Suo abbonamento sta per scadere
La UI delle Settings mostra i tipi obbligatori come interruttori bloccati. È intenzionale. Riceviamo un paio di richieste all'anno del tipo "posso disattivare le email feature_update" e diciamo di no.
Routing email per tipo
Cosa risolve: le scuole vogliono che tipi di notifica diversi arrivino in caselle diverse — "le richieste a admissions@yourschool.ch, le candidature ad admissions@yourschool.ch, le prenotazioni alla casella principale della scuola." Senza questa funzione, le notifiche email di ciascun utente vanno all'email del suo account — va bene per un team amministrativo di una sola persona, ma diventa disordinato per un'operazione di 3+ persone con responsabilità divise.
La funzionalità si trova in fondo a Settings → Notifications, nella sezione "Per-type email routing". Per ciascuno dei 6 tipi di notifica instradabili può impostare un indirizzo email dedicato:
inquiry_received— tipicamente admissions@inquiry_replied— tipicamente lo stesso di soprabooking_requested— admissions@ oppure un visits@ dedicatobooking_confirmed— ugualeapplication_received— admissions@application_decision— admissions@
Lasci vuoto per usare l'email dell'account del destinatario (il comportamento predefinito).
Cosa interessa: solo il canale email. La notifica in-app continua ad arrivare ai membri del team indicati dalle regole di routing — è voluto, l'inbox in-app è una superficie per singolo utente, non una casella condivisa.
Perché solo 6 tipi sono instradabili: le notifiche di team, sistema e badge sono personali del destinatario (qualcuno ha cambiato il Suo ruolo; la Sua scuola ha ottenuto un badge). Instradarle a una casella condivisa non ha senso operativamente.
Cosa NON c'è ancora nel sistema
Alcune funzionalità che le scuole a volte cercano:
- Orari di silenzio — "non inviare email tra le 20 e le 7." Non implementato. La piattaforma invia quando l'evento si verifica.
- Modalità digest — "inviami un'unica email riepilogativa al giorno invece di una per evento." Non implementato. Ogni evento attiva la propria email.
- Pulsante di notifica di prova — "inviami un esempio di come appare una notifica di richiesta, per verificare il routing." Non implementato. Per verificare: invii una richiesta di prova dal Suo profilo pubblico in una finestra in incognito.
Nessuno di questi è un blocco per le operazioni quotidiane. Se uno diventa un vero problema, ce lo faccia sapere.
Email respinte
Se una notifica email rimbalza (la casella del destinatario è piena, l'indirizzo non è valido, l'email è rifiutata dal suo server), la piattaforma contrassegna la consegna come fallita lato server. Al momento non vedrà un avviso in-app: la dashboard dei rimbalzi per gli admin delle scuole non è ancora esposta.
Se sospetta che le notifiche non arrivino (ad es. "avrei dovuto ricevere l'email di richiesta ma non l'ho ricevuta"):
- Controlli prima la cartella spam: una classificazione spam falsa positiva spiega l'80% delle segnalazioni "email mancante"
- Controlli il routing a livello di scuola: il Suo ruolo è effettivamente incluso in quel tipo di notifica?
- Controlli il Suo override per singolo membro: ha disattivato per sbaglio il canale email per quel tipo?
- Ci scriva: possiamo controllare il log delle consegne per Suo conto
Errori comuni
- Instradare notifiche critiche verso una casella di posta personale. "La controllerò io" dura fino a quando non va in vacanza. Usi un indirizzo basato sul ruolo (admissions@yourschool.ch) in modo che i cambi di personale non rompano il flusso di lavoro.
- Disattivare inquiry_received. È attivo di default per un motivo. Se lo disattiva, perderà delle richieste. Non lo faccia.
- Impostare tutto su email + in-app per tutti. L'affaticamento da notifiche distrugge la disciplina della casella di posta. Sia selettivo: la maggior parte delle persone ha bisogno di sole 3-5 tipologie via email.
- Saltare il test di verifica. Dopo aver configurato le notifiche, invii una richiesta di prova dal Suo profilo pubblico in incognito. L'email è arrivata? Nella casella giusta? Se no, lo sistemi ora.
Quando rivolgersi a noi
Scriva a admin@swissprivate-schools.ch se:
- Una notifica attesa non arriva: possiamo controllare il log delle consegne e identificare se si tratta di un problema di routing o di un rimbalzo
- Vuole che il routing email per tipo venga messo in priorità (registriamo queste richieste; 2-3 = priorità)
- Sospetta che un tipo di notifica venga attivato in modo errato (ad es. "sto ricevendo booking_reminder per prenotazioni annullate"): è un bug, lo segnali
- Ha bisogno di una riconfigurazione massiva delle notifiche durante una transizione di team (un nuovo head of school che prende il posto): possiamo aggiornare il routing in un'unica operazione
Rispondiamo entro 2 giorni lavorativi.