Concoro

Un candidato trova un concorso pubblico promettente. Il titolo è vago, i requisiti iniziano a pagina dodici e la scadenza si trova tra un riferimento normativo e un’approvazione amministrativa.

In Italia le opportunità del settore pubblico sono tecnicamente pubbliche, ma sono sparse tra portali istituzionali, descritte con terminologie incoerenti e spesso pubblicate dentro lunghi documenti amministrativi.

La maggior parte dei servizi esistenti si comportava come un database: elenchi, categorie e filtri, lasciando ai candidati il compito di tradurre studi ed esperienza nel linguaggio delle istituzioni.

La vera domanda non era come migliorare la ricerca, ma come aiutare i candidati a capire pertinenza, idoneità e prossimo passo.

Il primo concept raccoglieva i concorsi attivi e li presentava in un’interfaccia di ricerca più chiara. Era utile, ma trattava ogni bando come una pagina da mostrare, non come un documento da comprendere prima.

Le job board tradizionali presuppongono titolo, luogo, datore di lavoro e requisiti chiari. I bandi pubblici raramente arrivano in modo così ordinato.

Concoro è quindi diventato un prodotto di supporto alle decisioni in tre fasi: strutturare l’opportunità, collegarla al candidato e spiegarne la pertinenza.

• Strutturare l’opportunità
• Collegarla al candidato
• Spiegare la pertinenza

La stessa professione poteva essere descritta in modo diverso da due enti. Titoli simili apparivano sotto intestazioni diverse, mentre il nome del ruolo poteva indicare una classificazione contrattuale anziché il lavoro reale.

Ho sviluppato un modello normalizzato per settore, famiglia professionale, tipo di impiego, luogo, scadenze, idoneità, titoli, conoscenze tecniche, capacità, programma d’esame, riferimenti normativi e stato.

Questo schema condiviso permette a Concoro di presentare opportunità coerenti anche quando i bandi originali non lo sono. Senza, filtri migliori avrebbero solo reso più elegante la stessa confusione.

Molti portali pubblici riproducono l’organizzazione dell’ente che pubblica le informazioni. Concoro è stato progettato attorno alla persona che prova a usarle.

Le card mostrano ciò che serve per una prima decisione. I dettagli amministrativi e legali restano disponibili nella pagina completa attraverso una progressive disclosure.

L’obiettivo non era fingere che i concorsi fossero semplici. Chi scorre venti opportunità non ha bisogno di ogni riferimento normativo nella card. Chi prepara una candidatura sì.

• Qual è il ruolo?
• Dove si trova?
• Quando scade?
• Quali titoli sono richiesti?
• È adatto al mio profilo?
• Cosa succede dopo?

I filtri richiedevano ancora di sapere come tradurre il proprio percorso nella terminologia ufficiale. Una persona può sapere di aver studiato economia e preferire ruoli amministrativi senza conoscere la famiglia professionale o la categoria contrattuale corretta.

Ho progettato un onboarding in cinque passaggi su formazione, esperienza, settori preferiti, geografia, condizioni di idoneità e punti di forza.

L’interfaccia pone domande a cui i candidati possono rispondere. Dietro, le risposte diventano dati strutturati e semantici per raccomandazioni, ricerca prioritizzata, alert e supporto futuro alla candidatura.

• Formazione e titoli
• Esperienza professionale
• Settori e famiglie professionali
• Preferenze geografiche
• Idoneità e competenze

Il primo approccio confrontava un embedding del candidato con uno dell’intero bando. Ma un bando lungo mescola norme, procedure, responsabilità, qualifiche ed esami: considerarli tutti ugualmente importanti rendeva i risultati difficili da controllare.

Ho diviso ogni opportunità in tre dimensioni semantiche: nucleo del ruolo, requisiti e contesto professionale. Ognuna viene incorporata separatamente e salvata in Pinecone.

Le raccomandazioni combinano risultati semantici e vincoli strutturati, escludono opportunità scadute, raggruppano per concorso e restituiscono una selezione prioritizzata.

Un candidato può essere interessato a un ruolo senza poter partecipare. Mostrare un’opportunità promettente e rivelare il requisito escludente solo dopo una lunga lettura non è engagement. È attenzione sprecata.

Scadenze, titoli, condizioni obbligatorie e categorie di impiego agiscono quindi come vincoli di prodotto, non come testo passivo nella pagina di dettaglio.

Le raccomandazioni spiegano anche perché appaiono—esperienza, formazione, geografia, competenze o dominio—senza trasformare una percentuale opaca in un’autorità.

L’obiettivo non era convincere l’utente che l’algoritmo avesse ragione, ma dargli abbastanza contesto per decidere se il risultato fosse utile.

I candidati stavano già cercando di capire un processo occupazionale complesso. Non avevano bisogno di imparare anche come interrogare correttamente un chatbot.

L’AI lavora soprattutto dietro l’esperienza: interpreta documenti, estrae informazioni, classifica ruoli, normalizza termini, prepara rappresentazioni semantiche, recupera opportunità e supporta le spiegazioni.

L’interfaccia resta costruita attorno ad azioni familiari: esplorare, filtrare, salvare, confrontare e ricevere alert.

• Interpretare
• Estrarre
• Classificare
• Normalizzare
• Recuperare
• Spiegare

Il record strutturato rende il bando più comprensibile, ma la fonte ufficiale resta autorevole. I candidati possono vedere la provenienza dei dati e tornare al documento originale quando preparano la domanda.

Stato e scadenze sono vincoli di sistema. I concorsi scaduti si chiudono automaticamente e scompaiono da ricerca attiva, retrieval semantico, raccomandazioni e alert.

L’aggiornamento non è un’etichetta aggiunta dopo. Dati correnti, fonti visibili e incertezza esplicita fanno parte dell’esperienza.

Una copertura maggiore rendeva la piattaforma più utile, ma introduceva documenti incoerenti, classificazioni insolite e record incompleti. Servivano stati di validazione, reprocessing e modi per individuare i casi da controllare.

Una personalizzazione più complessa poteva migliorare la pertinenza rendendo però le raccomandazioni meno comprensibili. Ho preferito un matching modulare a un unico punteggio opaco.

Riassunti leggibili dovevano convivere con la completezza legale, mentre l’automazione su larga scala doveva preservare il controllo umano.

• Copertura vs qualità dei dati
• Personalizzazione vs trasparenza
• Semplicità vs completezza legale
• Automazione vs controllo

Concoro è diventato un prodotto informativo end-to-end capace di elaborare bandi, convertirli in uno schema condiviso, mantenere stati aggiornati, supportare ricerca strutturata e semantica, costruire profili e produrre raccomandazioni spiegabili.

Il risultato principale è l’architettura comune che collega fonti, opportunità strutturate, profili e raccomandazioni. Questo livello permette al prodotto di andare oltre la visualizzazione e aiutare le persone a prendere decisioni.

In questa fase non esistevano analytics comportamentali maturi o dati di lungo periodo. La fase successiva deve verificare se il sistema migliora scoperta, comprensione dell’idoneità e decisioni di candidatura.

Un’interfaccia di ricerca non può compensare informazioni incoerenti, incomplete o mal classificate. Gran parte dell’esperienza di Concoro viene determinata prima che il risultato appaia sullo schermo.

I miglioramenti AI più importanti sono arrivati da schemi più chiari, sezioni documentali significative e vincoli deterministici, non da un modello più nuovo o da un prompt più lungo.

Progettare un prodotto intelligente significa progettare il sistema che produce l’esperienza, non soltanto l’interfaccia attraverso cui viene usata.

Rendere pubbliche le informazioni non significa renderle utilizzabili.