> ## 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. # Chi risponde a cosa: il primo smistamento per tema > La tabella di smistamento di un ticket o di un task per tema: chi può rispondere e chi resta responsabile. Oggi è una convenzione che si applica a mano, non una regola scritta nel codice. **Questa guida è pubblica: la legge chiunque, e cancellare dopo non basta.** Niente nomi di persone o di aziende clienti, niente compensi, niente indirizzi interni, niente chiavi. Prima di scriverci dentro: [cosa ci va e cosa non ci va mai](/contribuire). Quando arriva una richiesta di uno studente, il tempo che si perde non è quello per risolverla: è quello per capire **di chi è**. Questa pagina toglie quel tempo di mezzo. Si legge il tema, si guarda la riga, si assegna. Questa pagina parla di **ruoli**, non di persone. Chi occupa oggi ciascun ruolo sta nel registro interno del team, non qui: è una pagina pubblica. Se non sai a quale persona corrisponde un ruolo, chiedilo in canale — non tirare a indovinare l'assegnatario. ## La tabella Confermata il **26/09/2026**. Due colonne diverse, e la differenza conta: **chi può rispondere** è chi ha le competenze per farlo senza passare da nessun altro; **chi è responsabile** è chi risponde del risultato anche quando materialmente ha risposto qualcun altro. | Tema | Chi può rispondere | Chi è responsabile | | - | - | - | | **Marketing** — GHL, ads, automazioni di marketing | il **setter titolare** può rispondere | l'**owner Acquisizione**, sempre | | **Conduit** — crediti, workspace, template, workflow | — | l'**owner Automazioni** oppure il **tecnico del delivery**: indifferente, chi lo prende lo tiene | | **Contratti** | il **commerciale** | il **commerciale** | | **Cose che lo studente può fare da solo** — password, dove trovo X, prenotare una call | il **setter titolare**, e le chiude da solo | il **setter titolare** | | **Tecnico non-Conduit** | il **tecnico del delivery** o l'**owner Automazioni** | chi dei due l'ha preso in carico | La riga «marketing» è l'unica con la doppia firma, ed è voluta: il setter titolare **può** rispondere per non far aspettare lo studente, ma la richiesta resta dell'owner Acquisizione. Rispondere non trasferisce la responsabilità. ## Come si usa, in pratica Non serve capire il problema: serve capire **di che famiglia è**. È marketing? È Conduit? È un contratto? È una cosa che lo studente può fare da solo? Tutto il resto è «tecnico non-Conduit». Una voce senza assegnatario non si muove. Se hai il dubbio fra due ruoli, scegline uno e scrivilo nella nota: «assegnato a X, se è tuo passalo». Meglio un'assegnazione da correggere che una coda senza nomi. Vale sulla riga marketing e ovunque si risponda «per coprire». Una riga nella voce: chi ha risposto, e che la responsabilità resta dell'owner. Senza quella riga, l'owner scopre la richiesta quando è già un problema. ## Un solo cappello per studente Se uno studente ha più richieste aperte insieme, la risposta è **una sola, cumulativa** — mai una per richiesta. Sei messaggi separati nella stessa mattina, ognuno su un pezzo diverso dello stesso problema, non sono sei risposte: sono rumore che lo studente deve rimettere insieme da solo. Prima di rispondere, controlla sempre se la persona ha altro aperto. Se sì, una sola risposta che elenca ogni punto — anche quando i temi sono diversi (una riga Conduit, una marketing, una tecnica) e quindi gli owner sono diversi: chi scrive per primo raccoglie tutto, non aspetta che ognuno degli owner scriva la propria riga separatamente. **Oggi il sistema fa il contrario.** Misurato il 26/09/2026: il sentinella che diagnostica i ticket sul droplet produce una bozza per ogni ticket, indipendentemente dagli altri ticket aperti dalla stessa persona — tre ticket dello stesso studente nello stesso minuto hanno prodotto tre bozze separate, senza che nessuna delle tre sapesse delle altre due. Finché non è una regola del sistema, è chi risponde a doverci pensare a mano, ogni volta. Lo stesso vale a monte, prima ancora che qualcuno risponda: se una richiesta sullo stesso tema per lo stesso studente è già aperta da qualche parte, non se ne apre una seconda — si riprende quella. Misurato lo stesso giorno: un solo tema («sito di prenotazione diretta») aveva **4 voci aperte** per la stessa persona, 3 owner diversi, 9 giorni, perché ogni volta che è arrivata una nuova segnalazione nessuno ha controllato se ce n'era già una. ## Due regole che non si leggono dalla tabella ### Le richieste trovate da un giro proattivo non vanno al primo smistamento Una richiesta che **arriva dallo studente** (un ticket, un messaggio nel gruppo) e una che **viene trovata** girando i gruppi o controllando i sistemi non sono la stessa cosa, anche quando parlano dello stesso argomento. La seconda è quasi sempre più vecchia, più complessa e richiede di sapere qualcosa che nessun sistema mostra. Va quindi direttamente a un **ruolo tecnico** — tecnico del delivery o owner Automazioni — **non** al ruolo di primo smistamento, che su quei casi non ha modo di chiudere da solo. Misurato il 21/09/2026 e confermato come regola. ### Il dubbio si risolve aprendo una voce, non rispondendo Se la risposta che stai per scrivere contiene «dovrebbe» o «credo», non è una risposta: è una voce da aprire. Il criterio completo, con la procedura passo per passo, è in [La coda Voci](/delivery/coda-voci). ## Cosa fa il sistema da solo, oggi **Questa pagina è oggi una convenzione, non una regola scritta nel codice.** Misurato il 26/09/2026 sulla piattaforma: * Fra i temi che si possono scegliere aprendo una voce a mano **«Conduit» non esiste**: ci sono un tema generico, uno di marketing e tre di sviluppo interno. Un caso Conduit oggi si apre con il tema generico e si smista leggendo il titolo, non il tema. * **Nessun automatismo assegna una voce in base al tema.** Scegliere «marketing» non la manda all'owner Acquisizione: l'assegnatario lo mette una persona, a mano, ogni volta. L'unica eccezione misurata è in fase di onboarding: il task «far compilare l'Onboarding marketing», creato insieme all'account di uno studente nuovo, nasce già assegnato all'owner Acquisizione. È un caso singolo scritto nel codice, non una regola generale per tema. Finché le cose stanno così, **questa pagina è la fonte di verità** — e funziona solo se la si applica a mano. Se un giorno lo smistamento diventerà una regola del sistema, questa pagina va riscritta lo stesso giorno: una pagina che descrive un automatismo che non c'è è peggio di nessuna pagina. ## Riferimenti Le tre porte da cui entra una richiesta, e quale ha un controllo automatico Dal gruppo WhatsApp a chi risolve, passo per passo Cosa fare una volta che la richiesta è tua Cosa comprende ciascun ruolo e chi copre chi This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.