CRM su misura: comprare, configurare o costruire con Accordo

In breve. Quando il processo commerciale non entra in un CRM standard, restano tre strade: piegare una piattaforma, generare tutto da zero, o costruire con Accordo — partire dai primitivi CRM e lasciare che l'agente li modelli sul processo, in un repository tuo. La tesi di questa pagina, ed è interpretazione mia: la terza via conviene quando il processo è il prodotto, cioè quando rinominarlo per farlo entrare nei campi standard costerebbe più che scriverlo. Con solution, esempi e limiti. Pubblicato il 6 ottobre 2026.

Le tre strade

La prima strada è configurare un CRM: veloce quando il processo ci entra. Usane uno quando ti serve un prodotto ospitato subito, domani mattina. La terza è generare da zero: libertà massima, ma il team deve riderivare policy, audit e verifica da solo.

La seconda — la terza via — è costruire con Accordo: partire dai primitivi CRM e lasciare che l'agente li modelli intorno al processo, in un repository che controlli. Una frase di intento di business diventa policy versionata nel repository, e il CRM che il team apre obbedisce a quella policy. Il confronto tra i tre percorsi, con i tradeoff, è nella pagina di comparazione di Accordo: leggila prima di scegliere, perché ogni strada ha un prezzo scritto.

Quando il custom conviene

Il segnale è preciso, ed è scritto nella solution: quando un CRM standard costringe il team a rinominare o aggirare il modo in cui vende davvero. Per founder, product leader o agenzie con un processo commerciale non standard, piegare la piattaforma significa nascondere il processo nei metadati — e ritrovarlo il giorno dell'audit, o il giorno in cui un'eccezione rompe il flusso.

Il flusso di lavoro è: brief, ispezione della composizione, piano verificato, generazione di modulo, servizio, API e Admin, verifica di progetto. Il risultato è un modello operativo posseduto nel codice, con record, azioni, decisioni ed evidence espliciti: stato, policy, decisioni umane ed evidence diventano parte del sorgente dell'applicazione.

Due esempi di come si costruisce

Il primo esempio è design-to-CRM dal manifest: scrivi un manifest dichiarativo del modulo — nome, descrizione, campi — e l'agente lo trasforma in migrazione, servizio, risorsa REST, metodo SDK e schermate Admin, senza scrivere codice di pagina. Con il limite dichiarato: oggi CRUD generato, mentre workflow e approvazioni per oggetti custom restano scritti a mano.

Il secondo è package ed estensioni esplicite: i domini opzionali vivono su un contratto pubblico di package, con dipendenze, capability e policy dichiarate. Personalizzare non significa forkare il motore: un package scritto dal cliente si attacca e si stacca con l'impronta del nucleo invariata.

Cosa resta vero anche qui

Tutto il cluster poggia sulla stessa disciplina del pillar sull'autonomia sotto controllo: agenti che propongono, policy deterministica che governa, umani nominati che decidono, audit su ogni verdetto. Il custom non è un'eccezione ai controlli: è il posto dove i controlli si vedono meglio, perché ogni regola vive nel tuo repository, versionata, con la storia che non si riscrive.

E valgono gli stessi confini: niente marketing automation eseguita, niente Interactions, niente prontezza generale dichiarata. La solution Custom CRM lo scrive chiaro: la verità di implementazione sta nel registro dei claim generato dalla suite di test, non nella descrizione di prodotto. Se trovi un claim che i test non supportano, è un bug: si toglie il claim o si aggiunge il test. E se a valutare è un coding agent, la pagina per gli agenti AI gli ordina di ispezionare l'applicazione prima di proporre: niente capability senza evidence nel repository.

Fatti e limiti, separati

Fatti: tre percorsi documentati con tradeoff; flusso brief-ispezione-piano-generazione-verifica; manifest che genera migrazione, servizio, REST, SDK e Admin; contratto pubblico di package con dipendenze e policy; registro claim legato alla suite (2413 test, 0 falliti, misurati il 29 settembre 2026).

Limiti: CRUD generato, workflow e approvazioni custom ancora scritti a mano; pipeline di design solo disegnata, non implementata; branding, navigazione e layout dichiarativi non supportati; nessuna pretesa di production-readiness. Tre percorsi e due esempi non misurano quanto il disegno regga in produzione: misurano che esiste, gira e dichiara i suoi confini.

Domande frequenti

Quando conviene un CRM su misura?

Quando il processo commerciale non entra nei campi standard senza rinominarlo o aggirarlo: il processo è il prodotto, e nasconderlo nei metadati della piattaforma costa più che scriverlo in un repository tuo.

Cosa significa costruire con Accordo?

Partire dai primitivi CRM e lasciare che un coding agent li modelli sul processo: brief, ispezione, piano verificato, generazione di modulo, servizio, API e Admin, verifica. Il risultato è codice tuo, revisionabile, nel tuo repository.

Cosa resta scritto a mano?

Workflow e approvazioni per oggetti custom, oggi: il generato copre il CRUD. E la pipeline di design — token, navigazione, layout da riferimento grafico — è disegnata ma non implementata.

Come verifico cosa è vero e cosa è roadmap?

Nel registro dei claim generato dalla suite di test, non nelle pagine di prodotto: ogni affermazione è legata a prove o marcata come limite. Se un claim non è supportato dai test, è un bug da segnalare.