# Automazione preventivi con AI: comprare un software pronto o costruire su misura?

[Pagina originale](https://danilolapegna.com/guides/automazione-preventivi-ai-build-vs-buy.html)

Lingua: it. Aggiornamento del contenuto: 2026-10-16.

Build vs buy per automatizzare i preventivi in una PMI con l'AI. Quando conviene un software pronto, quando una soluzione su misura, quando aspettare.

Prima di scegliere un prodotto per i preventivi, stima quanto tempo potresti risparmiare e quanti errori potresti evitare, poi confronta questi benefici con il costo del cambiamento. Confronta le funzioni che hai già, un prodotto pronto, un'integrazione mirata e un sistema su misura.

Parti da cinque richieste reali, private dei dati riservati: una standard, una con sconto speciale, una senza variante prodotto, una con listino aggiornato e una di un cliente non riconosciuto. Sono il materiale con cui confrontare le alternative, anche prima di chiedere un preventivo.

Questa guida riguarda la scelta d'acquisto. Per capire come progettare il flusso completo, leggi la [guida all'automazione dei preventivi](https://danilolapegna.com/guides/automazione-preventivi-ai-pmi.html).

## Le quattro strade possibili

**Usare meglio ciò che hai.** Il gestionale potrebbe già avere modelli, regole di sconto o importazioni che eliminano una parte del lavoro. Chiedi di vedere quelle funzioni sui tuoi cinque casi: il costo può essere inferiore a quello di aggiungere un nuovo sistema.

**Comprare un prodotto pronto.** I software per configurare prodotti compatibili, applicare prezzi e preparare offerte vengono spesso chiamati CPQ. Alcuni includono funzioni AI per leggere richieste e allegati. Il prodotto va provato sul tuo processo, con le integrazioni e il piano commerciale che compreresti davvero.

**Aggiungere un'integrazione o costruire su misura.** Un collegamento può bastare quando il prodotto funziona bene ma manca il passaggio verso il gestionale. Lo sviluppo più ampio ha senso quando restano scoperte regole importanti e il beneficio giustifica costruzione e gestione.

**Aspettare, risolvendo prima un problema preciso.** Se i reparti usano listini discordanti o nessuno sa chi possa approvare uno sconto, serve una decisione organizzativa. Puoi automatizzare una parte stabile senza incorporare nel software il disaccordo.

## La demo da chiedere a ogni candidato

Immagina un catalogo stabile con richieste che arrivano via email libera. Questo, da solo, non decide fra acquisto e sviluppo: [Microsoft documenta un prodotto](https://learn.microsoft.com/en-us/dynamics365/business-central/faqs-sales-order-taker-agent) capace di leggere email e allegati, verificare disponibilità e preparare preventivi con revisione umana. Disponibilità, limiti e adeguatezza vanno verificati sul servizio e sul caso concreto.

Presenta a ciascun candidato le stesse cinque richieste. Fai mostrare il percorso completo, dalla ricezione alla bozza nel gestionale, indicando che cosa è configurato, che cosa richiede lavoro manuale e che cosa dovrebbe ancora essere sviluppato.

| Caso | Esito da verificare |
|---|---|
| Richiesta standard | Prodotti, quantità e prezzi corretti; fonte del listino riconoscibile |
| Sconto speciale | Applicazione della regola autorizzata oppure richiesta di approvazione |
| Variante mancante | Domanda di chiarimento, senza scelta inventata |
| Listino aggiornato | Uso della versione valida, con data identificabile |
| Cliente non riconosciuto | Gestione esplicita dell'incertezza, senza attribuire condizioni di un altro cliente |

Per esempio, una richiesta di venti pezzi senza variante deve fermarsi prima del prezzo definitivo. Un prodotto che prepara una bozza elegante ma indovina la variante non ha superato quella prova. Un prodotto che chiede il chiarimento può aver gestito correttamente il caso, anche se la demo sembra meno spettacolare.

Decidi in anticipo quali errori impediscono l'invio: prodotto sbagliato, prezzo non autorizzato, dati di un altro cliente. Durante la prova conserva l'approvazione umana prima di ogni invio. Se un candidato non consente di provare un requisito essenziale, segnalalo come non verificato; non trasformare una promessa commerciale in un risultato.

## Confrontare il costo completo

| Voce | Prodotto pronto | Integrazione o su misura |
|---|---|---|
| Avvio | Configurazione, migrazione, formazione | Analisi, sviluppo, prove e formazione |
| Esercizio | Abbonamento, consumi ed eventuali componenti aggiuntivi | Hosting, consumi, manutenzione e supporto |
| Gestionale | Verificare connettori, accessi e funzioni effettivamente disponibili | Verificare le stesse possibilità: lo sviluppo non crea accessi che il gestionale non offre |
| Lavoro residuo | Eccezioni e correzioni che restano al personale | Eccezioni, correzioni e gestione delle modifiche |
| Uscita | Esportazione dati, costi e tempi per cambiare prodotto | Consegna codice, documentazione, credenziali e possibilità di affidare la manutenzione ad altri |

Scegli lo stesso periodo di confronto, per esempio dodici mesi, e somma queste voci. Le ore liberate sono capacità recuperata; diventano un risparmio monetario soltanto se una spesa diminuisce. Se mantieni il processo attuale non hai un nuovo investimento, ma continui a sostenerne tempi ed errori.

Il su misura non garantisce indipendenza dal fornitore. Codice, dati e istruzioni di gestione devono essere consegnabili e utilizzabili da qualcun altro. Chiedi una prova di esportazione e una procedura di ripristino: sono più informative della parola «proprietario» su una proposta.

## Come leggere il risultato della prova

- Se il prodotto copre i casi importanti e il costo complessivo è sostenibile, l'acquisto è una strada concreta.
- Se funziona ma manca un solo collegamento, valuta prima un'integrazione circoscritta.
- Se rimangono scoperte regole essenziali e stabili, verifica il su misura su quella parte, con una prima prova delimitata.
- Se le regole sono ancora contraddittorie o il beneficio non copre il costo, chiarisci il processo o rimanda l'investimento.

Il criterio che userei è questo: **comprare ciò che funziona già e costruire soltanto la differenza che conta.** Un catalogo particolare non obbliga a riscrivere tutto; allo stesso modo, una funzione presente in una brochure non basta a dimostrare che copra le tue eccezioni.

## Il prossimo passo

Per ogni alternativa conserva una scheda con esiti dei cinque casi, interventi manuali, costo completo e informazioni mancanti. Se una risposta è incerta, chiedi una prova mirata prima di ampliare il progetto.

Se vuoi un confronto indipendente, porta questa scheda alla [Diagnosi AI e automazione](https://danilolapegna.com/services/diagnosi-ai-automazione). Il lavoro parte dalle differenze emerse, non dall'idea che serva necessariamente un software nuovo.

## Domande frequenti

### Conviene comprare un software pronto o costruire su misura per automatizzare i preventivi?

Confronta le alternative sugli stessi casi. Compra se il prodotto copre i requisiti importanti; valuta un'integrazione se manca un collegamento; considera il su misura per regole essenziali ancora scoperte. Se le regole non sono concordate, chiariscile prima.

### L'AI può leggere richieste di preventivo scritte in email libere?

Sì, anche prodotti pronti possono leggere email e allegati. Provali sulle tue richieste: il su misura è giustificato dai requisiti importanti che restano scoperti, non dal semplice uso del testo libero.

### Come si decide senza sbagliare tra build, buy e aspettare?

Prova cinque richieste rappresentative: standard, sconto speciale, variante mancante, listino aggiornato e cliente sconosciuto. Confronta esiti, correzioni manuali e costo completo; lascia esplicito ciò che non hai verificato.