Come rifiutare una richiesta senza perdere la cliente

Chiudere il cerchio di solito vuol dire dire a qualcuno che la sua richiesta è stata rilasciata. La metà difficile, per cui la maggior parte dei sistemi di tracciamento non ha alcun processo, è dire di no. La maggior parte delle richieste di funzionalità non viene mai rilasciata, il che significa che la maggior parte della chiusura del cerchio che un prodotto deve davvero alle sue utenti è un rifiuto, non un annuncio, e un rifiuto gestito male costa più buona volontà di quanto ne sarebbe costato il silenzio. Gestito bene, può costare quasi nulla, perché ciò che chi fa una richiesta vuole davvero, il più delle volte, è sapere di essere stata ascoltata, non la funzionalità in sé.

Perché rifiutare bene conta quanto rilasciare bene?

Perché il silenzio si legge come un rifiuto senza spiegazione, e un no spiegato si legge come attenzione. Chi non sente nulla presume che la richiesta sia stata ignorata o persa, ed entrambe le conclusioni le insegnano a smettere di disturbarsi a chiedere, che è lo stesso risultato che un prodotto ottiene con un rifiuto vero e proprio, solo raggiunto più lentamente e con più risentimento lungo la strada. Una risposta che dice no, chiaramente e con un motivo, chiude il cerchio in modo completo quanto una funzionalità rilasciata, e lo fa più in fretta.

Cosa fa atterrare male un rifiuto?

Quasi sempre tre cose, in combinazione. Genericità: un “grazie per il feedback” preconfezionato che non fa riferimento a cosa è stato davvero chiesto si legge come non letto affatto, anche se lo era. Ritardo: un rifiuto che arriva sei mesi dopo la richiesta, quando chi ha chiesto se l’è ormai dimenticato, sembra peggio di un no rapido, perché implica che la richiesta sia rimasta ferma invece di essere stata considerata e rifiutata. E un motivo che non regge: “non è nella nostra roadmap” non risponde a nulla, mentre “questo richiederebbe riprogettare come funzionano i permessi, e non intendiamo toccarli quest’anno” dà a chi ha chiesto qualcosa che può davvero valutare e, se conta abbastanza, far scalare o aggirare.

Cosa dovrebbe dire davvero un buon rifiuto?

Quattro cose, in quest’ordine: un riconoscimento che nomina la richiesta specifica, non una parafrasi generica; il motivo reale, dichiarato onestamente anche quando il motivo onesto è “questo non si adatta a dove sta andando il prodotto” invece di una scusa più morbida; se la porta è chiusa o semplicemente non è aperta ora, perché servono toni molto diversi; e, quando esiste, un’alternativa che affronta il bisogno sottostante anche se non è la funzionalità richiesta alla lettera.

Ciao Jamie,

Grazie per la richiesta di aggiungere l'importazione CSV in blocco per
gli inviti al team. L'abbiamo valutata, e non la costruiremo: il nostro
flusso di invito si basa sulla revisione individuale di ogni nuovo
membro per motivi di sicurezza, e l'importazione in blocco andrebbe
contro questo per progettazione, non per svista.

Se il vero problema è invitare rapidamente un team numeroso, l'API
supporta inviti individuali via script, che ti dà quasi tutta la
velocità senza saltare la revisione: [link]. Fammi sapere se vuoi
aiuto per configurarlo.

Nota cosa fa questo che un modello non può: nomina la funzionalità reale, dà un motivo legato a una vera decisione di design invece che a una politica vaga, e offre un percorso che risolve il problema sottostante invece di chiudere solo il ticket.

In cosa differisce dal chiudere il cerchio su una funzionalità rilasciata?

La meccanica è simile, il tono no. Chiudere il ciclo di feedback con il cliente copre il caso rilasciato, dove il messaggio è una buona notizia e il rischio principale è dimenticarsi di inviarlo. Un rifiuto è una cattiva notizia, o almeno non quella desiderata, e ha bisogno di più cura nel motivo dato e meno automazione nella consegna: una notifica di funzionalità rilasciata può essere un commento preconfezionato innescato da un cambio di stato, ma un rifiuto che si legge come preconfezionato è esattamente il fallimento che questo intero approccio vuole evitare. I due condividono un requisito, però: la richiesta originale deve restare collegata a chi l’ha fatta, la stessa disciplina di tracciamento coperta da tracciamento delle richieste di funzionalità, altrimenti non c’è modo di inviare nessuno dei due messaggi individualmente.

Un rifiuto dovrebbe essere pubblico, come uno stato su una roadmap pubblica?

Di solito non il motivo specifico, anche se lo stato sì. Roadmap pubblica copre le etichette di stato che chi ha chiesto può controllare senza chiedere di nuovo, e uno stato “rifiutato” o “non pianificato” può far parte di quel sistema. Ma il motivo dettagliato, specie quando tocca priorità interne o contesto poco lusinghiero, di solito vale di più nella risposta individuale che in una pagina di stato pubblica, dove la stessa formulazione deve funzionare per ogni lettrice invece che per l’unica persona che ha davvero chiesto.

Ogni richiesta rifiutata merita una risposta individuale?

Ogni richiesta da una persona nominata e raggiungibile sì, almeno breve. Richieste ad alto volume, duplicate o anonime sono l’eccezione: raggruppare richieste simili e rispondere una volta per gruppo, o aggiornare un’etichetta di stato condivisa, è ragionevole quando le risposte individuali davvero non scalano. La linea da mantenere è che “non possiamo rispondere a tutti individualmente” dovrebbe essere un vincolo operativo reale, verificato contro il volume effettivo, non una scusa predefinita per saltare una risposta che avrebbe richiesto due minuti.

FAQ

È meglio rifiutare rapidamente con un motivo debole, o prendersi tempo per uno buono? Rapidamente, con un motivo onesto, batte entrambi presi separatamente. Una risposta rapida con un motivo vero, anche breve, supera una risposta lenta con uno rifinito; il ritardo stesso è parte di ciò che danneggia la fiducia.

Un rifiuto dovrebbe mai promettere di rivalutare la richiesta più avanti? Solo se è davvero probabile e c’è un meccanismo per rivalutarla davvero, come un’etichetta che la fa riemergere a un ciclo di pianificazione. Un vago “lo terremo presente” senza tale meccanismo è funzionalmente uguale al silenzio, solo formulato più gentilmente.

E se il motivo onesto è qualcosa che l’azienda non può condividere, come una preoccupazione competitiva? Dillo direttamente invece di inventare un motivo più morbido. “Non possiamo condividere il ragionamento specifico qui, ma non è qualcosa che pianifichiamo di costruire” è più onesto, e più rispettato, di una spiegazione inventata che crolla davanti a una domanda di approfondimento.

Rifiutare una richiesta significa che dovrebbe essere cancellata dal tracciamento? No. Tienila, etichettata come rifiutata con il motivo, così fa parte del pattern contro cui viene raggruppata la prossima richiesta simile, e così un contesto cambiato più avanti (una nuova integrazione, una nuova priorità di team) può farla riemergere invece di ripartire da zero con la valutazione.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Documentazione per sviluppatori, Strumenti di changelog a confronto