← Torna ai progetti

01 / PROGETTO PRINCIPALE · PILOT PRIVATO

AI Helpdesk
Assistant.

Dal ticket poco chiaro a una gestione tracciabile. L’IA propone il contesto; regole esplicite assegnano il lavoro; l’operatore decide e risolve.

SUPPORTO ITFASTAPI + POSTGRESQLGROQ OPZIONALE
IL PRINCIPIO
Richiesta+Contesto+Persona= lavoro gestibile
Il modello suggerisce. Permessi e assegnazioni restano nell’applicazione.

IL PROBLEMA / 01

Le richieste arrivano. Il contesto spesso no.

Un messaggio vago o una priorità scelta per urgenza percepita costringe il team a rifare il triage. Quando si aggiungono carichi sbilanciati e conoscenza dispersa, rispondere diventa più lento.

01Dati incompleti

L’operatore deve capire impatto, ambiente ed errore prima ancora di intervenire.

02Code poco leggibili

Priorità e assegnazione possono dipendere da informazioni parziali.

03Esperienza dispersa

Procedure e soluzioni passate esistono, ma non arrivano sempre a chi ne ha bisogno.

LA SOLUZIONE / 02

Un flusso unico.
Tre livelli di intelligenza.

Il prodotto combina comprensione del testo, strumenti di supporto e regole di assegnazione. Ognuno ha un perimetro preciso.

01 / COMPRENDERE
✳

Triage IA

Un worker elabora il ticket e valida categoria, priorità e sintesi. Se il provider non è disponibile, il portale lo dichiara con chiarezza.

02 / CONTESTUALIZZARE
⌕

Helpdesk Agent

Un’orchestrazione limitata cerca procedure e casi chiusi della stessa organizzazione, poi prepara controlli e informazioni da chiarire per il tecnico.

03 / DISTRIBUIRE
≋

Routing verificabile

Una policy applicativa considera competenze, livello, capacità e carico. Se manca un profilo idoneo, il ticket resta in coda.

DENTRO IL PRODOTTO / 03

La stessa richiesta.
Tre punti di vista.

Una ricostruzione fedele della struttura del portale con dati sintetici. Scegli un ruolo per vedere ciò che conta per quella persona.

INTERFACCIA RICOSTRUITA
NESSUN DATO REALE

RICHIEDENTE

Segui il ticket senza diventare il tecnico.

Il richiedente vede la propria richiesta, l’analisi quando è pronta, gli aggiornamenti e gli allegati. Riceve il feedback solo dopo la chiusura.

  • Stato e persona incaricata sempre leggibili
  • Risposta rapida quando serve un chiarimento
  • Nessuna nota interna o caso storico esposto
Helpdesk ITSUPPORTO
I miei ticket
Apri ticket
Notifiche 2
Organizzazione demoAndrea · requester
← Dashboard
TICKET #018

Accesso remoto non disponibile

Creato da Andrea · oggi, 09:42
ApertoAlta
Richiesta

Il collegamento VPN si interrompe dopo l’accesso. L’errore compare su due dispositivi.

Nota di sintesi operatore

Verifica in corso con il team infrastruttura.

Analisi IA

Possibile problema di accesso remoto.

Accesso remotoAlta
Proposta da verificare
Timeline ticket

Il ticket è stato preso in carico · Giulia

DAL TICKET ALLA RISOLUZIONE / 04

Ogni passaggio
lascia una traccia.

Il ticket viene salvato subito. Il lavoro più costoso procede in coda; le azioni importanti restano registrate.

  1. 01

    La richiesta entra

    Il richiedente apre il ticket, può aggiungere allegati e vede lo stato del lavoro.

    PERSONA
  2. 02

    Il triage viene elaborato

    Un job durevole produce l’analisi strutturata. Un retry del form non crea ticket duplicati.

    SISTEMA + IA
  3. 03

    L’agente prepara il contesto

    Recupera informazioni autorizzate, procedure e precedenti per una guida tecnica destinata all’operatore.

    AGENTE
  4. 04

    La policy propone un assegnatario

    Competenze, livello, capacità e carico decidono se assegnare o lasciare in coda.

    REGOLE
  5. 05

    Il tecnico chiude il ciclo

    Aggiorna, risolve e resta responsabile del ticket. Dopo la chiusura arriva il feedback del richiedente.

    PERSONA

COME È COSTRUITO / 05

Componenti separate.
Decisioni leggibili.

Il modello comprende il testo; l’applicazione decide permessi, stato e assegnazione. Questa divisione rende il comportamento verificabile.

ACCESSOBrowserTre ruoli
→
PORTALECaddy + FastAPISessioni, scope, workflow
↔
STATOPostgreSQLTicket, job, audit
↔
ELABORAZIONEWorker + GroqTriage e arricchimento
01

Confini dei dati

Ricerca e permessi sono limitati all’organizzazione. Il ticket è trattato come dato non fidato.

02

Fallback dichiarato

Se il provider IA non è disponibile, la richiesta rimane gestibile e lo stato è esplicito.

03

Verifica umana

Correzioni, trasferimenti e configurazioni del triage hanno un passaggio controllato.

STATO DEL PROGETTO / 06

Già realizzato.
E ciò che viene dopo.

Un pilot privato in evoluzione. Le capacità presenti e le idee future sono dichiarate separatamente.

OGGI

Funzioni implementate

  • Triage asincrono e risultato IA validato
  • Guida tecnica con knowledge base e casi autorizzati
  • Routing deterministico per competenze e carico
  • Portale per richiedente, operatore e admin
  • Audit, test automatici e smoke PostgreSQL
PROSSIMI PASSI

Evoluzioni proposte

  • Domande proattive al richiedente prima dell’invio
  • Ricerca semantica con citazioni e valutazione dedicata
  • Reparti, referenti e policy di instradamento più articolate
  • Misura dei risultati su un pilot con utenti reali

MATTEO / AI SYSTEMS

Un assistente utile
deve saper rendere conto.

Questo progetto mostra come inserire l’IA in un processo operativo senza perdere permessi, responsabilità e possibilità di correggere.