Utilizziamo i cookie
Utilizziamo cookie e tecnologie simili per migliorare la tua esperienza, analizzare il traffico e personalizzare i contenuti. Puoi accettare tutti i cookie o rifiutare quelli non essenziali.
19 Oct 2026
La maggior parte delle aziende che intervista i clienti dopo un acquisto segue sempre lo stesso schema: esporta gli ordini dall’ERP o dalla piattaforma ecommerce una volta al giorno, li abbina a un elenco di contatti e invia un’email CSAT tre giorni dopo. Funziona, tecnicamente. Ma tratta ogni ordine come lo stesso evento, ignora il fatto che “consegnato”, “reso” e “ticket aperto” sono momenti completamente diversi con domande completamente diverse da porre, e opera sempre con un giorno di ritardo rispetto alla realtà.
La soluzione non è un export migliore. È trattare ogni evento commerciale — ordine effettuato, spedito, consegnato, reso, rimborsato, ticket di assistenza risolto — come un proprio trigger che attiva il sondaggio giusto, alla persona giusta, nel momento giusto, con il contesto dell’ordine già collegato. Questo è un problema di collegamento, non di progettazione del sondaggio, ed è importante essere onesti su cosa richieda davvero questa connessione.
Un singolo trigger batch legato a “ordine creato” non può distinguere un cliente il cui pacco è arrivato in orario da uno il cui pacco è bloccato in un magazzino. Non può distinguere un acquirente alle prime armi da qualcuno al decimo riordino. E di sicuro non può dirti che l’ordine in questione era in realtà un reso, non un acquisto — perché al momento in cui viene eseguito l’export CSV, il reso è già stato ricondotto a “ordine” come generico campo di stato.
Il risultato sono sondaggi che pongono la domanda sbagliata al momento sbagliato: un’email NPS che arriva lo stesso giorno di una spedizione in ritardo, oppure un sondaggio di soddisfazione generico inviato a qualcuno che è nel bel mezzo di un RMA e vuole solo il proprio rimborso. Nulla di tutto questo è un fallimento nella scrittura del sondaggio. È un fallimento idraulico — il sistema di feedback non ha mai ricevuto l’evento specifico, solo uno snapshot giornaliero.
Una volta che si guarda al ciclo di vita commerciale come a una sequenza di eventi distinti anziché a una singola riga in una tabella, la strategia del sondaggio diventa molto più chiara:
Ognuno di questi merita un set di domande diverso, un canale diverso e, in diversi casi, un’urgenza diversa. Una spedizione in ritardo potrebbe giustificare un check-in proattivo immediato; un ticket risolto potrebbe giustificare un CSAT lo stesso giorno. Gli export batch appiattiscono tutto questo in un unico passaggio indifferenziato di “invia sondaggio”.
Per distributori e rivenditori di fascia media che utilizzano Tally Prime, il Tally Prime Connector è il percorso più diretto dall’evento commerciale al trigger del sondaggio. Viene installato come file TDL e legge tipi di voucher standard e personalizzati direttamente da un’azienda Tally — voucher di vendita, note di credito, ricevute, anagrafiche di inventario, qualsiasi cosa l’azienda tracci. Ogni tipo di transazione può essere configurato in modo indipendente: il proprio metodo di autenticazione (chiave API, Basic Auth, OAuth 2.0 con rinnovo automatico del token, o richieste firmate HMAC), la propria modalità di trigger (Realtime al salvataggio, Batch con intervallo di 5–60 minuti, Programmato giornaliero/settimanale/mensile, o un export manuale una tantum) e il proprio ID workflow.
Questa granularità per tipo di transazione è fondamentale qui. I voucher di vendita possono funzionare in modalità Realtime e avviare immediatamente un workflow quando un ordine viene fatturato. Le note di credito — cioè i resi — possono funzionare con la stessa impostazione Realtime ma instradare verso un workflow completamente diverso che avvia un modulo di intake RMA anziché un sondaggio di soddisfazione. Le anagrafiche di inventario, che non necessitano di una reazione istantanea, possono essere raggruppate in batch in un workflow notturno destinato invece all’analisi.
Non tutte le aziende utilizzano Tally. Shopify, Magento, un sistema di gestione ordini personalizzato o uno strumento di fulfillment sviluppato internamente possono tutti inviare eventi del ciclo di vita dell’ordine a SurveyAnalytica come payload webhook generici, che il motore di workflow accetta come tipo di trigger di prima classe insieme agli eventi di clickstream e agli eventi del ciclo di vita dei thread. La meccanica è la stessa indipendentemente dalla fonte: un evento arriva con campi strutturati (ID ordine, ID cliente, elenco SKU, stato, timestamp), e una condizione di workflow decide cosa succede dopo in base al campo di stato — “consegnato” si ramifica in un modo, “reso_richiesto” si ramifica in un altro.
Per le organizzazioni soggette a rigidi controlli di rete aziendale, il traffico in uscita del workflow può essere instradato tramite un proxy HTTP, HTTPS (con tunnel CONNECT) o SOCKS5, il che è più importante di quanto sembri — molti team IT di fascia media non approveranno una nuova integrazione SaaS finché non avranno confermato che rispetta le regole di uscita esistenti.
Gli eventi d’ordine ti dicono cosa è successo. Non ti dicono cosa lo ha preceduto. Gli SDK del Clickstream Publisher (web, React Native, Flutter, iOS, Android) catturano la sessione di navigazione prima di un acquisto — pagine di prodotto visualizzate, abbandono del carrello, tempo trascorso sulla pagina della politica di reso — e la chiamata identify collega quella sessione anonima al contatto noto una volta che il cliente effettua l’accesso o il checkout. Ciò significa che quando un evento di ordine effettuato attiva un workflow, lo stesso ID contatto ha già una traccia comportamentale collegata, informazione utile quando si deve decidere se un punteggio CSAT basso sia un’anomalia o uno schema ricorrente.
Ecco una configurazione concreta per un distributore di fascia media che utilizza Tally Prime per la fatturazione e l’evasione ordini:
Nulla in questa configurazione ha richiesto sviluppo personalizzato. Ha richiesto di mappare correttamente i campi del voucher sulle variabili di workflow, scegliere la modalità di trigger giusta per ogni tipo di transazione e decidere quale ramo dovesse prendere ciascun evento — lavoro di configurazione, non di codice.
Vale la pena essere diretti sul costo di configurazione, perché i fornitori che vendono solo il livello del sondaggio raramente devono esserlo. Collegare gli eventi commerciali ai flussi di feedback richiede: un ID cliente o contatto presente nel payload del sistema sorgente (se il tuo ERP non lo cattura in modo affidabile, l’abbinamento si rompe ancora prima di iniziare); una configurazione corretta per tipo di transazione nel connettore, inclusi autenticazione e modalità di trigger; lavoro DNS se si desiderano domini di invio personalizzati o un dominio personalizzato per il portale partecipanti; e qualcuno nel team che comprenda sia il modello dati del sistema sorgente sia il motore di workflow abbastanza bene da mappare correttamente i campi. Nulla di tutto questo è esotico, ma non è nemmeno un interruttore da cinque minuti, e qualsiasi guida all’integrazione che lasci intendere il contrario sta saltando la parte che determina realmente se la pipeline regge sotto volumi d’ordine reali.
Lo schema descritto sopra funziona perché SurveyAnalytica tratta gli eventi commerciali come trigger di workflow nativi anziché richiedere un passaggio di importazione separato. Il motore di workflow accetta payload webhook, eventi del connettore, eventi di clickstream ed eventi del ciclo di vita dei thread come tipi di trigger equivalenti, e la configurazione per tipo di transazione nel Tally Prime Connector significa che un voucher di vendita e una nota di credito provenienti dallo stesso sistema contabile possono guidare esperienze di sondaggio completamente diverse senza middleware personalizzato.
Le sezioni ripetibili gestiscono il problema strutturale che i costruttori di sondaggi generici non affrontano — un reso con quattro articoli non dovrebbe produrre un unico blocco di testo unito e illeggibile, dovrebbe produrre quattro risposte analizzate in modo indipendente con una numerazione stabile degli articoli per il reporting a valle. E poiché la stessa piattaforma ospita il sondaggio, il workflow e il livello di analisi, le schede KPI e i punteggi di sentiment generati da un modulo RMA sono immediatamente disponibili su una dashboard operativa senza un passaggio separato di export e abbinamento.
Nulla di tutto questo sostituisce l’avere ID cliente puliti nei propri sistemi sorgente o l’eseguire correttamente la configurazione DNS e di autenticazione — quel lavoro preparatorio spetta all’acquirente, non alla piattaforma. Ciò che viene eliminato è la necessità di un livello di integrazione separato solo per far sì che un evento d’ordine attivi innanzitutto il sondaggio giusto.
Build surveys, run campaigns, and analyze responses with AI — free to start.
Il divario tra “inviamo sondaggi post-acquisto” e “sappiamo esattamente perché questo cliente è insoddisfatto e quale ordine lo ha causato” non è un problema di progettazione del sondaggio — è un problema di collegamento. Ordine effettuato, spedito, consegnato, reso e rimborsato sono cinque momenti diversi che meritano cinque domande diverse, attivate dall’evento reale anziché da un job batch notturno. Se il trigger è corretto, l’insight segue naturalmente; se è sbagliato, nessuna progettazione ingegnosa delle domande potrà rimediare a un sondaggio che arriva nel momento sbagliato ponendo la domanda sbagliata.
No comments yet. Be the first to comment!