Browsed by
Category: Italian

La trasparenza dell’Agenzia delle Entrate in tema di Fattura Elettronica

La trasparenza dell’Agenzia delle Entrate in tema di Fattura Elettronica

Volendo fare luce su alcune delle scelte tecnologiche effettuate in tema di “Sistema di Interscambio” (Fattura Elettronica), come avevo anticipato nel precedente post sull’argomento (se non lo avete già letto lo trovate qui), un gruppo di professionisti si è riunito ed inviato, sia a Sogei (società che gestisce la piattaforma) che ad Agenzia delle Entrate una Istanza di Accesso Civico Generalizzato (FOIA) richiedendo:

Tutti i documenti di collaudo inerenti gli sviluppi software di applicazioni informatiche inerenti il sistema di Fattura Elettronica divenuto obbligatorio in data 1.1.2019 (SDI).

Tutti i documenti di analisi di sicurezza informatica, specificamente rivolti ad analizzare, verificare eventuali problematiche di sicurezza applicative e/o infrastrutturali relative al servizio di Fattura Elettronica di cui sopra.

L’accesso a questi documenti permetterebbe una analisi esterna dell’architettura nonché l’avvio di una ben più aperta conversazione allo scopo di migliorare questa piattaforma che, pare, accompagnerà l’Italia per molti anni a venire. Il testo completo della richiesta, se siete curiosi, potete leggerlo qui.

Abbiamo deciso di inviare questa richiesta soprattutto alla luce dei molti enti pubblici nel mondo che stanno infatti intraprendendo la via della trasparenza totale: Swiss Post, per esempio, interessata a confermare/verificare la sicurezza del proprio portale di e-voting (voto online), ha pubblicato il codice sorgente della piattaforma e ha invitato esperti ed interessati ad un “Public Intrusion Test”. Non garantirà ai partecipanti solo un safe harbour legale e il diritto di pubblicazione delle loro scoperte, ma offrirà anche una ricompensa economica a chi scoverà delle vulnerabilità.

In settimana però abbiamo ricevuto la risposta da parte dell’AdE, la quale ci comunica che:

…valutata la probabilità e serietà del danno ai correlati interessi, nonché il rischio di pregiudizio ai beni e interessi tutelati dall’ordinamento in rapporto all’interesse conoscitivo del richiedente, l’istanza non viene accolta.

Accesso negato, quindi. Questo appare come un tentativo di mantenere alcune informazioni segrete secondo il principio (ampiamente contestato) di “security through obscurity“: un qualcosa di opposto ad esempi come quello di Swiss Post e delle decine di altri enti pubblici che rilasciano il codice dei loro applicativi sotto licenze Open Source.

Di seguito acuni punti salienti del loro rifiuto (la cui versione integrale è qui):

All’esito della valutazione effettuata, si ritiene che dall’ostensione dei documenti richiesti possa derivare un pregiudizio concreto ai predetti interessi pubblici, rispetto ai quali recede l’interesse del singolo alla conoscibilità dei dati, dei documenti e delle informazioni in possesso della pubblica amministrazione.

I documenti oggetto di richiesta, infatti, contengono informazioni idonee a disvelare l’architettura del sistema di interscambio, anche con riferimento alle caratteristiche di sicurezza dello stesso e alle relative misure progettate e realizzate a protezione del suo funzionamento e dei dati ivi contenuti.

L’accesso a tali documenti, pertanto, risulta concretamente idoneo ad arrecare grave pregiudizio alla salvaguardia dell’interesse patrimoniale dell’Erario.

Sotto altro profilo, occorre rilevare che l’ostensione dei documenti richiesti comprometterebbe, altresì, la sicurezza delle informazioni relative ai sistemi informatici utilizzati nell’ambito del processo di fatturazione elettronica.

I due paragrafi che seguono sono particolarmente interessanti:

Occorre inoltre evidenziare che le finalità per le quali il legislatore riconosce il diritto di accesso civico generalizzato sono quelle “di favorire forme diffuse di controllo sul perseguimento delle funzioni istituzionali e sull’utilizzo delle risorse pubbliche e di promuovere la partecipazione al dibattito pubblico”.

La comunicazione dei documenti richiesti appare evidentemente non pertinente ed eccedente rispetto a tali finalità.

Noi abbiamo infatti richiesto i documenti per verificare l’adeguatezza, la sicurezza e l’architettura di un sistema dal quale dipenderà l’economia di un intero paese (e che tutti noi abbiamo finanziato), sulla base di osservazioni effettuate sul materiale già di pubblico dominio: scopi che sembrano ricalcare parola per parola gli scopi dell’accesso civico generalizzato.

I documenti richiesti sono di carattere prettamente architetturale, informazioni di alto livello che, come è chiaro ad un qualunque esperto di infrastrutture, sono ben lontane dal causare un diretto rischio per la sicurezza o la stabilità di una infrastruttura.

AdE ha nel frattempo emesso un nuovo comunicato in cui sostanzialmente, nuovamente, conferma che il Sistema di Interscambio stia funzionando a dovere. Al comunicato ha però prontamente risposto l’Associazione Nazionale Commercialisti, segnalando qualcosa di diametralmente opposto: in molti casi i tempi di consegna delle fatture non sono rispettati (30 giorni al posto di 5), si riscontrano problemi tecnici di varia natura, e, a conferma di quello che era il più grande timore, iniziano ad emergere problemi intrinseci del protocollo di interscambio.

Quando potremo contare su un livello di trasparenza adeguato per un paese che vuole guardare avanti ed evolversi, e non indietro?

I dubbi sulla tecnologia del Sistema di Interscambio (Fattura Elettronica)

I dubbi sulla tecnologia del Sistema di Interscambio (Fattura Elettronica)

Essendo l’Italia detentrice del Guinness World Record per le catastrofi tecnologiche, dalla Posta Elettronica Certificata (PEC) ai vari down dei siti istituzionali durante elezioni e censimenti, non ho potuto sottrarmi dal dedicare le mie attenzioni a Sistema di Interscambio e Fattura Elettronica.

Tutto è iniziato quando mi sono trovato sommerso nella valanga di commenti negativi di utenti che segnalavano problemi tecnici e di sviluppatori che si lamentavano della complessità di implementazione e del basso livello di qualità delle API del SdI. Dopo aver passato qualche serata a studiarne le specifiche (pubblicate qui), mi sento di condividere i dubbi sulla qualità dell’implementazione, dell’infrastruttura e della gestione di quest’ultimo.

Vi starete chiedendo il perchè, immagino. Le osservazioni più rilevanti, in ordine sparso, sono:

  • Le API si basano su SOAP+XML, uno standard superato dal molto più diffuso REST+JSON. Non si tratta solamente di una questione estetica: l’utilizzo di tecnologie obsolete scarica sugli sviluppatori che devono utilizzare queste API una complessità che non potrà che crescere nel tempo. Utilizzare librerie deprecate o poco supportate e standard non più ampiamente utilizzati significa diventare parte di una nicchia, con svantaggi e problemi facilmente immaginabili.
  • I template WSDL pubblicati contengono URL come http://servizi.fatturapa.it/ e http://www.fatturapa.it/): tutte in chiaro, nessuna traccia di HTTPS. Va detto che un redirect verso HTTPS lo effettuano, ma questo modo di procedere lascia comunque aperti vari scenari di attacco Man in The Middle. Potrebbe trattarsi di semplici segnaposto, ma anche se fosse, per quale motivo diffondere dei template che contengono simili oscenità?
  • Gli endpoint SOAP non sono protetti da una CDN che possa permettere di bloccare flooding e attacchi più sofisticati che malintenzionati potrebbero lanciare contro la piattaforma: si possono solo immaginare gli effetti catastrofici che l’indisponibilità del SdI avrebbe sull’economia dell’intero paese (parlavo giusto qualche giorno fa di come realtà quali Netflix e Spotify siano più resistenti di molte infrastrutture critiche nazionali).
  • I frontend, some se non bastasse, sono tutti all’interno dello stesso range di IP, annunciato da AS33964 (Sogei) a due soli carrier prettamente nazionali, Fastweb e BT Italia.

Sia chiaro: queste scelte potrebbero avere serie motivazioni alle spalle, e non possiamo valutarle come “sbagliate” a priori e dal nostro punto di osservazione esterno. La loro distanza dalla pratica comune però garantisce il diritto, il dovere quasi, di fare delle domande e metterle sotto la lente, per assicurare siano la scelta migliore per tutti noi.

Un tema che è importante discutere è infatti quello della trasparenza (trattasi pur sempre di Pubblica Amministrazione, che lavora con i soldi dei cittadini e per i cittadini). Mentre le segnalazioni di difficoltà e ritardi nell’elaborazione non si fermano (basta fare una ricerca sui social media), ad esempio, l’Agenzia delle Entrate diffonde comunicati stampa in cui sostiene che:

“sul sistema di interscambio sono già transitate quasi un milione e mezzo di fatture elettroniche senza che il partner tecnologico Sogei abbiano (sic.) rilevato alcun problema tecnico”

Il valore di una simile affermazione è nullo se non contestualizzato: non serve a niente sapere quante sono le fatture processate se non sappiamo quante ne sono invece fallite, quante sono quelle emesse lo scorso anno nello stesso periodo con metodo cartaceo, qual è il tempo medio di elaborazione, etc.

Molti interrogativi ma poche risposte, quindi. Per trovarle abbiamo riunito alcuni dei professionisti che si erano espressi sulla piattaforma e inviato sia all’Agenzia delle Entrate che a Sogei una Istanza di Accesso Civico Generalizzato (FOIA), richiedendo copia dei documenti relativi a progettazione, sicurezza e manutenzione del SdI.

L’intenzione, una volta entrati in possesso di questi documenti, è quella di studiarli e avviare un dibattito aperto sui punti sopra espressi e quanto di nuovo dovesse emergere: è responsabilità di tutti noi. Vi terremo aggiornati.

UPDATE: qui trovate la seconda parte di questa odissea.

(per domande, richieste varie o se volete contribuire, potete contattarmi qui o su Twitter)

Il Cloud spiegato a Nonna Pina: l’alta affidabilità

Il Cloud spiegato a Nonna Pina: l’alta affidabilità

Noi nerd soffriamo di una patologia che spesso ci porta a dare per scontato che chiunque abbia ben chiaro ciò che, al contrario, è chiaro solo a noi.

Io non sono un nativo delle nuvole: so cosa sono i server, so cosa sono i RAID, e so anche dove si nascondono le birre in datacenter. Nelle mie frequentazioni risalenti a quell’era geologica ho una completa rappresentazione delle idee sbagliate che i sistemisti, gli sviluppatori o gli IT manager hanno in tema di cloud computing.

…e non sono poche: complici sicuramente campagne di marketing di compagnie “wannabe” traboccanti di buzzword (da #cloud a #blockchain passando per #ai), la confusione e quindi l’incomprensione è sempre in agguato. Da qui l’idea di una serie di post, scritti in modo (quasi) semplice, che abbiano lo scopo di spiegare (anche a Nonna Pina, per l’appunto) i fondamenti di questo, per qualcuno, nuovo mondo.

Partiamo da un tema molto caldo: l’alta affidabilità nel cloud. Quello che insomma spinge in media ogni due giorni un sistemista a lamentarsi nel suo gruppo Facebook di fiducia di qualcosa del tipo “…mi avevate detto che il cloud è super affidabile, ci ho spostato la mia macchina virtuale e dopo tre mesi era già down!”.

Questo è senza dubbio il salto concettuale più complesso: nel mondo pre-cloud l’alta affidabilità veniva implementata negli strati più bassi della piramide: si usavano server con componenti ultra ridondati, fatti per non guastarsi mai, collocati in datacenter sotterranei (o con scudi esterni in acciaio), progettati per resistere a qualunque attacco o avversa condizione esterna e, in sostanza, non spegnersi mai.

Un approccio sicuramente molto comodo per chi si occupa dell’applicativo che in questo resta totalmente agnostico perchè pensa a tutto l’infrastruttura sottostante, ma con un numero importante di problemi al seguito. Iniziando dal fatto che un simile modello è sostenibile solo su un singolo datacenter o al massimo un paio, a patto che siano molto vicini geograficamente: i costi crescono in modo sproporzionato, e si arriva comunque ad una situazione sub-ottimale sia di latenza per gli utenti finali (se i DC sono vicini tra loro non possono essere anche vicini agli utenti) che di rischio (sarebbero soggetti alle stesse minacce di tipo metereologico e geologico). Come se questo non bastasse, la scalabilità viene limitata in modo importante, richiedendo di fatto che ogni componente della vostra infrastruttura sia rinchiuso in una ed una sola VM.

Siamo di fronte ad uno dei cambiamenti di paradigma più radicali che il cloud abbia portato: l’alta affidabilità si sposta sugli strati più alti della piattaforma e si basa sul presupposto che ogni componente dell’infrastruttura possa fallire in qualunque momento, sia esso una VM, un datacenter o un intero campus. Notate il salto? Ci siamo evoluti dall’usare componenti indistruttibili pur sapendo non fosse possibile considerare ogni casistica al dare per scontato che tutto ciò che può succedere succederà, e quindi al pianificare reazioni automatiche a qualunque tipo di guasto. Si è passati da un paradigma molto costoso che non poteva considerare ogni eventualità ad un paradigma molto più economico, in cui si progetta tenendo sempre in considerazione il peggiore caso possibile.

Questo vi farà sicuramente riflettere: NukeMap alla mano, con una sola bomba nucleare in un punto strategico un attaccante potrebbe cancellare dalla faccia della terra i vostri conti correnti e infrastrutture critiche nazionali (in Italia ed in Europa, non conosco le leggi/pratiche comuni nel resto del mondo), ma non potrebbe scalfire minimamente le vostre playlist Spotify o i vostri post su Facebook. Quello che alcuni definirebbero “evento catastrofico” è per altri “ordinaria amministrazione”. Se non vogliamo guardare a casi così catastrofici, scommetto che almeno una volta nell’ultimo anno non siete riusciti ad accedere all’home banking della vostra banca a causa di una manutenzione programmata. Vi è mai capitato lo stesso su Snapchat o su Netflix? No? Esattamente.

A riprova del fatto che il focus si sia spostato dall’evitare gli imprevisti al gestirli, ci siamo addirittura inventati il Chaos Engineering: l’idea, anzi, la pratica di causare artificialmente guasti e disastri in produzione per verificare che le nostre piattaforme siano in grado di gestirli senza che gli utenti finali ne risentano.

Ricapitolando, quindi, l’alta affidabilità nei sistemi IT tradizionali si fonda sull’implementare infrastrutture sotto vari aspetti sub-ottimali usando componenti, costosi e complessi, progettati per non fallire mai. Nel paradigma cloud, al contrario, si implementano infrastrutture utilizzando componenti semplici e quindi economici, consci del fatto che questi prima o poi si romperanno e quindi progettando le applicazioni per gestire senza impatto le situazioni avverse.

…chiaro?

[nel prossimo capitolo a Nonna Pina spiegheremo invece i fondamenti di scalabilità]

DAZN, Serie A e streaming: dove stanno i problemi?

DAZN, Serie A e streaming: dove stanno i problemi?

Immagino sentiate la mancanza dei miei articoli polemici, quindi eccone uno. Parliamo di DAZN, della Serie A, di streaming e dei problemi che qualcuno ha avuto nella visione delle prime partite di questa stagione: mi sono capitati sottomano in questi giorni articoli di “esperti” con idee molto poco chiare che parlano di banda larga, di codec, di reti, di capacità dei server e altro.

Non ci siamo.

Siccome esattamente come nel caso dei vaccini la disinformazione fa danni e porta in direzioni sbagliate, vi regalo le mie competenze (la progettazione di infrastrutture per eventi straordinari come questo costituisce gran parte del mio lavoro) per fare chiarezza: se siete giornalisti e questo articolo non vi basta, sentitevi liberi di contattarmi.

Fatemi iniziare con un pò di sano debunking e quindi dall’esplorare quali non sono le cause della bassa risoluzione / buffering / interruzioni:

  • Non è la banda larga: il concetto di “banda larga” è riferito all’ultimo miglio, in sostanza alla connessione tra voi e la centrale Telecom più vicina. Per tutta una serie di ragioni che non vi sto a spiegare (questioni di fisica dei mezzi trasmissivi), questo è stato storicamente il collo di bottiglia delle reti. In alcune zone d’Italia si naviga a 1 gigabit al secondo, in altre a 250 megabit, in altre ancora a 30mbps e in alcune addirittura a soli 7mbps: quest’ultima è più che sufficiente a ricevere un flusso video con risoluzione decente, anche se la velocità effettiva dovesse essere inferiore. Non fraintendetemi, la lenta diffusione della banda larga può essere una serissima questione di sviluppo economico, ma in questo caso, semplicemente, non è il nostro problema.
  • Non sono i codec: alcuni codec possono essere più pesanti di altri sulla CPU, ma a meno che non stiate usando un PC di 25 anni fa più o meno qualunque processore è in grado di mostrare uno streaming in qualità accettabile senza interruzioni. A meno che sul vostro computer non girino anche un miner Bitcoin e 327 virus con cui condividete la capacità di calcolo, ovviamente.
  • Non è nemmeno la capacità dei server: la tecnologia si è evoluta e le realtà al passo con i tempi (e DAZN lo è) utilizzano infrastrutture elastiche, pronte a scalare per servire più richieste in pochi minuti, nel caso in cui si renda necessario. Di solito lavoriamo perchè le previsioni di carico siano adeguate, ma anche nel caso in cui si dimostrassero errate, correggere il dimensionamento sarebbe cosa da poco. Tutto questo, in una infrastruttura correttamente progettata, ad un costo molto basso.
  • Non è colpa della collocazione geografica delle CDN: questa è una teoria interessante ma totalmente campata in aria, e ci spenderò qualche minuto. Le CDN sono reti ad altissima capacità il cui compito è consegnare contenuti (video, immagini) agli utenti finali (voi). In rete si trova un comunicato stampa di DAZN in cui annunciano di aver scelto LimeLight, che in Italia ha infrastruttura a Milano e Palermo, come partner CDN: secondo gli scienziati, era ovvio che una CDN con presenza solo a Milano e Palermo non fosse all’altezza. Ma questo è sbagliato, per vari motivi:
    • L’analogia “immaginate come sarebbe difficile fare la spesa se gli unici due centri commerciali in Italia fossero a Milano e Palermo: da Roma sono 600km, quasi 12 ore di macchina tra andata e ritorno” potrebbe sembrare sensata, ma è pretestuosa: per la spesa settimanale si impiega un’ora normalmente, il viaggio Roma-Milano aumenta questo tempo di 12 volte ed equivale alla perdita di una giornata intera. Per i dati che viaggiano su fibre ottiche invece è il contrario: le “operazioni intermedie” indipendenti dalla distanza impiegano comunque qualche millisecondo, ed il dover percorrere una tratta di 600km al posto di una lunga solo 6 cambia di pochissimo il ritardo totale.
    • Se invece che usare Google in cerca di comunicati stampa i sopracitati scienziati avessero analizzato lo streaming vero, si sarebbero accorti che DAZN usa almeno tre CDN diverse, alcune con presenza più capillare in Italia. La storia di Palermo e Milano quindi non regge, o comunque non può essere banalizzata su un fattore di semplice distanza.
    • Internet non soffre di barriere nazionali (non ancora perlomeno), e le CDN hanno altre presenze vicino all’Italia come Vienna, Zurigo, Marsiglia, Monaco etc: è realistico pensare che anche queste location contribuiscano all’esperienza del pubblico italiano.

 

Arrivati a questo punto vi starete chiedendo dove stia il problema, ed eccoci alla risposta: non lo so, ma ho un paio di “maggiori indiziati”, che vi espongo.

Il primo è la particolare conformazione della rete italiana che per questioni geografiche e soprattutto storiche consiste di fatto in una stella con centro a Milano. Le interconnessioni tra diversi provider (tra le quali, ad esempio, la connessione tra chi vi vende la linea internet di casa e la CDN di DaZN) avvengono quasi esclusivamente lì, rendendo di fatto inutile la localizzazione geografica dei punti di distribuzione contenuti (per farla molto semplice, anche se la CDN di riferimento installasse un nodo nella vostra stessa città, con buone possibilità si dovrebbe comunque passare da Milano, o quantomeno da Roma, per raggiungerla).

Questo ci porta al secondo fattore in gioco: il trasporto dati nazionale di lunga distanza (il collegamento Napoli-Roma-Milano, per intenderci) ha costi relativamente alti se comparato a tratte molto più estese (Londra-New York), dettati dalla complessità infrastrutturale e dalla scarsità di competizione e di investimenti. Il traffico in rete è esploso negli ultimi anni, e certe tratte di interesse internazionale si sono sviluppate in modo molto veloce e spinto – altre, di interesse meramente nazionale, sono rimaste indietro e si stanno muovendo più lentamente. In questa condizione è facile che per motivi tecnico-economici si creino situazioni di congestione temporanea durante eventi eccezionali, per il semplice motivo che evitarla sarebbe troppo costoso.

Il terzo fattore è relativo al criterio di dimensionamento dei trasporti digitali, che spesso si deve per forza basare su dei dati di utilizzo medio. Torniamo all’analogia con i trasporti automobilistici: nelle due settimane centrali di Agosto sarebbe indubbiamente comodo se tutte le autostrade a tre corsie ne avessero invece cinque. Perchè allora non ne hanno cinque? Per il semplice motivo che quelle corsie sarebbero da mantenere tutto l’anno pur essendo necessarie per sole due settimane: i costi, in altre parole, avrebbero la prevalenza sui benefici. Lo stesso accade su certe tratte di trasporto difficili da ampliare e mantenere (molte altre sono invece dimensionate in base al picco di traffico atteso, quindi sulla base del caso peggiore).

Non si può infine non citare il nostro buon vecchio PEBKAC – acronimo che in informatica si usa per indicare il problema che sta tra la sedia e la tastiera (in questo caso tra la poltrona e il telecomando), cioè l’utente. In molti si sono avvicinati ai servizi di streaming per la prima volta in questa occasione, e non hanno mai verificato prima che la loro rete di casa (banalmente, il Wi-Fi) fosse pronto a gestire un simile traffico. Sono pronto a scommettere che gran parte dei problemi stia qui.

Tutto chiaro ora? Se ci sono domande chiedete pure.

 

iliad: dov’è veramente la rivoluzione?

iliad: dov’è veramente la rivoluzione?

A due mesi dal lancio in Italia di iliad, il nuovo operatore di telefonia mobile lowcost, l’hashtag #Rivoluzioneiliad continua a rompere le palle ad essere in testa al mio feed Twitter, con una strategia di comunicazione completamente incentrata sulla parola rivoluzione.

Ma c’è veramente una rivoluzione in atto? E se si, in cosa, precisamente? Vi siete fatti questa domanda?

Io si.

No, la rivoluzione non è nel prezzo. Certo, 6.99 €/mese per 40 GB di traffico con illimitati minuti ed SMS non sono male, ma la telefonia mobile in Italia era già da prima molto economica se comparata ai paesi vicini: provate voi ad andare in Inghilterra con 30 €/mese in mano a pretendere un iPhone.

Quindi, in cosa iliad è radicalmente diversa da Tre, Vodafone, Wind e Tim?

In famiglia era arrivato il momento di aggiornare tutti i contratti di telefonia, parliamo di famiglia estesa e 10 SIM in quattro nazioni, perciò ho dovuto studiare le offerte di ogni compagnia di rilievo nei paesi coinvolti.

E ho subito capito: in Italia iliad è diversa nella flessibilità, nella chiarezza, nell’onestà.

I “vecchi” operatori continuano imperterriti a nascondere tariffe in ogni angolo e sostanzialmente a prendere in giro i propri clienti: un esempio eclatante lo abbiamo visto due anni fa, quando un reparto marketing di qualcuno dei grandi ha deciso che accorciare il periodo di offerta da un mese a 28 giorni (di fatto introducendo una tredicesima mensilità da pagare) era più elegante che comunicare un aumento dei prezzi, e tutti gli altri lo hanno seguito. Semplice e diabolicamente geniale: aggiungere un mese sotto i piedi dei clienti, per aumentare le tariffe in modo coatto.

Non iniziamo nemmeno a parlare delle rimodulazioni (leggi: aumenti) unilaterali. Si, vero, si può recedere senza costi quando accadono, ma se ce n’è una ogni sei mesi e tutti gli operatori le propongono contemporaneamente, i clienti sono in una gabbia.

Anche sulle tariffe nascoste gli esempi si sprecano: chiamate a zero € al minuto, e scritto in piccolo uno scatto alla risposta che ti costringe a ipotecare la casa (la finezza di questa offerta è veramente apprezzabile). Tariffa mensile molto vantaggiosa, ma che poi si scopre durare solo per 6 mesi sui 24 totali di vincolo contrattuale. O, ancora, pacchetto 24 mesi con telefono a 20 €/mese e zero € di attivazione, ma con scritto sotto in piccolo che ne dovrai pagare 150 come rata finale.

Questo dovrebbe già bastare, ma c’è una cosa che trovo veramente impossibile da digerire: la penalizzazione della base clienti esistente di un operatore rispetto ai nuovi. Hai avuto una tariffa per 3 anni e adesso che sono scaduti i vincoli vuoi aggiornarla, perchè in media sul mercato con gli stessi soldi puoi avere di più? L’aggiornamento ad un piano che il tuo stesso operatore offre con attivazione gratuita ai nuovi clienti a te invece può costare anche 5/6 mensilità: ed è così, punto.

In Italia c’è un mercato che costringe i clienti al turnover continuo: vengono ignorate le richieste e le insoddisfazioni dei già clienti e si investe solo sui nuovi. Ci sarà sempre un potenziale “nuovo” cliente da portare a bordo che sarà insoddisfatto del suo precedente operatore, e così la ruota continua a girare.

Per fare un esempio di cosa c’è oltre le Alpi, in Inghilterra piani ricaricabili non esistono (esistono in realtà, ma sono talmente costosi che hanno senso solo se usate il cellulare tre minuti al mese), e anche se volete solo una SIM, serve un abbonamento di 12 o 24 mesi. Passati questi 12/24 mesi però, si è totalmente liberi di scegliere una qualunque offerta dello stesso operatore, pagandola al massimo come la pagherebbe un nuovo cliente e senza costi legati al cambio. Si, avete letto bene: al massimo, perchè molto spesso la vostra fedeltà sarà premiata e avrete accesso allo stesso pacchetto, ad un costo inferiore.

Ecco la #Rivoluzioneiliad: il nuovo operatore si propone di ribaltare tutto questo. La loro offerta è chiara, leggibile, facile da capire. Le procedure tutte automatizzate e semplici, il servizio clienti veloce e incredibilmente cordiale. Come se non bastasse, poco dopo il lancio qualcuno ha notato che una postilla nel contratto dava a iliad la possibilità di cambiare l’offerta, facendo traballare il “per sempre” con cui era pubblicizzata.

Sapete come questa ha reagito? Ha rivisto il contratto, togliendo l’ambiguità.

Il “se” è d’obbligo in quanto esiste da due mesi, ma se iliad dimostrerà di poter sostenere un business con queste premesse e questi principi, allora a tutti gli altri non resterà che adattarsi.

%d bloggers like this: