Un’azienda ha cento persone che possono segnalare un guasto, chiedere un documento o aprire una richiesta al reparto amministrativo. Cinque persone lavorano quotidianamente la coda; tre specialisti intervengono soltanto quando serve. Se il preventivo del software viene calcolato su centotto posti identici, il progetto può apparire troppo costoso prima ancora di provarlo. Il problema non è soltanto economico. Dare a ogni richiedente la vista completa, i commenti interni o la possibilità di assegnare e chiudere ticket aumenta confusione ed esposizione dei dati. Ridurre tutti a un semplice indirizzo email, invece, rende difficile seguire lo stato, aggiungere informazioni e consultare soluzioni già pubblicate. Servono ruoli differenti. Il metodo tradizionale confonde spesso account e licenza. Un account identifica la persona; la licenza abilita determinate funzioni. Chi apre una richiesta può avere un portale personale senza diventare agente. Chi fornisce un parere occasionale può ricevere accesso limitato o essere coinvolto attraverso un flusso di approvazione. Soltanto chi lavora code, SLA e risposte necessita normalmente del ruolo operativo completo.

IN SINTESI

Perché è importante

  • Chi apre e segue la propria richiesta non necessita automaticamente degli stessi permessi di chi assegna, risponde e gestisce le code.
  • Prodotti diffusi adottano modelli diversi: Atlassian non licenzia i clienti del portale, mentre altri strumenti prevedono agenti pieni, occasionali o leggeri con limiti specifici.
  • La scelta corretta parte da persone, frequenza e azioni necessarie; prezzo per posto e permessi vanno valutati insieme.

Il problema — Cento richiedenti non sono cento operatori

La domanda giusta non è «quante persone abbiamo?», ma «quante eseguono ciascuna azione, con quale frequenza e su quali dati?». Questa distinzione evita sia sprechi sia un sistema economico che costringe il lavoro a tornare su email e chat private. Il richiedente crea il ticket, vede le proprie richieste o quelle condivise con il suo gruppo, risponde e consulta la conoscenza pertinente. Non dovrebbe vedere le code complete o note interne. L’operatore classifica, assegna, comunica, gestisce scadenze e chiude. Lo specialista occasionale legge soltanto i casi a cui viene invitato, lascia un contributo interno o approva un passaggio senza diventare proprietario stabile della coda. Atlassian documenta un modello netto per Jira Service Management: il cliente può inviare e seguire richieste senza licenza di prodotto; la guida aggiornata il 30 luglio distingue anche Customer, Service Desk Team e Agent e indica quale ruolo consuma una licenza. È un esempio, non una regola universale. Configurazione, piano e permessi cambiano le capacità disponibili.

Freshdesk espone piani per agente e day pass destinati a collaboratori occasionali; Zoho Desk prevede light agent con possibilità più limitate e condizioni che dipendono dall’edizione. Queste opzioni non sono equivalenti. Un posto economico può non consentire assegnazione o modifica dei campi; un cliente gratuito può vedere soltanto i propri ticket. Il confronto deve partire dall’azione necessaria, non dal nome commerciale del ruolo. Aggiungete un amministratore separato. Chi configura campi, automazioni, esportazioni e accessi non deve usare un account condiviso. Ogni ruolo ha autenticazione personale, principio del minimo privilegio e revoca rapida. La riduzione delle licenze operative non giustifica scorciatoie sull’identità. Costruite tre righe: operatori a tempo pieno per prezzo mensile; specialisti occasionali per accesso o giornate effettive; richiedenti per eventuale costo del portale. Aggiungete implementazione, integrazioni, migrazione, formazione e manutenzione. Dividete poi il totale per ticket risolti nel periodo, non per il numero astratto di account. Nel caso esemplificativo, cinque agenti lavorano ogni giorno e tre specialisti entrano due volte al mese. Un piano con clienti gratuiti e accessi giornalieri può essere più efficiente di otto agenti completi; un contratto aziendale può invece offrire condizioni diverse. I prezzi pubblici sono un riferimento, non un’offerta: valuta, IVA, fatturazione annuale, soglie e componenti AI possono cambiare il totale.

Il risparmio diventa falso se il ruolo limitato costringe un responsabile a copiare ogni risposta. Misurate riassegnazioni, attese degli specialisti e richieste aperte fuori sistema. Se metà dei dipendenti torna a WhatsApp perché il portale è lento o non consente allegati, il costo per licenza è diminuito mentre il costo del processo è salito. Anche la privacy entra nel conto. Un portale deve mostrare soltanto il necessario; i gruppi condivisi vanno definiti consapevolmente; note interne, dati sanitari o informazioni disciplinari richiedono accessi più stretti. Esportazioni e amministrazione devono essere tracciate.

DALLA TEORIA ALLA PRATICA

Cosa puoi farci concretamente

  • Contare per ruolo richiedenti mensili, operatori quotidiani, specialisti occasionali e amministratori, evitando di usare il totale dei dipendenti come numero di licenze.
  • Preparare una matrice con ciò che ogni ruolo può vedere, modificare, assegnare, approvare ed esportare.
  • Provare il modello per trenta giorni e misurare richieste fuori sistema, tempi, riassegnazioni, accessi e costo per ticket risolto.

Dal foglio alla prova — Un pilota di trenta giorni con quattro verifiche

Prima settimana: raccogliete cento richieste recenti e indicate chi le ha aperte, chi le ha lavorate e chi ha soltanto fornito un’informazione. Seconda: costruite la matrice dei permessi e configurate un solo processo. Terza e quarta: fate entrare richiedenti reali, cinque operatori e specialisti occasionali, mantenendo un canale di recupero in caso di blocco. Controllate quattro risultati: ogni persona vede soltanto ciò che deve; nessuna richiesta valida richiede una licenza piena per essere aperta; gli specialisti possono contribuire senza scambi paralleli; costo e tempo per soluzione sono leggibili. Provate anche un cambio di reparto, l’uscita di un operatore, un ticket condiviso per errore e un accesso revocato. Solo dopo il pilota si confrontano prodotti o si decide un’integrazione. La soluzione può essere configurare meglio lo strumento esistente, cambiare piano, introdurre un portale o costruire un flusso su misura. Non esiste un vincitore automatico: esiste un modello di accesso coerente con il lavoro. Se oggi non sai quante persone aprono, gestiscono e approvano le richieste, descrivi il flusso nel check-up AI aziendale. Il primo passo non è acquistare licenze: è rendere visibili ruoli, volumi, eccezioni e costo reale.

Per il business, l’AI diventa rilevante quando modifica una metrica operativa: capacità, qualità, tempo o rischio. Il numero di utenti e di conversazioni descrive l’adozione, ma non dimostra da solo un ritorno. Il collegamento al processo deve essere esplicito. Nel caso di “Cento persone aprono ticket, cinque li gestiscono: perché i ruoli contano più delle licenze”, questo significa leggere la novità oltre l’annuncio e capire quali parti del lavoro vengono realmente modificate. Il rischio è estendere un progetto prima di avere una baseline e criteri di uscita. Costi di integrazione, revisione e cambiamento organizzativo possono superare le licenze. Una valutazione completa considera anche alternative più semplici. Le imprese più efficaci gestiranno un portafoglio di casi, ampliando quelli misurabili e interrompendo gli altri. Governance e formazione non saranno attività separate: diventeranno il metodo con cui la tecnologia viene scelta, controllata e migliorata. La notizia è quindi un indicatore di una trasformazione più ampia, che va seguita attraverso risultati e condizioni operative anziché con la sola successione degli annunci.

Quello che conta adesso

Contare per ruolo richiedenti mensili, operatori quotidiani, specialisti occasionali e amministratori, evitando di usare il totale dei dipendenti come numero di licenze. Questo primo passo serve a trasformare il tema in un perimetro verificabile: un responsabile, un input conosciuto, un risultato atteso e una misura precedente con cui confrontarsi. Senza questi elementi il progetto rimane una dimostrazione difficile da valutare. Preparare una matrice con ciò che ogni ruolo può vedere, modificare, assegnare, approvare ed esportare. L’azione deve essere documentata insieme ai criteri di controllo, indicando quali casi possono procedere e quali devono fermarsi. È così che l’esperienza delle persone diventa una regola applicabile e migliorabile nel tempo. Provare il modello per trenta giorni e misurare richieste fuori sistema, tempi, riassegnazioni, accessi e costo per ticket risolto. Prima di estendere il metodo è utile raccogliere correzioni, tempi e costi per alcune settimane. Gli errori vanno raggruppati per causa: dati, istruzioni, strumenti o eccezioni del processo. Ogni categoria richiede un intervento diverso. Chi apre e segue la propria richiesta non necessita automaticamente degli stessi permessi di chi assegna, risponde e gestisce le code. È il punto da cui partire perché definisce l’effetto più immediato per professionisti e imprese. La sua importanza va misurata sul lavoro quotidiano: quante attività coinvolge, quali persone tocca e cosa accade quando il risultato non è corretto.

Prodotti diffusi adottano modelli diversi: Atlassian non licenzia i clienti del portale, mentre altri strumenti prevedono agenti pieni, occasionali o leggeri con limiti specifici. Questo secondo elemento chiarisce perché non basta scegliere un prodotto. Servono un processo, dati affidabili e una responsabilità finale. L’adozione diventa sostenibile quando la tecnologia può essere osservata e corretta senza interrompere l’operatività. La scelta corretta parte da persone, frequenza e azioni necessarie; prezzo per posto e permessi vanno valutati insieme. Il terzo punto indica la prospettiva di medio periodo. La decisione migliore non è necessariamente quella con più funzioni, ma quella che mantiene valore, controllo e possibilità di evoluzione quando cambiano modelli, prezzi o requisiti.

APPROFONDIMENTI

Fonti

Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.

  1. Atlassian — Manage access to Jira Service Management projects and requests, aggiornato 30 luglio 2026Documentazione
  2. Atlassian — Customer accounts and product licensesDocumentazione
  3. Freshworks — Freshdesk pricingFonte primaria
  4. Zoho — Adding and Managing Agents in DeskDocumentazione