Idea principale

Una tassonomia del feedback dei clienti si degrada da entrambi i lati. Con troppe poche categorie si mettono insieme cose che non stanno allo stesso livello: un attrito su una schermata e un obiettivo di crescita finiscono nello stesso contenitore, e il contenitore non significa più nulla. Con troppe categorie la classificazione diventa un lavoro a sé: la persona che inserisce un verbatim dopo un'intervista esita, rimanda, poi smette di inserire.

Il secondo fallimento è il più costoso, perché non si vede nel modello. Sulla carta, la tassonomia fine è migliore: distingue di più, perde di meno. Nell'uso, è vuota.

Il criterio di scelta non è quindi la completezza teorica della suddivisione, ma ciò che un team riesce davvero a sostenere nel tempo — dopo sei mesi, quando la novità è passata e nessuno controlla più la compilazione. Un framework è buono se a quel punto viene ancora compilato.

Perché è importante

Questo cambia chi decide. Pensata come un problema di modellazione, la tassonomia si progetta da soli, a tavolino; pensata come un problema di adozione, si mette alla prova su verbatim reali con chi dovrà inserirli — supporto, customer success, vendite.

E dà una ragione per smettere di aggiungere. Davanti a un feedback che non trova posto, il riflesso è creare la categoria mancante; decidere in base all'adozione impone di mettere sul piatto il costo d'uso di quella categoria in più.

Sfumature e limiti

L'adozione non è l'unico criterio: un framework banale da compilare ma incapace di distinguere due livelli di decisione viene adottato ed è inutile. Il vincolo è una soglia minima — coprire tutto lo spettro del feedback — sotto la quale la semplicità non serve a niente.

La soglia dipende anche da chi inserisce. Un team di analisti dedicati regge una granularità che un team operativo, che inserisce fra un appuntamento e l'altro, non reggerà.

Domande aperte

• Quante categorie abbandona un team nelle settimane successive alla messa in servizio, e questo abbandono si vede già durante il test?