Un contratto viene annullato: come correggere la vendita già inviata alle campagne?

Il commerciale registra un contratto, la vendita torna alle campagne e il report si aggiorna. Poi il cliente annulla. Nel gestionale la situazione cambia; nella piattaforma pubblicitaria potrebbe essere rimasta la versione felice della storia.

Collegare advertising e vendite significa gestire anche ciò che succede dopo il primo invio. Annullamenti, riduzioni di importo ed errori di inserimento non sono dettagli amministrativi: cambiano il risultato con cui valuti le campagne. La soluzione non è cancellare una riga dal CRM e sperare che tutti gli altri sistemi se ne accorgano.

Prima domanda: che cosa rappresentava quella conversione?

Distinguerei tre situazioni. Un contratto valido viene successivamente annullato; un contratto resta valido ma cambia importo; un record era sbagliato fin dall’inizio, per esempio perché duplicato. Sono eventi diversi e devono avere motivi di rettifica diversi.

Conta anche la definizione iniziale. Se misuri “contratto firmato”, non stai necessariamente misurando “servizio attivato” o “pagamento ricevuto”. Decidi se l’annullamento corregge il risultato netto che vuoi rappresentare oppure se firma e attivazione sono fasi separate da leggere distintamente. Non cambiare significato alla metrica a metà report.

È lo stesso criterio da applicare quando scegli quale valore del contratto inviare alle campagne: il numero deve avere una definizione stabile, non soltanto una valuta accanto.

La correzione parte dal dato aziendale

Nel CRM o nel gestionale manterrei la storia della vendita, aggiungendo stato aggiornato, motivo della variazione, valore precedente, valore corretto, data effettiva e responsabile della modifica. Cancellare il record originale rende più difficile ricostruire ciò che è già stato trasmesso.

Il registro degli invii dovrebbe conservare anche piattaforma, azione di conversione, identificatore originale ed esito della rettifica. Separerei chiaramente “da correggere”, “inviato”, “accettato” e “da verificare nel report”. Un’automazione eseguita non dimostra che la vendita giusta sia stata aggiornata.

La priorità è avere una fonte aziendale corretta anche quando una piattaforma non consente più di modificare il dato. Il report direzionale non deve mantenere una vendita annullata soltanto per coincidere con il pannello pubblicitario.

Google Ads: ridurre il valore e ritirare non sono la stessa cosa

Nella procedura di caricamento degli aggiustamenti, Google distingue RESTATE, per ridefinire il valore, e RETRACT, per ritirare la conversione. L’aggiustamento usa riferimenti alla conversione originale, come ID ordine e nome dell’azione, insieme all’ora della modifica. Per il caricamento tramite file, nuove conversioni e aggiustamenti vanno tenuti separati. Fonte: Google Ads, procedura di aggiustamento delle conversioni.

Attenzione allo zero: nella stessa procedura Google avverte che ridurre il valore a zero ritira la conversione e che gli aggiustamenti successivi su una conversione ritirata vengono ignorati. Non userei quindi zero per indicare “importo ancora da controllare”. Prima della rettifica verificherei anche finestre temporali e requisiti del metodo utilizzato: non è un’operazione sempre disponibile, né identica per tutte le origini del dato.

Il connettore deve supportare proprio la modifica che ti serve

Non basta sapere che un’integrazione “invia conversioni”. Serve sapere se gestisce anche le rettifiche, con quali campi e quale comportamento in caso di errore.

La documentazione Data Manager API, aggiornata il 7 ottobre 2026, descrive un meccanismo specifico: nella stessa azione di conversione, un transactionId corrispondente identifica un aggiustamento; se non corrisponde, la richiesta viene trattata come una nuova conversione. Il nuovo valore sostituisce quello registrato, senza aumentare il conteggio quando l’evento è abbinato. Fonte: Google for Developers, conversion adjustments con Data Manager API.

Questo rende l’identificatore una parte decisiva del controllo. Cambiarlo per “far passare” una richiesta può trasformare una correzione in un nuovo evento. La stessa pagina descrive aggiornamenti del valore e integrazioni dei dati utente: non va interpretata come prova che qualunque operazione di ritiro sia disponibile nello stesso modo.

Per Meta, LinkedIn o un’integrazione server-side con Stape preparerei una verifica separata delle funzionalità effettive. Non trasferirei nomi dei campi e comportamenti di Google sugli altri canali. Se una destinazione non supporta la rettifica necessaria, documenterei il limite nel reporting anziché simulare una cancellazione con un evento inventato.

Un esempio: il contratto scende da 5.000 a 3.500 euro

Esempio interamente ipotetico: un contratto viene registrato e inviato con valore di 5.000 euro. Successivamente il perimetro del lavoro si riduce e il valore concordato diventa 3.500 euro.

Il dato aziendale conserva la variazione. Nel percorso di aggiornamento del valore documentato dalla Data Manager API, l’importo da inviare sarebbe il nuovo totale di 3.500 euro, non una nuova vendita da 3.500 né la sola differenza di meno 1.500. Prima si verifica che identificatore, destinazione e azione corrispondano all’evento originario.

Se invece il contratto fosse annullato completamente, cambierebbe l’operazione richiesta. Il team dovrebbe scegliere una procedura di ritiro supportata, non riutilizzare automaticamente il flusso di riduzione dell’importo.

La verifica finale riguarda anche i report

Dopo l’elaborazione confronterei il risultato aziendale aggiornato con quanto modificato nella piattaforma. Google dispone di segmenti dedicati agli aggiustamenti, utili per distinguere conteggi e valori originali dalle variazioni successive. Fonte: Google Ads, impatto degli aggiustamenti sui report.

Controllerei un campione dall’annullamento fino al report, con lo stesso metodo usato per collaudare il ritorno delle vendite alle campagne. La domanda conclusiva è semplice: stiamo ancora premiando risultati che non esistono più?

Il collegamento si completa quando gestisce anche le eccezioni. Se oggi le tue automazioni conoscono solo lo stato “vinto”, possiamo progettare insieme rettifiche, controlli e responsabilità.

Fonti ufficiali consultate il 16 ottobre 2026. L’esempio è ipotetico e non rappresenta un caso cliente. Supporto tecnico, tempi ed effetti dipendono dalla piattaforma e dall’integrazione utilizzata; nessun miglioramento delle performance è garantito.