Creare dashboard con Claude: dalla configurazione ai controlli SQL

Che cosa fa, in pratica, Claude Dashboards?

Si collega una fonte di dati, si formula una domanda e si ottiene una dashboard costruita per rispondere. Un data warehouse è l’archivio centrale in cui l’azienda raccoglie i dati da analizzare. Un CRM conserva i dati sui clienti e sulle vendite. Claude traduce la domanda in SQL, le istruzioni con cui un database seleziona e conta quei dati, ed esegue la query sulla fonte collegata.

Il grafico è come uno scontrino con il calcolo allegato. Si può aprire la query che produce un dato e controllare quando il grafico è stato aggiornato l’ultima volta. La visualizzazione è utile; poter vedere il calcolo è ciò che consente di verificarla. Anthropic propone questa funzione per le domande esplorative, lasciando gli approfondimenti agli strumenti di analisi già in uso. Come funziona la beta

La guida introduttiva cita Amazon Redshift, BigQuery, ClickHouse, Databricks e Snowflake, oltre ad app collegate come Salesforce. Sono gli esempi documentati: non significa che qualsiasi CRM o database funzioni automaticamente. Esempi di fonti supportate

Quali piani lo includono e quanto costa?

Dashboards è disponibile a partire da Pro, oltre che nei piani Max, Team ed Enterprise. Il piano Free non lo include. Al momento della stesura, Pro costa US$20 con fatturazione mensile o US$200 con fatturazione annuale. La pagina dei prezzi presenta Dashboards come funzione beta. Prezzi di Claude

Il lavoro sulle dashboard rientra nei limiti di utilizzo del piano. Non è una quota separata e illimitata per la reportistica. Su Enterprise, un proprietario dell’organizzazione deve attivare Dashboards da Organization settings > Artifacts. Disponibilità e utilizzo di Dashboards

Chi ha già un piano compatibile può avviare un progetto pilota senza aggiungere un altro abbonamento software. Restano però i costi di configurazione, verifica della query, consumo della quota Claude ed eventuali costi della fonte di dati. Chi non usa Claude deve includere nel confronto anche l’acquisto del piano. D’altra parte, nemmeno uno strumento BI comporta necessariamente una licenza aggiuntiva a pagamento: dipende dai diritti d’uso già disponibili e dalla modalità di distribuzione.

Per valutare la convenienza, partite dal tempo che dedicate ai report. Ecco un calcolo esemplificativo, non un risparmio misurato: quattro report al mese da 90 minuti ciascuno richiedono sei ore. Se il progetto pilota porta ogni report a 30 minuti, verifica compresa, il totale scende a due ore, con un risparmio di quattro. Un abbonamento Pro mensile da US$20 si ripagherebbe quindi attribuendo un valore di US$5 a ogni ora risparmiata, prima dei costi di configurazione e della fonte di dati. Se controllare il risultato richiede tanto tempo quanto preparare il report originale, il risparmio svanisce.

Come creare dashboard: dai dati alla condivisione

Iniziate dall’app web o desktop di Claude, dove sono disponibili i comandi di condivisione. Una dashboard viene salvata come artifact, un contenuto modificabile che Claude affianca alla conversazione. Potete riaprirla dalla scheda Artifacts. Per usare gli artifact serve Cloud code execution and file creation, disponibile in Settings > Capabilities nei piani individuali o in Organization settings > Capabilities per Team ed Enterprise. Configurazione di Artifacts

1. Fate attivare le funzioni necessarie al proprietario dell’organizzazione

Su Team o Enterprise, il proprietario deve verificare l’esecuzione del codice nel cloud, attivare Artifacts e abilitare il modello Dashboards in Organization settings > Artifacts. Su Enterprise, Dashboards è inizialmente disattivato; i ruoli personalizzati possono limitarne l’accesso a gruppi specifici. Per usare app collegate negli artifact, controllate anche Organization settings > Capabilities > Visuals > Enable artifact connectors. Guida all’amministrazione di Artifacts

2. Collegate i dati che userete davvero

Aprite Customize > Connectors, selezionate +, cercate il servizio e controllate le funzionalità disponibili. Scegliete quindi Connect o Install e completate l’autenticazione. Su Team ed Enterprise, il proprietario deve prima rendere disponibile il connettore da Organization settings > Connectors > Browse connectors > Add to your team. Gli utenti si autenticano in seguito, salvo che l’organizzazione usi l’autenticazione gestita. Per abilitare il servizio nella conversazione, usate + > Connectors. Configurazione dei connettori

Per un data warehouse, coinvolgete chi gestisce la connessione e i permessi sulle tabelle. La guida a Dashboards elenca le piattaforme, ma non prevede un unico modulo universale per le credenziali dei warehouse. Seguite i requisiti del connettore scelto. Per il primo progetto pilota, consiglio l’accesso a una sola tabella approvata per la reportistica, oppure a una vista che presenti una query salvata come tabella, con i soli permessi necessari alla lettura.

3. Formulate una domanda utile all’azienda

Aprite Artifacts, scegliete un modello Dashboards e descrivete la domanda. Potete anche scriverla in chat o selezionare Output > Dashboards. Specificate la tabella o l’app, la definizione della metrica e il periodo. Affinate il risultato nella conversazione, poi aprite l’SQL del grafico e correggete eventuali discrepanze. Creare e affinare una dashboard

4. Verificate che cosa vede il destinatario prima di ampliare la condivisione

Aprite Share e controllate le opzioni disponibili per destinatari e accesso. Gli artifact condivisi richiedono un account Claude. Le parti collegate alle fonti usano le connessioni di chi le visualizza; senza accesso alla fonte compare un errore. Gli artifact collegati ad app non possono usare Anyone with the link, e gli utenti esterni invitati via email non possono usare le parti che dipendono da Claude o dai vostri connettori. Regole di condivisione degli artifact

Per una dashboard aziendale, iniziate condividendola con uno dei colleghi a cui è destinata e chiedetegli di confermare ciò che vede. Il fatto che funzioni nel vostro account non dimostra che funzioni anche nel suo.

Un esempio pratico: il valore delle opportunità vinte per regione

Chi segue le attività operative di una piccola azienda software vuole capire quali regioni abbiano contribuito alle vendite acquisite nel trimestre precedente. Usate il valore delle opportunità chiuse come vinte, cioè delle trattative contrassegnate come vinte, senza chiamarlo ricavo contabile. Un contratto firmato, una fattura e un ricavo contabilizzato misurano cose diverse.

Per questo esempio, supponiamo che BigQuery contenga una tabella chiamata crm.opportunities, con una riga per opportunità, un campo is_won impostato su true o false, un campo region, un campo amount_usd convertito su una base comune in dollari e un campo closed_date memorizzato come data nel fuso orario aziendale concordato. Nomi dei campi e ipotesi sono esemplificativi: non si tratta di uno schema di Anthropic.

La domanda da scrivere

Questo prompt fissa metrica, fonte, valuta e limiti temporali. Chiede anche di esplicitare i casi problematici che un grafico ben presentato può nascondere.

La query da controllare

Aprite la query generata. Con queste ipotesi, la logica essenziale dovrebbe somigliare al seguente SQL BigQuery esemplificativo, che non è stato eseguito su un dataset reale:

SELECT region, SUM(amount_usd) AS closed_won_usd
FROM `crm.opportunities`
WHERE is_won = TRUE
  AND closed_date >= DATE '2026-07-01'
  AND closed_date < DATE '2026-10-01'
GROUP BY region
ORDER BY closed_won_usd DESC;

La query seleziona le trattative vinte, limita le date di chiusura al trimestre e somma i valori in dollari per regione. Il limite superiore esclusivo lascia fuori il 1 ottobre. Non contiene join, quindi nessuna tabella aggiuntiva moltiplica le righe; eventuali duplicati già presenti nella fonte possono comunque gonfiare la somma.

Non usatela senza modifiche se il warehouse conserva lo storico delle opportunità, più righe di dettaglio per trattativa o timestamp al posto delle date. Chiedete prima al responsabile dei dati di stabilire quali record e quali regole temporali usare. Una query SQL può essere eseguita correttamente e rispondere comunque alla domanda sbagliata.

Le verifiche da fare prima di condividere

• Contate ogni opportunità una sola volta. Verificate che nella fonte ci sia una sola riga per opportunità. Controllate alcuni ID delle trattative e riconciliate il totale complessivo con il report CRM di riferimento, applicando gli stessi filtri.
• Usate le date previste. Esaminate le trattative vicine ai confini del trimestre. Confermate che il criterio voluto sia la data di chiusura, non quella di creazione o di fatturazione.
• Adottate una definizione univoca della valuta. Verificate come viene prodotto amount_usd. SUM ignora gli importi null, cioè i valori mancanti: indagateli e decidete anche come visualizzare le regioni mancanti.
• Controllate l’aggiornamento a entrambe le estremità. Leggete la data dell’ultimo aggiornamento di ogni grafico e verificate quando il warehouse ha ricevuto le ultime modifiche dal CRM. Una query appena eseguita su una tabella non aggiornata restituisce comunque dati vecchi.
• Verificate accesso e significato. Chiedete a un collega di aprire la dashboard condivisa con la propria connessione. Includete la definizione della metrica e le eventuali esclusioni, perché un totale delle vendite non venga riutilizzato come ricavo contabile.

Se i totali non coincidono, risolvete la discrepanza prima di aggiungere altri grafici. Tra le domande utili da fare in seguito: “Quali record spiegano la differenza?” e “La fonte contiene versioni storiche della stessa opportunità?”. La prima dashboard si guadagna fiducia facendo tornare i conti, non con l’aspetto.

Sei impieghi utili, in ordine di beneficio potenziale

Queste proposte presuppongono che i campi necessari siano già disponibili in una fonte collegata. Non sono risultati ottenuti da clienti né affermazioni sul supporto di ulteriori connettori.

Il primo caso da affrontare dovrebbe avere una fonte chiara, un totale noto con cui confrontarsi e una persona responsabile della definizione. Una richiesta generica come “mostrami lo stato di salute dell’azienda” non offre nessuno di questi vantaggi.

Come affiancarlo a Looker Studio, Metabase e Power BI

Consiglio di usare Claude per le domande che stanno ancora prendendo forma. Mantenete uno strumento BI quando il report richiede un modello stabile, una distribuzione gestita nel tempo o controlli espliciti sull’aggiornamento.

Questo confronto riguarda i flussi di lavoro: non afferma che Claude esporti direttamente verso questi tre prodotti. Per una selezione più ampia di strumenti di reportistica, consultate le alternative a Databox.

Quali problemi restano da risolvere al team?

Una metrica ambigua non diventa da sola una definizione aziendale condivisa. È la mia valutazione pratica di questo flusso di lavoro: “ricavo”, “cliente attivo” e “ticket risolto” richiedono un responsabile che stabilisca cosa includere. E disegnare un grafico non ripara i dati mancanti a monte.

Una connessione attiva non garantisce dati aggiornati. L’annuncio descrive dashboard che restano aggiornate, ma la guida introduttiva non specifica un intervallo di aggiornamento. Non indica nemmeno limiti per dashboard, grafici o righe. Sono dettagli non pubblicati, da non interpretare come capacità illimitata. Né l’annuncio né la guida pubblicano risultati sull’accuratezza di Dashboards. Annuncio, guida introduttiva

La dashboard non può concedere accessi alla fonte che il connettore non possiede. Le connessioni ordinarie ereditano i permessi dell’utente; una credenziale condivisa, invece, porta con sé i propri permessi di accesso. Verificate quale modalità usa la vostra connessione. Permessi dei connettori

Per gli impegni contrattuali sull’aggiornamento dei dati, la reportistica sottoposta ad audit e le definizioni complesse di metriche condivise, continuerei a usare un sistema che il team gestisce già per quei requisiti. Provate prima la beta su una domanda interna ben circoscritta. L’SQL visibile aiuta a verificare il lavoro; non certifica la risposta.

Due proposte da sviluppare attorno a Dashboards

Le opportunità riguardano servizi e materiali di supporto. La guida introduttiva non documenta un’API per sviluppatori dedicata alla funzione Dashboards, quindi nessuna delle proposte ne presuppone l’esistenza.

La proposta più solida: configurare e validare una metrica di vendita

Una piccola azienda potrebbe pagare uno specialista per trasformare una domanda poco chiara sulle vendite in una metrica documentata, una vista approvata nel warehouse, una dashboard Claude e una checklist di riconciliazione.

I dati DataForSEO per le ricerche in inglese negli Stati Uniti, recuperati il 10 ottobre 2026, stimano 1,000 ricerche mensili per “sales dashboard”. Indicano interesse per l’attività di reportistica, non una domanda dimostrata per questo servizio. La risposta relativa ai suggerimenti segnala un calo annuo del 32%: non è quindi una prova di mercato in crescita.

L’incarico minimo vendibile comprende una metrica di vendita, un report noto con cui confrontarla, la configurazione della connessione e il passaggio di consegne alla persona responsabile del dato. Il problema è che la pulizia della fonte potrebbe assorbire gran parte del lavoro: definite per questa attività un perimetro separato. È l’opportunità più solida perché ciò che ha valore è un dato concordato e verificato, un risultato che un generatore generico di grafici non può fornire da solo.

La seconda proposta: un kit per verificare le dashboard

Un consulente potrebbe creare un kit riutilizzabile per chi svolge il lavoro operativo: schede per definire le metriche, esempi di prompt, domande per il controllo delle query e una checklist di accettazione per la condivisione. Prima di provare a vendere un prodotto autonomo, offrite una prima verifica assistita.

La stessa rilevazione DataForSEO stima 140 ricerche mensili negli Stati Uniti per “ai dashboard generator”. Tra le ricerche correlate compare “Ai dashboard generator free”, un segnale di sensibilità al prezzo. La risposta relativa ai suggerimenti riporta un calo annuo del 47%. Sono segnali modesti, che giustificano un piccolo esperimento più che un grande investimento software.

Il kit iniziale potrebbe comprendere l’esempio sulle vendite e uno sui ticket di assistenza arretrati, con ipotesi sui dati dichiarate chiaramente. I punti deboli sono la facilità di imitazione e le alternative gratuite. Per giustificare l’acquisto servirebbero definizioni specifiche per settore e un lavoro di verifica accurato. Per organizzare istruzioni riutilizzabili per la reportistica, consultate Claude Skills per i report settimanali ai clienti.

Da dove partire lunedì

Scegliete la persona che oggi esporta il report vendite settimanale e affiancatele il responsabile della tabella di origine. Create soltanto la vista delle opportunità vinte, confrontate i totali, controllate data e ora dell’ultimo aggiornamento e apritela dall’account del collega a cui è destinata. Registrate tutto il tempo impiegato, correzioni comprese. Ampliate il progetto solo se il pilota semplifica quel lavoro di reportistica mantenendo chiara la definizione del dato.

Per costruire un flusso di reportistica verificato attorno ai vostri dati, possiamo aiutarvi con l’automazione AI.