Un processo decisionale
The Kanso Filter.
Sei domande prima che un cambiamento vada live.
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 Sua proprietà?
Handling time, customer effort, CSAT, first-contact resolution, lifetime value. Scelga 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 custom?
Le roadmap delle piattaforme evolvono più velocemente del codice custom.
06
Sa indicare la metrica che dovrebbe muovere, e come la misurerà?
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 Sua proprietà 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 Suo cambiamento.
Risponda a ciascuna domanda per il cambiamento che sta valutando. Il verdetto si aggiorna man mano. Nulla di ciò che scrive lascia il Suo browser.
01
Elimina un passaggio?
02
Muove una metrica di Sua proprietà?
03
Migliora l'accuratezza o la qualità?
04
Riduce al minimo gli oneri di manutenzione?
05
Il nativo batte il custom?
06
Sa indicare la metrica che dovrebbe muovere, e come la misurerà?
Verdetto corrente
0 di 6 risposte sì
Funziona interamente nel Suo browser. Non vediamo né conserviamo le Sue 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 custom è diventato una passività.
La soluzione non è più disciplina durante lo sviluppo. È decidere bene prima dello sviluppo. Scegliere la metrica di Sua proprietà, 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 Sua proprietà? | 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 custom? | Forse | Verificare prima l'auto-tagging nativo di Zendesk. |
| 06 | Sa indicare la metrica che dovrebbe muovere, e come la misurerà? | 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.