Da archivio contatti a customer hub: People e Companies in Accordo

In breve. Un archivio contatti sa rispondere a domande sui clienti; un customer hub sa anche agire su di loro, con azioni governate, identità logica e traccia per ogni record. È la distinzione che uso dopo averla costruita in Accordo, dove People e Companies sono i due registri della fondazione customer — ed è interpretazione mia, non una definizione di mercato. Da dove viene, cosa comprende e cosa resta fuori, con i fatti separati dai limiti. Pubblicato il 6 ottobre 2026.

L'archivio risponde, l'hub agisce

La differenza non sta in quanti campi ha una scheda cliente. Sta in cosa la scheda può fare senza uscire dai binari: avanzare un rinnovo, registrare un'approvazione, aprire una richiesta operativa che il sistema sa custodire fino a una decisione umana. Un archivio con mille campi resta un archivio; un hub con tre azioni governate è già un hub.

In Accordo "hub" significa questo: una catena unica di record commerciali con azioni governate, import bounded in JSON e identità logica del cliente. La tesi completa sull'autonomia che ne deriva è nel pillar sull'autonomia sotto controllo; qui racconto il pezzo dei dati, i due registri da cui tutto parte.

People e Companies: due registri, un'identità logica

Nella superficie del CRM web di Accordo, People e Companies stanno al secondo livello, subito sotto la dashboard: sono i registri delle persone e delle aziende clienti. La fondazione che li alimenta ha un perimetro scritto e stretto: import JSON bounded con ricevute per riga, idempotenza, matching deterministico e identità logica, con i collegamenti canonici decisi da umani.

Ogni pezzo del perimetro risponde a un guasto visto o previsto. Le ricevute per riga dicono cosa è entrato e cosa no, riga per riga, invece di un semaforo unico sull'intero import. L'idempotenza fa sì che riprovare non duplichi: dopo un fallimento, la riga morta non deve tornare all'infinito, come ho imparato nel retry che riceveva la riga morta. Il matching deterministico decide sempre allo stesso modo a parità di dati, così due import dello stesso file convergono invece di divergere. E i collegamenti canonici — quale persona appartiene a quale azienda quando i dati sono ambigui — li decide un umano, non un punteggio di similarità.

L'import che è arrivato in fondo

Il 10 settembre 2026 l'import CSV dell'owner nel pilot è arrivato in fondo end-to-end, con ricevuta datata. Prima ci sono stati due fallimenti di upload, con due cause radice entrambe del solo hosting condiviso, corrette dal vivo. Lo cito con questi dettagli perché è l'unico import di cui posso raccontare l'esecuzione: due artefatti diversi, due stati diversi, entrambi scritti nel diario del pilot.

La fondazione customer-data completa, intanto, ha la matrice di verifica chiusa — browser Chromium reale sul flusso principale, replay byte-identici, matrici di fault e corse — ma la PR è lasciata esplicitamente aperta e non mergiata. Implementata e verificata, sì; live, no. Il registro lo scrive come regola generale: una PR mergiata non si registra mai come capacità validata, figuriamoci una aperta. People e Companies, come capacità di prodotto, stanno in questo stato: meccanica provata, giro dal vivo ancora da percorrere.

Cosa l'hub non è

Il perimetro si definisce anche per esclusione, ed è la parte che tengo più stretta. La fondazione non è un CDP completo: niente warehouse, niente streaming, niente segmentazione di audience, niente attivazione, niente timeline completa. Per cosa sia un CDP vero, con ingestione e personalizzazione su molte fonti, c'è la guida dedicata: è il contesto da cui Accordo prende le distanze con onestà, non ciò che Accordo fa.

Altre due esclusioni, scritte nei documenti: Interactions non esiste ancora nel prodotto, e la marketing automation non esegue niente — il package opzionale registra funnel osservati e proposte revisionate da umani, ma non invia, non pubblica, non spende. Accanto a un CDP esterno o a uno strumento di invio, l'hub sta come strato di processo deterministico, non come sostituto.

Fatti e limiti, separati

Fatti: People/Companies come registri della superficie CRM; fondazione con import JSON bounded, ricevute per riga, idempotenza, matching deterministico, identità logica e collegamenti canonici umani; matrice di verifica chiusa con browser reale, replay byte-identici, fault e corse; import CSV del pilot riuscito end-to-end il 10 settembre 2026 con ricevuta datata, dopo due fallimenti da hosting condiviso corretti dal vivo.

Limiti: la fondazione completa ha la PR aperta e non mergiata, quindi non è live; il giro completo sulla nuova UX del web CRM non è ancora stato ripercorso dal vivo da un umano; niente CDP (warehouse, streaming, attivazione, timeline), niente Interactions, niente marketing automation eseguita. Una verifica chiusa e un import riuscito non misurano quanto il disegno regga in produzione: misurano che la meccanica esiste e gira. La tesi completa è nel pillar sull'autonomia sotto controllo.

Domande frequenti

Cosa distingue un customer hub da un archivio contatti?

Le azioni governate: l'hub non si limita a rispondere a domande sui clienti, ma esegue azioni sui record — avanzamenti, approvazioni, richieste operative — dentro policy scritte, con identità logica e traccia. Un archivio con mille campi resta un archivio.

Perché l'import è bounded e con ricevute per riga?

Perché un import senza confini e senza ricevute dà un solo verdetto — riuscito o fallito — su migliaia di righe. Con riga per riga sai cosa è entrato, cosa no e perché, e puoi riprovare solo ciò che serve senza duplicare ciò che c'è già.

L'hub sostituisce un CDP?

No. La fondazione ha import bounded, idempotenza, matching deterministico e identità logica, ma niente warehouse, streaming, segmentazione, attivazione o timeline completa. Sta accanto a un CDP esterno come strato di processo, non al suo posto.

Quando People e Companies saranno pronti?

Quando la sequenza lo dirà con evidence eseguibile: oggi la meccanica è verificata ma la PR è aperta e non mergiata, e il giro completo sulla nuova UX non è stato ripercorso dal vivo. Lo stato si legge nei documenti, non si indovina dal codice.