E-Mail Marketing, i pericoli dello SPAM e dell’overload informativo: le soluzioni da adottare

E-mail marketing, un’introduzione

E-mail marketing è innanzitutto comunicazione d’impresa, personalizzata per target

Come prima cosa, occorre una precisazione: molti pensano che l’e-Mail Marketing coincida con l’invio massivo (30-40 mila e-mail ad invio) di e-mail a soggetti più o meno consenzienti … non è esattamente questa l’attività di e-Mail Marketing ma di DEM – Direct Email Marketing (intesa anche come e-mail advertising). Non è una differenza capziosa ma sostanziale, l’e-Mail Marketing comprende tutte le attività di comunicazione dell’azienda attraverso le e-mail. L’e-Mail Marketing investe, ovviamente, l’attività promozionale, ma anche le e-mail transazionali e quelle di servizio. Occorre fare un’altra doverosa precisazione, l’invio di un messaggio indistinto ad una lista di distribuzione (mailing list), NON è e-mail marketing: siamo in una situazione di e-mail marketing quando siamo in una situazione di personalizzazione del messaggio per i vari target e quando c’è un riscontro/monitoraggio dell’efficacia della comunicazione.
Un semplice elenco per evidenziare quanto sopra affermato, delle varie azioni di e-mail marketing:

e-mail promozionali:

• e-mail di lancio prodotti servizio (le più usate/abusate)
• e-mail di lancio di nuovi prodotti servizi
• e-mail di invito ad eventi aziendali (fiere, work shop, ecc.)
• e-mail sponsorizzate (presenza di un banner/link all’interno di e-mail inviate da info-mediari))
• ecc.

e-mail commerciali:

• e-mail di invio di offerte, proposte, sconti, ecc.
• e-mail di invio cataloghi-prodotto
• e-mail di up-selling, cross-selling ai clienti acquisiti

e-mail informative:

• Newsletter
• Comunicati e circolari aziendali
• Comunicati stampa
• ecc.

e-mail transazionali e di supporto:

• e-mail di check da form compilati (es. dal sito web: conferma d’iscrizione, registrazione, di benvenuto, ecc.)
• Avvisi e aggiornamenti, assistenza tecnica, dal call center, ecc.
• Informazioni contabili ed amministrative
• Autoresponder o e-mail trigger
• ecc.

Da questo elenco si può notare come non sia agevole dare coordinamento e coerenza comunicativa alle varie tipologie di e-mail, poiché investono più canali di comunicazione (il sito web, il call center ad esempio) e personale interno con funzioni diverse (marketing, commerciale, assistenza, amministrazione, ecc.). Tutto ciò per voler dimostrare che cosa? Che l’attività di DEM – Direct Email Marketing B2B, sono (purtroppo) gestite ancora in modalità azienda-azienda (magari inviando all’e-mail info) quando è del tutto evidente che la comunicazione non può che essere persona-persona, anche se coordinata in termini di marketing e comunicazione.

Le attività principali di e-mail marketing in acquisition – reperimento nuovi contatti/clienti – possono essere così rappresentate (dettaglio preso da un progetto da me redatto):

Si può notare come l’attività di definizione degli obiettivi, del target e della comunicazione, unitamente al monitoraggio (e-mail aperte, click a link, compilazione form, ecc.) e analisi finale contraddistingua l’attività di e-mail marketing dal semplice invio massivo di e-mail a delle mailing list.

Oltre che all’attività di acquisition, tra gli obiettivi principali dell’e-mail marketing, ci sono ance quelli di:

• retention, fidelizzazione e mantenimento dei clienti acquisiti.
  • Gli strumenti principali sono le e-mail commerciali.
• branding, mantenimento e sviluppo dell’immagine (brand image), del valore percepito della marca (brand equity, della conoscenza e consapevolezza (brand awareness), ecc..
  • Gli strumenti principali sono le e-mail informative. Faccio notare che l’e-mail marketing in ordine al branding è uno strumento poco efficace, almeno rispetto agli altri due obiettivi di acquisition e retention.

Lo SPAM

E-mail mantra: list segmentation + relevant content = improved results.
Lo SPAM è soprattutto un’attività di marketing indifferenziata.

Se lo SPAM sancisce che l’e-mail non è ne richiesta ne desiderata dal destinatario (che almeno esiste) è ancor più grave – a livello marketing – un invio ad e-mail generiche e/o non referenziate a persone/destinatari. Vi assicuro che le liste che sono in vendita quando non sono filtrate e pulite (posizionamento, cluster, segmentazione e target) possono arrivare un bassissimo tasso di conversione pari a 5/10.000 (5 conversioni e/o risposte positive ogni 10.000 e-mail inviate), senza contare al ritorno negativo che il brand subisce per tutti i destinatari che considerano l’e-mail ricevuta indesideratamante: mi chiedo, ne vale la pena?
Si presta a diventare SPAM non solo l’invio l’invio indifferenziato e non monitorato a mailin list, come indicato anche all’inizio del presente articolo, ma anche l’invio reiterato di diversi messaggi alla stessa mailing list senza che i destinatari ne abbiano dato il cansenso dopo il primo invio (Opt-out).

L’overload informativo e le possibili soluzioni

L’overload informativo è un sovraccarico d’informazioni derivante dalle e-mail in arrivo alle quali abbiamo dato il nostro consenso (opt-in), ma anche una cattiva gestione dei filtri e dalla numerosità ed eterogeneità delle iscrizioni a newsletter.

Dalla parte delle dell’emittente/promotore di e-mail marketing (estendibile anche per l’invio di SMS-MMS), la strategia in ambito acquisition che mi sento di consigliare per evitare sia, ovviamente, lo SPAM si riassume nelle attività di prospecting. Per prospecting intendo quelle attività di reperimento, affinamento e gestione dei prospect (i potenziali clienti), che richiedono un forte presidio da parte dell’emittente/promotore. Come realizzare quest’attività di prospecting? Magari in un prossimo articolo approfondirò questo tema, per ora mi fermo all’indicazione (il cosa).

Dalla parte dei destinatari in molti casi si verifica una crescente irritazione delle e-mail spazzatura-SPAM (già oggetto di filtri più o meno efficaci) non creano il danno delle e-mail provenienti da crescenti e sovrapposte azioni di permission marketing, le quali, nel corso degli anni, si rivelano un vero dispendio di tempo giornaliero.
Occorre tener presente che l’e-mail marketing è solo una delle cause del sovraccarico delle informazioni che riceviamo, il vero problema risiede nella più generale gestione dell’informazione dell’azienda che ha, secondo la mia esperienza sul campo, due sbocchi possibili:

• L’Enterprise Portal (detto anche Corporate Portal, l’intranet degli anni ‘90, insomma)
• L’ECM – Enterprise Content Management (web e document management, ma non solo …)

Se gli imprenditori rilevassero il tempo giornalmente impiegato nella propria azienda in ricerca di informazioni – intese come anche ricerca documentale e non solo come ricerca di informazioni nei motori di ricerca – in gestione delle versioni dei documenti, nelle attività di collaborations (riunioni, condivisione di progetti, problemi, ticket, reclami, ecc. ecc.)… si renderebbero conto che l’investimento in Enterprise Content Management ( in ottica di TCO – Total Cost of Ownership), sarebbe un investimento sia economico che nella conoscenza esplicita della propria azienda.
Oltre a questo aspetto di risparmi di tempo nella ricerca delle informazioni – tangibile anche in termini di minori costi – c’è da considerare il vantaggio intangibile di avere le informazioni giuste e nella versione/formato corretta per il target/utente interno: in poche parole parole efficacia dell’informazione e knowledge management.

Conclusioni

Termino l’articolo sperando di aver ampliato l’ottica e l’approccio di e-mail marketing. E’ un canale di comunicazione a disposizione del marketing e come tale va trattato.

Le PMI, ma soprattutto alle piccole imprese che ancora non utilizzano le attività di e-mail marketing, non consiglio di adottare i – seppur ottimi – software di gestione degli invii massivi e delle newsletter, ma di rivolgesi alle web agency che sono specializzate direct marketing online. Ricordo che l’e-mail marketing ha un costo per contatto (CPL – Costo per Lead) molto basso (0,50 €uro contro i 10 €uro del direct mail, per esempio), pertanto l’e-mail marketing, si presta ad essere ancora uno strumento molto valido per le attività promozionali dell’azienda.
Ritengo di non aver evaso un argomento così vasto, ma di averlo inquadrato almeno con gli elementi e l’esperienza che ho acquisito nella mia attività professionale.

Segnalo altri articoli del blog che affrontano l’argomento:

• Il Permission Marketing secondo Seth Godin, appunti sull’”E-mail marketing”
• L’azienda, la relationship e lo sviluppo del Know How
• I Sistemi di Misurazione ed il CRM Intelligence: l’esempio del “ciclo di vita del cliente”

Leonardo Milan

Technorati Tag: e-mail marketing,direct marketing,internet marketing

Condividi questo articolo:
  share on facebook  tweet this story  email this story 

Pubblica questo articolo:
Technorati   OKnotizie  Delicious  Segnalo Digg

 

Scegliere un’architettura: linee guida e ruolo del middleware

Come già trattato nell’articolo precedente "Dallo studio di fattibilità; alla software selection: analisi e scelta degli strumenti e delle tecnologie", un team di sviluppo ha a disposizione un insieme ragionevolmente ampio di scelte e alternative. Inoltre, i diversi stili architetturali possono essere combinati per ottenere strutture e architetture complesse. I criteri principali (e iniziali) si riferivano alla scelta tra prodotti/applicazioni industriali e prodotti/applicazioni Open Source.

Introduzione metodologica alla scelta architetturale

Come si sceglie un’architettura?
Come si giunge a scegliere uno stile architetturale (o una combinazione di stili) tra i tanti possibili?

Se è vero che l’architettura di un sistema non è derivabile in modo diretto dalla natura e struttura del problema, quali criteri e linee guida occorre seguire nel progettare la soluzione? In realtà questo passaggio costituisce uno degli elementi più critici e complessi del lavoro iniziale della analisi architetturale.
In questa fase entrano in gioco aspetti quali l’esperienza del team di sviluppo, della sua capacità di analisi e sintesi, ma anche di intuito e di creatività. Il problema da risolvere in ordine allo sviluppo e/o reengineering di un sistema informativo è stato "osservato e studiato".
In generale, è difficile ricondurre la scelta di una soluzione architetturale a un mero processo o metodo sistematico che determina in modo meccanico quale alternativa preferire. Ci sono peraltro una serie di criteri e di linee guida che possono essere seguiti come qui di seguito andiamo ad enunciare.

Linee guida e aspetti considerati

a) Scelte architetturali già perseguite in casi simili: il DSSA – Domain Specific Software Architecture, l’ambiente e le caratteristiche del dominio applicativo dell’azienda.

Esempio: DSSA Domain Specific Software Architecture Activity Flow
(Fonte: The Domain-Specific Software Architecture Program)

In primo luogo, esistono soluzioni architetturali per specifici settori applicativi. Per esempio, nel caso dei sistemi di controllo, vi sono architetture di riferimento che possono essere raffinate e adattate al caso specifico. Nel mondo delle applicazioni per Internet, la stessa architettura J2EE (Java Platform, Enterprise Edition) identifica una serie di elementi e componenti per la costruzione di applicazioni distribuite client-server multilivello.
Il team di progetto, a fronte di un problema, può quindi innanzitutto valutare le scelte architetturali già perseguite in casi simili e che si sono rivelate efficaci per quel tipo di problemi. Negli anni scorsi, è stata creata l’espressione Domain Specific Software Architetture proprio per indicare soluzioni architetturali ottimali per "specifici domini applicativi".

b) L’analisi dei requisiti e dalle caratteristiche

Occorre chiedersi: quale architettura è più coerente con le richieste del committente?
Più in generale, la definizione dell’architettura di un sistema complesso viene effettuata studiando i requisiti (vedi anche "Implementazione di un CRM: un confronto tra approccio applicativo e organizzativo") e le caratteristiche del problema sia da un punto di vista funzionale che non funzionale.
I risultati di queste analisi sono confrontati con le caratteristiche e proprietà tipiche dei diversi stili e da questo nascono le ipotesi architetturali. Se il problema, per esempio, è l’integrazione di archivi dati gestiti da organizzazioni autonome, è evidente che nascono (almeno) due possibilità:
- o si consolidano tutti i dati in un archivio centrale, con un sistema client-server (magari a più livelli per ottimizzare le prestazioni complessive)
- oppure si adotta un’architettura P2P – Peer-to-Peer, nella quale ciascuno continua a essere "padrone e gestore unico" dei propri dati. In questo secondo caso, si pone il problema di come propagare query e operazioni di aggiornamento delle informazioni. Quindi si potrebbe pensare a un sistema P2P ibrido oppure a un’architettura composita P2P + publish-subscribe.

La scelta tra queste diverse alternative deve considerare il trade-off (vantaggi e svantaggi della scelta, considerando anche gli aspetti di costo-opportunità) che ciascuna soluzione comporta.
Se per esempio le funzioni e operazioni svolte da ciascun nodo autonomo sono le stesse e avvengono su dati assolutamente identici, non ha senso avere una replicazione dei sistemi: un sistema centralizzato (magari ridondato per garantire fault-tolerance e affidabilità) è la soluzione più conveniente dal punto di vista economico e gestionale. Se invece i diversi nodi hanno, almeno in parte, dati diversi con funzioni che possono mutare o evolvere in modo indipendente, è preferibile (se non obbligatorio) attuare una strategia distribuita P2P.
In ogni caso, è evidente che il team di progetto si trova di fronte a un insieme non limitato di alternative.
Spesso, esse non sono presenti solo o principalmente a livello di stile architetturale, ma anche e soprattutto a livello di variante o specifica implementazione dello stile o di combinazione di stili.
Sono l’esperienza, le competenze, l’intuito e la professionalità di un team di progetto a costituire la chiave di volta per affrontare questo passaggio in modo efficace e convincente.

c) Il deployment le infrastrutture IT: le prestazioni e l’efficienza del sistema

La scelta di un’architettura deve essere guidata anche da considerazioni di carattere prestazionale. Potrebbe essere necessario, per garantire un certo tipo di prestazioni, dover valutare quale architettura risulti più conveniente, oppure come una certa architettura debba essere rivista o adattata per conformarsi al problema specifico.

- Per esempio, dovendo gestire un alto carico di richieste in un sistema client-server multi-tier, potrebbe essere utile avviare studi che valutano, dal punto di vista della capacità complessiva di risposta, architetture a tre o quattro livelli, con diversi meccanismi di distribuzione delle funzioni applicative o dei criteri di replica e gestione dei tier intermedi.
- Da tempo, questo tipo di analisi è condotto simulando e studiando il comportamento delle diverse architetture tramite modelli matematici basati sulla teoria delle code (o tecniche simili). Tali approcci sono piuttosto diffusi in molti settori dell’ingegneria e sono certamente di ausilio anche al team di progetto.

d) II ruolo del middleware (Orchestration, ESB – Enterprise Service Bus e WorkFlow)

Da Wikipedia: con il termine middleware
oggi si intendono una serie di strumenti come DBMS, Web server, Application server, sistemi di gestione dei contenuti ed altri strumenti basati sul concetto di sviluppo e pubblicazione di applicazioni e contenuti. Gli sviluppi attuali si dirigono verso XML, SOAP, servizi Web e architetture orientate ai servizi.
Un aspetto importante che influisce in modo significativo sull’attività di progettazione è la scelta del middleware. Infatti, è indubbio, e alcuni studi lo hanno dimostrato, che l’utilizzo di una particolare tecnologia di middleware influisce sulle scelte architetturali. Può persino accadere che l’adozione di un tipo di middleware renda più o meno facile (e persino possibile) la realizzazione di una soluzione basata su una specifica architettura.

- Tecnologie a eventi
Un caso esemplare è costituito dalle tecnologie di middleware a eventi (tipo JMS – Java Message Service).
Queste tecnologie forniscono operazioni e servizi per gestire la pubblicazione e ricezione di eventi: offrono il dispatcher e i servizi di publish, subscribe, push e pull.

- Architettura publish-subscribe
Dovendo realizzare un’architettura publish-subscribe, è indubbio che la disponibilità di questo tipo di tecnologia faciliti grandemente tutto il processo di sviluppo.
Il team di progetto può concentrarsi nell’identificazione dei diversi componenti dell’architettura, dei tipi di eventi da scambiare e della gestione della chiamata dei servizi offerti dal middleware, ignorando gli aspetti implementativi della gestione degli eventi.Questa architettura consente un’elevata scalabilità.

- Sistema client-server
Al contrario, se si dovesse realizzare un sistema client-server utilizzando un middleware a eventi, il team di progetto si troverebbe di fronte a problemi non marginali. Certamente è possibile realizzare una chiamata sincrona attraverso pubblicazioni di eventi e sottoscrizioni, ma il compito del team di progetto sarebbe alquanto ostico.
Chi richiede un servizio deve pubblicare un evento con le informazioni sul servizio richiesto.
Il ricevente deve essersi già sottoscritto a quel tipo di evento. In caso contrario, la richiesta va persa e il richiedente rimane inascoltato (senza avere meccanismi efficienti per venirlo a sapere in tempi rapidi).
Quando chi offre il servizio riceve l’evento di richiesta, deve generare un nuovo evento con la risposta.
Il richiedente del servizio deve essersi registrato per tempo, per poter essere sicuro di ricevere l’evento di risposta.
Come si può facilmente desumere, pensare di gestire interazioni client-server con questo meccanismo è semplicemente improponibile: appare quindi evidente che la scelta del middleware possa avere un’influenza più o meno significativa sull’architettura (e viceversa).

In generale, ogni tecnologia di middleware, in modo più o meno invasivo, induce uno o più stili architetturali. Esistono tecnologie di middleware molto semplici e flessibili che possono essere utilizzate per tutti gli stili architetturali.
Altre sono particolarmente adatte a realizzare solo uno o pochi stili.

- Adozione della RMI – Remote Method Invocation
Per esempio, con l”adozione della RMI – Remote Method Invocation, invocazione remota di metodi) si utilizza una tecnologia che consente a processi Java distribuiti di comunicare attraverso una rete.
Questa tecnologia include una API (application programming interface) il cui scopo esplicito è quello di rendere trasparenti al programmatore quasi tutti i dettagli della comunicazione su rete.
Essa consente, infatti, di invocare un metodo di un oggetto remoto (cioè appartenente a un diverso processo, potenzialmente su una diversa macchina) quasi come se tale oggetto fosse "locale" (ovvero appartenente allo stesso processo in cui è eseguita l’invocazione). In questo senso, la tecnologia RMI può essere ricondotta, da un punto di vista concettuale, all’idea di chiamata di procedura remota riformulata per il paradigma object-oriented (in cui, appunto, le procedure sono sostituite da metodi).
Con RMI è possibile realizzare sistemi client-server a più livelli e, con un po’ di programmazione aggiuntiva, anche sistemi P2P. Le architetture J2EE (Java Platform, Enterprise Edition) sono particolarmente adatti a sistemi client-server multi-tier con codice mobile di tipo COD (tramite gli applet), mentre può risultare (nella sua configurazione completa) particolarmente pesante e onerosa per gestire sistemi P2P con funzioni RE (Remote Evaluation).

Avendo scelto uno stile architetturale, è quindi necessario assicurarsi che il middleware prescelto sia compatibile con la scelta fatta. Il middleware gioca inoltre un ruolo importante anche nella scelta di componenti da integrare in un sistema informatico esistente o già parzialmente implementato.
Infatti, se il componente utilizza meccanismi di middleware e logiche di funzionamento (interfacce) non compatibili con il "sistema ricevente", si ha una situazione di integrazione impossibile ("rigetto") o estremamente costosa (è necessario costruire adattatori che facciano da interprete tra le diverse parti).
Ancora una volta, emerge un problema di scelta progettuale che vede il team di progetto giocare un ruolo essenziale. Nel determinare l’architettura del sistema e il middleware di supporto, il team di progetto deve assicurarsi che non vi sia architectural mismatch, cioè incompatibilità architetturali tra i diversi elementi dell’architettura e in particolare tra essi e il middleware scelto per implementarli.

Da dove partire: l’approccio Top-down e Bottom-up

In diverse circostanze, è emerso un tema particolarmente rilevante: nella progettazione e realizzazione di un sistema informatico si procede in modo top-down o bottom-up?
- L’approccio Top-down
Deriva direttamente dalla logica dello stepwise refinement:
si parte dall’astrazione massima e progressivamente la si raffina in funzioni elementari e quindi in codice. Più in generale, si definisce l’architettura del sistema e si raffinano i ai diversi componenti ed elementi che ne emergono.
"Scendendo" a livello di componente si giunge a progettare il modulo e quindi il codice dei singoli metodi o procedure.
- L’approccio Bottom-up
Si parte da componenti già pronti o facilmente realizzabili e li si assembla progressivamente fino a costituire il sistema completo.
È l’approccio che sfrutta al meglio i cicli di vita basati sul riuso di componenti (component-based development).

Leonardo Milan

Technorati Tag: Studio di fattibilità,Software Selections,percorso decisionale e implementativo

Dallo studio di fattibilità alla software selection: analisi e scelta degli strumenti e delle tecnologie

La software selection segue dei percorsi di valutazione che prevedono un arco di attività e di approfondimenti che vanno dallo studio di fattibilità alla software selection.

Fonte: http://www.websitepromotion.it/content/view/50/83/

Gli aspetti che vengono tradizionalmente considerati nella software selection sono i seguenti:
- copertura funzionale (ampiezza e profondità);
- tecnologia del software;
- costi di avvio;
- canone di manutenzione annuale;
- costi di manutenzione ed aggiornamento;
- costi organizzativi;
- competenza del partner tecnologico;
- robustezza e possibili evoluzioni della soluzione.

I criteri sopra elencati non mi soddisfano. la software selection deve considerare che il software una volta che entra in funzione (se tutto va bene …), ha un impatto con l’organizzazione e con il Sistema Informativo esistente molto più ampio di quello che inizialmente si tende a (non) valutare. Molto spesso si assiste a riunioni di pianificazione di un progetto nelle quali si dibatte sui vari tipi di tecnologie:
- ambienti di sviluppo,
- middleware
- database
- strumenti di gestione delle configurazioni ecc.
La software selection, la scelta di una tecnologia, o di uno strumento di sviluppo, è particolarmente difficile e, poiché incide in modo significativo sullo svolgimento del progetto, è essenziale che sia compiuta sulla base di considerazioni tecnico-economiche adeguate, molto dettagliate quali, ad esempio, le seguenti.

• Copertura funzionale:
  Gli applicativi, il middleware, l’infrastruttura IT, ecc. sono in grado di coprire i requisiti (architetturali, funzionali ed organizzativi) richiesti?
• Qualità intrinseca della tecnologia:
  Quali sono le prestazioni e funzioni garantite?
• Allineamento con le caratteristiche del progetto:
  È inutile scegliere una tecnologia eccellente, ma inadatta al progetto che si deve svolgere.
• Compatibilità e vincoli tecnologici:
  Questa tecnologia deve integrarsi con altri componenti preesistenti? Se sì, è in grado di farlo? Occorre tener presente le necessità e/o le compatibilità di integrazione/interoperabilità con il sistema informativo dell’azienda unitamente alla la scalabilità dell’applicazione con altri moduli o software del fornitore/partner tecnologico.
• Transizione e facilità di apprendimento:
  È semplice adottare questa tecnologia e quanto è già conosciuta dal team di progetto?
• TCO – Total Cost of Ownership:
  Quanto costa acquisire e soprattutto mantenere nel tempo una tecnologia? Spesso ci si concentra sul suo costo iniziale e non si presta attenzione ai costi di manutenzione e/o aggiornamento. Il TCO deve avere un’enfasi sui costi e/o canoni di assistenza e di manutenzione evolutiva negli anni.
• Lock-in:
  Quanto questa tecnologia vincolerà scelte future? Il personale IT sarà in grado di sostituirla in modo ragionevolmente facile, nel momento in cui ci fossero alternative più convenienti?
• Affidabilità e del fornitore e indipendenza dal fornitore:
  Quanto affidabile è il fornitore della tecnologia? L’implementatore può contare sul suo supporto stabile e competente? È assicurata indipendenza da fornitore?

Queste osservazioni sono solo alcune tra quelle che il responsabile di un progetto deve considerare al momento di una scelta tecnologica importante. Purtroppo, molto spesso queste decisioni sono governate da criteri di carattere commerciale o addirittura ideologico. È invece essenziale che tutti gli aspetti chiave di una scelta siano opportunamente considerati e pesati.

Per ulteriori approfondimenti e per proseguire questo percorso di software selection, consiglio di leggere anche l’articolo: “Scegliere un’architettura: linee guida e ruolo del middleware”.

Leonardo Milan

Technorati Tag: Studio di fattibilità,software selections,percorso decisionale e implementativo