Skip to main content

Funzionalità equivalenti

Questa pagina è la vista docs-app della matrice di parità più completa in Matrice delle Funzionalità. La domanda a cui risponde è semplice: Cosa deve esistere prima che questa piattaforma possa sostituire Charles nei flussi operativi reali?

Standard di sostituzione

La piattaforma è operativamente equivalente quando:
  • il traffico cliente in entrata arriva sul nostro Webhook e appare nella nostra inbox
  • i messaggi in uscita, i template e gli aggiornamenti di stato sono di proprietà della nostra piattaforma
  • contatti, stato subscriber e gestione dell’opt-out non dipendono più da Charles
  • gli operatori possono gestire le conversazioni senza tornare allo strumento incumbent
  • i sistemi interni possono continuare a chiamare gli endpoint di compatibilità durante la migrazione
  • le operazioni possono ispezionare, ripetere e verificare i fallimenti senza l’intervento del vendor

Mappa dei moduli

Inbox e workspace operatore

La parità richiesta include:
  • lista conversazioni, ricerca, filtri di coda, stato di assegnazione, conteggi non letti
  • dettaglio thread con cronologia in entrata e in uscita
  • visibilità dello stato di consegna e dello stato di lettura
  • consapevolezza della finestra di servizio e avvisi template-only
  • pannello laterale contatto, note, tag e azioni rapide
  • punti di ingresso per l’invio dei template e comportamento delle risposte condivise
  • auditabilità per assegnazione, invio, replay e azioni di intervento

Contatti e stato subscriber

La parità richiesta include:
  • ID di riferimento CRM esterni
  • normalizzazione dei numeri di telefono e matching dell’identità
  • stato di opt-in e opt-out
  • tag, note e proprietà custom
  • attribuzione della fonte e contesto commerciale
  • comportamento esplicito di suppressione per destinatari non sicuri

Template e risposte condivise

La parità richiesta include:
  • mirror locale dei template del provider
  • visibilità di locale, categoria, variabili e approvazione
  • gate dell’invio quando la conversazione è fuori dalla finestra di servizio
  • anteprima e validazione prima dell’invio
  • risposte condivise di proprietà del team, distinte dai template del provider

Campagne

La parità richiesta include:
  • bozza campagna e revisione al lancio
  • selezione dell’audience o dello snapshot
  • stato di scheduling
  • visibilità della consegna e dei fallimenti a livello di destinatario
  • pausa, ripresa, annullamento e audit trail

Journey e automazioni

La parità richiesta include:
  • trigger Webhook e di compatibilità
  • definizioni versionate
  • attese, rami e aggiornamenti di proprietà/tag
  • stato di pubblicazione
  • storico delle esecuzioni, fallimenti e limiti di esecuzione replay-safe

Integrazioni e compatibilità

La parità richiesta include:
  • endpoint di compatibilità per la mutazione dei contatti
  • endpoint di compatibilità per il trigger delle journey
  • modello di integrazione Webhook-first per Twenty CRM
  • metadata di audit espliciti per le azioni dei partner in entrata
  • replay e ispezione dei fallimenti per il traffico di integrazione

Operazioni e governance

La parità richiesta include:
  • diagnostica runtime
  • forensics dei Webhook e controlli di replay
  • visibilità della coda e dell’outbox
  • accesso ai log di audit
  • feature flag e kill switch
  • amministrazione di credenziali e canali

Fasce di priorità

Livello di continuità P0

  • inbox core
  • contatti e stato subscriber
  • registro template e gate di invio
  • ingest Webhook in entrata
  • accodamento degli intent in uscita
  • consegna e riconciliazione degli stati
  • endpoint di compatibilità
  • diagnostica runtime e audit

Parità operativa P1

  • campagne
  • runtime delle journey
  • segmenti e gestione dell’audience
  • sincronizzazione più profonda con Twenty CRM
  • reportistica essenziale
  • ergonomia di collaborazione

Espansione P2

  • livelli di assistenza AI
  • sperimentazione più ricca
  • supporto più ampio dei canali
  • analytics avanzate e funzionalità di raccomandazione

Cosa significa “drop-in” qui

La sostituzione non deve copiare i dettagli implementativi di Charles. Deve preservare il contratto operativo:
  • i sistemi upstream possono continuare ad attivare contatti e flow
  • gli operatori possono continuare a gestire il traffico cliente in entrata
  • i template approvati e le regole di invio restano applicabili
  • la gestione dei fallimenti operativi è almeno tanto solida quanto lo stato incumbent