Schema CRM leggero per piccoli team che resta semplice

Quale problema dovrebbe risolvere questo schema CRM

Un piccolo team ha bisogno di un CRM che risponda rapidamente alle domande di tutti i giorni: con chi stiamo parlando, cosa stiamo cercando di chiudere, cosa è successo per ultimo e cosa succede dopo. Questo è il vero compito di uno schema CRM leggero. Tutto ciò che non supporta queste domande è solitamente rumore.

I piccoli team raramente hanno bisogno di gerarchie di account complesse, decine di oggetti personalizzati o modelli di scoring complicati. Hanno invece bisogno di una proprietà chiara, di una storia semplice dei touchpoint e di una pipeline che tutti comprendano nello stesso modo.

La “semplicità” si rompe quando dipende da testo libero e duplicati. Se una persona scrive lo stato di un deal come "Negoziazione" e un'altra scrive "negoziazione", il reporting diventa approssimativo. Se le attività vivono in tabelle separate per chiamate, riunioni e note, finisci con più campi data e senza un valore affidabile di “ultima attività”.

Questo schema si attiene a quattro oggetti core che coprono la maggior parte dei CRM per piccoli team senza trasformarsi in un mostro:

• Contatti (e opzionalmente Organizzazioni) come le persone con cui parli
• Opportunità/Deal come le potenziali vendite che segui attraverso una pipeline
• Attività come registro unificato per task, riunioni, chiamate e note
• Permessi come regole pratiche su chi può vedere e modificare cosa

Un reporting pulito significa poter vedere in modo affidabile i deal per fase questa settimana, il tasso di conversione da fase a fase, il tempo medio in fase, l'ultima attività per deal e i task aperti di ogni venditore per oggi. Quei report dovrebbero avere ancora senso quando il team cresce da 3 a 15 persone.

Se stai costruendo un CRM interno in uno strumento no-code come AppMaster, questo approccio mantiene il database piccolo offrendo comunque numeri stabili per dashboard e revisioni settimanali.

Principi per restare leggeri senza chiudersi in una scatola

Uno schema CRM leggero funziona quando risponde chiaramente a una domanda: dove risiede questo fatto? Se la stessa “verità” può essere salvata in due posti, lo sarà, e i tuoi report deriveranno.

Scegli un piccolo set di oggetti fonte di verità e fai in modo che tutto il resto punti a loro. Per la maggior parte dei piccoli team, significa Contatti, Organizzazioni (opzionale), Deal e Attività. Quando serve più dettaglio, aggiungi una nuova tabella invece di infilare significati in un unico campo di testo che diventa un cassetto dei rifiuti.

Alcune regole mantengono il modello semplice e flessibile:

• Un fatto, una casa: un numero di telefono appartiene al Contatto, il valore di un deal appartiene al Deal.
• Preferisci tabelle esplicite ai campi sovraccarichi: la cronologia delle fasi non è una stringa separata da virgole.
• Mantieni gli ID stabili e i nomi modificabili: le persone rinominano le aziende, non cambiano le chiavi primarie.
• Separa “stato” da “tipo”: un task può essere “aperto” e “chiamata” allo stesso tempo.
• Assumi che le importazioni saranno disordinate: campi vuoti, duplicati e formattazioni strane sono normali.

Pianifica dati disordinati dal giorno uno aggiungendo alcuni campi noiosi ma potenti: created_at, updated_at e un semplice external_id (o import_source + import_key) sulle tue tabelle core. Questo ti dà un modo sicuro per reimportare senza creare duplicati.

Un esempio concreto: importi un foglio dove “Acme Inc.” appare come “ACME” in metà delle righe. Se Organization.name è modificabile e Organization.id è stabile, puoi unire i record in seguito senza rompere deal e attività esistenti.

Contatti e organizzazioni: la struttura più semplice che funziona

Uno schema CRM leggero parte da una decisione: tracci solo persone, o persone più aziende? Se il tuo team vende a imprese (B2B), quasi sempre vuoi sia Contatto (persona) che Organizzazione (azienda). Se vendi a consumatori (B2C), puoi saltare le organizzazioni e mantenere ogni record come contatto.

Per una configurazione B2B, mantieni semplice la relazione: ogni contatto appartiene a una singola organizzazione principale (nullable), e un'organizzazione può avere molti contatti. Questo copre la maggior parte dei flussi di lavoro dei piccoli team senza spingerti in gerarchie di account complicate.

Mantieni i campi richiesti al minimo

Il modo più veloce per generare dati disordinati è rendere obbligatori troppi campi. Una buona baseline è:

• Contatto: id, nome (o first_name + last_name), created_at
• Organizzazione: id, name, created_at

Tutto il resto (titolo, sito web, indirizzo, settore, sorgente) può essere opzionale. Puoi aggiungere regole dopo, ma è difficile pulire un database pieno di segnaposto come "N/A".

Email e telefono: unicità senza dolore

È allettante rendere l'email unica. Funziona bene per B2C o per un CRM che funge anche da sistema di autenticazione. Nei piccoli team B2B, inbox condivise (sales@, info@) e numeri di telefono riutilizzati sono comuni. Regole di unicità rigide possono bloccare record validi.

Un compromesso pratico:

• Applica l'unicità solo quando il valore è presente (e solo se si adatta al tuo caso d'uso).
• Consenti duplicati, ma mostra un avviso lieve nell'interfaccia quando si trova una corrispondenza.

Se ti servono più email o numeri, evita colonne come email_2 o phone_3. Usa una tabella separata (per esempio, ContactMethod con type, value, is_primary). I report restano puliti e il modello scala naturalmente.

Esempio: incontri Pat, che cambia lavoro a metà trimestre. Con il Contatto collegato all'Organizzazione, puoi spostare Pat nella nuova azienda, mantenere i vecchi metodi di contatto per la cronologia e i report continueranno a contare i deal per azienda correttamente.

Deal e pipeline: struttura che resta leggibile

Un deal è l'unità della previsione: una potenziale vendita con un passo successivo chiaro. Mantieni il record del deal snello e riferisciti a tutto il resto.

Inizia con campi che puoi spiegare a chiunque nel team:

• Nome del deal: una etichetta breve che abbia senso in una lista
• Fase: riferimento a una fase di pipeline (non scritta a mano)
• Valore: importo atteso (e scegli una valuta per tutto il sistema)
• Owner: la persona responsabile di farlo avanzare
• Data di chiusura: la migliore stima corrente di quando si chiuderà

Per le relazioni, scegli un contatto primario sul deal. Questo mantiene i report semplici (per esempio, fatturato per contatto, tasso di chiusura per segmento). Se alcune volte servono altre persone coinvolte, aggiungi una tabella deal_contacts così puoi allegare contatti extra senza trasformare ogni deal in un many-to-many complesso. La maggior parte dei piccoli team va bene con 1 contatto primario più partecipanti opzionali.

Le fasi sono dove i CRM spesso si incasinano. Non memorizzare la fase come testo libero. Memorizza le fasi come dati di riferimento così puoi rinominare una fase dopo senza rompere i report. Una tabella minima per le fasi potrebbe includere:

• stage_id
• pipeline_id
• stage_name
• stage_order
• is_closed (o flag separati per vinto e perso)

Se il tuo team è piccolo, evita di separare i record in “lead” e “deal” a meno che non gestisci davvero i lead in modo diverso. Una regola semplice funziona: quando hai una vera opportunità da tracciare, è un deal. Prima di quello, mantienilo come un contatto con uno stato tipo “new” o “nurture”. Questo rende la pipeline leggibile e impedisce che deal a metà creino rumore nei numeri.

Esempio: un team di due persone traccia “Acme Renewal” come un deal di proprietà di Sam, fase “Proposal Sent”, valore 12.000, data di chiusura il mese prossimo. Il contatto primario è l'acquirente e un secondo contatto è aggiunto come approvatore finanziario. I report restano coerenti perché i nomi e l'ordine delle fasi sono fissi.

Attività: un modello per task, riunioni e note

Un piccolo team non ha bisogno di tabelle separate per chiamate, email, riunioni e note. Un modello Activity unico è di solito sufficiente e rende il CRM più facile da usare e da riportare.

Una singola tabella Activity

Usa un record per ogni cosa che è successa (o che dovrebbe succedere). Daglielo un semplice campo type con un set fisso ridotto, per esempio: call, email, meeting, note, task. Mantieni la lista corta così le persone scelgono le stesse parole ogni volta.

Per collegare le attività senza confusione, usa regole chiare:

• Se riguarda una persona (follow-up, email introduttiva), collegalo a un contatto.
• Se riguarda il movimento di revenue (call di pricing, riunione di negoziazione), collegalo a un deal.
• Se coinvolge entrambi, collegalo a entrambi, ma tratta il deal come primario per i report di pipeline.

In pratica, Activity può avere contact_id (nullable) e deal_id (nullable), più un opzionale owner_id (chi è responsabile).

Timestamp adatti al reporting

Tieni sia due_at che completed_at. Rispondono a domande diverse. due_at ti dice cosa avrebbe dovuto succedere (pianificazione e carico di lavoro). completed_at ti dice cosa è effettivamente successo (esecuzione e tempi).

Puoi derivare lo stato senza un campo separato: se completed_at è impostato, è fatto. Se no, è aperto. Questo evita valori di stato extra che si scollano.

Per il testo dell'attività, conserva un unico campo ricercabile come summary o body. Evita di sovra-strutturare le note all'inizio. Esempio: “Chiamata con Maya: budget confermato, inviare proposta venerdì.” Aggiungi campi specializzati solo quando senti veramente dolore.

Proprietà e visibilità: mantienila pratica

La proprietà è chi è responsabile del prossimo passo. In uno schema CRM leggero, di solito significa un campo come owner_user_id su un deal (e spesso anche sui contatti).

Due significati di “owner” vengono spesso confusi: assegnazione utente (una persona specifica) e assegnazione team (un gruppo). Se provi a rendere tutto di proprietà di un team fin dal primo giorno, perdi chiarezza su chi deve agire oggi.

Un default che funziona per la maggior parte dei piccoli team è: tutto visibile a tutti, ma ogni deal ha esattamente un owner. La collaborazione resta facile e eviti casi limite di permessi quando qualcuno deve sostituire un collega.

Quando serve visibilità più stretta, mantienila come un interruttore singolo, non come una matrice complessa. Per esempio, aggiungi un campo visibility su deal e attività con valori come public e private, dove private significa “solo l'owner (e gli admin) possono vederlo.”

Hai bisogno di team o territori solo quando una di queste cose è vera:

• Hai gruppi separati che non dovrebbero vedere i deal degli altri.
• Fai report per team e le persone si spostano tra i team.
• I manager devono accedere al loro gruppo, ma non all'intera azienda.
• Assegni lead a una coda condivisa prima che un rappresentante li reclami.

La proprietà influenza il reporting. Se vuoi numeri puliti “per venditore”, fai i report sul owner_user_id corrente del deal. Se vuoi anche rollup “per team”, aggiungi owner_team_id (o derivarlo dal profilo dell'owner), ma sii esplicito su quale sia la fonte di verità.

Esempio: due venditori condividono una inbox. Un nuovo deal nasce non assegnato con owner_user_id = null e owner_team_id = Sales. Quando Alex lo prende, imposta owner_user_id = Alex (mantieni team come Sales). La pipeline resta leggibile e i totali di team funzionano.

Progettazione dei permessi: controllo sufficiente senza complessità

Inizia con RBAC semplice

I permessi funzionano meglio quando separi tre idee: ruoli (chi), risorse (cosa) e azioni (cosa possono fare). Questo è il controllo di accesso basato sui ruoli (RBAC) e resta comprensibile mentre il team cresce.

Mantieni le risorse vicine agli oggetti core: Contatti, Organizzazioni, Deal, Attività e magari Pipelines (se le fasi sono modificabili). Definisci un piccolo set di azioni coerente su di essi: view, create, edit, delete, export.

Separare l'export vale la pena. Molti team sono a posto con ampi diritti di visualizzazione, ma vogliono limitare le estrazioni massive di dati.

I permessi a livello di oggetto sono il posto più semplice per cominciare: “Questo ruolo può modificare i deal?” Per la maggior parte dei piccoli team, questo basta per mesi. Le regole a livello di record (per contatto o per deal) sono dove arriva la complessità, quindi aggiungile solo quando serve davvero.

Un passo pratico iniziale è una singola regola di proprietà: ogni record ha owner_user_id, e i non-admin possono modificare solo ciò che possiedono. Se ti serve un altro livello, aggiungi team_id e consenti la visualizzazione a livello di team mantenendo le modifiche riservate al proprietario.

Regole a livello di record quando servono davvero

Aggiungi permessi a livello di record per casi come:

• I venditori non devono vedere i deal degli altri
• Il support può visualizzare i deal ma mai modificarli
• I manager possono vedere tutto e riassegnare owner

Mantieni le esigenze di audit leggere ma reali. Aggiungi created_at, created_by, updated_at e updated_by in ogni tabella principale. Se serve una storia più profonda dopo, aggiungi una piccola tabella audit_log con: tipo oggetto, id record, azione, chi, quando e un breve JSON dei campi cambiati.

Passo dopo passo: costruisci lo schema in un weekend

È più facile azzeccarlo trattandolo come un piccolo prodotto: definisci prima i dati, verifica che funzionino con voci reali, poi costruisci le schermate.

Giorno 1: blocca il modello dati

Inizia con uno schizzo ERD rapido su carta o lavagna. Mantieni il numero di tabelle piccolo, ma sii chiaro sui collegamenti: il contatto appartiene a un'organizzazione (opzionale), il deal appartiene a una pipeline e ha un owner, l'attività può riferirsi a un contatto e/o a un deal.

Poi fai le basi in ordine:

• Definisci oggetti e relazioni: contatti, organizzazioni, deal, attività, utenti/ruoli, più piccole tabelle di lookup se servono.
• Definisci campi richiesti e default: rendi obbligatori created_at, owner_id e nomi chiave; imposta default per fase e valuta se usi importi.
• Definisci enum o lookup: fasi del deal e tipi di attività così il reporting resta coerente.
• Aggiungi indici per filtri comuni: owner_id, fase, due_at, created_at e chiavi esterne che filtri quotidianamente.
• Testa con 20 record reali: usa nomi reali, date e note disordinate per vedere cosa si rompe.

Giorno 2: verifica che rapporti siano puliti

Prima di costruire le form, scrivi 6-8 domande che il tuo team si pone ogni settimana. Per esempio: “Deal in Negotiation per owner”, “Attività scadute”, “Nuovi contatti questo mese”, “Ricavi vinti per mese”. Se una domanda richiede join confusi o casi speciali, correggi lo schema ora.

Uno scenario di test semplice aiuta: aggiungi 3 contatti in un'azienda, 2 deal in fasi diverse e 6 attività sparse tra loro (una chiamata, una riunione, due task e due note). Poi verifica se puoi rispondere chi lo possiede, cosa succede dopo e cosa è cambiato la settimana scorsa senza indovinare.

Una volta che i dati sono solidi, costruisci l'interfaccia e le automazioni per ultime. Andrai più veloce e non dovrai riscrivere la storia più avanti per far combaciare i report con la realtà.

Errori comuni che rendono i report disordinati

I report disordinati iniziano solitamente con “fix veloci” che sembrano più rapidi oggi ma ti costano ogni settimana dopo. Uno schema CRM leggero funziona meglio quando i tuoi dati hanno forme chiare e poche regole che il team segue davvero.

Una trappola comune è forzare tutto in un'unica tabella “customer”. Sembra semplice finché non devi rispondere a domande base come “Quanti deal sono legati a una azienda?” o “Quale persona ha cambiato lavoro?”. Separa persone (contatti) e aziende (organizzazioni) e collegale.

Un altro killer del reporting è lasciare le fasi dei deal come testo libero. Se una persona scrive “Negoziazione” e un'altra “negoziazione”, il grafico della pipeline è già sbagliato. Usa una lista fissa di fasi (o una tabella stage) così ogni deal punta allo stesso insieme di valori.

Evita di impacchettare più valori in un campo. Email o numeri separati da virgola rendono ricerca, deduping ed export dolorosi. Se davvero servono valori multipli, memorizzali come righe separate (per esempio, una email per record in una tabella figlia).

Le attività si confondono quando le date sono vaghe. Un singolo campo “date” non riesce a dirti se un task era dovuto venerdì scorso o completato venerdì scorso. Separa quei concetti così puoi fare report su lavoro scaduto e lavoro completato correttamente.

Ecco una rapida checklist “salva il te futuro”:

• Separa contatti e organizzazioni, poi collegali
• Usa ID di fase, non nomi di fase digitati
• Un valore per campo; usa tabella figlia per valori multipli
• Tieni due_at e completed_at separati
• Inizia con ruoli semplici; aggiungi regole a livello di record solo dopo aver visto flussi reali

Esempio: se il team registra le chiamate come note e poi le marca “fatte” modificando lo stesso campo, non potrai misurare quanto hanno impiegato i follow-up. Con campi separati quel report è semplice.

Checklist rapida prima di impegnarti sullo schema

Prima di costruire schermate, automazioni e dashboard, fai un rapido controllo su reporting e regole. Uno schema CRM leggero resta leggero solo se puoi rispondere alle domande comuni senza hack personalizzati o campi una tantum.

Esegui questi controlli usando dati di esempio reali (anche 20 contatti e 10 deal bastano). Se resti bloccato, di solito significa un campo mancante, una picklist incoerente o una relazione troppo lasca.

I 5 controlli che catturano la maggior parte dei problemi

• Fondamentali del reporting: puoi raggruppare i deal per fase, per owner e per mese di chiusura senza indovinare quale campo data usare?
• Gestione del lavoro: riesci a estrarre “attività scadute per owner” in un report unico, dove scaduto si basa su una sola data di scadenza e uno stato chiaro di completamento?
• Contatto-organizzazione: un contatto può esistere senza organizzazione, e può essere collegato dopo senza rompere la storia (email, note, partecipazione a deal)?
• Coerenza: fasi e tipi di attività provengono da una lista fissa, così non finisci con “Follow up”, “Follow-up” e “Followup” come tre valori diversi?
• Sicurezza: puoi limitare chi può cancellare record o esportare liste, senza bloccare aggiornamenti normali come spostare un deal alla fase successiva?

Se puoi rispondere “sì” a tutti e cinque, sei in buona forma. Altrimenti, correggilo ora mentre lo schema è ancora piccolo.

Un suggerimento pratico: definisci fasi e tipi di attività una volta (come tabella o enum) e riusali ovunque così ogni schermo e processo usa gli stessi valori.

Un esempio realistico per piccoli team e passi successivi

Un'agenzia di 5 persone è un buon test per uno schema CRM leggero. Il team è impegnato, i lead arrivano da ovunque e nessuno vuole fare il babysitter dei dati. Immagina: 1 admin, 2 vendite, 1 responsabile operations e 1 membro in sola lettura (il founder che guarda solo i numeri).

Arriva una nuova richiesta inbound (form web o email): “Serve refresh del sito, budget 15k, timeline 6 settimane.” La regola è semplice: crea un'organizzazione (se è un'azienda) e un contatto (la persona). Poi crea un deal legato all'organizzazione, con il contatto come contatto primario per quel deal.

Per mantenere la velocità, usano una piccola checklist di intake:

• Se il dominio o il nome azienda corrisponde a un'organizzazione esistente, riusala.
• Se l'email della persona esiste, riusa quel contatto.
• Crea sempre un deal per una reale intenzione d'acquisto.
• Metti il messaggio originale nella descrizione del deal.
• Aggiungi la sorgente (referral, form, outbound) come singolo campo.

Le attività evitano chiamate mancate perché ogni prossimo passo diventa un elemento datato di cui è responsabile una persona. Quando sales fa una discovery call, registra un'attività come meeting e aggiunge subito la successiva: una chiamata tra due giorni. Se ops ha bisogno di dettagli per stimare il lavoro, crea un’attività task sullo stesso deal così tutto appare nello stesso posto.

I ruoli restano pratici: Admin può modificare tutto e gestire le impostazioni, Sales può creare e aggiornare contatti, deal e loro attività, Ops può aggiornare campi di delivery e attività, e Read-only può vedere pipeline e report senza cambiare dati.

Se vuoi trasformare questo in uno strumento interno funzionante rapidamente, AppMaster (appmaster.io) è un'opzione semplice: puoi modellare lo schema nel suo Data Designer (PostgreSQL), aggiungere regole di flusso con l'editor Business Process, costruire una piccola inbox lead e la pagina deal, poi distribuire su AppMaster Cloud o sul tuo cloud quando sei pronto a condividerlo col team.