Le domande migliori non mettono il fornitore all'angolo. Rendono verificabili perimetro, responsabilità, architettura, costi e risultato.
Chiedete le risposte per iscritto. Alcune devono entrare nel contratto o nello Statement of Work; altre diventano allegati tecnici, piano di progetto, matrice RACI, piano di test o piano di transizione. L'obiettivo non è irrigidire la relazione con il partner: è ridurre le ambiguità prima che diventino costi, ritardi o aspettative diverse.
Come usare questa guida
Non serve fare tutte le domande nella prima call. Se state ancora valutando più partner, mandatele insieme alla richiesta di offerta. Se avete già una proposta sul tavolo, usatele nella fase di chiarimento prima della firma.
Per ogni risposta cercate cinque elementi:
- un perimetro chiaro;
- un responsabile nominato;
- un output o una decisione attesa;
- un'assunzione esplicita;
- un punto in cui la risposta verrà verificata.
"Lo definiremo durante l'analisi" può essere una risposta legittima. Ma deve chiarire chi lo definirà, con quale attività, entro quando e con quale effetto su tempi e costi.
Strategia e perimetro
1. Quale problema di business risolve questa proposta?
Chiedete di descrivere il problema senza citare prima la tecnologia. Una risposta solida indica il processo coinvolto, gli utenti interessati, il problema operativo attuale, il risultato atteso e il motivo per cui Salesforce o Agentforce sono la soluzione adatta.
Perché conta: se il partner parte dai prodotti invece che dal problema, rischiate di comprare una soluzione prima di aver definito il caso d'uso.
2. Cosa è incluso e cosa è esplicitamente escluso?
Non chiedete "c'è tutto?". Chiedete una lista scritta di funzionalità incluse ed escluse, sistemi coinvolti nelle integrazioni, migrazioni dati incluse ed escluse, ambienti, formazione, supporto e hypercare, attività a carico vostro e attività gestite da terze parti.
Perché conta: le change request nascono raramente da richieste nuove. Nascono da attività che ciascuna parte pensava fossero comprese.
3. Quali assunzioni possono modificare stima, tempi o perimetro?
Chiedete di dichiarare tutte le ipotesi alla base dell'offerta: disponibilità e qualità dei dati, esistenza delle API necessarie, disponibilità degli utenti per workshop e test, numero di processi o business unit coinvolte, tempi di approvazione di security e legal, accesso agli ambienti, presenza dei decisori interni.
Perché conta: non esiste un preventivo senza assunzioni. Il rischio non è che esistano, è scoprirle dopo il kickoff.
4. Quali alternative avete valutato, e perché non le proponete?
Chiedete quale soluzione più semplice hanno considerato, cosa sarebbe possibile fare senza Data 360 o Agentforce, quali casi d'uso suggeriscono di rimandare e quale parte del perimetro affronterebbero in una seconda fase.
Perché conta: un partner competente non propone sempre il perimetro più ampio. Sa distinguere ciò che serve subito da ciò che si può validare o rimandare.
Architettura e integrazioni
5. Qual è l'architettura proposta e quali sono le sue dipendenze?
Chiedete un diagramma architetturale, non una slide commerciale. Deve mostrare sistemi sorgente e destinatari, flussi di dati, integrazioni e middleware, dove risiedono i dati, quale sistema è la fonte autorevole, i componenti Salesforce o esterni, gli ambienti di sviluppo, test e produzione, e le dipendenze da licenze o team terzi.
Perché conta: l'architettura rende visibili le dipendenze che un elenco di funzionalità nasconde.
6. Perché questa architettura e non una più semplice o headless?
Chiedete perché serve un agente nativo Salesforce invece di usare Salesforce come sistema di record rendendo dati e azioni disponibili in ChatGPT, Claude, Slack o Teams; quali vantaggi concreti offre la proposta su adozione, sicurezza, governance e manutenzione; e quali costi e limiti introduce rispetto alle alternative.
Perché conta: il punto di partenza della decisione non è la piattaforma. È dove lavorano gli utenti, quali azioni devono compiere e quale sistema deve governare dati e autorizzazioni. Il confronto fra le due strade è in Quanto costa davvero Agentforce.
7. Quali integrazioni servono e chi ne è responsabile?
Per ciascuna: quale sistema fornisce o riceve dati, quali dati vengono letti o scritti, se esistono già API documentate, chi sviluppa e chi mantiene, chi possiede il sistema esterno, quali volumi e limiti sono previsti, quali attività dipendono da altri fornitori.
Perché conta: un'integrazione non è "collegare due sistemi". È un insieme di responsabilità, sicurezza, gestione errori e manutenzione, che va assegnato in modo esplicito.
Dati, sicurezza e AI
8. Quali dati userà la soluzione, e qual è la fonte corretta per ciascuno?
Chiedete una mappa dei dati critici per il caso d'uso: quali servono, da dove arrivano, chi ne è responsabile, con quale frequenza si aggiornano, se esistono duplicati o fonti in conflitto, quali controlli di qualità verranno eseguiti prima del rilascio.
Perché conta: qualità e governance dei dati sono condizioni necessarie per risultati affidabili, tanto più se un agente deve leggere quelle informazioni e agire di conseguenza. È il tema del materiale Salesforce su sicurezza e governance delle soluzioni agentiche e sulla strategia dei dati.
9. Quali autorizzazioni avrà ogni utente, e cosa potrà leggere o modificare l'agente?
Chiedete una matrice di accesso per ruoli e casi d'uso: chi vede quale tipo di dato, chi può avviare azioni, quali azioni l'agente esegue in autonomia, quali richiedono approvazione umana, come vengono trattati dati personali o regolamentati, quali log e audit trail saranno disponibili.
Perché conta: un agente introduce un livello di accesso e automazione in più. La soluzione deve rispettare privilegio minimo, controllo degli accessi, tracciabilità e protezione dei dati.
10. Come testerete accuratezza, sicurezza e comportamento dell'agente prima del go-live?
Questa domanda deve produrre un piano di test: quali scenari reali verranno provati, quali utenti parteciperanno, come si gestiscono risposte errate, come si testano prompt injection, accessi non autorizzati e casi limite, quali soglie minime servono per andare in produzione, chi approva il rilascio.
Perché conta: il test di un agente non verifica solo se risponde, ma se protegge i dati, rispetta i permessi, agisce correttamente e resta monitorabile dopo il rilascio. Salesforce stessa lega l'adozione degli agenti alla fiducia e alla preparazione delle persone.
11. Cosa accade quando la soluzione sbaglia o non riesce a completare un'azione?
Chiedete il processo di gestione delle eccezioni: come viene rilevato l'errore, se l'utente può correggere o chiedere supporto, quando scatta l'escalation a una persona, chi analizza gli errori ricorrenti, come si correggono prompt, dati e istruzioni, entro quanto vengono gestiti gli incidenti rilevanti.
Perché conta: un buon progetto non presume che l'agente sia sempre corretto. Progetta come l'organizzazione rileva e riduce gli errori nel tempo.
Costi e condizioni commerciali
12. Qual è il costo completo su 24 mesi?
Chiedete una stima separata per licenze e rinnovi, implementazione, integrazioni, migrazione e bonifica dati, consumo variabile, supporto e manutenzione, formazione, prodotti di terzi e attività richieste ai vostri team.
Perché conta: il primo anno può contenere sconti e attività una tantum. Su 24 mesi diventano visibili i costi ricorrenti.
13. Quali costi dipendono da volume, utilizzo o condizioni non ancora certe?
Quale volume è stato assunto, quale unità di consumo si applica, quale margine di errore è stato considerato, quali costi emergono se il volume cresce del 25%, 50% o 100%, se esistono soglie di allarme o tetti di spesa, quale parte del costo resta al partner e quale a voi.
Perché conta: una previsione di consumo è un'ipotesi. Va documentata, monitorata e aggiornata dopo il pilota.
14. Quali componenti mostrati in demo richiedono licenze o prodotti aggiuntivi?
Chiedete una matrice semplice, con una riga per ogni capacità vista:
| Funzionalità mostrata | Prodotto o edizione richiesta | Inclusa nella proposta? | Costo aggiuntivo |
|---|---|---|---|
| Agente sulla conoscenza interna | Agentforce + fonte dati | sì / no | da indicare |
| Dati esterni in tempo reale | Data 360 + integrazione | sì / no | da indicare |
Perché conta: una demo serve a capire le possibilità. Il contratto deve chiarire quali di quelle possibilità state effettivamente comprando.
Team, governance e continuità
15. Chi lavorerà sul progetto, e con quale disponibilità?
Chiedete nome, ruolo, seniority e percentuale di allocazione di sponsor, solution architect, project manager, lead tecnico, specialisti di dati, integrazione e sicurezza, figure AI e team di supporto post-rilascio. Chiedete anche se chi ha partecipato alla prevendita seguirà l'avvio e l'architettura.
Perché conta: non serve che il team di vendita diventi il team di delivery. Serve continuità fra ciò che è stato promesso, l'architettura definita e le persone che eseguiranno.
16. Quali responsabilità restano in capo a noi?
Chiedete una matrice RACI che copra decisioni funzionali, disponibilità e qualità dei dati, sicurezza e compliance, accesso agli ambienti, priorità di backlog, user acceptance test, formazione e adozione, gestione operativa dopo il go-live.
Perché conta: un partner può costruire una soluzione, ma non può sostituire il process owner, il data owner o chi possiede la decisione interna.
17. Cosa dovrà saper fare il nostro team quando il progetto finisce?
Chiedete un piano di transizione: documentazione consegnata, formazione prevista, procedure operative, gestione di utenti e permessi, gestione delle integrazioni, processo per le modifiche future, proprietà di codice e configurazioni, supporto previsto dopo il go-live.
Perché conta: il risultato non è una soluzione rilasciata. È un'organizzazione capace di governarla e farla evolvere.
Risultati e controllo del progetto
18. Come definiamo il successo prima di iniziare?
Ogni caso d'uso dovrebbe avere una baseline iniziale, una metrica di risultato, una data di misurazione, una fonte dati per calcolarla, un responsabile della verifica e un criterio per estendere, correggere o fermare.
Perché conta: una soluzione può essere tecnicamente corretta e non generare valore. La metrica serve a distinguere le due cose.
19. Quali sono i rischi principali, e come li gestirete?
Chiedete un registro rischi iniziale con rischio, probabilità, impatto, responsabile, azione di mitigazione e condizione che fa scattare l'escalation.
Perché conta: un partner affidabile non promette che non esistono rischi. Li rende espliciti e propone come affrontarli.
20. Cosa suggerite di rimandare, semplificare o non fare?
Una risposta utile suona così: partiamo da un processo invece che da cinque, non colleghiamo subito tutti i sistemi, usiamo prima i dati già disponibili, rimandiamo l'automazione delle azioni più rischiose, validiamo l'adozione prima di estendere.
Perché conta: saper ridurre il perimetro iniziale è un indicatore di maturità. Un progetto può essere ambizioso senza provare a risolvere tutto al primo rilascio.
Le sei domande che faccio io
Le venti precedenti le fa, in qualche forma, chiunque abbia gestito un acquisto importante. Queste sei le fa chi la piattaforma la possiede e se la tiene dopo che il progetto è finito e il partner è andato via. Sono quelle che costano di più quando nessuno le ha fatte.
21. Cosa lasciate dentro la nostra org?
Chiedete il conto esatto di oggetti custom, campi, flow, classi, permission set e pacchetti gestiti che il progetto introduce, e il loro impatto sui limiti della piattaforma.
Perché conta: il progetto finisce, l'org resta. Ogni oggetto aggiunto è manutenzione che eredita chi possiede la piattaforma, e non compare in nessun preventivo. Su un'org con dieci anni di stratificazioni è la voce che decide quanto costerà il progetto successivo.
22. Come vi inserite nel nostro ciclo di rilascio?
Sandbox e loro aggiornamento, strategia di branch, finestre di deploy, conflitti con i rilasci già pianificati, chi risolve un merge che tocca lo stesso flow.
Perché conta: su una piattaforma in esercizio esiste già un treno di rilasci. Un progetto che assume di poter rilasciare quando vuole produce un ritardo che non è nel suo piano: è nel vostro.
23. Cosa si rompe di quello che oggi funziona?
Chiedete un piano di test di regressione sui processi esistenti, non solo i test sul nuovo. E chiedete chi lo esegue.
Perché conta: il danno più caro non è il progetto nuovo che non funziona. È il processo che funzionava e smette, perché quello ha già utenti, volumi e aspettative.
24. Cosa di quello che costruiamo diventerà standard di prodotto?
Salesforce rilascia tre volte l'anno. Chiedete quali parti del perimetro sono già annunciate come funzionalità native, e quando.
Perché conta: costruire a mano una cosa che arriva nativa fra due release è spesa buttata più la manutenzione di un doppione. Un partner che segue la roadmap sa rispondere; se non sa rispondere, avete comunque imparato qualcosa.
25. Se ci fermiamo dopo il pilota, cosa resta da smontare?
Chiedete il costo e la procedura del rollback: cosa va disinstallato, quali dati restano e in che formato, quali processi tornano manuali, quanto tempo serve.
Perché conta: se fermarsi costa più che continuare, il criterio di stop che avete scritto a inizio progetto non è esercitabile. E un criterio che non si può esercitare non è un criterio: è una frase nel piano.
26. Chi intesta le licenze?
Acquisto diretto da Salesforce oppure rivendita tramite il partner, e cosa succede al rinnovo se cambiate fornitore di servizi.
Perché conta: cambia il vostro potere negoziale al rinnovo e la libertà di sostituire chi implementa senza rimettere in discussione anche le licenze.
Come valutare le risposte
| Tipo di risposta | Cosa indica | Come proseguire |
|---|---|---|
| Descrive un caso simile, con limiti, rischi e risultati | Esperienza concreta e capacità di contestualizzare | Chiedete quale parte è trasferibile al vostro caso |
| Riconosce ciò che non è ancora noto e propone come verificarlo | Trasparenza e metodo | Fate inserire attività, tempi e responsabilità nel piano |
| Risponde solo con funzionalità del prodotto | Non ha risposto sul processo o sul rischio | Riportate la domanda su dati, persone, output e responsabilità |
| Rimanda molto alla fase di analisi senza stimare attività | Perimetro ancora immaturo | Chiedete un discovery esplicito, con output e costo |
| Promette tutto senza condizioni o compromessi | Possibile sovrastima del perimetro | Chiedete assunzioni, dipendenze, rischi e priorità |
| Mette per iscritto assunzioni e impegni | Buona base di lavoro | Usate il materiale per contratto, SOW e governance |
Domande frequenti
Fare queste domande crea tensione con il partner?
No. Un partner serio ha interesse a chiarire perimetro, dipendenze, responsabilità e criteri di successo prima del kickoff. Le ambiguità danneggiano entrambe le parti: il cliente vede costi e ritardi inattesi, il partner riceve richieste non previste e perde fiducia. Chiarire prima riduce quel rischio per tutti e due.
Devo fare tutte le domande?
No, sono una checklist. Per una valutazione iniziale partite da problema, perimetro, assunzioni, architettura, costi a 24 mesi, team e metriche. Per un progetto AI o Agentforce aggiungete sempre dati, permessi, test, monitoraggio ed escalation. Se la piattaforma è già in esercizio, aggiungete le domande su debito tecnico, ciclo di rilascio e regressione.
Cosa faccio se le risposte sono solide ma il prezzo è più alto?
Confrontate i partner sul costo totale e sul rischio, non sulla tariffa. Un partner più caro ha senso se riduce dipendenze non pianificate, garantisce figure senior nei momenti chiave, costruisce un'architettura manutenibile e vi lascia autonomi dopo il go-live. Questa differenza però deve essere visibile nella proposta scritta, non promessa a voce.
Approfondimenti
- Quanto costa davvero Agentforce - e quando valutare un'alternativa headless
- Conviene Agentforce?
- Review indipendente di una proposta - le stesse domande fatte sulla vostra, con i rilievi in ordine di rischio.