Un processo decisionale
The Kanso Filter.
Sei domande prima che un cambiamento venga rilasciato.
Lo applichiamo prima di raccomandare qualsiasi cambiamento a un team di servizio. La maggior parte dei cambiamenti che falliscono non fallisce in fase di sviluppo. Vengono rilasciati senza una risposta chiara a una di queste sei domande. Il filtro forza quelle risposte prima che il lavoro inizi, quando è ancora possibile intervenire a basso costo. Lo utilizzi sulle proprie decisioni, sulle proposte dei vendor e sulle nostre.
Perché esiste
È nato come un elenco di lavori andati a vuoto.
Continuavamo ad assistere al rilascio di cambiamenti che aggiungevano un workflow, un'integrazione, una schermata, e sei mesi dopo i numeri su cui il team veniva giudicato non si erano mossi. L'impegno era reale. Il risultato no. Così abbiamo scritto le domande che, a posteriori, avrebbero bloccato ciascuno di quei cambiamenti prima che qualcuno li sviluppasse. Quell'elenco è il filtro. È volutamente diretto: se un cambiamento non riesce a rispondere a queste domande, la mossa onesta è non farlo.
Ognuna intercetta una modalità di fallimento prima del rilascio.
01
Elimina un passaggio?
I passaggi sono clic, campi di form, ricerche, handoff, decisioni che il team deve prendere.
02
Muove una metrica di cui siete responsabili?
Handling time, customer effort, CSAT, first-contact resolution, lifetime value. Scegliete quella su cui il team è giudicato, non quella più facile da contare.
03
Migliora l'accuratezza o la qualità?
Misurabile. Nominare la metrica prima del deployment.
04
Riduce al minimo gli oneri di manutenzione?
Valuti la manutenzione continuativa, i single point of failure e il debito tecnico che il team si porta dietro, non solo il tempo risparmiato.
05
Il nativo batte il personalizzato?
Le roadmap delle piattaforme evolvono più velocemente del codice personalizzato.
06
Sapete indicare la metrica che dovrebbe muovere, e come la misurerete?
Indichi la misura e la finestra temporale prima di iniziare, così potrà capire in seguito se ha funzionato.
Il passo successivo
Decidere sulla base del miglioramento sostanziale, non del risparmio ottenuto.
Un cambiamento guadagna il suo posto quando muove una metrica di cui siete responsabili abbastanza da essere percepita. Il risparmio sui costi è un dato, non il test. Se non riesce a nominare la metrica, il target e la finestra temporale prima di iniziare, non potrà stabilire in seguito se il cambiamento ha funzionato, ed è così che un cambiamento fallisce silenziosamente: nessuno ha definito la misura che lo avrebbe dimostrato. Quindi lo si rigetti velocemente. Si elimini l'idea debole nella fase delle domande, dove costa un pomeriggio, non dopo lo sviluppo, dove costa un trimestre. Lo scopo del filtro è spendere quel pomeriggio.
Usalo ora
Valuta il vostro cambiamento.
Risponda a ciascuna domanda per il cambiamento che sta valutando. Il verdetto si aggiorna man mano. Nulla di ciò che scrive lascia il vostro browser.
01
Elimina un passaggio?
02
Muove una metrica di cui siete responsabili?
03
Migliora l'accuratezza o la qualità?
04
Riduce al minimo gli oneri di manutenzione?
05
Il nativo batte il personalizzato?
06
Sapete indicare la metrica che dovrebbe muovere, e come la misurerete?
Verdetto corrente
0 di 6 risposte sì
Funziona interamente nel vostro browser. Non vediamo né conserviamo le vostre risposte.
Come usarlo
Percorrere le sei domande in ordine. Poi decidere.
- Tutti e sei sìSi rilascia.
- Quattro o cinqueSi rilascia con note esplicite sui gap.
- Meno di quattroNon si rilascia. Il perimetro non è corretto, o il cambiamento non restituirà abbastanza da giustificare la manutenzione.
Perché i cambiamenti falliscono
Un cambiamento raramente fallisce perché è stato sviluppato male.
Fallisce perché nessuno ha nominato la metrica che avrebbe dovuto muovere, quindi nessuno ha potuto verificare in seguito se lo avesse fatto. Oppure perché la manutenzione ha silenziosamente superato il valore. Oppure perché la piattaforma ha rilasciato la stessa cosa nativamente tre mesi dopo e lo sviluppo personalizzato è diventato una passività.
La soluzione non è più disciplina durante lo sviluppo. È decidere bene prima dello sviluppo. Scegliere la metrica di cui siete responsabili, concordare il target e la finestra temporale e verificare prima se il nativo copre la maggior parte del percorso. Se un cambiamento non può mostrare un miglioramento sostanziale, la mossa giusta è solitamente non farlo.
Esempio pratico
Deployment di AI di auto-tagging su Zendesk.
Il filtro applicato, riga per riga, a una decisione reale.
| # | Domanda | Verdetto | Note |
|---|---|---|---|
| 01 | Elimina un passaggio? | Sì | Elimina il tagging manuale sull'80% dei ticket. |
| 02 | Muove una metrica di cui siete responsabili? | Sì | Un routing più veloce riduce il time-to-first-response; ~45 sec × 30.000 ticket/mese = 375 ore restituite alla coda. |
| 03 | Migliora l'accuratezza? | Forse | È necessario un confronto con la baseline prima del go-live. |
| 04 | Riduce al minimo gli oneri di manutenzione? | Forse | Retraining trimestrale del modello (contenuto), senza nuovi single point of failure, ma deve guadagnarsi il posto. |
| 05 | Il nativo batte il personalizzato? | Forse | Verificare prima l'auto-tagging nativo di Zendesk. |
| 06 | Sapete indicare la metrica che dovrebbe muovere, e come la misurerete? | Sì | Accuratezza di tagging e routing indicata in anticipo, monitorata settimanalmente rispetto a una baseline. |
| Risultato del filtro | Si rilascia se il nativo non copre la tassonomia. Altrimenti si usa il nativo. | ||
Ha un cambiamento che sta valutando?
Finanziamo un numero limitato di assessment Maturity Mapping per team con un problema di servizio reale. Candidarsi indicando la metrica che si vuole muovere, e se non è adatta, lo diremo.