> ## Documentation Index > Fetch the complete documentation index at: https://docs.mattone.co/llms.txt > Use this file to discover all available pages before exploring further. # Uno studente segnala un problema: cosa succede > La procedura passo per passo: chi prende in carico, entro quanto, cosa si guarda per primo, quando si escala e a chi. Questa è la procedura, non il principio. Vale dal momento in cui una segnalazione entra fino al momento in cui viene chiusa. Se sei nuovo: leggila una volta intera prima di gestire il tuo primo caso, poi tienila aperta durante. ## Da dove arrivano le segnalazioni Sono quattro strade, e vanno tutte nella stessa coda. Non esiste una coda "importante" e una "minore". | Strada | Chi la genera | Trappola | | - | - | - | | Messaggio diretto della persona che assistiamo | studente o cliente | arriva al singolo, non alla squadra: se chi lo riceve non lo riporta, non esiste | | Thread del cliente nel canale del team | chiunque nel team | si perde fra i messaggi se non viene nominato un proprietario | | Riepilogo automatico delle conversazioni aperte | il sistema | **il più pericoloso**: arriva puntuale ogni giorno, e proprio per questo si smette di leggerlo | | Monitoraggio periodico | chi presidia i numeri | vede il degrado prima della lamentela, ma solo se qualcuno guarda davvero | **L'avviso automatico non è una presa in carico.** Un riepilogo che elenca dieci conversazioni aperte ha fatto il suo lavoro; il lavoro che manca è che una persona scriva il proprio nome accanto a ognuna. Finché quel nome non c'è, la segnalazione è **ricevuta ma non presa**, e resta ferma per giorni senza che nessuno se ne accorga — perché formalmente l'avviso c'era. ## La procedura Due gesti, sempre insieme. **Il nome:** una persona sola prende il caso. Non è chi lo risolverà per forza, è chi risponde di farlo avanzare. Va scritto nel thread del cliente, per esteso. **La ricevuta:** un messaggio a chi ha segnalato che dice tre cose e basta — ho letto, me ne occupo io, ti aggiorno entro *\[momento preciso]*. Non serve avere la soluzione per mandarla, e non va rimandata finché non ce l'hai: è esattamente l'attesa che genera la seconda segnalazione arrabbiata. Il riferimento operativo è **risposta entro 4 ore lavorative**, lo stesso standard del delivery. Vale per la ricevuta, non per la soluzione. Senza un caso concreto non si diagnostica, si tira a indovinare. Prima di aprire qualsiasi pannello, ottieni queste cinque risposte: 1. **Cosa doveva succedere** secondo chi segnala. 2. **Cosa è successo davvero** — testo esatto, screenshot, non il riassunto. 3. **Su quale unità e in quali date**, se il caso riguarda una prenotazione o un soggiorno. 4. **Su quale canale** è avvenuto lo scambio. 5. **Quando è stata l'ultima volta che funzionava**, se è mai funzionato. L'ultima domanda è quella che il team salta più spesso ed è la più utile: separa "non ha mai funzionato" (quasi sempre configurazione mai completata) da "ha smesso di funzionare" (quasi sempre qualcosa è cambiato, e sapere *quando* dice *cosa*). Se chi segnala non risponde, **non riempire i buchi con una ricostruzione plausibile**. Un caso ricostruito a memoria porta a diagnosticare un problema che non è quello reale, e a dichiararlo risolto senza averlo mai toccato. | Gravità | Riconoscila da | Primo aggiornamento | Ritmo mentre è aperta | | - | - | - | - | | **Bloccante** | un ospite non entra, non paga, o non riceve risposta adesso | subito, prima di tutto il resto | ogni poche ore finché non rientra | | **Degrado** | funziona ma male o a intermittenza; il cliente sta rimediando a mano | entro la giornata lavorativa | ogni giorno lavorativo | | **Fastidio** | infastidisce, non blocca nulla | entro 4 ore lavorative | ogni due giorni lavorativi | | **Domanda** | non è un guasto: è una cosa che non si sa fare | entro 4 ore lavorative | si chiude nello stesso giro | Una segnalazione bloccante ha la precedenza su qualunque cosa tu stia facendo, incluse le altre segnalazioni arrivate prima. Non partire dal punto che ti incuriosisce di più. Parti dal più economico da escludere. 1. **L'ospite è servito adesso?** Se un ospite è in mezzo al problema, sistemalo a mano *prima* di diagnosticare. La diagnosi può aspettare venti minuti; una persona chiusa fuori no. 2. **Il collegamento fra i sistemi è vivo?** Un collegamento caduto spiega da solo la maggior parte dei sintomi "strani", e si controlla in un minuto. 3. **La configurazione è quella prevista?** Confrontala con la checklist di verifica finale dell'onboarding, punto per punto. La maggioranza dei "non funziona" muore qui. 4. **Il dato di partenza esiste?** Molte funzioni non falliscono: girano a vuoto perché ciò su cui dovevano lavorare non è mai stato caricato. Non danno errore, danno un risultato vuoto. Solo se tutti e quattro passano hai davanti un caso che vale la diagnosi tecnica: applica allora le [cinque mosse del metodo](/troubleshooting/metodo). A questo punto devi rispondere a una domanda sola: è configurazione o è un difetto del sistema? Non rispondere a intuito — la procedura per deciderlo con una prova è in [Nostro o suo?](/manutenzione/nostro-o-suo). Si escala per un motivo, non per stanchezza. Le condizioni sono due, e basta una: * **è scaduto il tempo** previsto dalla gravità e non hai ancora *la causa* (non la soluzione: la causa); * **la causa è fuori dal tuo perimetro** — richiede una decisione commerciale, una spesa, un accesso che non hai, o un intervento del fornitore. **A chi, nell'ordine:** l'owner del verticale competente → l'account manager del cliente → la decisione go/no-go solo per i casi previsti dalla matrice di escalation. Non si saltano gradini in su, mai. Chi riceve l'escalation resta responsabile finché non la restituisce esplicitamente. **Come si passa un caso — quattro righe, sempre queste:** ```text theme={null} Cliente: [chi] — chi lo segue: [nome] Cosa succede: [sintomo osservato, non interpretato] Cosa ho già escluso e con quale prova: [1-3 righe] Cosa mi serve da te: [decisione / accesso / intervento] ``` Un'escalation senza la riga "cosa ho già escluso" fa ricominciare il lavoro da zero a chi la riceve. È il modo più veloce per trasformare un problema di due ore in un problema di due settimane. **Nessuna segnalazione aperta può restare senza un aggiornamento oltre le 24 ore lavorative** — nemmeno quando non ci sono novità. "Nessuna novità, sto aspettando *\[cosa]*, ti aggiorno *\[quando]*" è un aggiornamento valido; il silenzio no. Vale anche verso l'interno: se il caso è passato a un'altra persona, chi l'ha passato controlla che sia stato ripreso. Un passaggio di consegne non confermato non è avvenuto. Prima di scrivere "risolto" servono due cose: la prova che l'effetto c'è ([Verificare il risolto](/manutenzione/verificare-il-risolto)) e la riga scritta nell'archivio interno ([Chiusura e diario](/manutenzione/chiusura-e-diario)). Se il lavoro tocca un cliente che segue un'altra persona, avvisala **prima** di chiudere ([Chi avvisare](/manutenzione/chi-avvisare)). ## Tre modi per sembrare presidiato senza esserlo Tutti e tre superano una metrica di tempo di risposta — e per questo sono più pericolosi di un silenzio, che almeno si vede. «Ti aggiorno», «ci pensiamo noi», «a breve ti aggiorniamo» sono risposte legittime — ma **contano come risposta in qualunque metrica di tempo**, e su un campione misurato la maggioranza di quelle frasi non ha mai generato un secondo messaggio. Il caso sembra presidiato perché è stato risposto in fretta; non lo è, perché non è mai stato chiuso. Ogni volta che scrivi una di queste formule, quella frase **è** l'apertura di un impegno con un nome e una data, non una risposta a sé stante. La chiusura è **un messaggio dedicato**, mai un pensiero: «fatto, ecco l'esito» oppure «ancora in corso, ti aggiorno entro \[quando]» — vedi il passo 7 della procedura qui sopra, "Tieni viva la segnalazione finché è aperta". Menzionare una persona senza aggiungere testo non è un passaggio di consegne: è una notifica che arriva a chi la riceve senza dirgli cosa fare. Su un campione di gruppi misurato, nella maggioranza dei casi la persona taggata non è intervenuta e la richiesta è rimasta scoperta per **giorni**, in un caso ritaggata una seconda volta senza altro testo. Un tag deve **sempre accompagnare una frase** che dice cosa succede e per quando: mai un nome da solo. Un vocale con dentro una domanda precisa, anche architetturale o bloccante, può restare senza risposta perché **non è cercabile e non genera da solo un ticket**: il gruppo va avanti come se non fosse arrivato. Trascrivilo sempre (una trascrizione automatica costa pochissimo) e trattalo come qualunque altro messaggio di testo: stessa gravità, stessa procedura, stesso obbligo di chiusura. Misurato: i vocali non sono di per sé il collo di bottiglia del tempo di risposta — durano in mediana pochi secondi e una parte non piccola la manda il team stesso. Il collo vero è la **coda dei messaggi mai ripresi**: la stessa disciplina di questa pagina, applicata senza eccezioni al canale vocale. ## Se una segnalazione non l'ha presa nessuno Succede, e va trattato come un caso a sé — non come una dimenticanza individuale. * La coda ha **un proprietario di turno** che ogni giorno lavorativo verifica una cosa sola: che ogni voce aperta abbia un nome accanto. Non deve risolverle, deve assegnarle. * Ogni voce senza nome viene **letta ad alta voce nel kick-off settimanale** e assegnata lì, in diretta. * Una segnalazione ferma da più di una settimana **non si chiude in silenzio**. Si riapre il contatto con chi l'aveva mandata, riconoscendo l'attesa: chi ha scritto tre volte senza risposta ha smesso di credere che scrivere serva, ed è un danno più costoso del guasto iniziale. **Il segnale da tenere d'occhio non è quanti problemi arrivano, ma quanti hanno un nome accanto entro il primo giro.** Il primo numero misura i clienti; il secondo misura noi. Il passo 5, in dettaglio Le cinque mosse di diagnosi Il playbook di supporto a volumi Chi è l'owner di quale verticale This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.