> ## 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. # Da dove nasce un ticket > Le porte da cui entra oggi una richiesta di uno studente, cosa fa la macchina da sola e cosa deve fare una persona, in ogni caso. **Questa guida è pubblica: la legge chiunque, e cancellare dopo non basta.** Niente nomi di persone o di aziende clienti, niente compensi o tariffe, niente indirizzi interni o chiavi. Prima di scriverci dentro: [cosa ci va e cosa non ci va mai](/contribuire). Una domanda semplice che si fa spesso, e la risposta oggi non è "da un solo punto". Ci sono **tre porte** diverse che portano tutte, alla fine, nello stesso posto (**Team → Task**, in piattaforma). Solo una delle tre ha un controllo automatico che segnala se qualcuno se la dimentica. Sulle altre due, se nessuno guarda, la richiesta resta lì. ## Le tre porte ### 1. Lo studente scrive nella bolla del supporto (questa è automatica) Dal 09/10/2026 il supporto in piattaforma funziona **a conversazioni**, come la chat di un sito di assistenza. C'è **una sola porta**: la bolla arancione in basso a destra, presente in ogni pagina. Si apre su **«Le tue conversazioni»** — tutte quelle dello studente, salvate sul server, con lo stato, l'anteprima dell'ultimo messaggio, la data e il numero di messaggi — più **«Nuova conversazione»**. La pagina **Supporto** (`/supporto`) è la stessa cosa a pagina intera, con in più il pulsante per prenotare una call. Lo studente non sceglie nessuna categoria: la assegna l'assistente, e la vede solo il team. Ogni conversazione è un ticket fin dal primo messaggio. Stati che vede lo studente: | Stato | Quando | | - | - | | **Aperta** | risponde l'assistente | | **In lavorazione** | è passata al team (o il team l'ha messa in attesa di qualcun altro: il motivo resta interno) | | **Risposta del team** | l'ultimo messaggio è del team; un pallino segnala la risposta non ancora letta | | **Risolta** | chiusa. Se lo studente ci scrive di nuovo, **si riapre e torna al team** | #### Quando l'assistente passa la conversazione al team Una regola sola, uguale per la chat e per il controllo automatico che gira ogni 10 minuti sulle conversazioni ferme: 1. **Due tentativi.** L'assistente prova a risolvere quando ha il materiale per farlo. Se dopo **due** risposte lo studente scrive di nuovo senza dire che ha risolto, al terzo messaggio la conversazione passa al team, senza un terzo giro. 2. **Copertura parziale o nulla.** Se l'assistente dichiara che il materiale copre solo in parte, o che non ce l'ha scritto, lascia allo studente quello che ha trovato e passa subito la conversazione al team. 3. **Lo studente chiede una persona o una call.** Passa subito; nella stessa risposta lo studente trova anche il link per prenotare la call da solo. Restano sempre validi i casi fuori portata dell'assistente (accesso perso, pagamenti, fatture, richieste commerciali, guasti veri), che passano al team al primo messaggio. Quando passa, lo studente legge nella conversazione **«Lo passo al team, ti rispondiamo qui.»** Non gli arriva nessuna mail di «ticket ricevuto», e non gli si promette una risposta via email: **il team risponde dentro la stessa conversazione** (vedi [Come si risponde e si chiude un ticket](/delivery/rispondere-e-chiudere-ticket)). #### Cosa succede dal lato del team, senza che nessuno faccia nulla a mano * la conversazione diventa un ticket **in carico al team**, con tutta la cronologia; * un messaggio arriva nel canale del team dedicato ai ticket, con il link diretto, chi l'ha aperto, e lo stato del suo account (bloccato o no, contratto caricato o no, carta di pagamento presente o no); come prima riga del thread c'è **il motivo del passaggio** (quale delle regole qui sopra); * per i passaggi decisi dalla chat parte anche una mail al team; * **entro circa due minuti**, un controllo automatico legge il ticket nuovo e scrive, nello stesso canale, una diagnosi con una bozza di risposta. **Non scrive niente allo studente da solo, non tocca nessun sistema**. * se lo studente scrive ancora mentre la conversazione è del team, l'assistente **non risponde più**: il messaggio va al team, come riga nel thread del ticket. Chi presidia il canale apre il ticket da **Team → Ticket**, risponde e chiude da lì. Se passa troppo tempo senza risposta (24 e 48 ore), l'avviso arriva nel thread del ticket e sale a chi è sopra. Una conversazione riaperta dallo studente fa ripartire questi tempi da capo. ### 2. Il setter titolare del gruppo la apre a mano, partendo da WhatsApp (questa è tutta manuale) Nei gruppi WhatsApp degli studenti scrive **una sola persona**, il setter titolare di quel lotto di gruppi. Quando un messaggio dello studente richiede qualcosa di tecnico, o lo studente è bloccato, il setter lo trasforma **lui, a mano**, in un task sulla piattaforma (dalla coda, oppure a parole dal suo assistente), e lo assegna a chi lo deve risolvere. La procedura, passo per passo, è già scritta qui: [La coda Voci](/delivery/coda-voci) — nella UI di oggi la stessa cosa si chiama "Task", non più "Voci"; il meccanismo è identico. **Il punto da tenere a mente**: qui **non esiste nessun filtro automatico** che legge i gruppi WhatsApp e decide da solo di aprire un ticket o un task. Non è un pezzo di codice che manca per un bug: è una porta che oggi è, di proposito, interamente nelle mani del setter titolare. Se il setter non lo fa a mano, quel messaggio resta nel gruppo e basta — nessun sistema se ne accorge. **Predisposto, non ancora collegato (09/10/2026):** la piattaforma ha già il pezzo che permetterà all'assistente del team di registrare un messaggio arrivato da WhatsApp **dentro la conversazione di supporto dello studente** (crea la conversazione o ritrova quella aperta sullo stesso canale; una conversazione nata così è subito del team, l'assistente non risponde). Serve un permesso dedicato sul token, che si dà a mano. Finché non viene collegato, vale quanto scritto sopra. ### 3. Chiunque nel team la apre a mano, direttamente Qualunque persona con accesso admin può aprire un task da **Team → Task**, partendo da qualcosa che ha visto altrove: una call, una segnalazione arrivata su un altro canale, un problema notato mentre lavorava su altro. È la via più diretta. C'è anche un caso automatico dentro questa porta: ogni lunedì mattina un controllo passa su ogni workspace studente e, se trova un problema tecnico noto (per esempio l'assistente vocale che non gestisce chiamate da giorni), apre da solo un task con il titolo che comincia per "\[Check-up]". Questo è un controllo dei sistemi, non una lettura dei messaggi: non ha niente a che vedere con la porta 2. ## Dove finiscono, tutte e tre Un ticket aperto dalla porta 1 e un task aperto a mano dalle porte 2 o 3 vivono, oggi, in **due tabelle diverse dietro le quinte** — ed è per questo che in piattaforma esistono due pagine, **Team → Ticket** e **Team → Task**. Un ticket che resta troppo a lungo senza che nessuno lo prenda in carico genera in automatico un task collegato, così chi lavora sui task lo vede anche lì senza dover controllare due posti. Il contrario non succede: un task aperto a mano (porte 2 e 3) non genera mai un ticket. ## Cosa è automatico e cosa manuale, in una tabella | Porta | Cosa fa la macchina da sola | Cosa deve fare una persona | | - | - | - | | Bolla del supporto (conversazione) | risponde l'assistente; con la regola dei due tentativi passa la conversazione al team, avvisa il canale (con il motivo), prepara una diagnosi entro \~2 minuti | leggere la diagnosi, rispondere nella conversazione, chiudere | | Gruppo WhatsApp | **niente** — nessun filtro legge i gruppi da solo | il setter titolare deve trasformarlo lui in un task | | Controllo del lunedì mattina | apre da solo un task quando trova un problema tecnico su un workspace | una persona lo prende e lo risolve | | Chiunque nel team | niente | apre un task a mano quando vede un problema altrove | ## Perché conviene saperlo Chi si aspetta "tutte le richieste passano da un solo imbuto" oggi si sbaglia, e vale la pena dirlo chiaro: **non esiste ancora un punto d'ingresso unico**. Le tre porte portano tutte alla stessa stanza, ma solo la prima ha un controllo che avvisa se qualcosa resta indietro. Sulle altre due la sicurezza è una sola: che il setter titolare del gruppo faccia davvero, ogni volta, il passaggio a mano — e che chi presidia la coda dei task controlli ogni giorno chi è **senza assegnatario** o **fermo da più di 72 ore**. La porta 2, passo per passo: dal gruppo WhatsApp a chi risolve Come si diagnostica e si risponde, una volta preso in carico Tempi ed escalation di una segnalazione Chi presidia cosa Fonti: codice (`src/lib/support/regola-passaggio.ts` per la regola dei due tentativi, `src/lib/support/passa-al-team-server.ts` per il passaggio, `src/app/api/support/chat/route.ts`, `src/app/api/support/escalate/route.ts`, `src/app/api/cron/support-escalated/route.ts`, `src/app/api/cron/ticket-sla`, repo `mattone-platform`), l'agente che diagnostica in automatico (`giro/ticket/sentinella.py` + `prompt.md`, repo `mattone-delivery-brain`), e una lettura diretta del database il 17/09/2026: nessun codice nel repo della piattaforma legge i gruppi WhatsApp per aprire un ticket — quel passaggio è, oggi, sempre a mano. Conversazioni e regola dei due tentativi: verificate in produzione il 09/10/2026 su conversazioni di prova (risposta dell'assistente, passaggio su richiesta di una persona, thread, avviso a 24 ore, riapertura, risposta del team dentro la conversazione). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.