← INDIETRO
Smart Client
2026
CRM AI-native
Italia
L'azienda ci ha chiesto di esplorare cosa potesse fare davvero l'AI per i nostri prodotti. Nello stesso periodo un altro team stava valutando quale CRM acquistare. Ho preso alla lettera entrambe le domande: invece di scrivere una valutazione dei software sul mercato, ne ho progettato e sviluppato uno nostro.
Nessuno dei software acquistabili rispecchiava il modo in cui funzionano davvero i gestionali del nostro dominio: il ciclo di vita del cliente, il modello dei ruoli, le regole di validazione che sappiamo già funzionare. Da lì nasce Smart Client: un CRM per le piccole imprese italiane, costruito su quei pattern, con l'AI integrata nel dominio invece che appiccicata di lato. In 17 giornate di lavoro effettive è passato dal primo schizzo a un prodotto funzionante davanti a utenti reali.
Il mio ruolo: designer e sviluppatore — ricerca, UX, UI, frontend, backend, integrazione AI e il sito di presentazione usato per le sessioni di value proposition. La pubblicazione è stata fatta insieme a uno degli sviluppatori senior dell’azienda, che ha allineato il backend agli standard di sviluppo interni.

La sfida

Le piccole imprese italiane gestiscono le vendite tra un foglio Excel, la casella di posta e la memoria. I CRM disponibili falliscono da due direzioni opposte: piattaforme enterprise ridimensionate male (troppo complesse, pensate in inglese, a listino per postazione) oppure rubriche cresciute male (immediate all'inizio, ingestibili dopo tre mesi). Nessuna delle due è progettata per un'azienda da tre a quindici persone.
Il brief che mi sono dato aveva due parti. Progettare un CRM che si adattasse al modo in cui queste aziende lavorano già — e dimostrarlo invece di raccontarlo. Lo sviluppo assistito dall'AI cambia l'economia di un'esplorazione di design: quella che sarebbe stata una presentazione con un prototipo cliccabile poteva diventare un prodotto funzionante, con autenticazione, database e API reali. Era questa la vera scommessa, ed è il motivo per cui aveva senso portarla in azienda.
Il vincolo che ha guidato ogni decisione: una persona sola, settimane e non mesi, e nessuna scorciatoia che rendesse il risultato inutilizzabile in un test con utenti veri.

Ricerca e discovery

Tredici anni sui gestionali significano non partire da zero. La ricerca serviva a capire cosa fosse trasferibile e cosa no:
  • ● Audit dei pattern dei nostri prodotti
    Ho estratto i pattern di interazione e validazione che funzionano già per le PMI italiane nei nostri gestionali e li ho usati come design system di partenza.
  • ● Analisi competitor
    Benchmark tra HubSpot Free, Pipedrive e Zoho e strumenti italiani come TeamSystem e Danea, per distinguere ciò che le PMI adottano da ciò che abbandonano dopo la prova.
  • ● Modellazione del dominio
    Ho mappato il ciclo di vendita italiano su due modelli espliciti: una macchina a stati del cliente (LEAD → CONTATTO → CLIENTE) e una pipeline separata per le opportunità (Qualifica → Proposta → Negoziazione → Vinta), così che chi è una persona e quale trattativa è aperta restino due domande distinte.
  • ● Spike tecnici prima del design
    Ho prototipato subito le parti rischiose — l’accesso unico, la pipeline drag-and-drop e la possibilità per l’assistente di agire sui dati reali con un passaggio di conferma. Sapere cosa costava poco e cosa costava molto ha permesso di definire lo scope onestamente.

Insight

  • Obiettivo La pipeline è la porta d'ingresso

    Nessuno vuole "un CRM". Vogliono un posto che mostri cosa vale la pena fare questa settimana. La board Kanban doveva essere la schermata d'arrivo, non una scheda dentro una dashboard.

  • Puzzle I cambi di stato sono decisioni, non data entry

    Spostare un cliente da lead a cliente acquisito è un momento di business. Imporre le transizioni valide lato server protegge il modello mentale dell'utente molto meglio di un tooltip che ne spiega la regola.

  • ⚠ L'AI deve proporre, mai agire

    Scrivere bozze, riassumere e suggerire erano benvenuti. Inviare una mail o modificare un record senza conferma è stato bocciato ogni volta che è emerso. L'human-in-the-loop non era una funzione di sicurezza: era la condizione per l'adozione.

  • ⊞ "Cosa faccio oggi?" batte "ecco i tuoi dati"

    L'output più utile non è una dashboard. È un elenco breve e ordinato di cose da fare adesso, ognuna con accanto il motivo — che è una regola di scoring, non una risposta generata.

Idea ed esplorazione

Ho costruito l'MVP prima di chiedere qualsiasi cosa. La prima versione aveva il ciclo di vita del cliente, la pipeline e i preventivi — nessuna AI. L'ho mostrata ai manager che stavano valutando l'acquisto come una build funzionante da usare davvero, e la conversazione è passata immediatamente da "quale compriamo" a "vai avanti, e mettici l'AI dentro". Un prototipo che gira argomenta meglio di una slide che lo descrive.
Ottenuto il via libera, il problema successivo non era più di design: era portare la cosa fuori dal mio portatile. Ho lavorato con uno degli sviluppatori senior dell’azienda, che ha allineato il backend agli standard di sviluppo interni perché potesse essere pubblicato su un server di sviluppo aziendale. È quella collaborazione ad aver trasformato una build che potevo aprire solo io in un prodotto raggiungibile dai colleghi con un link, ed è il motivo per cui i test utente si sono poi svolti su un ambiente realmente pubblicato e non su un prototipo.
Rendere l'AI nativa significava legarla al dominio, non appoggiare una chat sopra il prodotto. Undici tool danno all'assistente accesso reale a clienti, opportunità, attività e preventivi — lettura, creazione e modifica — e ogni scrittura si ferma su una conferma esplicita prima di essere eseguita. La lista delle priorità del giorno sta volutamente fuori dal modello: è un motore di scoring deterministico, perché un ordinamento di cui fidarsi ogni mattina deve essere una regola discutibile, non una generazione opaca.
Design e implementazione sono andati in un unico ciclo, senza passaggio di consegne. Lavorare in git con l'AI come partner di sviluppo significa che uno schizzo può diventare una schermata funzionante nel pomeriggio: l'esplorazione avviene nel medium reale — dati veri, latenze vere, casi limite veri — e non in un prototipo che li nasconde tutti e tre.
PROBLEMS RESEARCH IDEATION TESTING SOLUTION PROBLEMS RESEARCH IDEATION TESTING SOLUTION

Test e iterazione

Abbiamo condotto sessioni con cinque utenti reali del mercato di riferimento, testando due cose insieme. Prima la value proposition, usando un sito di prodotto che ho progettato e sviluppato apposta: si capisce cos'è, per chi è e perché è diverso, senza che nessuno lo spieghi? Poi il prodotto stesso — su una build di staging funzionante, non su un prototipo Figma.
Ogni sessione seguiva lo stesso percorso: creare un cliente, farlo avanzare nella pipeline, generare un preventivo e completare un'attività assistita dall'AI. Le correzioni venivano rilasciate tra una sessione e l'altra: dal commento di un partecipante alla modifica in linea passavano ore, non sprint. È la parte di questo progetto che ha cambiato il mio modo di lavorare: il costo di agire su un feedback si è abbassato al punto che non c'era più motivo di rimandarlo.

Cosa è emerso dai test

  • Il messaggio è arrivato prima del prodotto

    I partecipanti sapevano spiegare cos'era il prodotto e a chi si rivolgeva partendo dal solo sito, senza sollecitazioni: il posizionamento ha retto prima ancora che qualcuno toccasse l'app.

  • La pipeline non ha avuto bisogno di istruzioni

    Tutti i partecipanti hanno spostato la prima card senza che glielo si dicesse. Il modello mentale vicino al foglio di calcolo si è trasferito esattamente come previsto dall'audit dei pattern.

  • La validazione lato server è stata letta come guida, non come attrito

    Quando una transizione di stato non valida veniva bloccata, gli utenti leggevano il messaggio e si correggevano. Nessuno ha provato a forzarla, nessuno ha detto che il software li stesse ostacolando.

  • È il passaggio di conferma a rendere l'AI utilizzabile

    Vedere l'azione proposta prima che venisse eseguita è stato indicato esplicitamente come il motivo per cui avrebbero lasciato l'assistente vicino ai dati dei clienti. L'esecuzione automatica avrebbe bruciato la fiducia che il resto del prodotto si era guadagnato.

Risultati e impatto

Un'esplorazione che doveva finire con una raccomandazione è finita con un prodotto che gli utenti hanno chiesto di comprare.
17
Giornate di lavoro effettive dal primo schizzo al prodotto davanti a utenti reali — design, frontend, backend e integrazione AI
4 / 5
Utenti molto interessati al termine del test — due di loro hanno chiesto spontaneamente di acquistarlo
11
Tool AI legati nativamente al dominio — lettura, creazione e modifica — con ogni scrittura dietro una conferma umana
  • ● 12 aree di prodotto rilasciate
    Clienti, opportunità, pipeline, attività, contatti, comunicazioni, documenti, preventivi, impostazioni, statistiche, AI e messaggistica.
  • ● Due artefatti, una sola finestra temporale
    Il CRM e il sito di prodotto usato per testare la value proposition sono stati progettati e rilasciati negli stessi 17 giorni.
  • ● Forma da produzione, non da demo
    Interfaccia bilingue con cambio a runtime, visibilità per ruolo su tre profili e un contratto documentato tra front end e back end, non un collegamento cablato da demo.
Il punto di questo progetto non è il software. È che la distanza tra una decisione di design e la prova che quella decisione funzioni si è ridotta quasi a zero. Lavorando in git con l'AI come partner di sviluppo ho potuto mettere un prodotto vero davanti a utenti veri nel tempo che di solito richiede la sola discovery, e rispondere alla domanda sull'acquisto con un test invece che con un'opinione. È questo che porto dentro tredici anni di prodotti complessi: il giudizio su cosa costruire resta lo stesso, ma il costo di scoprire se avevo ragione è cambiato.