Analisi win loss: come farla in cinque passi, con un modello gratuito e i veri motivi delle trattative

Publish date: 4 nov 2026
Un'analisi win loss chiede agli acquirenti perché hanno scelto te, un concorrente o nessuno. Poi trasforma le risposte in numeri su cui agire. Ti servono tre cose: un registro con un codice motivo per ogni trattativa chiusa, una traccia di intervista breve e una revisione mensile che cambi qualcosa. Questo articolo ti dà tutte e tre.
I dieci codici motivo vengono dal registro di Spona, con 137 trattative chiuse, e le otto domande dalle 29 interviste che Spona ha fatto dopo la decisione. Il foglio Google Sheets gratuito, in inglese, contiene tutte quelle trattative come righe di esempio. Così vedi le formule al lavoro prima di cancellarle. Fai una copia del foglio e segui i cinque passi qui sotto.
Get thousands of leads in 4 minutes.
Stop stitching tools together.
Start with verified sales data, delivered in minutes.
No contracts · No setup · No onboarding
Analisi win loss: a quali domande risponde
L'analisi risponde a tre domande: perché vinci, perché perdi e perché alcune trattative si fermano senza una decisione. Quasi tutti i team saltano la terza. Per The JOLT Effect, Dixon e McKenna hanno analizzato milioni di conversazioni di vendita registrate. Hanno scoperto che dal 40 al 60% delle trattative perse si chiudeva senza decisione.
Se il tuo registro ha solo Vinta e Persa, circa metà delle tue sconfitte potrebbe nascondersi nella colonna sbagliata. Classifica ogni trattativa chiusa come vinta, persa o senza decisione e dai a ogni esito i suoi codici. Un acquirente che ha messo in pausa un progetto non ti ha scartato. Uno che ha firmato con il fornitore attuale sì, e i due casi richiedono correzioni diverse.
La seconda cosa che l'analisi ti dice è quanto sbaglia il tuo CRM. Clozd gestisce programmi di interviste per conto dei fornitori. Secondo Clozd, i motivi delle trattative perse indicati da acquirente e venditore coincidono solo nel 15% dei casi. Il venditore scrive «prezzo»; l'acquirente dice che il team non riusciva a cambiare processo.
Solo la versione dell'acquirente ti dice cosa cambiare. Per questo il metodo che segue tiene due fonti per ogni motivo: il codice che il venditore sceglie alla chiusura e la risposta che l'acquirente dà qualche settimana dopo. Il modello le registra entrambe e mostra quanto spesso coincidono.
Il registro di Spona lo dimostra con i numeri. Contiene 137 trattative chiuse. Di queste, 85 sono state vinte e 25 perse. Le altre 27 si sono chiuse senza decisione.
Calcolando su questi numeri, Spona ha vinto il 62,0% di tutte le trattative chiuse e il 77,3% di quelle arrivate a una decisione. La differenza tra i due tassi nasce dalle trattative senza decisione. Un registro con solo Vinta e Persa non la mostra mai. Il modello la mette in primo piano.
Come si fa un'analisi win loss?
Cinque passi, nell'ordine in cui il modello li aspetta. Ogni passo finisce con una riga, un codice o un conteggio, così niente dipende dalla memoria.
- Estrai ogni trattativa chiusa, comprese quelle senza decisione. Esporta ogni opportunità chiusa dalla tua pipeline di vendita con la cronologia delle fasi. Tieni le trattative che si sono spente dopo una proposta. Vanno nel registro come Nessuna decisione (No decision), non nella pipeline aperta. La guida di Klue dice che servono almeno 10 trattative simili prima che uno schema significhi qualcosa. Il registro di Spona ha aggiunto da 32 a 40 trattative chiuse al mese per quattro mesi. Anche così, quattro dei suoi dieci codici sono rimasti sotto le 10 trattative. Un team più piccolo dovrebbe estrarre almeno un trimestre. Un team che chiude poche trattative al mese dovrebbe estrarre un anno.
- Codifica un motivo principale nel CRM. HubSpot offre due proprietà predefinite delle trattative per questo, il motivo di vittoria e il motivo di sconfitta: Closed won reason e Closed lost reason. Limita entrambe a un elenco fisso dei tuoi codici e aggiungi un gruppo di codici per No decision. Un codice per trattativa, scelto alla chiusura dal venditore che l'ha seguita. Una trattativa con due motivi prende quello che l'acquirente ha citato per primo. Registra anche da dove viene il codice: il campo del CRM, un debrief del venditore o un'intervista all'acquirente. Se il tuo CRM è un foglio di calcolo, il nostro modello di CRM ha un campo per il motivo di sconfitta che puoi collegare allo stesso elenco.
- Intervista gli acquirenti dopo la decisione. Il codice del venditore è un'ipotesi; la risposta dell'acquirente è il dato. Clozd suggerisce di intervistare tra 30 e 90 giorni dopo la decisione, con una divisione equa tra vinte e perse. User Intuition propende per da due a quattro settimane, finché il ricordo è fresco. Klue consiglia chiamate di 30 minuti con un'ora bloccata in agenda. Aspettati che accetti un'intervista dal 15 al 30% degli acquirenti, contro una quota dal 3 al 5% per i sondaggi. A fare le domande dovrebbe essere qualcuno diverso dal venditore. Pragmatic Institute mette in chiamata le persone di prodotto, perché gli acquirenti possono tacere le cattive notizie per proteggere il rapporto con il venditore. In Italia, la FAQ del Garante sul registro delle attività di trattamento chiarisce chi lo deve tenere. Tra gli obbligati ci sono anche le imprese con meno di 250 dipendenti che effettuano trattamenti non occasionali. Il registro indica i termini ultimi di cancellazione per ogni categoria di dati, o i criteri per fissarli, e descrive in generale le misure di sicurezza. Registrazioni delle interviste e parole degli acquirenti vanno quindi lì, con una data di cancellazione. Conserva le parole di un acquirente solo se la colonna Permesso di citazione (Quote permission) della scheda Traccia intervista (Interview guide) lo consente.
- Registra e conta. Una riga per trattativa chiusa: l'esito, il codice, la fonte del codice e le parole dell'acquirente. Poi conta le trattative dietro ogni codice. Un codice con tre trattative dietro è un aneddoto. Un codice con undici trattative dietro è uno schema. Tieni le parole dell'acquirente brevi e testuali; una parafrasi perde la parola che contava. Fissa un minimo prima di leggere qualsiasi codice e tratta tutto ciò che sta sotto come «non ancora». Il modello fa i conteggi al posto tuo e segnala ogni codice sotto il minimo che hai fissato.
- Dai a ogni codice principale un responsabile e un cambiamento. La regola di Liminal è che gli insight devono aggiornare tre cose ogni mese: battlecard, domande di discovery e gestione delle obiezioni. Assegna a un team il primo codice di ogni esito. Scrivi il cambiamento e controlla il mese dopo se il conteggio si è mosso. Il sondaggio di Clozd ha rilevato che solo il 39% delle aziende gestisce il win loss come un programma continuo e trasversale. Il 72% dei programmi fa capo ai team go-to-market, diviso in parti uguali tra vendite e marketing. Scegli subito un responsabile e fissa la data della revisione prima di uscire dalla stanza.
Domande per intervista win loss: le otto che facciamo
Klue suggerisce di scrivere da 20 a 30 domande e di aspettarti di usarne circa la metà. La traccia di Spona ne ha otto. Coprono il fattore scatenante, le alternative, le prove, la classifica dei criteri, le persone, il quasi ripensamento, il cambiamento mancato e ciò che è successo dopo. Sei vanno a tutti gli acquirenti; una solo a chi ha scelto Spona e una solo a chi non l'ha scelta.
La tabella riporta le domande parola per parola, con il numero di interviste in cui è stata fatta ciascuna. Sostituisci «Spona» con il nome della tua azienda nelle domande 6 e 7. La scheda Interview guide del modello ha una colonna per la tua formulazione accanto alla nostra. Fai le domande in ordine: la classifica della domanda 4 ha senso solo quando le alternative della domanda 2 sono sul tavolo.
| N. | Domanda | Rivolta a | Interviste |
| 1 | Che cosa vi ha fatto pensare, all'inizio, che valesse la pena dedicare tempo a questo progetto? | Entrambi | 29 |
| 2 | Quali alternative avete valutato seriamente? | Entrambi | 29 |
| 3 | Quali prove hanno cambiato la vostra opinione sulla qualità dei dati? | Entrambi | 29 |
| 4 | Come si sono classificati nella decisione record utilizzabili, workflow e condizioni commerciali? | Entrambi | 29 |
| 5 | Chi ha influenzato la decisione e che cosa contava per ciascuna persona? | Entrambi | 29 |
| 6 | Che cosa vi ha quasi impedito di scegliere Spona? | Vinta | 17 |
| 7 | Che cosa avrebbe dovuto cambiare Spona per vincere? | Persa | 12 |
| 8 | Che cosa è successo dopo che avete preso la decisione? | Entrambi | 29 |
I conteggi vengono da 29 conversazioni programmate dopo la decisione, separate dalle chiamate di vendita. Di queste, 17 sono seguite a trattative vinte e 12 a trattative perse. Il gruppo non include nessun acquirente la cui trattativa si è chiusa con No decision. È la lacuna che colmeremmo per prima.
I codici senza decisione (un progetto in pausa, una data di lancio che slitta, una verifica degli acquisti) sono difficili da assegnare partendo solo da un campo del CRM. Il venditore vede la trattativa spegnersi e deve tirare a indovinare. Solo l'acquirente sa se il progetto è morto o si è solo spostato. Aggiungi questi acquirenti alla tua lista di interviste fin dal primo mese.
La domanda 1 si guadagna il posto perché separa un vero fattore scatenante da un desiderio vago. La domanda 2 ti dice contro chi competevi davvero, che può non essere il fornitore segnato nel CRM. La domanda 3 chiede prove, non opinioni, quindi la risposta cita un campione, un test o il file di un concorrente. La domanda 4 impone una classifica, ed è così che scopri se «prezzo» voleva dire il prezzo o l'impossibilità di comprare in piccolo.
Le domande 6 e 7 sono la coppia che cambia il playbook di vendita. Il quasi ripensamento di un acquirente vinto è il motivo di sconfitta di domani. Il cambiamento mancato di un acquirente perso è una lacuna di prodotto o una prova che non hai saputo mostrare. La domanda 8 coglie ciò che è successo dopo la firma o il rifiuto, cioè dove stanno le referenze e i rischi di churn.
La domanda 5 conta soprattutto per gli account più grandi. Gartner stima che il tipico gruppo d'acquisto per un acquisto B2B complesso conti da sei a 10 decisori. Questi acquirenti passano solo il 17% del tempo d'acquisto a incontrare potenziali fornitori. Il venditore potrebbe averne incontrati due o tre.
L'intervista è la tua unica occasione per sentire cosa contava per gli altri. Annota il ruolo di ogni persona, non il nome. Poi riporta i ruoli nel tuo modello di buyer persona, così la prossima discovery call li cerca per qualifica.
Analisi win loss: 137 trattative Spona per motivo
Quasi tutti gli elenchi di codici pubblicati sono generici. AskElephant propone cinque motivi di sconfitta: prezzo, tempistica, aderenza, concorrente e fallimento del processo. Il modello di Unkover divide i motivi in cinque categorie: prezzi, prodotto, persone, processo e posizionamento. Nessuno dei due elenchi ha conteggi di trattative reali, e nessuno dà codici propri alle trattative senza decisione.
Il CRM di Spona usa dieci codici sui tre esiti: quattro per le vinte, tre per le perse e tre per quelle senza decisione. Ogni trattativa chiusa ne porta esattamente uno. I codici sono specifici di un fornitore di dati, quindi rinominali per il tuo prodotto. Mantieni la struttura: un codice nomina un motivo che l'acquirente riconoscerebbe, non una fase di vendita o una sensazione.
La tabella riporta ogni codice, la regola per usarlo e le parole dell'acquirente registrate per quel codice nel registro di Spona. Ogni codice ha una sola formulazione registrata. Leggi la citazione come la frase tipica, non come qualcosa che ha detto ogni acquirente.
| Esito | Codice | Quando usarlo | Parole dell'acquirente registrate |
| Won | Copertura verificata (Verified coverage) | i record degli account target dell'acquirente si sono rivelati corretti | «Abbiamo trovato le persone giuste nel territorio in cui vendiamo davvero.» |
| Won | Acquisto flessibile (Flexible purchase) | l'acquirente poteva partire in piccolo o pagare in base all'uso | «Abbiamo potuto finanziare un pilota mirato senza comprare più dati del necessario.» |
| Won | Adattamento al workflow (Workflow fit) | il risultato si integrava con gli strumenti e i passaggi che avevano già | «Il file era semplice da usare nel workflow che avevamo già.» |
| Won | Supporto e rapidità (Support and speed) | domande e correzioni sono state gestite in fretta | «Abbiamo risolto rapidamente la definizione della lista e le correzioni.» |
| Lost | Contratto in essere (Existing contract) | un contratto con il fornitore attuale copre questo periodo di budget | «Siamo già impegnati con il fornitore attuale per questo periodo di budget.» |
| Lost | Vincolo di budget (Budget constraint) | nessun budget per un altro strumento a pagamento | «Non possiamo aggiungere un altro workflow a pagamento in questo trimestre.» |
| Lost | Cambio di processo (Workflow change) | il team non poteva cambiare processo durante la valutazione | «Il nostro team non è riuscito a cambiare processo durante la migrazione.» |
| No decision | Progetto in pausa (Project paused) | il progetto ha perso il suo responsabile | «Le assunzioni sono cambiate e al momento nessuno segue il progetto outbound.» |
| No decision | Nessuna urgenza (No urgency) | il bisogno c'è, ma la data che lo determina continua a slittare | «Ci servono i dati, ma la data di lancio continua a slittare.» |
| No decision | Ritardo acquisti (Procurement delay) | la decisione aspetta la verifica fornitori o dell'ufficio acquisti | «Stiamo aspettando la verifica interna dei fornitori.» |

Verified coverage è il codice di 31 delle 137 trattative, la quota singola più alta. Calcolato sui conteggi, è il 36,5% delle vinte. Sul lato delle sconfitte, Existing contract è il codice di 11 perse su 25. Le parole registrate citano il periodo di budget, non il prodotto.
Procurement delay è il codice di 11 delle 27 trattative senza decisione. I tre motivi principali per cui non si vince stanno tutti dentro l'azienda dell'acquirente: un contratto, una verifica e un responsabile che manca. Ecco perché la traccia di intervista chiede cosa è successo dopo la decisione, e perché il passo 1 tiene nel registro le trattative senza decisione.
Flexible purchase, il secondo codice di vittoria con 23 trattative, è quello che puoi verificare con i prezzi pubblici. Il piano Pro di Spona costa 99 $ al mese e include 10.500 crediti. Una nuova sessione di ricerca richiede 1.000 crediti, quindi ne restano 9.500. Standard Search con la sola email costa da 3 a 7 crediti per lead.
Secondo il nostro calcolo, quel primo mese compra circa da 1.357 a 3.166 lead verificati. Ogni ricerca parte da un campione gratuito. L'importo è rimborsabile per 14 giorni, purché tu non abbia speso crediti. È il tipo di acquisto che descrivono le parole registrate per questo codice.
Modello di analisi win loss: a cosa risponde ogni scheda
Il modello è un foglio Google Sheets in inglese con cinque schede. Fanne una copia: si apre con le 137 trattative di Spona già inserite nella scheda Registro trattative (Deal log). Ogni conteggio e ogni segnalazione nelle altre schede funziona prima ancora che tu scriva qualcosa. Cancella le righe di esempio quando sei pronto, oppure tienile per un mese per imparare le formule.
| Scheda | A cosa risponde | Cosa contiene |
| Istruzioni (Instructions) | Come la imposto e la mantengo affidabile? | Sei passi di configurazione, l'impostazione del minimo di trattative, tutti i menu a tendina in un unico punto |
| Deal log | Cosa è successo in ogni trattativa chiusa, e perché, in un codice? | Una riga per trattativa: esito (Outcome), codice motivo (Reason code), fonte del codice (Source of reason), parole dell'acquirente (Buyer wording), domanda successiva fatta (Next question asked), intervistato (Interviewed) sì o no |
| Codici motivo (Reason codes) | Cosa significa ogni codice, quanto spesso ricorre e chi è responsabile della correzione? | Dieci codici con regola, parole dell'acquirente e domanda successiva; conteggi e quote in tempo reale; i conteggi di Spona come riferimento; una segnalazione per i codici con troppo poche trattative |
| Interview guide | Cosa dicono gli acquirenti dopo la decisione, e coincide con il codice del CRM? | Le otto domande con la tua formulazione accanto; un registro con una colonna Corrispondenza (Match) che confronta il motivo dell'acquirente con il codice CRM |
| Riepilogo (Summary) | Dove vinciamo, perdiamo e ci fermiamo, e sta cambiando qualcosa? | Conteggi per esito e tassi di vittoria, i tre motivi principali per esito, esiti per fascia dimensionale e per concorrente, tasso di corrispondenza delle interviste, trattative chiuse al mese |

Tre elementi del foglio impediscono al registro di andare alla deriva. Primo, la colonna Controllo codice (Code check) del Deal log verifica il codice di ogni riga rispetto all'esito con COUNTIFS. Mostra «Codice non coerente con l'esito» («Code does not fit outcome») quando un venditore registra un motivo di vittoria su una trattativa persa. Secondo, le colonne Outcome, Fascia dimensionale (Size band) e Reason code sono menu a tendina da un intervallo che rifiutano qualsiasi valore fuori elenco.
La colonna Concorrente citato (Competitor named) si limita ad avvisare, quindi «ZoomInfo + Sales Navigator» viene accettato. Terzo, la scheda Reason codes segnala ogni codice con meno trattative del minimo indicato nella scheda Instructions. La segnalazione dice «Troppo poche trattative per leggerlo» («Too few deals to read»), e il minimo parte da 10. Con le righe di esempio, quattro codici hanno quella segnalazione.
La scheda Reason codes tiene anche i conteggi di Spona in due colonne fisse, come riferimento. I tuoi conteggi in tempo reale stanno accanto, così vedi se le tue sconfitte si concentrano dove si concentravano le nostre. Ogni codice ha un team responsabile suggerito da un menu a tendina: vendite (Sales), marketing, prodotto (Product), pricing o direzione (Leadership). Rinomina i codici in base al tuo prodotto e il responsabile resta legato alla riga.
La scheda Interview guide è dove il problema del 15% di coincidenza diventa visibile. Ogni riga di intervista prende dal Deal log l'esito e il codice CRM della trattativa. Prende il motivo principale dell'acquirente da un menu a tendina con gli stessi codici e mostra Corrisponde (Match) o Non corrisponde (Mismatch). La scheda Summary ne ricava un tasso di corrispondenza.
Se il tuo è basso, i tuoi venditori non mentono. Tirano a indovinare, e la soluzione è il passo 3, non un richiamo. La scheda Summary suddivide anche gli esiti per fascia dimensionale e per concorrente citato. Quando aggiungi le date di chiusura, conta le trattative chiuse al mese.
Altre due colonne del Deal log tengono il registro onesto. Source of reason indica se il codice viene dal campo CRM (CRM field), da un debrief del venditore (Rep debrief) o da un'intervista all'acquirente (Buyer interview): così vedi quanta parte del registro poggia su ipotesi. Interviewed segna le trattative con un'intervista completata, e la scheda Summary le conta. Filtra il Deal log per esito per confrontare le interviste su vinte e perse con la divisione equa che raccomanda Clozd.
Gli altri modelli gratuiti sul tema sono più scarni. Quello di Mural è una lavagna dietro una registrazione, il foglio di Klue sta dietro un modulo e l'XLSX di Unkover ha otto campi e nessun dato di esempio. Chi usa Excel può scaricare il nostro file da File, Scarica, Microsoft Excel (.xlsx). Le formule usano COUNTIFS, INDEX, MATCH e SUMPRODUCT, quindi Excel e LibreOffice le ricalcolano senza modifiche.
Dai motivi ai cambiamenti concreti
Un conteggio non è un cambiamento. La scheda Reason codes dà a ogni codice un team responsabile suggerito. Il Deal log annota la domanda successiva che il venditore ha fatto una volta chiaro il codice. Quelle domande sono l'inizio della correzione, perché verificano se il motivo era reale o una scusa cortese.
Ecco i sei codici che sono costati trattative a Spona, con il responsabile che suggeriamo e la domanda successiva fatta dal venditore:
| Codice | Responsabile suggerito | Domanda successiva fatta |
| Existing contract | Sales | Quando si decide il rinnovo, e possiamo testare una lacuna prima di allora? |
| Budget constraint | Pricing | Quale strumento o costo di ricerca attuale dovrebbe sostituire un pilota riuscito? |
| Workflow change | Product | Quale parte si potrebbe testare senza cambiare l'attuale workflow di invio? |
| Project paused | Sales | Chi dovrebbe guidare la prossima decisione e quando dovremmo riparlarne? |
| No urgency | Marketing | Quale evento renderebbe questo un progetto attivo? |
| Procurement delay | Sales | Quali prove aiuterebbero chi valuta a chiudere la decisione? |
Tre delle sei domande riguardano i tempi: una data di rinnovo, una data per riparlarne, un evento che renda attivo il progetto. Questo indica una correzione nella qualificazione più che nel prodotto. Chiedi la data di rinnovo del fornitore attuale e il responsabile del progetto alla prima chiamata. La nostra checklist di qualificazione dei lead è il posto giusto per queste due domande.
Workflow change chiama in causa prodotto e onboarding. L'acquirente perso non poteva cambiare processo in piena migrazione, quindi la modifica è un pilota che gira accanto al workflow attuale invece di sostituirlo. Budget constraint chiama in causa il pricing. La sua domanda chiede quale costo attuale un pilota sostituirebbe, e così trasforma «niente budget» in un confronto.
I codici di vittoria meritano lo stesso trattamento. Verified coverage ha vinto più trattative di ogni altro codice. La prova che lo sostiene, un test sugli account target dell'acquirente, va portata alla prima chiamata, non alla terza. Flexible purchase ha vinto 23 trattative, il che suggerisce di aprire con il piccolo pilota invece che con il contratto annuale.
Rivedi i conteggi con una cadenza fissa. Clozd raccomanda una revisione fissa mensile o trimestrale. La cadenza mensile va bene per un team che chiude 30 o più trattative al mese; quella trimestrale per uno più piccolo. Il resoconto pratico di Cotera descrive un riepilogo mensile di una pagina in tre paragrafi: i numeri, lo schema e le azioni.
La scheda Summary ti dà il primo paragrafo. Il secondo è il codice il cui conteggio si è mosso di più. Il terzo dice chi ha cambiato cosa, e la data in cui lo verificherai di nuovo.
Get thousands of leads in 4 minutes.
Stop stitching tools together.
Start with verified sales data, delivered in minutes.
No contracts · No setup · No onboarding
FAQ sull'analisi win loss
Chi dovrebbe condurre le interviste win loss?
Non il venditore che ha seguito la trattativa. Klue indica un intervistatore imparziale, con le vendite che fanno la presentazione iniziale. Pragmatic Institute vuole che a guidare siano le persone di prodotto, perché gli acquirenti possono tacere critiche che danneggerebbero il venditore.
Secondo il sondaggio di Clozd, chi si affida a una società esterna ha più del doppio delle probabilità di dire che il feedback va abbastanza in profondità. Per un team piccolo, un responsabile vendite che non ha seguito la trattativa è la via di mezzo pratica.
Quante trattative servono per un'analisi win loss?
Klue fissa la soglia a 10 trattative simili per schema. Per le interviste, Clozd rileva che le risposte arrivano a saturazione tra 25 e 30 per segmento. User Intuition fissa il minimo per schemi indicativi a da 20 a 30 interviste.
Liminal osserva che la maggior parte dei programmi intervista da 8 a 12 acquirenti a trimestre, troppo pochi per vedere un cambiamento. Le 29 interviste di Spona in quattro mesi rientrano negli intervalli di Clozd e User Intuition, lette come un unico segmento.
Come si calcola il win loss?
Il tasso di vittoria è il numero di trattative vinte diviso per le trattative chiuse. L'esempio di Klue divide 40 vittorie per 100 trattative chiuse. Le stesse 40 vittorie contro 60 sconfitte danno un rapporto win loss di due a tre. Decidi se «chiuse» include le trattative senza decisione e dichiaralo nel report.
Il registro di Spona calcola due tassi dagli stessi conteggi: il 62,0% di tutte le trattative chiuse e il 77,3% di quelle decise. Il modello li mostra entrambi, perché la differenza tra i due viene dalle tue trattative senza decisione.
I motivi win loss del CRM possono sostituire le interviste?
No, ma tienili entrambi. Il codice del CRM costa poco, è immediato e copre ogni trattativa, quindi è il denominatore giusto per i conteggi. In HubSpot, la prima correzione è limitare le proprietà predefinite dei motivi a un elenco fisso dei tuoi codici.
L'intervista è lenta e copre un campione, ma è l'unica fonte che l'acquirente controlla. Il dato di Clozd sul 15% di coincidenza è il motivo per cui il modello ha una colonna Match. Ti mostra quanto spesso le due fonti concordano sulle tue trattative.
Share this article
GET FREE LEADS





