---
title: "Come concatena sequenze di email in modo che ciò che fa un potenziale cliente decida cosa succede dopo?"
blueprint: 016
slug: chaining-email-sequences-on-engagement
category: Outreach
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/it/blueprints/chaining-email-sequences-on-engagement/
language: it
translation_of: https://blueprints.coevera.com/blueprints/chaining-email-sequences-on-engagement/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# Come concatena sequenze di email in modo che ciò che fa un potenziale cliente decida cosa succede dopo?

**Risposta breve.** **Una sequenza di email è un circuito chiuso.** Iscrive un record, invia i
suoi passi e termina. Non esiste alcun nodo che iscriva qualcuno a *un'altra* sequenza, quindi una
scala a più fasi non può essere costruita con le sole sequenze.

Ciò che una sequenza ha, invece, sono le **azioni globali**: agganci che scattano alla
**risposta**, alla **disiscrizione**, al **mancato recapito** e a una **condizione
personalizzata**, ed è quest'ultima il modo in cui si intercetta un'apertura o un clic. Tutte
tranne il mancato recapito possono creare un record da un modello. Quindi la catena si costruisce
così: la sequenza **crea un task che porta un puntatore alla sequenza successiva**, e un processo
ricevitore attivato dalla creazione del task scrive quel puntatore sul contatto ed esegue una
nuova iscrizione. **Il task è il bus dei messaggi** tra due sequenze che non possono vedersi a
vicenda.

L'avvertenza che conta più del meccanismo: quei task sono **contabilità, non lavoro**. Se
costruisce la scala in modo che nulla chieda mai a una persona di agire, una campagna bloccata
diventa invisibile: centinaia di record di attività, e nessuno che se ne accorga.

## 01 · Il problema di business

Ha un elenco di persone che vale la pena contattare e un messaggio che merita più di un invio. Una
singola email viene ignorata; cinque identiche sono spam. Ciò che vuole davvero è una scala in cui
**il comportamento decide il gradino**:

- chi **risponde** dovrebbe smettere subito di ricevere la campagna e arrivare a una persona;
- chi **apre o fa clic** ha mostrato interesse e dovrebbe ricevere il messaggio successivo,
  diverso;
- chi **non interagisce mai** dovrebbe avanzare a tempo, oppure fermarsi;
- chi **si disiscrive o ha un mancato recapito** dovrebbe essere escluso ovunque, in modo
  permanente;
- e lei dovrebbe poter rispondere a **«questa campagna è ancora in corso?»** senza aprire cinque
  schermate.

I primi quattro sono meccanismo. Il quinto è quello che decide se la macchina vale la pena di
averla, ed è quello che quasi non viene mai costruito.

## 02 · Perché l'approccio ovvio non funziona

### Un'unica lunga sequenza con tutti i passi

La lettura più semplice di «campagna multi-touch» è una sequenza con dieci passi. Invia a tempo e
non può ramificarsi: un destinatario che fa clic al passo due riceve il passo tre esattamente come
se non lo avesse fatto. L'unica leva comportamentale che una sequenza ha sul proprio flusso è la
**rimozione dalla sequenza**: può fermarsi, ma non può cambiare direzione.

### Aspettarsi che una sequenza passi il testimone a un'altra sequenza

L'idea successiva è un insieme di sequenze brevi in cui l'ultimo passo di ciascuna iscrive alla
successiva. Un passo del genere non esiste. I nodi di una sequenza inviano email, attendono e
creano record: **l'iscrizione a una sequenza non è un'azione che una sequenza possa compiere**.
Nulla nell'editor lo lascia intendere finché non si cerca il nodo e lo si trova assente.

### Usare invece un processo pianificato di scansione

Un processo pianificato giornaliero sui contatti, che sposta chiunque abbia cambiato engagement,
funziona, e butta via proprio ciò per cui valeva la pena farlo. L'engagement è un **evento**:
aperto alle 09:14, cliccato il link dei prezzi, risposto. Una scansione notturna vede solo lo
stato, arriva fino a un giorno dopo, e non può dirle *quale* messaggio ha prodotto la reazione.

### Lasciare che il processo ricevitore scatti per chiunque

Una volta costruita la catena basata sui task, il processo ricevitore osserva la creazione dei
task. Se ne lascia l'attore su **qualsiasi utente**, la lettura predefinita di «quando viene
creato un task», ogni task che un venditore crea a mano viene valutato dal meccanismo della
campagna. La correzione è una sola impostazione, e il §5 spiega perché non è facoltativa.

## 03 · Modello dati

Tre oggetti e una convenzione reggono l'intero progetto.

| Elemento | Ruolo |
|---|---|
| **Sequenza di email** | Invia i passi. Termina. Non può concatenarsi |
| **Task** (creato da un'azione globale) | **Il messaggio.** Porta il puntatore alla sequenza successiva |
| **Processo ricevitore** | Attivato dalla creazione del task; scrive il puntatore sul contatto e passa il testimone |
| **Contatore dei passi** sul contatto | Il gradino su cui si trova il contatto. Il processo di iscrizione si ramifica in base a esso |

**Fonte.** Centro assistenza Coevera, [Using email sequences in
Coevera](https://help.coevera.com/en/articles/5694513-using-email-sequences-in-coevera): la
sequenza così come viene fornita, prima che vi si concateni qualcosa.

### Che cosa iscrive una sequenza, e su che cosa

Il trigger di una sequenza indica un **tipo di entità** e uno specifico **id di campo**, il campo
email a cui invia, con un **lookup** facoltativo che le permette di raggiungere un indirizzo su un
record correlato. Questo dettaglio conta più di quanto sembri: una sequenza che iscrive lead può
inviare all'email del contatto principale tramite la relazione, ed è per questo che il record
iscritto e il destinatario non devono per forza coincidere.

### Le impostazioni che delimitano una sequenza

| Impostazione | Che cosa fa |
|---|---|
| `timezone`, `dayOfWeek`, `fromTimeOfDay`/`toTimeOfDay` | Finestra di invio: al di fuori di essa gli invii vengono trattenuti |
| `activeFrom`, `activeTo` | Durata della campagna, sotto forma di date |
| `autoUnenrollWhenExpired` | Se chi è ancora nella sequenza ne viene rimosso alla scadenza |
| `everyEmailStartsConversation` | Se ogni invio apre una nuova conversazione o ne continua una |
| `triggerProcess`, `triggerProcessId` | **Il processo ricevitore indicato per nome.** Un processo per sequenza |

### Perché il messaggio deve essere un record

Un'azione globale può creare un **task**, un **lead** o un testo, e le statistiche li contano
separatamente. Un task è il vettore giusto qui perché costa poco, si collega al contatto, contiene
campi personalizzati, e la sua creazione è una superficie di trigger. Il puntatore viaggia in uno
di quei campi.

> **L'alternativa scartata.** L'istinto ordinato è un contatore che la catena incrementa: il passo
> 1 diventa il passo 2, che diventa il passo 3. Ciò che fa invece una scala reale è far sì che
> ogni sequenza **indichi quella che le succede**, perché il modello del task è il punto in cui
> viene scritto il valore e il modello è per sequenza. Questo fa della catena un insieme di
> puntatori scritti a mano, il che è più flessibile (un ramo può saltare un gradino) e più fragile
> (§6).

## 04 · Configurazione a livello di campo

### Le quattro azioni globali, per intero

Sono gli unici agganci comportamentali della sequenza. Gli eventi sono esattamente quattro:

| Evento | Rimozione dalla sequenza | Invio di un'email diversa | Creazione di un record | Inoltre |
|---|---|---|---|---|
| **On reply** | ✅ | ✅ | ✅ | — |
| **On unsubscribe** | implicita | — | ✅ | — |
| **On custom condition** | ✅ | ✅ | ✅ | **accetta un filtro** |
| **On bounce** | ✅ | — | — | **può disiscrivere il destinatario** |

Ognuna è un flag più il suo contenuto: una risposta può rimuovere dalla sequenza, inviare una
risposta interlocutoria e creare un task, indipendentemente l'una dall'altra.

### La condizione personalizzata è dove risiedono aperture e clic

Risposta, disiscrizione e mancato recapito sono eventi fissi. **Apertura e clic non sono eventi a
cui ci si iscrive**: sono condizioni che si descrivono. La condizione personalizzata accetta un
normale filtro, e la forma funzionante è composta da due clausole:

```
Message.subject         Is  "{the subject of the step you are watching}"
Email.tracking_status   Is  Opened  OR  Clicked
```

La clausola sull'oggetto è ciò che limita la condizione a *un solo passo* della sequenza anziché a
qualsiasi messaggio mai inviato. Significa anche che **modificare l'oggetto di un passo rompe,
senza che nulla lo segnali, la condizione che lo osserva**: il filtro continua a cercare una
stringa che nessuno invia più.

### Il puntatore e il contatore

| Campo | Si trova su | Scritto da | Letto da |
|---|---|---|---|
| Puntatore alla sequenza successiva | Task | Il modello di task della sequenza | Il processo ricevitore |
| Contatore dei passi | Contact | Il processo ricevitore (e il processo di ingresso, una volta) | I rami del processo di iscrizione |
| Appartenenza alla campagna | Contact | Il processo di ingresso | Ogni controllo della catena |
| Flag di esclusione | Contact | Disiscrizione, mancato recapito o una persona | Ogni controllo della catena |

**Dia al campo puntatore un nome che dica ciò che fa.** È il valore più portante dell'intera
catena e il più facile da scambiare per qualcosa di innocuo: il §6 ne descrive la conseguenza.

### Una nota sulle condizioni booleane nei filtri

I controlli di esclusione verificano valori booleani, e un test booleano «è falso» viene
memorizzato **senza alcun operatore**: `operator: null` con un valore di `0`. È coerente ovunque
si filtrino valori booleani, quindi una regola con un operatore null su un campo casella di
controllo è normale e non rotta. Vale la pena saperlo prima di mettersi a cercare un operatore
mancante che non doveva mai esserci.

## 05 · Automazione e logica

### Il processo ricevitore, e l'impostazione che lo rende sicuro

Un solo processo, attivato dalla **creazione del task**, legge il puntatore e instrada. L'attore
del suo trigger è la parte da impostare correttamente. L'attore di un trigger di record assume uno
di quattro valori:

| Attore | Scatta quando il record viene creato da… |
|---|---|
| `AnyUser` | chiunque, **compresa una persona** |
| `ProcessOwner` | il proprietario stesso del processo |
| `SelectedUnitsAndUsers` | un insieme definito di unità o utenti |
| **`ApplicationsOnly`** | **solo l'automazione, mai una persona** (letto dall'enum, non testato) |

**Solo applicazioni è la scelta corretta per un processo ricevitore**, ed è la differenza tra un
circuito chiuso e uno in cui chiunque può spingere qualcuno per errore. Un venditore che registra
una chiamata non dovrebbe iscrivere di nuovo un potenziale cliente a una campagna drip.

### Il percorso, dall'inizio alla fine

```
sequence step / global action fires
  └─ creates Task  { pointer = "next sequence" }
       └─ catcher process  (Task · Create · ApplicationsOnly)
            ├─ filter: task activity type is an engagement type
            ├─ filter: pointer is not empty
            ├─ filter: contact is in this campaign, not unsubscribed, not archived
            └─ write Contact.step_counter = Task.pointer
                 └─ hand off to the enrolment process
                      └─ branch on step_counter → enrol into that sequence
```

Il passaggio finale è una chiamata a un sottoprocesso, che è il modo in cui qui qualsiasi cosa
attraversa il confine di un processo: il vincolo e la disciplina dei nomi sono nel [Blueprint
011](https://blueprints.coevera.com/it/blueprints/keeping-hundreds-of-automations-maintainable/).

### La scala di iscrizione condivisa è la parte fragile

Nella pratica il processo di iscrizione non viene costruito per ogni campagna: si accumula. Un
esempio in produzione contiene decine di campagne non correlate in un unico processo di oltre
cento nodi, con il controllo di una campagna a diciannove livelli di profondità. Poiché un filtro
è un unico controllo i cui rami seguono la regola della **prima corrispondenza**, l'iscrizione di
un contatto dipende dalla sua posizione rispetto a diciannove campagne con cui non ha nulla a che
fare. Qualsiasi cosa faccia corrispondere prima un controllo precedente rende irraggiungibile
quello successivo, senza che nulla lo segnali.

Quando conta, dia a una campagna un proprio processo di iscrizione. La scala condivisa è comoda
una volta e costosa da lì in poi.

### Faccia sì che un gradino produca lavoro

L'intera catena descritta sopra è meccanismo. Da qualche parte al suo interno, **un ramo deve
creare un task che ci si aspetta davvero che una persona svolga**: aperto, assegnato a un
proprietario reale, con una scadenza. Il candidato ovvio è l'aggancio sulla risposta, e il
successivo è un clic su qualcosa di commercialmente rilevante. Il [Blueprint
014](https://blueprints.coevera.com/it/blueprints/customer-health-score-churn-risk/) sostiene la
stessa tesi dal lato opposto: l'automazione dovrebbe indirizzare l'attenzione verso una persona, e
dovrebbe essere una persona a impegnarsi.

## 06 · Limiti e compromessi

> **Un task completato non è lavoro.** Dove ogni modello di task viene creato con uno stato già
> completato, assegnato a un solo amministratore, e consumato da un processo che accetta solo
> l'automazione, la scala produce **record di attività e nessun elemento di lavoro**. È facile
> farlo per errore, perché i task esistono per trasportare un valore e non per chiedere qualcosa a
> qualcuno, e il risultato è una campagna che sembra attiva in ogni report e non chiede nulla a
> nessuno.

- **Poiché nulla chiede, nessuno se ne accorge.** Osservato su una scala attiva: una coorte ferma
  al primo passo per mesi, senza alcuna risposta registrata, alcun incontro e alcuna squalifica
  per nessuno di loro. La catena funzionava; il flusso in ingresso si era fermato. Nulla segnala
  l'assenza di nuovi record, perché una campagna vuota e una settimana tranquilla hanno la stessa
  forma: la stessa classe di errore dell'interruzione della replica descritta nel [Blueprint
  009](https://blueprints.coevera.com/it/blueprints/automating-on-integration-owned-fields/).
- **Un campo puntatore con un nome sbagliato è un filo scoperto.** Un campo etichettato come una
  durata in minuti, che contiene il numero della sequenza successiva, svolge il compito più
  delicato della catena sotto un nome che invita a modificarlo. Chiunque lo cambi, una persona che
  riordina un task o qualsiasi automazione futura che tocchi un campo con quel nome, reinstrada in
  silenzio i contatti in una campagna diversa. Gli dia un nome secondo la sua funzione, e
  consideri qualsiasi etichetta breve e generica su un campo di controllo come un difetto pronto a
  manifestarsi.
- **La scala può terminare grazie a un'impostazione anziché ai propri dati.** Una sequenza finale
  il cui modello di task punta ancora a un gradino precedente, e che si ferma solo perché il suo
  flag di creazione del task è disattivato, è **a una casella di controllo da un ciclo infinito**.
  Renda terminale nei dati il puntatore dell'ultimo gradino, zero o un valore che nessun ramo
  riconosce, così che attivare il flag sia sicuro.
- **Nulla fa avanzare il contatore tranne l'engagement.** Il processo di ingresso scrive il passo
  uno; solo il processo ricevitore lo fa avanzare. Un contatto che non apre, non fa clic e non
  risponde mai resta al passo uno per sempre: comportamento corretto, e invisibile a meno che
  qualcuno non ne faccia un report.
- **Modificare l'oggetto di un'email rompe la condizione che lo osserva.** La condizione
  personalizzata cerca la stringa dell'oggetto, quindi un ritocco al testo stacca l'aggancio senza
  che nulla lo segnali. Nulla fallisce; il gradino smette semplicemente di intercettare chiunque.
- **La gestione dei mancati recapiti brucia gli indirizzi in modo permanente.** Al mancato
  recapito si può disiscrivere il destinatario, il che è giusto per la recapitabilità e non
  perdona un elenco di cattiva qualità: un'importazione validata male esclude una parte di sé al
  primo contatto, e quei contatti vengono poi esclusi da ogni campagna futura dagli stessi
  controlli di esclusione. Validi prima del primo invio: il [Blueprint
  005](https://blueprints.coevera.com/it/blueprints/contact-migration-without-data-loss/) descrive
  che aspetto ha un'importazione non validata.
- **Le statistiche sono per sequenza, non per catena.** Ogni sequenza riporta iscrizioni, invii,
  destinatari, aperture, clic, risposte, mancati recapiti, disiscrizioni, task e lead creati, e un
  **conteggio delle iscrizioni correnti**, ma nulla aggrega una scala. Lo stato di salute della
  campagna nel suo insieme va ricostruito a mano da cinque schermate, ed è esattamente per questo
  che nessuno lo fa.

### Il compromesso da dichiarare apertamente

Costruire la scala con i task consente una vera ramificazione comportamentale su una piattaforma
le cui sequenze non possono ramificarsi, usando solo componenti nativi. Il costo è che la logica
della catena risiede in tre posti contemporaneamente, il modello di task dentro ogni sequenza, i
filtri del processo ricevitore e i controlli del processo di iscrizione, e nessuna schermata li
mostra tutti e tre insieme. Con una convenzione sui nomi e un diagramma è sostenibile, senza non
lo è. Se la campagna è davvero lineare e nessuno ha bisogno di ramificare in base al
comportamento, una sola sequenza con più passi è la risposta onesta e mantenerla in vita costa una
frazione di quanto costa la catena.

## 07 · Verifica

Letto da uno spazio in produzione: una scala di sequenze a cinque gradini, il suo processo
ricevitore, il processo di iscrizione condiviso e lo schema alla base di tutti e tre.

- **L'insieme delle azioni globali è stato letto dallo schema**, confermando esattamente quattro
  eventi, risposta, disiscrizione, condizione personalizzata, mancato recapito, con i loro flag
  indipendenti per rimozione dalla sequenza, invio di email e creazione di record, che solo la
  condizione personalizzata ha un filtro, e che solo il mancato recapito offre di disiscrivere il
  destinatario.
- **La condizione personalizzata è stata letta da una sequenza attiva:** una clausola sull'oggetto
  combinata con uno stato di tracciamento dell'email aperta o cliccata.
- **Le impostazioni della sequenza**, cioè finestra di invio, fuso orario, attiva da e attiva fino
  a, rimozione automatica alla scadenza, ogni email avvia una conversazione, e il processo di
  trigger indicato per nome, sono state lette dallo schema e confermate come compilate su sequenze
  attive.
- **Il processo ricevitore è stato tracciato in produzione:** attivato dalla creazione del task
  con attore `ApplicationsOnly`, con filtri sul tipo di attività di engagement, su un puntatore
  non vuoto e sull'appartenenza alla campagna e sui flag di esclusione del contatto, poi scrive il
  puntatore sul contatto e passa il testimone.
- **I quattro valori dell'attore sono stati confermati dall'enum**, così come gli eventi di
  trigger, che comprendono email inviata ed email ricevuta insieme a creazione, aggiornamento ed
  eliminazione.
- **Lo schema dei puntatori della scala è stato letto dai modelli di task**: ogni gradino scrive
  il numero di quello che gli succede, e il gradino finale porta ancora un puntatore a uno
  precedente affidandosi a un flag disattivato per terminare.
- **Il processo di iscrizione condiviso è stato misurato:** oltre cento nodi, decine di campagne
  non correlate in un'unica scala con regola della prima corrispondenza, il controllo di una
  campagna a diciannove livelli di profondità, e il processo stesso con uno stato di avviso.
- **La convenzione booleana con operatore null è stata confermata** in tre processi indipendenti:
  un test booleano «è falso» non memorizza alcun operatore e un valore pari a zero.

**Non osservato, e dichiarato come tale:**

- Una sequenza che invia durante questo lavoro. Ogni risultato è letto dalla configurazione
  memorizzata e dalle statistiche memorizzate, non da una campagna eseguita appositamente.
- Che cosa succede se il flag di creazione del task del gradino finale viene attivato: il ciclo è
  dedotto dal valore del puntatore memorizzato, non osservato.
- Se modificare l'oggetto di un passo stacchi la condizione personalizzata, cosa che discende
  dalla forma del filtro ma non è stata testata.
- Il comportamento dei tipi di record lead e testo che un'azione globale può creare; è stato
  tracciato solo il percorso del task.
- Che `ApplicationsOnly` ignori un task creato da una persona. Il suo significato è stato letto
  dall'enum, non testato creando un task a mano.

### Che cosa segnalerebbe una regressione

- **Ogni sequenza della scala che riporta zero iscrizioni correnti.** Il controllo di salute più
  economico in assoluto, e l'unico che distingue «nessuno è ancora nella sequenza» da «nessuno ha
  ancora interagito».
- **Task che si accumulano mentre il contatore dei passi resta a uno.** Il processo ricevitore
  scatta e il passaggio di consegne no, quindi i contatti vengono contrassegnati e mai spostati.
- **Il conteggio dei task creati di un gradino che scende a zero mentre gli invii continuano.** La
  sua condizione personalizzata ha smesso di trovare corrispondenze, il più delle volte perché è
  stato modificato un oggetto.
- **Qualsiasi task aperto assegnato a una persona con il tipo di attività della campagna.** O
  l'attore del processo ricevitore è stato non è più limitato a solo applicazioni, o qualcuno sta
  lavorando all'interno dei tipi di task della macchina, ed entrambe le cose produrranno
  iscrizioni sorprendenti.

## Blueprint correlati

- [Blueprint 011 — Come mantiene gestibili centinaia di automazioni del
  CRM?](https://blueprints.coevera.com/it/blueprints/keeping-hundreds-of-automations-maintainable/)
  — filtri con regola della prima corrispondenza e passaggi a sottoprocessi, gli elementi con cui
  è costruita questa catena.
- [Blueprint 014 — Come individua i clienti a rischio di abbandono prima del
  rinnovo?](https://blueprints.coevera.com/it/blueprints/customer-health-score-churn-risk/) — la
  stessa tesi dal lato opposto: l'automazione indirizza l'attenzione, una persona si impegna.
- [Blueprint 009 — Come automatizza sui campi del CRM di proprietà di un altro
  sistema?](https://blueprints.coevera.com/it/blueprints/automating-on-integration-owned-fields/)
  — perché un flusso interrotto è silenzioso anziché rotto.
- [Blueprint 005 — Come migra i contatti da un altro sistema senza perdere dati senza
  accorgersene?](https://blueprints.coevera.com/it/blueprints/contact-migration-without-data-loss/)
  — che cosa fa un elenco non validato al primo contatto.

## Domande frequenti

### Come concatena sequenze di email in modo che ciò che fa un potenziale cliente decida cosa succede dopo?

Tramite un task. Una sequenza di email è un circuito chiuso: iscrive un record, invia i suoi passi e termina, e non ha alcun nodo che iscriva qualcuno a un'altra sequenza. Ha invece le azioni globali, alla risposta, alla disiscrizione, a una condizione personalizzata come un'apertura o un clic, e al mancato recapito, e tre dei quattro, tutti tranne il mancato recapito, possono creare un record da un modello. Quindi la sequenza crea un task che porta un puntatore alla sequenza successiva, un processo attivato dalla creazione del task scrive quel puntatore sul contatto, e un processo di iscrizione separato legge il puntatore ed esegue l'iscrizione. Il task è il bus dei messaggi tra due sequenze che non possono vedersi a vicenda.

### Come fa scattare un'azione quando qualcuno apre un'email di una sequenza o vi fa clic?

Con l'azione globale a condizione personalizzata. A differenza di risposta, disiscrizione e mancato recapito, che sono eventi fissi, la condizione personalizzata accetta un filtro, di solito l'oggetto del messaggio più lo stato di tracciamento dell'email aperta o cliccata. Quando corrisponde, la sequenza può rimuovere il destinatario, inviare un'email diversa e creare un record, in qualsiasi combinazione.

### Perché una scala di outreach automatizzata genera attività ma nessun lavoro?

Perché i task che crea sono pura contabilità. Se ogni modello di task viene creato già completato, assegnato a un solo amministratore, e il processo che li consuma accetta come attore solo l'automazione, a nessuna persona viene mai chiesto di fare qualcosa. La scala produce centinaia di record di attività e zero elementi di lavoro, quindi una coorte può restare ferma al primo passo per mesi e nulla nel sistema lo segnala.

### Come impedisce che il task manuale di una persona rientri in una sequenza automatizzata?

Imposti l'attore del trigger del processo ricevitore su solo applicazioni. L'attore di un trigger di record può essere il proprietario del processo, unità e utenti selezionati, qualsiasi utente, oppure solo applicazioni: quest'ultimo significa, secondo quanto letto dall'enum e senza test, che il processo scatta per i record creati dall'automazione e mai per quelli di una persona. Senza questa impostazione, chiunque crei un task del tipo osservato iscrive di nuovo un contatto senza che nessuno se ne accorga.

### Come capisce che una campagna automatizzata ha smesso di funzionare?

Deve chiederselo deliberatamente, perché l'arresto produce silenzio anziché errori. Ogni sequenza espone un conteggio delle iscrizioni correnti, quindi una scala in cui ogni sequenza riporta zero iscrizioni in corso non ha nessuno che la percorra. L'assenza di nuovi record in ingresso all'inizio sembra esattamente una settimana tranquilla, e nessun avviso distingue le due cose.

---

Pubblicato da Coevera. Ridotto allo schema riutilizzabile: nessun nome di cliente, nessun dato
dei clienti, nessun dato personale.