CX Operations · Scaling
Cosa si rompe per primo quando il supporto cresce, e in che ordine
Le funzioni di supporto non si degradano in modo uniforme. Falliscono in sequenza, e la sequenza è abbastanza costante da poterla anticipare.
L'ho visto succedere a dimensioni molto diverse, da team interni piccoli fino a un'operation europea con 1.850 agenti su quattro paesi. L'ordine cambia poco. Quello che cambia è quanto costa ogni rottura nel momento in cui qualcuno le dà un nome.
La rottura compare un livello sopra dove è successa
Questa è la parte che costa più soldi alle aziende, quindi la metto per prima.
Ogni livello di un'organizzazione di supporto assorbe il fallimento di quello sotto, finché non ce la fa più. Il che significa che il sintomo che vedi non è quasi mai la cosa rotta.
Risposte incoerenti dagli agenti sembrano un problema di formazione. Sotto, la documentazione ha smesso di essere aggiornata sei mesi fa e gli agenti lavorano a memoria e chiedendosi tra loro. Team lead lenti sembrano un problema di performance. Sotto, il percorso di escalation non ha un titolare definito fuori dal CX, quindi ogni questione trasversale diventa un favore personale che il tuo team lead deve negoziare.
Sistemi il livello dove compare il sintomo e torna entro un trimestre, perché la rottura vera è ancora lì.
Primo: la knowledge base
Un team di supporto piccolo tiene la conoscenza nelle persone. Uno chiede a voce, uno risponde, chi sta vicino sente. Funziona davvero bene, non costa niente, ed è il motivo per cui nessuno si accorge di quando smette di funzionare.
Smette quando il team è troppo grande perché tutti sentano tutto, oppure quando escono le prime persone. Il sintomo sono due agenti che danno due risposte diverse alla stessa domanda nella stessa settimana.
La soluzione non è comprare uno strumento per la knowledge base. Quasi tutte le aziende ne hanno già uno, non mantenuto. La soluzione è dare un nome alla persona il cui lavoro include tenerla aggiornata, e darle il tempo in agenda per farlo. È un ruolo noioso, senza gloria, e con il ritorno per euro più alto di tutta la funzione.
Secondo: il percorso di escalation
All'inizio l'escalation è un nome. Un agente ha un problema, scrive al fondatore o al capo prodotto, e si risolve nel pomeriggio.
Si rompe quando alla persona che riceve i messaggi finiscono le ore. Quello che la sostituisce è di solito niente, e a riempire il vuoto è l'agente che decide in silenzio di non fare escalation.
Quella decisione è la più costosa. Il problema non sparisce. Diventa un contatto non risolto, poi un contatto ripetuto, poi un cliente perso, e la prima volta che la direzione ne sente parlare è in una review tre mesi dopo.
La versione strutturale è un referente con nome e cognome in ogni dipartimento fuori dal CX, con un tempo di risposta concordato. Non un turno, non una casella condivisa. Una persona, il cui responsabile sa che questo fa parte del suo lavoro.
Terzo: la qualità smette di significare qualcosa
Il monitoraggio qualità sopravvive più a lungo di quanto dovrebbe, perché il punteggio continua a essere prodotto. Quello che si degrada è l'accordo su cosa significhi.
Con tre team lead che valutano, lo scostamento è inevitabile. Uno pesa l'empatia, un altro la risoluzione, il terzo la velocità perché è quello che gli chiede il suo capo. In due trimestri il voto di un agente dipende in modo concreto da chi lo ha ascoltato, e tutti sul floor lo sanno prima di chiunque in direzione.
Quando quella cosa diventa di dominio pubblico, il punteggio smette di cambiare i comportamenti e diventa qualcosa da gestire invece che da cui imparare. Sessioni di calibrazione a cadenza fissa, con una griglia scritta, sono l'unica cosa che ho visto tenere insieme il sistema.
Quarto: il livello dei team lead
Quasi tutte le scale-up promuovono i loro agenti migliori a team lead. È l'istinto giusto e viene eseguito male più spesso che bene.
Il problema non è la scelta della persona. È promuovere qualcuno in un ruolo che nessuno ha definito, senza formazione, i cui criteri di successo restano le vecchie metriche individuali. Continua a gestire da solo i contatti più difficili, perché è quello in cui è bravo e dove si sente competente. Il suo team non impara niente, e l'organizzazione ha trasformato un ottimo agente in un supervisore in affanno.
La versione in fase di selezione l'ho scritta in l'articolo su come assumere leadership CX. Internamente la soluzione è più piccola: definisci il ruolo prima della promozione, e cambia cosa misuri il giorno in cui cambia il titolo.
Quinto: nessuno fuori dal CX possiede un risultato cliente
Questa è l'ultima a rompersi e la più difficile da riparare, perché quando diventa visibile è un problema aziendale, non di supporto.
Lo schema è che il supporto diventa il posto dove arrivano i fallimenti di tutte le altre funzioni. Errori di fatturazione, ritardi di consegna, bug di prodotto, un'email di onboarding poco chiara. Il supporto assorbe il contatto, si scusa bene, risolve quel che può, e niente di tutto questo cambia il dipartimento che lo ha causato.
Con 1.850 agenti su quattro mercati, la cosa che ha smesso di scalare era la distanza tra una decisione e la persona che la esegue. Un problema in un paese ci metteva settimane a salire, e arrivava riformulato da ogni livello che aveva attraversato. Lo abbiamo chiuso mettendo un referente con nome e cognome in ogni dipartimento fuori dal CX, e dando ai responsabili di prima linea una strada diretta che saltava due livelli. È stato scomodo per il centro, e ha significato che i problemi mi arrivavano quando erano ancora poco costosi.
La risposta strutturale a tutto questo è quella che descrivo nel modello del Customer Happiness Center.
Cosa sistemare per primo
Lavora dal fondo della catena, non dal sintomo che urla di più.
Documentazione ed escalation prima degli strumenti, sempre. Uno strumento nuovo appoggiato su un processo non documentato codifica quel processo, e smontarlo dopo costa diverse volte quello che costerebbe sistemarlo adesso.
Se sei tra Series A e Series B e più di due di queste cose ti suonano familiari, la lettura onesta è che la tua funzione di supporto sta in piedi perché alcune persone stanno lavorando più duro di quanto il disegno consenta. Funziona finché una di loro non se ne va.