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.

Chi scrive le user stories nel tuo Scrum team?

Se pensate che sia una domanda retorica ebbene non lo è!
E’ anzi un interrogativo su cui può essere utile mettere a confronto esperienze di vita diverse.
Questa riflessione nasce in seguito alla partecipazione ad un meetup di Pierluigi Pugliese intitolato “Stupidaggini che avete sentito su Scrum, Ep. 3: Le User Stories non si scrivono!”, organizzato all’interno del gruppo Milano Scrum/Agile User’s Group.

Il titolo – inutile dirlo – mi ha attirato ed ero sicura che potesse aggiungere spunti interessanti alle riflessioni su uno degli strumenti più utilizzati dai Product Owner.
Ma non parleremo soltanto di chi scrive le user stories, smonteremo anche alcune “leggende metropolitane” che derivano da cattive pratiche ed insegnamenti discutibili discussi durante l’incontro con l’Agile coach.

Inutile dire che molti di questi comportamenti errati li ho vissuti in prima persona e in alcuni casi so di esserne stata anche corresponsabile, quindi voglio fare la mia parte nel smantellarli insieme a voi.
Nella mia esperienza con diversi development team Scrum ho visto un po’ tutte le situazioni: dai team che non fanno partire lo sviluppo se non ci sono user stories super-dettagliate, al PO che si sobbarca l’intero onere della chiarificazione dei bisogni, ai team che che contribuiscono solo al livello degli acceptance criteria fino a quelli più navigati che sono in grado di scrivere storie end-2-end e spacchettarle a dovere.
Tutte queste situazioni – giuste e sbagliate – sono dei pattern ed è utile sapere come affrontarle.

Ma partiamo dalla prima di queste male pratiche…

Il minimalismo delle user stories

Le storie sono:

  • il valore di business che vogliamo generare per l’utente
  • una promessa di conversazioni
  • riassumono l’aspettativa di business
  • descrivono l’attività da fare
  • sono un elemento di pianificazione
  • non si scrivono

Vi ritrovate in queste affermazioni?
C’è forse qualcosa che vi stona?
Davvero le user stories non si scrivono? Cosa intende dire Pugliese?

Pierluigi con questa affermazione provocatoria vuole ribadire che le user stories non sono semplicemente un modo un po’ diverso di esprimere i requisiti, un altro tipo di formato, bensì piuttosto un modo minimalista per descrivere le funzionalità e di semplificare la parte burocratica.

Questo approccio minimalista funziona a patto che la conversazione tra stakeholder, sviluppatori e Product Owner avvenga davvero.
La scrittura è secondaria; la card riassume la conversazione e non ne contiene tutti i dettagli, solo ciò che serve al team per ricordarsi cosa deve fare.

Capite bene che questo approccio definito lightweight dagli agilisti (= leggero) sta in piedi se e solo se una reale interazione avviene.
Se non c’è un momento di confronto e di approfondimento qualsiasi user story sarà monca, una promessa (di conversazione) non avvenuta.
E a quel punto nascerà inevitabilmente la richiesta di una maggiore documentazione.
Infatti una cosa che mi è spesso capitato di notare è che quando i team sono meno maturi tendono a utilizzare le storie come copertine di Linus e chiedono al Product Owner di specificare e dettagliare molto di più.

Quando ravviso questo comportamento so che è il momento di alzare le orecchie.
Può essere un indicatore rilevante del fatto che:

  • il chiarimento non è ancora avvenuto (la card non serve a eludere la conversazione)
  • Il vero valore dello strumento user stories non è stato compreso (siamo di fronte a una trasposizione dei vecchi documenti di requisiti)
  • il team demanda in toto la chiarificazione al PO (di questo aspetto ne parliamo più in là…)
  • c’è scarsa fiducia tra gli interlocutori (questo – se vero – è l’aspetto più problematico che richiede attenzione immediata).

Le parole di Pugliese per me sono sempre illuminanti…

Senza la conversazione le user stories non hanno senso. Non sono una religione alternativa per scrivere i requisiti! Se usate in maniera stupida, meccanica, inutile e dannosa fanno spegnere il cervello agli sviluppatori

Chi fa la business analysis?

Chi è l’owner della business analysis? La domanda sembrerebbe retorica… in fondo esiste una figura professionale proprio per questo, tuttavia negli Scrum team come sapete non ci sono singoli “detentori” di attività.
E’ un punto importante spesso poco capito. Nel team ideale tutti fanno tutto, o meglio sono in grado di fare tutto. Nella realtà spesso non è così perché le competenze e le seniority sono diverse, ma pratiche come il peer programming e le pair review ci vengono in aiuto facendo sì che la conoscenza di tutto il team aumenti progressivamente con il tempo.

La stessa cosa vale per l’analisi dei requisiti.
Magari date per scontato che il momento della chiarificazione dei bisogni sia appannaggio del Product Owner e del business analyst (se avete la fortuna di averlo) ma non è così!

“Voglio che il team faccia business analysis” – ha insistito il coach durante il meetup – “Più persone possibili devono saper fare le domande giuste e ovviamente devono avere competenze di dominio sufficienti per fare le domande giuste”.

Ma a cosa punta questo approccio? La finalità è avere una responsabilità condivisa dell’intero Scrum team sul risultato finale. L’analisi è una premessa fondamentale per fare la modellazione di un sistema attraverso le user stories.
Per questo motivo secondo Pugliese è un’attività che può essere portata avanti direttamente dal team con gli stakeholder senza necessariamente la presenza del Product Owner (ricordate quando si diceva di “smettere di fare il piccione viaggiatore”?)

Il vero ruolo del Product Owner

Ma se il product owner non scrive le storie e non fa chiarificazione – ha chiesto un partecipante – qual è esattamente il suo ruolo?
Esattamente quello che prescrive la Scrum Guide: essere il responsabile di massimizzare il valore prodotto.

Il PO non fa chiarificazione, può partecipare a questa attività ma non è il suo focus primario. Il product owner regola il sistema dal punto di vista delle priorità; decide cosa fare del backlog (se una storia entra, non entra e con quale priorità). In questo modo fa strategia di prodotto.
Impiegarlo solo per spiegare o scrivere le user stories è di fatto svilire questa figura a un lavoro di segretariato, quando invece il suo vero scopo è capire cosa c’è di valore e come massimizzarlo.

Non possiamo pensare che gli stakeholder si mettano d’accordo sulle priorità perché hanno solitamente interessi troppo diversi. Il team può chiarire autonomamente cosa vuole ottenere lo stakeholder, ma poi è con il PO che ci si confronta sulle priorità.
Non è compito degli sviluppatori, dei designer o degli analisti decidere cosa è più importante e cosa no.

Detto questo vi chiedo: nella vostra esperienza quanta parte del lavoro del PO è focalizzato sulla massimizzazione del valore e quanto sulla scrittura e la chiarificazione? Adesso che sapete qual è l’approccio più produttivo ed efficace avete voglia di condividerlo con i vostri team?