Customer-obsessed… puoi davvero dire di esserlo?

Mettere il cliente al centro è fondamentale per instaurare una relazione di lunga durata, ma le parole non bastano

Il cliente al centro: quante volte vi capita di sentire questo claim? In continuazione, giusto?
E quante volte – in situazioni che non sono andate lisce – vi siete davvero sentiti al centro dell’attenzione come cliente?
Ecco, appunto… tra il dire e il fare a volte… c’è di mezzo ciò che le aziende pensano di essere ma non sono.

Il tema della customer-obsession sta prendendo piede anche in Italia e moltissime aziende – non solo Amazon – si confrontano con questo cambio radicale di prospettiva, un’evoluzione che porta la soddisfazione del cliente a rimodulare l’intera strategia aziendale.
Moltissimi professano la propria customer-obsession o customer-centricity ma nei fatti – non solo a parole – quanti lo sono davvero?

Prima delle vacanze mi sono capitate tre esperienze diverse che mi hanno fatto riflettere sul tema e che vi racconto oggi.

Customer-obsession: volevo solo un’informazione…

Un amico decide di mettere il suo bilocale in affitto; i nuovi affittuari chiedono di poter disporre di una lavatrice. La cucina – acquistata anni fa – non è predisposta per l’inserimento dell’elettrodomestico perché l’appartamento sinora è stato messo sul mercato per affitti brevi.
Il proprietario a cavallo delle vacanze ha bisogno di capire che lavatrice può inserire nella struttura della cucina e se è necessariamente legato all’acquisto di un modello da incasso.

Sul sito dell’azienda questo tipo di informazione è irreperibile, ci sono solo le dimensioni degli elettrodomestici venduti.
Si può prenotare una consulenza online (bel servizio!) ma l’appuntamento in questione ha un costo che viene stornato solo in caso di acquisto di un’intera cucina. Ma qui non si tratta di fare il preventivo per una soluzione “chiavi in mano”, semplicemente di ottenere un’informazione su un elettrodomestico.

L’amico prova a contattare l’assistenza: il numero di servizio è a pagamento; quello gratuito non risponde mai.
Una mattina ho assistito a non meno di 20 tentativi… parte il disco, si selezionano le voci corrette e quando è il momento di parlare con un operatore silenzio… nessuno risponde dall’altra parte (ci sente? non ci sente?).
L’apparecchio rimane muto per interminabili minuti e poi puntualmente cade la telefonata.
Alla faccia dell’attenzione al cliente… in fondo la persona in questione voleva solo un’informazione, un chiarimento che avrebbe richiesto non più di 5 minuti.
Ma davvero l’unica alternativa che si prospetta è quella di recarsi al punto vendita? Sul serio?

Alla fine l’informazione è arrivata da un volenteroso falegname che ha ispezionato la cucina in videochiamata. E’ stato in grado di fornire tutte le indicazioni del caso in pochi minuti senza che nessuno dei due interlocutori abbia dovuto spostarsi né perdere tempo.
Punto, set, partita!
In questo caso libero professionista batte azienda multinazionale dell’arredamento che fattura miliardi ogni anno in tutto il mondo.

Qual era il valore per il cliente?
Ottenere velocemente una risposta per poter effettuare il giusto acquisto e installarlo per tempo. Era pronto a mettere mano subito al portafoglio ma non ha trovato dall’altra parte un canale d’ascolto.

Se non rispondi ai clienti che cercano di contattarti in una situazione di bisogno puoi dirti davvero “customer-obsessed”?

Customer-centricity: rincorrere la gente per pagare

In famiglia siamo abbonati da anni ad una pay tv.
L’anno scorso durante il lockdown decidiamo di aderire ad un’offerta di contenuti particolarmente interessante e di goderci l’intrattenimento durante la forzata permanenza in casa.

Al cambio dell’offerta il provider smette di inviare le fatture mensili.
Chiamiamo per segnalare l’anomalia, il mancato addebito viene riportato almeno 6 volte. Cominciamo a far presente che – oltre ad essere una situazione ridicola in cui è il cliente che segnala il mancato pagamento – vorremmo evitare di dover pagare tutto in un’unica rata.
La situazione va avanti così per altri 3 mesi e poi – come da programma – arriva il costo tutto in una botta sola, esattamente ciò che volevamo evitare.

A onor del vero devo dire che dopo l’ennesimo contatto telefonico la situazione si sblocca e l’azienda, per ovviare al problema, ci offre due mesi di contenuti gratis.
Apprezzo molto il gesto e penso che questo sia un buon esempio di ovviare ad eventuali errori ma quanto tempo ho dovuto passare al telefono per segnalare un’anomalia?
Perché il customer care non è stato in grado di registrare la situazione la prima volta che sono stati contattati? L’informazione si è persa nel nulla.

Se non ascolti ciò che i clienti ti segnalano sui canali predisposti al contatto puoi dirti davvero “customer-obsessed”?

Customer first: sono già vostro cliente!

Alzi la mano chi non è stufo di ricevere offerte di tutti i tipi dai vari call center!
Ultimamente il mio cellulare è stato preso d’assalto.

Ho cambiato operatore telefonico da circa 8 mesi perché pagavo una tariffa mensile totalmente sproporzionata ai servizi offerti. Il nuovo è stato molto efficiente nel processo di number portability e attivazione, niente da dire… dopodiché sono cominciate telefonate a raffica per propormi…… di passare alla compagnia a cui avevo appena aderito (!!!).
Una situazione che è andata avanti non per una settimana bensì per mesi.

Ora, io dico, spesso i sistemi di CRM implementati nelle aziende sono incasinati e talvolta sfuggiti al controllo ma nel momento in cui vi segnalo più volte (non meno di 8) che sono già vostra cliente volete fare qualcosa per aggiornare questo benedetto dato?
Da dove diavolo attingono i contatti i call center? Possibile che non ci sia un qualche processo di normalizzazione dei dati – anche ex post – che faccia evitare di perdere tempo a voi e di infastidire i già clienti?

Il cliente al centro sì, ma non dei vostri casini!

Anche qui stiamo parlando di una realtà che ha quasi 500 milioni di clienti in tutto il mondo… non posso credere che in un’azienda di simile portata le lead vengano trattate con tanta superficialità!

Se neanche sai che un tuo cliente è un tuo cliente puoi dirti davvero “customer-centered”?

La customer-centricity come azione

Io penso che prima di proporsi come customer-first sia opportuno per qualunque realtà professionale fare un atto di realismo e capire qual è davvero lo stato dell’arte dal punto di vista del cliente.
Anche solo realizzare una user journey e analizzare dove e quando il servizio non è all’altezza delle aspettative può fare una grande differenza.
E’ un primo passo per mettersi in discussione e ci sono frotte di clienti che sarebbero più che felici di aiutare le aziende nella risoluzione.

Essere customer-obsessed non è uno stato dal mio punto di vista, bensì un’azione, una tensione costante a fare meglio. E’ un processo kaizen, di miglioramento continuo.

Diventare customer-centric non è una moda né uno scherzo; è un processo che richiede tempo e rivoluziona nelle fondamenta la cultura aziendale.
Nessun cliente pretende che questo avvenga in pochi giorni, ma tutti vogliono vedere uno sforzo reale verso questo risultato dalle aziende che si dichiarano tali.

Fatti, non parole!
Altrimenti la customer obsession o customer centricity è solo l’ennesimo hashtag di marketing, opera di belletto, forma priva di sostanza.

Non sarebbe più serio dichiararsi customer-curious e far partire un processo di apprendimento?
Con meno arroganza, presunzione di sapere cosa “è meglio per il cliente” e auto-centrismo si potrebbero costruire collaborativamente dei prodotti straordinari. Non pensate?

Riferimenti

Ecco qualche link se volete approfondire il tema:

Da quando l’architettura informativa è passata di moda?

Oggi è uno di quei giorni in cui mi sento… “vintage”, diciamo così…
In questo periodo mi capita di lavorare con diverse agenzie esterne, alcune per la parte di UX e UI di nuovi servizi, altri per la parte di sviluppo, altre ancora che devono semplicemente declinare dei template fatti e finiti inserendo contenuti in lingua.
E proprio quest’ultima esperienza è quella che mi ha fatto sorgere grosse perplessità.

Ho visto un processo al contrario: la creazione dei contenuti ha tenuto decisamente in poco conto la struttura precedentemente condivisa del sito. Per certi versi l’ha addirittura stravolta senza però proporre un disegno alternativo.

La mia domanda è: com’è possibile pensare di sviluppare dei contenuti senza ragionare sull’architettura informativa del sito?
Per me questo approccio non ha alcun senso.

L’architettura dell’informazione riguarda il modo in cui informazioni, documenti, beni e servizi sono organizzati all’interno degli spazi (digitali e non) per favorire l’orientamento dell’utente, la reperibilità dell’informazione stessa, la comprensibilità e l’usabilità.

L’importanza di organizzare lo spazio informativo

Quando ho iniziato a lavorare in ambito digital – ormai decenni fa – non c’erano ancora tutte le metodologie e gli approcci strutturati che ci sono oggi. Il mio mentore era un architetto con una grande passione per il mondo digitale e l’attitudine da ricercatore universitario quale in effetti era.

Correva l’anno 2000 e ciò che facevamo ai tempi in ambito digitale era il corrispettivo di un lavoro pionieristico. Architetture informative, interaction design, progettazione di interfacce erano termini inusuali, attività che portavamo avanti sperimentando con gli strumenti e le modalità.
Ma c’era già un punto fermo: tutto parte dalla progettazione dello spazio nel suo insieme. Prima di entrare nei dettagli bisogna avere chiaro il disegno nel suo complesso.

Una volta che avete quello tutti i pezzi vanno poi ad incastrarsi come in un puzzle.
Si parte dalle fondamenta nella costruzione, non dalla decorazione d’interni.
La struttura d’insieme prima dei singoli ambienti.
La mappa del sito prima della UX e della UI, non il contrario.

Il percorso della progettazione

Questi insegnamenti a distanza di anni sono tuttora validi; costituiscono basi solide per la progettazione di qualsiasi tipo di servizio.

E ancora oggi procedo così: la prima cosa che faccio se devo riprogettare un servizio esistente è sempre andare a mapparlo. Sia esso un sito o un’applicazione più complessa non posso ragionare chiaramente se non sono consapevole di com’è articolato.

Stessa cosa mi capita quando si tratta di progettare un prodotto ex-novo. Subito dopo la fase di discovery e la raccolta dati cominciamo ad abbozzare la struttura.
Non è detto che sia “buona la prima”; anche su questo artefatto potrà essere necessario iterare più volte.
Personalmente mi piace partire da un’idea sulla base degli insight raccolti, schizzare un disegno, confrontarmi con il team di sviluppo e gli stakeholder per raccogliere vari punti di vista e arrivare alla fine ad una mappa che farà da guida per tutti i passaggi successivi.
E’ con questa mentalità che approccio ancora a tutti i lavori.

Qui trovate un paio di esempi di ciò che intendo per architettura informativa.
Il primo è uno schema della struttura di una rivista scientifica.

Architettura informativa di una rivista scientifica

Il secondo una mappatura delle funzionalità di un Back-Office.

Il valore della mappatura

Per quanto mi riguarda il tempo impiegato in questa analisi è ben speso perché a partire da questi schemi posso progettare con efficacia e controllo cosa andrò a cambiare, come e che tipo di effetti mi aspetto di produrre sulle metriche del servizio.

Ecco perché sono spiazzata quando mi capita di imbattermi in proposte senza capo né coda… non riesco ad orientarmi! Né a tacere a dire il vero…

Si dice “se non lo sai spiegare in maniera semplice significa che non l’hai capito abbastanza” ma parafrasando posso dire “se non sei in grado di tradurre la tua idea in uno schema, forse hai ancora della confusione in testa”.

Mi trovo davanti pagine e pagine di testi con una sequela di keyword dove però non è chiara la relazione tra i contenuti, né tantomeno come dovranno essere calati su una struttura esistente. Oppure wireframe incoerenti che vengono costruiti senza una solida mappa sottostante.

Quindi vi chiedo: davvero l’architettura informativa è passata di moda? E se conoscete delle valide alternative vi va di condividerle? Io senza un’organizzazione logica e semantica dell’informazione nello spazio digitale navigo nel buio.

3 consigli per esercitare meglio la tua product ownership

Conoscete Robbin Schuurman? E’ un Agile Coach e Scrum Master Trainer di origini olandesi che ha alle spalle un’esperienza di Product Owner e prima ancora di Project Manager.
E’ anche un prolifico autore di articoli e post sul suo blog, su Medium e Scrum.org.
In questi giorni ascoltavo una puntata di Product Owner Podcast di cui è stato ospite per parlare delle responsabilità del PO e di come dire no.

Abbiamo già parlato in passato di questa responsabilità del PO.
Schuurman ribadisce che dire no è una delle cose più difficili che il product owner deve fare e allo stesso tempo uno dei modi più efficaci per creare valore.
Proprio così! Creare valore attraverso la negazione. Perché di 10 idee o richieste che arrivano sul nostro tavolo statisticamente una sola è veramente rilevante per le nostre personas primarie mentre le altre 9 – che magari sono comunque buone idee – non lo sono.
Quindi dire no alla maggior parte delle richieste ha la finalità di preservare il massimo valore del prodotto che state gestendo.

Speriamo di poter leggere presto qualche chicca nel prossimo libro di Schuurman in uscita “50 Shades of No”; nel frattempo lui ha suggerito 2 modi immediatamente spendibili per dire no e condiviso alcuni consigli per esercitare al meglio la product ownership che trovo pratiche e centrate. Ve le riassumo.

Dire no in modo gentile e perentorio

Sostiene il coach: “Dire no è difficile per moltissimi Product Owner. È difficile perché ci sono tantissime persone che chiedono o esigono determinate funzionalità. Massimizzare il valore è una tua responsabilità e lo fai mediante lo stakeholder management e dicendo no”.

Ecco due esempi efficaci per un NO “chiaro e tondo”:

  • non implementiamo la funzionalità X perché non è coerente con la product vision
    Questo è un no molto potente, ma presuppone che abbiate formulato una product vision e che sia stata anche condivisa con gli stakeholder
  • non lavoreremo sul requisito X perché non è di valore per i clienti e gli utenti
    Anche questa affermazione è perentoria e contiene a sua volta un presupposto: che abbiate preso il tempo di validare con questi interlocutori cosa sia realmente di valore.

In sostanza il presupposto per poter dire no con credibilità è fare bene l’attività di stakeholder management. Attendiamo “50 Shades of No” per prendere altri spunti…

Non tutti gli stakeholder sono ugualmente importanti

“Chi sono i tuoi stakeholder e con chi spendi il tuo tempo?” ci chiede Chris.
Nella sua esperienza ha incontrato molti product owner che trascorrono tanto tempo a gestire gli stakeholder (e questa di per sé è una cosa positiva!) senza tuttavia fare dei distinguo in termini di importanza o dedicando troppa energia a quelli meno importanti.
Gli stakeholder meno importanti sono solitamente quelli con poco potere e poco interesse per il prodotto finale; gruppi di persone che dovrebbero essere tenuti d’occhio saltuariamente.

“Nelle pratiche quotidiane molti PO sembrano dare ugualmente importanza a tutti. Mi dispiace… questo non è vero! Non tutte le parti interessate sono ugualmente importanti! Alcuni hanno un alto interesse per il prodotto, altri un interesse basso… alcuni hanno molto potere, altri no… alcuni collaborano con voi nella creazione, altri sono solo interessati all’impatto che il vostro prodotto avrà sul loro dipartimento e sulle persone”.

E’ fondamentale secondo il coach essere ben consapevoli di quali sono gli stakeholder più importanti e meno importanti. Robbin Schuurman ci suggerisce di creare una mappa degli stakeholder così da organizzare il nostro tempo con le parti interessate in modo più efficace, efficiente e intelligente (è un tema che abbiamo toccato in relazione agli stakeholder).

Esercitati ad agire da owner

Non è inusuale all’inizio della carriera come PO trovarsi in situazioni in cui non si ha alcun mandato, alcun potere decisionale o alcuna libertà. E’ capitato a tutti noi e in breve tempo abbiamo realizzato che dovevamo rimboccarci le maniche.
Non è la Scrum Guide o qualche guru dell’Agile a venirci in aiuto quando si tratta di guadagnare autorevolezza sul campo di gioco.

Quello che potete cominciare a fare (in qualsiasi momento) è comportavi da “owner”, da proprietari del prodotto.
Non avete bisogno di chiedere il permesso di sviluppare una nuova funzionalità o dedicare del tempo alla risoluzione di bug o alla riduzione del debito tecnico. Schuurman ci incita a comportarci da proprietari e non da proxy.

“Devi smettere di fare lo scriba e iniziare a comportarti da owner! Il modo in cui ti presenti agli stakeholder, il modo in cui presenti il tuo prodotto e il modo in cui agisci (parli, ti comporti, ti presenti, ecc.) determinano il mandato che ottieni! Se inizi ad agire come un vero product owner, ad assumerti la responsabilità, a formulare un piano dimostrando che ti prendi cura del prodotto e del tuo team, questo ti aiuterà ad aumentare il tuo mandato”.

Questo è un punto cardine sottolineato dall’autore: tra le responsabilità del PO c’è creare un piano, costruire il prodotto e renderlo di successo (in questo ordine!). Se non ti sei preso il tempo di elaborare un tuo piano qualcun altro te ne affibbierà uno. Del resto la delivery ha bisogno di una tabella di marcia, una previsione, una guida per un arco di tempo che va dai 3 ai 6 mesi, senza che diventi “il santo graal” né tantomeno sia scolpito nella pietra.
Piano e vision devono precedere la creazione del product backlog.

Smetti di fare il piccione viaggiatore…

Schuurman riporta la sua esperienza di coaching: “Quello che vediamo fare abbastanza spesso dai Product Owner è che iniziano a fungere da proxy, un gateway, l’unico punto di ingresso, verso il team di sviluppo.
Il team non sono autorizzati a parlare con gli stakeholder, i clienti e gli utenti; tutte le comunicazioni in questi team passano attraverso il Product Owner
”.

Esercitare il controllo non significa fare da tramite tra gli stakeholder e il team.
Questa mala pratica ha un costo enorme in termini di tempo per il PO oltre a rivelarsi inefficace e diseducativa per lo Scrum team.

Un product owner consapevole del proprio ruolo supporta il più possibile la comunicazione diretta tra stakeholder, clienti, utenti, business, sales e sviluppo.
In questo modo il team recepisce direttamente i feedback sul prodotto, acquisisce comprensione degli utenti e del business.
Per quanto il mandato del PO sia ampio e versatile non c’è bisogno di affrontare tutti i problemi da solo; si può fare leva sulla squadra nel momento in cui ha compreso la visione di prodotto, la direzione in cui vuoi andare e quali sono i prossimi passi da compiere.

Tra i valori agili ci sono l’autonomia e il coraggio: non dimentichiamo di lasciare spazio al team per esercitarli! Una volta che il PO ha condiviso la vision di prodotto e ha fornito un obiettivo chiaro per lo sprint , lascia che gli sviluppatori si organizzino a riguardo e che prendano tutti i contatti che servono per costruire al meglio le funzionalità richieste, compresa la comunicazione diretta con gli stakeholder.
E se proprio qualcosa va storto, c’è la Sprint Retrospective con il team per scoprire cosa non ha funzionato e come migliorare in futuro.