Il primo resoconto pubblico del cantiere REMAXIMIZE. Caso studio operativo: una realtà immobiliare presente tra le province di Belluno e Treviso.
In questo resoconto
- Da quali problemi organizzativi siamo partiti
- Il confine fra il gestionale degli immobili e il CRM delle relazioni
- Che cosa è stato costruito in sette giorni, con lo stato di ogni funzione
- Come abbiamo reso il sistema più solido
- Che cosa verificheremo nei prossimi 30 giorni
In un’agenzia immobiliare le informazioni non mancano. Mancano i passaggi.
Una richiesta arriva da un portale e resta in una casella email. Una visita si fa, ma nessuno annota perché il cliente ha detto no. Un proprietario chiede una valutazione e la richiesta aspetta che qualcuno se ne ricordi. Quando una persona è assente, una parte del lavoro si ferma con lei.
Da qui è partito il cantiere di SESTANTE, il CRM operativo del progetto REMAXIMIZE. Non da un elenco di funzioni, ma da sei problemi concreti: richieste disperse, tempi di risposta non visibili, visite senza feedback, follow-up dimenticati, dati immobiliari incoerenti e perdita di continuità fra persone e sedi. È l’approccio che descriviamo nel metodo REMAXIMIZE.
Il cantiere viene sperimentato in REMAX Casamia, realtà con tre agenzie operative a Belluno, Treviso e Valdobbiadene e un Info Point a Lamon. È il caso studio operativo, non il promotore del progetto. REMAXIMIZE è un progetto indipendente: Zoho è la tecnologia che usiamo oggi per costruire e provare SESTANTE, non un partner.
Come leggere gli stati. Ogni funzione porta un solo stato: PROGETTATO, IN COSTRUZIONE, IN TEST, IMPLEMENTATO o MISURATO. In questa prima settimana nulla è ancora MISURATO. Le definizioni sono nella pagina del Cantiere CRM immobiliare.
Il confine tra immobili e relazioni
La prima decisione non è stata tecnica. Abbiamo stabilito che cosa il CRM non deve fare.
Il gestionale immobiliare dell’agenzia resta la fonte principale dei dati sugli immobili: schede, annunci, pubblicazione sui portali. SESTANTE non lo sostituisce e non lo duplica. Organizza ciò che il gestionale non segue: persone, richieste, attività, esiti e prossime azioni. Così si evitano due archivi concorrenti sullo stesso immobile.
La seconda decisione riguarda il metodo di lavoro. Tutto si costruisce e si prova in una sandbox, un CRM separato dall’ambiente di lavoro quotidiano. Ogni modifica viene provata lì prima di arrivare al lavoro quotidiano delle agenzie.
Che cosa abbiamo costruito
In sette giorni la sandbox ha ricevuto utenti, dati e le prime regole di lavoro. Dieci utenti con ruoli distinti partecipano alla prima configurazione e ai test; le licenze Zoho One oggi disponibili in prova sono dodici. Il quadro aggiornato delle componenti è anche nella pagina Cosa stiamo costruendo.
| Funzione | Stato | Prossima verifica |
|---|---|---|
| 10 utenti con ruoli distinti (Broker, responsabili di sede, consulenti, segreterie) | IN TEST | Permessi di ogni ruolo provati su casi reali |
| Circa 310 immobili e 230 proprietari importati dal gestionale | IMPLEMENTATO VIA FILE | Correzione alla fonte dei dati incoerenti |
| Integrazione diretta con il gestionale tramite API | PROGETTATO | Verifica di fattibilità tecnica |
| Oltre mille richieste recenti dai portali | IN TEST — VOLUME DA CONFERMARE | Conteggio verificato portale per portale |
| Lettura delle email ogni cinque minuti su tre caselle | IN TEST | Nessuna richiesta persa nel passaggio |
| Attivazione della quarta casella | IN COSTRUZIONE | Prima settimana di lettura regolare |
| Regole di assegnazione | IN TEST | Controllo dei casi assegnati |
| Cruscotti differenziati per ruolo | IN COSTRUZIONE | Prima versione per ogni ruolo |
| Calcolo del tempo di prima risposta | IN TEST | Confronto con gli orari reali |
| Avvisi e riassegnazione automatica | IN COSTRUZIONE | Soglie approvate dal Broker |
| Registrazione visite ed esiti | IN TEST | Uso quotidiano da parte dei consulenti |
| Motivo di non interesse dopo le visite | IN TEST | Motivi registrati in modo uniforme |
| Storico di circa 1.260 mediazioni | IMPLEMENTATO COME ARCHIVIO | Revisione con le segreterie |
| Risposta dal CRM all’indirizzo reale del cliente | PROGETTATO — FASE 2 | Avvio della fase 2 |
I numeri sono arrotondati e descrivono il materiale di partenza, non risultati commerciali.
Richieste e assegnazioni
Le regole sono poche e dichiarate. Una richiesta su un immobile va al consulente che lo segue. Una richiesta di valutazione, o un’opportunità di vendita, va al Broker. Se l’immobile non viene riconosciuto, la richiesta va alla segreteria, che la smista. L’obiettivo è che nessuna richiesta resti senza un nome accanto.
Cruscotti e tempi di risposta
Ogni ruolo avrà un cruscotto diverso: priorità del giorno, agenda, acquisizione, ribassi, attività da recuperare. Il tempo di prima risposta viene già calcolato, ma è in prova: prima di usarlo per avvisare qualcuno o riassegnare una richiesta deve dimostrarsi affidabile.
Come abbiamo reso il sistema più solido
Sei scelte tecniche nate dalla prova sul campo, ciascuna con il problema che risolve.
Revisione 1
Lettura delle email più robusta
Le email dei portali cambiano formato spesso: un sistema di integrazione standard non basta.
La soluzione: Oggi un piccolo programma nelle caselle di posta passa l’email completa al CRM, che la interpreta.
Revisione 2
Risposte sempre al cliente giusto
Le risposte automatiche non devono mai raggiungere l’indirizzo tecnico del portale al posto del cliente.
La soluzione: La risposta dal CRM all’indirizzo reale del cliente è rimandata alla fase 2 ed è progettata.
Revisione 3
Email ripulite prima dell’invio al CRM
Le email molto lunghe superano i limiti tecnici del passaggio al CRM.
La soluzione: Ora vengono ripulite e accorciate prima di essere trasmesse.
Revisione 4
Controllo leggero delle email già lette
Tenere traccia di tutte le email già lette appesantisce il servizio di posta.
La soluzione: La finestra di controllo è stata ridotta agli ultimi tre giorni.
Revisione 5
Modifiche solo a blocchi completi
Le correzioni parziali possono alterare le scadenze calcolate.
La soluzione: Da allora si sostituiscono blocchi completi e si verificano prima di rilasciarli.
Revisione 6
Qualità dei dati alla fonte
Il CRM rende visibili le incongruenze delle schede immobile importate, invece di nasconderle.
La soluzione: La correzione va fatta alla fonte, nel gestionale.
Il principio
L’automazione non migliora i dati: li mette in movimento. Se un dato è sbagliato all’origine, un sistema automatico lo porta più lontano e più in fretta.
Per questo ogni automatismo nasce in prova, e la qualità dei dati di partenza fa parte del progetto: non è un dettaglio da sistemare dopo.
I prossimi 30 giorni
Sono obiettivi di verifica, non promesse di risultato:
- confermare i volumi delle richieste, portale per portale;
- attivare la quarta casella email e controllare che nessuna richiesta vada persa;
- completare la prima versione dei cruscotti per ciascun ruolo;
- fissare le soglie dei tempi di prima risposta prima di attivare avvisi e riassegnazioni;
- portare tutti gli utenti in sandbox a registrare visite, esiti e motivi di non interesse;
- correggere nel gestionale le schede incoerenti emerse dall’importazione;
- iniziare a raccogliere il tempo di prima risposta: diventerà MISURATO solo dopo settimane di dati.
Il prossimo aggiornamento, fra 15 giorni, riporterà l’avanzamento di ogni funzione. Tutti gli aggiornamenti sono raccolti nel Diario del LAB.
Una domanda, per chi guida un’agenzia: quale passaggio del vostro lavoro dipende ancora dalla memoria di una sola persona? Se volete parlarne, partite da Per le agenzie.