Agentforce non conviene in astratto. Ha senso quando esiste un caso d'uso definito, con dati utilizzabili, responsabilità chiare e un risultato misurabile.
La domanda da porsi
"Conviene Agentforce?" è una domanda comprensibile, ma è troppo ampia per arrivare a una decisione. Agentforce è una piattaforma: il valore nasce dal caso d'uso su cui la applicate, non dalla piattaforma in sé.
La domanda che porta a una decisione è un'altra:
Quale processo vogliamo migliorare, quanto volume gestisce, quali dati usa e quale risultato ci aspettiamo?
Prima di valutare licenze, configurazione o partner, conviene verificare quattro elementi:
- il processo da supportare;
- la qualità e la disponibilità dei dati;
- il modello di governance e di accesso alle informazioni;
- il risultato atteso e il modo in cui verrà misurato.
Quando può avere senso
1. Il processo è ripetitivo e definito
Un buon caso d'uso parte da un processo che le persone eseguono in modo simile, con passaggi, regole e informazioni sufficientemente stabili: richieste di assistenza ricorrenti, aggiornamenti sullo stato di un ordine, raccolta di informazioni nel servizio clienti, supporto agli utenti interni su procedure standard.
Un test semplice: chiedete a tre persone che svolgono quell'attività di descriverne i passaggi. Se le tre descrizioni sono molto diverse, il processo non è ancora abbastanza definito da automatizzare, e un agente costruito sopra produrrà risultati incoerenti a seconda del caso che incontra.
In quella situazione il primo lavoro non è costruire un agente: è chiarire il processo.
2. I dati sono affidabili per quel caso d'uso
Un agente risponde in base alle informazioni che riceve e alle fonti a cui accede. Se i dati sono incompleti, duplicati, obsoleti o usati in modo incoerente, le risposte saranno poco affidabili - con tre conseguenze concrete: gli utenti smettono di fidarsi dello strumento, le escalation verso le persone aumentano invece di diminuire, e qualcuno prende una decisione su un'informazione sbagliata.
Prima di avviare il progetto conviene verificare un campione reale di record sul processo scelto:
- i dati essenziali sono presenti?
- i duplicati sono frequenti?
- le informazioni vengono aggiornate?
- è chiaro quale sistema è la fonte corretta?
- i campi hanno lo stesso significato per tutti i team?
La governance dei dati è parte della qualità delle risposte, non un'attività da rimandare a fine progetto. È il punto su cui insiste anche la documentazione di Salesforce, sia nel whitepaper sulla data governance per Agentforce sia nel materiale introduttivo su cosa sia la data governance.
3. Esiste una persona responsabile dopo il rilascio
Un agente non è un progetto che finisce alla pubblicazione. Va osservato, testato, aggiornato e corretto quando emergono casi non previsti. Serve una responsabilità chiara, interna, per:
- controllare risposte ed errori;
- gestire feedback ed escalation;
- aggiornare istruzioni, fonti e regole;
- verificare l'andamento delle metriche concordate;
- coordinare business, IT, sicurezza e compliance.
Che Salesforce metta a disposizione strumenti dedicati a costruire, testare e diagnosticare gli agenti è un segnale utile: il test e il controllo continuo sono parte del lavoro ordinario, non un'attività occasionale.
4. Il risultato è misurabile
Un progetto dovrebbe partire solo quando sapete scrivere con chiarezza cosa deve migliorare. Per esempio:
- ridurre del 25% le richieste ripetitive gestite dal supporto;
- ridurre il tempo medio di risposta su una tipologia specifica di richiesta;
- aumentare la percentuale di pratiche completate senza intervento manuale;
- ridurre il tempo per recuperare informazioni distribuite su più sistemi;
- migliorare la completezza dei dati raccolti durante un processo.
Se non riuscite a definire un criterio di successo prima della partenza, sarà difficile dimostrare il valore del progetto dopo il rilascio - e sarete voi a doverlo spiegare, non il fornitore.
Quando è meglio aspettare
Il processo non è ancora stabilizzato
Se ogni team lavora con procedure diverse, eccezioni non documentate e passaggi affidati alla memoria delle persone, un agente replicherà quella complessità. Prima si definiscono regole, responsabilità ed eccezioni principali; poi si valuta dove l'AI può intervenire.
I dati richiedono una bonifica importante
Duplicati, campi compilati in modo diverso, fonti in conflitto e proprietà dei dati poco chiara sono segnali che il progetto deve partire dalla base dati. Non significa che Agentforce non sarà utile: significa che bonifica, definizione delle fonti e governance rientrano nel perimetro e nel budget del progetto, e vanno preventivate.
Il modello di accesso non è stato verificato
Un agente può collegare informazioni provenienti da più oggetti, sistemi e fonti aziendali. Prima del rilascio va verificato quali informazioni può utilizzare, per quali utenti e in quali contesti. Sicurezza, privacy, visibilità dei dati e tracciabilità delle azioni sono requisiti di progetto, da verificare come si verifica un requisito architetturale - non dettagli tecnici da affrontare dopo.
Non esiste un responsabile del risultato
Se nessuno nel business possiede il processo e nessuno in IT può seguire il ciclo di vita dell'agente, il progetto resta senza guida dopo il go-live. In questi casi conviene fermarsi, assegnare responsabilità chiare e ripartire su un perimetro più limitato.
Cosa potete stimare, una volta risposto
Quando sapete indicare su quale processo avete volume, dati utilizzabili, regole chiare e una persona responsabile, la valutazione della piattaforma smette di essere un giudizio e diventa un calcolo. Potete stimare:
- il valore potenziale del caso d'uso;
- il livello di preparazione necessario;
- le attività preliminari su dati, processi e sicurezza;
- il perimetro del primo prototipo;
- il costo e il tempo realistici per arrivare in produzione.
Come valutare una demo
Una demo serve a capire cosa può fare il prodotto. È una cosa diversa dal dimostrare che lo stesso risultato sia replicabile nel vostro contesto, e le due vanno tenute distinte durante la valutazione.
Chiedete di lavorare su un caso d'uso vicino al vostro e di chiarire:
- quali dati utilizzerà l'agente;
- da quali sistemi verranno letti;
- come vengono gestiti errori, allucinazioni ed escalation;
- quali utenti potranno accedere alle informazioni;
- come verranno misurate accuratezza, utilizzo e valore;
- chi sarà responsabile della manutenzione dopo il rilascio.
Quando possibile, chiedete un prototipo limitato su dati reali o su un estratto anonimizzato e rappresentativo. Un test su un perimetro piccolo produce informazioni più utili di una demo generica.
Domande frequenti
Agentforce ha senso per un'azienda di 300 dipendenti?
La dimensione conta meno del volume e della ripetitività del processo scelto. Un'azienda di 300 persone con migliaia di richieste ricorrenti al mese ha un caso d'uso più solido di un'organizzazione molto più grande con processi frammentati.
Quanto tempo serve per vedere un risultato?
Su un caso d'uso circoscritto, con dati già disponibili e processo chiaro, un primo prototipo si realizza in settimane e si valida in pochi mesi. Se prima è necessario intervenire su dati, accessi o governance, la parte AI è una componente di una trasformazione più ampia e va pianificata come tale.
Possiamo iniziare in piccolo?
Sì, ed è quasi sempre l'approccio migliore. Un singolo caso d'uso, perimetro chiaro, dati verificati e una metrica definita. Stabilite prima di partire cosa deve accadere per proseguire, correggere o fermarsi. L'obiettivo iniziale non è distribuire una piattaforma: è dimostrare che un caso d'uso genera valore in condizioni reali.
Approfondimenti
- Quanto costa davvero Agentforce
- Cosa chiedere a un partner prima di firmare
- Readiness assessment - processo, dati, governance e valore atteso verificati sulla vostra situazione, in due giornate.