Refuzi o cerere de funcționalitate fără să pierzi clienta
5 min de citit
Închiderea buclei înseamnă de obicei să spui cuiva că cererea lui a fost lansată. Jumătatea grea, pentru care majoritatea sistemelor de urmărire nu au niciun proces, e să spui nu. Majoritatea cererilor de funcționalități nu sunt niciodată lansate, ceea ce înseamnă că majoritatea închiderii de buclă pe care un produs chiar o datorează utilizatoarelor sale e un refuz, nu un anunț, iar un refuz gestionat prost costă mai multă bunăvoință decât ar fi costat tăcerea. Gestionat bine, poate costa aproape nimic, pentru că ce vrea cea care cere cel mai mult, de cele mai multe ori, e să știe că a fost auzită, nu funcționalitatea în sine.
De ce contează refuzul bun la fel de mult ca lansarea bună?
Pentru că tăcerea se citește ca un refuz fără explicație, iar un nu explicat se citește ca atenție. Cea care nu aude nimic presupune că cererea a fost ignorată sau pierdută, iar ambele concluzii o învață să nu se mai obosească să întrebe, ceea ce e același rezultat pe care un produs îl obține cu un refuz real, doar atins mai încet și cu mai multă resentiment pe drum. Un răspuns care spune nu, clar și cu un motiv, închide bucla la fel de complet ca o funcționalitate lansată, și o face mai rapid.
| Răspuns | Ce învață cea care a cerut | Cost pentru relație |
|---|---|---|
| Tăcere | Nimeni n-a citit, sau nimănui nu-i pasă | Mare, și crește cu fiecare cerere viitoare |
| Răspuns automat fără motiv | E în coadă undeva, pe termen nedefinit | Mediu; cumpără timp dar nu încredere |
| Refuz cu motiv | A fost citit, luat în considerare și răspuns | Mic, dacă motivul e sincer |
| Refuz cu alternativă | Nevoia reală a fost chiar auzită | Cel mai mic; adesea construiește încredere |
Ce face un refuz să pice prost?
Aproape mereu trei lucruri, combinate. Genericitate: un „mulțumim pentru feedback” prefabricat care nu se referă la ce s-a cerut de fapt se citește ca și cum n-ar fi fost citit deloc, chiar dacă a fost. Întârziere: un refuz care vine la șase luni de la cerere, când cea care a întrebat a uitat deja că a întrebat, se simte mai rău decât un nu rapid, pentru că sugerează că cererea a stat neatinsă în loc să fi fost luată în considerare și refuzată. Și un motiv care nu ține: „nu e pe roadmap-ul nostru” nu răspunde la nimic, în timp ce „asta ar necesita reproiectarea modului în care funcționează permisiunile, ceea ce nu planificăm să atingem anul acesta” îi dă celei care a cerut ceva ce poate chiar evalua și, dacă contează suficient, escalada sau ocoli.
Ce ar trebui să spună de fapt un refuz bun?
Patru lucruri, în această ordine: o confirmare care numește cererea specifică, nu o parafrază generică; motivul real, declarat sincer chiar și atunci când motivul sincer e „asta nu se potrivește cu direcția în care merge produsul” în loc de o scuză mai blândă; dacă ușa e închisă sau doar nu e deschisă acum, pentru că astea necesită tonuri foarte diferite; și, când există, o alternativă care abordează nevoia de bază chiar dacă nu e funcționalitatea cerută la propriu.
Bună Jamie,
Mulțumim pentru cererea de a adăuga import CSV în masă pentru
invitațiile de echipă. Am analizat, și nu o vom construi: fluxul
nostru de invitații se bazează pe revizuirea individuală a fiecărui
membru nou din motive de securitate, iar importul în masă ar merge
împotriva asta prin design, nu din neglijență.
Dacă problema reală e invitarea rapidă a unei echipe mari, API-ul
suportă invitații individuale scriptate, ceea ce îți dă aproape toată
viteza fără să ocolești revizuirea: [link]. Spune-mi dacă vrei ajutor
să configurezi asta.Observă ce face asta ce nu poate face un șablon: numește funcționalitatea reală, dă un motiv legat de o decizie de design reală în loc de o politică vagă, și oferă o cale care rezolvă problema de bază în loc să închidă doar tichetul.
Cum diferă asta de închiderea buclei pe o funcționalitate lansată?
Mecanica e similară, tonul nu. Închiderea buclei de feedback cu clientul acoperă cazul lansat, unde mesajul e o veste bună și riscul principal e să uiți s-o trimiți. Un refuz e o veste proastă, sau cel puțin o veste nedorită, și necesită mai multă grijă în motivul dat și mai puțină automatizare în livrare: o notificare de funcționalitate lansată poate fi un comentariu șablon declanșat de o schimbare de status, dar un refuz care se citește ca șablon e exact modul de eșec pe care întreaga abordare încearcă să-l evite. Cele două împart totuși o cerință: cererea originală trebuie să rămână legată de cea care a făcut-o, aceeași disciplină de urmărire pe care o acoperă urmărirea cererilor de funcționalități, altfel nu există nicio modalitate de a trimite oricare dintre cele două mesaje individual.
Ar trebui un refuz să fie public, ca un status pe un roadmap public?
De obicei nu motivul specific, chiar dacă statusul da. Roadmap public acoperă etichetele de status pe care cea care a cerut le poate verifica fără să întrebe din nou, iar un status „refuzat” sau „neplanificat” poate face parte din acel sistem. Dar motivul detaliat, mai ales când atinge priorități interne sau context puțin flatant, de obicei merită mai mult în răspunsul individual decât pe o pagină de status publică, unde aceeași formulare trebuie să funcționeze pentru fiecare cititoare în loc de singura persoană care chiar a întrebat.
Merită fiecare cerere refuzată un răspuns individual?
Fiecare cerere de la o persoană numită și accesibilă da, măcar unul scurt. Cererile cu volum mare, duplicate sau anonime sunt excepția: gruparea cererilor similare și răspunsul o dată pe grup, sau actualizarea unei etichete de status partajate, e rezonabilă când răspunsurile individuale chiar nu se scalează. Linia de menținut e că „nu putem răspunde tuturor individual” ar trebui să fie o constrângere operațională reală, verificată față de volumul real, nu o scuză implicită pentru a sări peste un răspuns care ar fi luat două minute.
FAQ
E mai bine să refuzi rapid cu un motiv slab, sau să-ți iei timp pentru unul bun? Rapid, cu un motiv sincer, bate pe amândouă separat. Un răspuns rapid cu un motiv real, chiar și scurt, întrece un răspuns lent cu unul lustruit; întârzierea în sine e parte din ce strică încrederea.
Ar trebui un refuz să promită vreodată reconsiderarea cererii mai târziu? Doar dacă e chiar probabil și există un mecanism să o reconsideri de fapt, cum ar fi o etichetă care o readuce la suprafață la un ciclu de planificare. Un vag „o vom ține minte” fără un astfel de mecanism e funcțional același lucru cu tăcerea, doar formulat mai amabil.
Ce faci dacă motivul sincer e ceva ce compania nu poate împărtăși, cum ar fi o îngrijorare competitivă? Spune asta direct în loc să inventezi un motiv mai blând. „Nu putem împărtăși raționamentul specific aici, dar nu e ceva ce planificăm să construim” e mai sincer, și mai respectat, decât o explicație inventată care se prăbușește la o întrebare de urmărire.
Refuzarea unei cereri înseamnă că ar trebui ștearsă din urmărire? Nu. Păstreaz-o, etichetată ca refuzată cu motivul, ca să facă parte din tiparul față de care e grupată următoarea cerere similară, și ca un context schimbat mai târziu (o integrare nouă, o prioritate nouă de echipă) s-o poată readuce la suprafață în loc să înceapă evaluarea de la zero.
Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.