✹ DolceBot ✹
Progettazione di una piattaforma interna per la gestione di lead, trattative e onboarding di immobili in affitto breve.
✹ Contesto ✹
DolceBot è una startup di property management per affitti brevi: prende in gestione l'immobile di un proprietario e ne segue l'intero ciclo — contratti, adempimenti normativi, gestione operativa. Ogni immobile è un'entità con decine di dati collegati: fatturazione, codice identificativo nazionale, credenziali AlloggiatiWeb per la Questura, credenziali ISTAT e comunali, modalità d'accesso, dotazioni di sicurezza, regolamento casa.
✹ La sfida ✹
Il team lavorava su HubSpot: efficace su contatti e trattative, non pensato per i dati normativi e operativi di un immobile. Tutto ciò che non entrava nel CRM finiva in fogli Excel scollegati dalla trattativa a cui appartenevano. Ricostruire lo stato di un immobile significava aprire più file senza la certezza che fossero aggiornati, e lì un errore non era solo scomodo: un CIN sbagliato o una credenziale mancante poteva bloccare la pubblicazione di un annuncio o trasformarsi in una sanzione.
✹ Il mio ruolo ✹
Ownership completa del design della piattaforma interna: discovery, architettura dell'informazione, user flow, UI e test con utenti reali prima del lancio. Ho lavorato a stretto contatto con founder, CIO e CEO sul modello dei dati, e con account e facility manager sul lavoro quotidiano che la piattaforma doveva sostituire.
✹ Il processo ✹
01 — Discovery: ricostruire il ciclo di vita dell'immobile
Sono partito dal processo reale, non da una lista di funzionalità. Con il team ho ricostruito il ciclo Lead → Trattativa → Raccolta dati (su tre livelli: contrattuale, pre-onboarding, onboarding) e ho isolato ciò che HubSpot non poteva tracciare: tutti i dati legati all'immobile. Il CRM seguiva bene il contatto e la trattativa, ma i dati dell'immobile — l'entità centrale del business, con le sue decine di dati contrattuali, normativi e operativi — non avevano un posto dove vivere, e finivano sparsi in fogli Excel. Da qui è emerso il vincolo che ha orientato tutto il progetto: chi possiede il dato non è chi lo deve inserire. Le informazioni le ha il proprietario; l'operatore le rincorreva a voce o via email, ed era esattamente ciò che generava il caos.
02 — Gli insight che hanno guidato il progetto
I dati erano sparsi, e tenerli aggiornati era scomodo
Ogni informazione sull'immobile viveva in un file diverso, scollegato dalla trattativa. Non c'era un posto unico dove inserirla, ritrovarla o aggiornarla, e nessuna garanzia che l'ultima versione fosse quella giusta.
“Ogni volta che mi serviva un'informazione su un immobile aprivo tre file diversi, e non ero mai sicuro che fossero aggiornati.”
— Account Manager, DolceBot
Chi ha il dato non è chi lo inserisce
I dati li possedeva solo il proprietario; l'operatore passava mezza giornata a rincorrerli via mail e poi a ricopiarli a mano nei fogli Excel.
“Passavo un sacco di tempo a scrivere mail ai proprietari per farmi mandare le credenziali o il CIN, e poi a ricopiarle a mano.”
— Facility Manager, DolceBot
03 — Architettura dell'informazione e user flow
Si tratta della fase su cui ho iterato maggiormente. In questo frangente, attraverso un'attenta analisi, si è deciso di optare per la soluzione dei questionari, definendo l'architettura dell'informazione del CRM e mappando la distribuzione dei dati, la sequenzialità, i vincoli di obbligatorietà e la logica dei percorsi condizionali. Questo lavoro è stato condotto attraverso sessioni di co-progettazione ripetute con il CIO e il CEO, poiché l'intervento impattava direttamente sia sul modello operativo che su quello di conformità normativa dell'azienda. Una volta stabilita l'architettura di fondo, ho disegnato i relativi user flow per ciascun questionario mappando punti d'ingresso, bivi decisionali e i circuiti di gestione degli errori sui campi obbligatori, garantendo così che l'interfaccia venisse progettata su una logica strutturale già validata.
User flow — questionario contrattuale.
04 — Design dell'interfaccia e Design System Shadcn (Devias Kit Pro)
Ho disegnato le varie sezioni del CRM e i flussi dei tre questionari utilizzando il design system di shadcn (Devias Kit Pro), già condiviso con gli sviluppatori: invece di costruire un design system da zero ho riusato quello che il team stava già usando in codice, creando solo le variabili colore del brand DolceBot per allineare i componenti alla sua brand identity. Scelta consapevole: rinunciare a un design system proprietario in cambio di velocità di messa in produzione e di un allineamento diretto con lo sviluppo, dato che design e codice partivano dagli stessi componenti. Per una startup che aveva bisogno di uno strumento in uso, non di una vetrina, era il trade-off giusto.
Design System Shadcn — Devias Kit Pro — Components.
05 — Test con utenti reali
Prima del lancio ho fatto testare i questionari a proprietari veri, non a colleghi. È lì che ho visto quali termini normativi bloccavano le persone, dove si fermavano e quando «Salva ed esci» diventava una via di fuga necessaria. I test hanno cambiato microcopy e ordine dei passaggi.
✹ La soluzione ✹
Il CRM
Il gestionale del team è organizzato in sezioni (Overview, Lead, Trattative, Account Manager), con il cuore operativo in due sezioni collegate: Lead e Trattative. In Lead l'account manager aggiunge e gestisce i contatti dei proprietari; a una stessa lead si possono associare più trattative, una per ogni immobile che il proprietario affida in gestione. La trattativa di un immobile si chiude quando l'onboarding è completato. Nella pagina relativa ad ogni singola trattativa il team trova la scheda trattativa: in testa i dati essenziali (lead, località, tipologia di contratto, facility manager, commissioni) e sotto tre schede — contrattuale, pre-onboarding e onboarding — che raccolgono tutto ciò che prima viveva in Excel. Da lì il team vede a colpo d'occhio a che punto è l'immobile, quali dati mancano e in quale stato di avanzamento si trova.
Progettazione della sezione Trattative su Figma.
Le sezioni Lead e Trattative: a ogni lead si legano più trattative e ogni trattativa avanza per stati, dalla creazione all'onboarding dell'immobile.
I questionari
I dati non li inserisce il team: li raccoglie il proprietario attraverso tre questionari progressivi, inviati dalla scheda trattativa e scanditi dai suoi stati di avanzamento. È l'operatore DolceBot ad avviare il flusso, mandando il primo questionario, il contrattuale; i due successivi partono in automatico man mano che il proprietario completa il precedente e l'operatore ne verifica i dati. Ogni risposta riporta i dati nella scheda corrispondente. Li ho pensati come tappe a carico crescente, ciascuna con un obiettivo chiaro.
Step 1 — Questionario contrattuale
5 passaggi essenziali: fatturazione, informazioni immobile, CIN, autorizzazioni, riepilogo. È il questionario che permette al proprietario di compilare tutti i dati necessari al contratto: da questi il documento si genera in automatico grazie all'integrazione con PandaDoc, scelto perché produce il contratto dai dati appena raccolti e ne gestisce la firma digitale senza scambi manuali di documenti. All'operatore DolceBot resta solo revisionarlo e inviarlo al proprietario per la firma.
Progettazione del flusso del questionario contrattuale su Figma.
Alcuni passaggi del questionario contrattuale: dati di fatturazione, informazioni immobile, codice identificativo nazionale.
Step 2 — Questionario di pre-onboarding
11 passaggi che raccolgono gli adempimenti normativi e le informazioni d'accesso necessari a mettere l'immobile in regola e in condizione di operare. Qui il proprietario inserisce le credenziali per AlloggiatiWeb (la comunicazione degli ospiti alla Questura), quelle per ISTAT e per il comune, il referente operativo della struttura, le modalità d'accesso, le foto, le dotazioni di sicurezza, la gestione delle pulizie e i prezzi. Sono dati che solo lui possiede e che, se mancanti o sbagliati, bloccano la messa a reddito o espongono a sanzioni.
Alcuni passaggi del questionario di pre-onboarding: credenziali comunali per le tasse di soggiorno, foto dell'immobile, gestione dei prezzi.
Step 3 — Questionario di onboarding
8 passaggi che raccolgono la descrizione fisica dell'immobile e le regole per gli ospiti. Qui il proprietario inserisce le caratteristiche della struttura, i servizi dell'edificio, il parcheggio, il regolamento interno, le informazioni sul quartiere, le modalità d'accesso e le indicazioni per le emergenze: sono tutti i dati che servono per pubblicare l'immobile sui principali portali di affitti brevi come Airbnb e Booking.
Alcuni passaggi del questionario di onboarding: regolamento casa, servizi interni unità, caratteristiche dell'immobile.
✹ Impatto della soluzione ✹
-40%
Tempo di onboarding di un immobile.
-25%
Errori di inserimento dati.
✹ Cosa ho imparato ✹
Ho imparato che per una startup come DolceBot contava molto di più far risparmiare tempo e gestire tutto in un'unica piattaforma con dati interconnessi che avere un'interfaccia impeccabile. Il valore non stava nell'estetica ma nel togliere lavoro manuale: un dato inserito una volta, alla fonte, e disponibile ovunque servisse. È per questo che ho speso le ore sul modello dei dati e sui flussi invece che sul ridisegno dei componenti, e che riusare il design system di shadcn è stata una scelta consapevole, non una rinuncia.