Bucla de feedback

Cum ceri feedback clienților într-un produs software

7 min de citit

Ca să cereți feedback clienților într-un produs software, puneți o singură întrebare precisă despre ceva ce utilizatorul tocmai a făcut, în locul în care a făcut-o. „Cum a mers exportul raportului?” imediat după un export primește un răspuns. „Spuneți-ne ce părere aveți despre produsul nostru” din subsolul paginii primește tăcere. Restul paginii e despre momente, canale și formulările exacte.

Majoritatea sfaturilor pe această temă sunt scrise pentru magazine și ghișee de relații cu clienții. O echipă de software știe exact ce a făcut utilizatorul cu o secundă în urmă, deci întrebarea poate fi despre asta.

MomentUnde întrebațiÎntrebare gata de folosit
Imediat după terminarea unei sarciniÎn aplicație, lângă rezultat„Exportul a făcut ce aveați nevoie?”
După prima folosire a unei funcții noiÎn aplicație, o singură dată„Ce încercați să faceți cu Bulk Edit?”
După rezolvarea unui tichet de suportÎn conversația de suport„S-a rezolvat sau mai e ceva în neregulă?”
După ce un utilizator se blochează sau abandonează un fluxEmail, a doua zi„V-ați oprit la pasul 3 din configurare. Ce v-a împiedicat?”
După 30 de zile de folosire regulatăEmail de la o persoană cu nume„Care e singurul lucru pe care l-ați schimba?”
Când un utilizator anuleazăÎn fluxul de anulare„Ce v-a făcut să plecați astăzi?”
După ce livrați ceva ce au cerutUnde au cerut„Ați cerut import CSV. E live. Acoperă cazul dumneavoastră?”

Care e momentul potrivit să ceri feedback?

Momentul potrivit e imediat după ce utilizatorul termină ceva, cât detaliul e încă proaspăt. O întrebare care urmează unei acțiuni primește un răspuns despre acea acțiune. O întrebare care apare de nicăieri primește un răspuns despre starea de spirit a persoanei, sau niciun răspuns.

Nu întrebați la înscriere, pentru că nimeni n-a folosit încă nimic. Nu întrebați în mijlocul unei sarcini, pentru că întrerupeți exact ce vreți să aflați. După ce o persoană a răspuns, lăsați-o în pace până aveți ceva de raportat înapoi.

Unde ar trebui să ceri feedback clienților?

Întrebați în locul în care s-a petrecut experiența. Un mesaj în aplicație se potrivește unei întrebări despre un ecran. Conversația de suport se potrivește unei întrebări despre o remediere. Emailul se potrivește unei întrebări despre o săptămână de folosire sau despre un flux abandonat. Un apel se potrivește întrebărilor pe care nu le puteți anticipa.

Fiecare canal aduce alt fel de răspuns:

  • În aplicație: răspunsuri scurte, imediate și precise, dar doar de la cei prezenți. Nu auziți nimic de la utilizatorii care au plecat.
  • Conversația de suport: de la oameni deja destul de frustrați cât să scrie. Bun pentru a găsi ce e stricat, slab pentru a judeca restul produsului.
  • Email: răspunsuri mai lungi de la mai puțini oameni, și singura cale de a ajunge la utilizatorii care au tăcut. Scrieți-l ca o notă scurtă de la o persoană cu nume, cu o singură întrebare în ea.
  • Interviu: calea de a afla de ce fac oamenii ce fac. Rugați-i să vă arate cum lucrează și tăceți cât timp o fac.

Calitatea semnalului din feedback arată cum să cântăriți ce vă spune fiecare canal.

Cum ceri feedback în mod profesionist?

Fiți precis în privința lucrului vizat, spuneți de ce întrebați și faceți ca răspunsul să coste sub un minut. O cerere profesionistă numește momentul, face clar că un om va citi răspunsul și nu își cere scuze pentru întrerupere.

Numiți acțiunea exactă („exportul pe care tocmai l-ați rulat”), cereți un singur lucru, folosiți o casetă de text liber fără câmpuri obligatorii și semnați cu un prenume.

Care e o propoziție bună pentru a cere feedback?

O propoziție bună e o întrebare despre un moment precis, la care se poate răspunde în câteva cuvinte. Comparați cele două coloane de mai jos. La cele din stânga se poate răspunde dând din umeri. Cele din dreapta cer persoanei să-și amintească ceva real.

Cerere slabăCerere mai bună
„Aveți feedback?”„Care a fost cea mai grea parte din configurare?”
„Cum vă place produsul nostru?”„Pentru ce l-ați folosit săptămâna trecută?”
„Evaluați experiența de la 1 la 10.”„Ați terminat astăzi ce veniseți să faceți?”
„Spuneți-ne cum ne putem îmbunătăți.”„Ce v-a încetinit săptămâna aceasta?”
„Ne-ați recomanda?”„Cui l-ați arătat ultima oară și ce ați spus?”

Alta care merge aproape oriunde: „Ce folosiți în schimb când asta nu vă ajută?” Scoate la iveală adevăratul concurent, care e adesea o foaie de calcul.

Care sunt cele mai proaste moduri de a cere feedback?

Cele mai proaste cereri sunt largi, premature, lungi sau cu răspunsul sugerat. Au toate aceeași problemă: persoana nu poate răspunde fără să facă gândirea pe care ar fi trebuit s-o faceți voi.

  1. „Vă rugăm să completați chestionarul nostru de 20 de întrebări.” Cei care îl termină sunt cei cu cel mai mult timp liber sau cu cele mai puternice păreri.
  2. Un popup pe prima pagină după autentificare. Utilizatorul a venit să facă ceva și l-ați blocat. Singurul răspuns rezonabil e să-l închidă.
  3. „Ne-ar plăcea să aflăm părerea dumneavoastră!” fără nicio întrebare. Cere utilizatorului să inventeze subiectul.
  4. O întrebare sugestivă: „Cât de mult vă place noul dashboard?” Primiți acord și nu aflați nimic.
  5. O notă fără continuare. Un 6 din 10 vă spune starea de spirit. Nu vă spune ce să schimbați.
  6. Întrebați, apoi tăceți. Asta vă costă runda următoare, despre care vorbim mai jos.

Cum se numește feedbackul clienților despre un produs?

Feedbackul despre un produs se numește de obicei feedback de produs și se împarte în două feluri. Un raport de eroare spune că ceva nu funcționează cum trebuie. O cerere de funcționalitate spune că ceva lipsește. Distincția decide cine se uită primul la el, iar cerere de funcționalitate sau eroare trasează această linie. Un al treilea fel, laudele, merită păstrat și citat cu permisiune.

Un formular de feedback care oferă „Bug” și „Feature request” ca prime opțiuni face această primă triere în locul vostru.

Ce faceți cu răspunsurile?

Puneți fiecare răspuns acolo unde lucrează deja echipa, cu cuvintele persoanei intacte. O singură linie de text citat bate rezumatul vostru. Etichetați-l după tip și urgență aproximativă, uniți repetițiile și hotărâți: construiți, amânați sau refuzați.

Refuzul e tot un răspuns. „Nu vom construi asta, și iată de ce” pune capăt așteptării, iar refuzul cererilor de funcționalități are formulări pentru el. Pentru instalațiile din spate, urmărirea cererilor de funcționalități descrie cum aduceți cereri din cinci canale într-o singură listă. Dacă primiți cereri în scris, un șablon de cerere de funcție le păstrează comparabile.

Widgetul Changeloop înregistrează fiecare trimitere ca issue GitHub, deci feedbackul ajunge lângă codul care îl va rezolva. Cu orice instrument regula e aceeași: o singură listă, un singur responsabil, niciun răspuns uitat în căsuța cuiva.

De ce să spui ce s-a livrat?

Îi arată persoanei că a meritat să răspundă. Un utilizator care v-a spus ceva și apoi aude „asta s-a livrat, mulțumim” are un motiv să răspundă din nou. Unul care nu aude nimic concluzionează că nimeni nu citește caseta.

Deci ultimul pas al cererii este un răspuns. Spuneți fiecărei persoane care a cerut când se livrează cererea ei, pe limba ei, pe canalul pe care l-a folosit. Închiderea buclei de feedback a clientului descrie mecanismul: intrarea de changelog publicată declanșează mesajul, deci solicitantul e anunțat abia când schimbarea e live. În Changeloop, când feedbackul din widget a devenit un issue GitHub iar pull request-ul îmbinat îl închide, aprobarea intrării postează un comentariu „Shipped” pe acel issue și îi arată trimițătorului intrarea în widget; issue-urile create manual și repozitoriile GitLab sau Bitbucket nu primesc comentariu. Documentația noastră descrie configurarea widgetului și a feedului.

Un răspuns poate fi scurt: „Ați cerut import CSV în martie. E live astăzi, iar iată cum funcționează.” Vă oferă și cea mai bună întrebare următoare: dacă acoperă ce aveau nevoie.

Un plan de pornire

Alegeți un moment din tabelul de la început, cel în care utilizatorii reușesc sau renunță cel mai des. Scrieți o întrebare pentru el, puneți-o într-un singur canal și citiți fiecare răspuns două săptămâni înainte de a adăuga un al doilea mesaj. Răspundeți oricui v-a dat ceva concret.

FAQ

Cât de des ar trebui să ceri feedback clienților? Legați cererile de evenimente, nu de calendar. Un utilizator ar trebui să vadă cel mult un mesaj pe săptămână și niciunul imediat după ce a răspuns la unul. Următorul mesaj după un feedback ar trebui să fie un răspuns despre ce s-a întâmplat cu el.

Cum ceri feedback fără să-i enervezi pe utilizatori? Întrebați după o sarcină, niciodată în mijlocul uneia, limitați-vă la o întrebare și faceți mesajul ușor de închis. Respectați o închidere câteva săptămâni.

Ar trebui să oferi un stimulent pentru feedback? De obicei nu e nevoie. O întrebare precisă și un răspuns vizibil cântăresc mai mult decât un card cadou, iar stimulentele atrag oameni care vor recompensa. Păstrați-le pentru interviuri, unde cereți 20 de minute din timpul cuiva.

Ce faci dacă nu răspunde nimeni? Îngustați întrebarea și apropiați-o de moment, de exemplu un singur ecran, întrebat imediat după folosire. Dacă rămâne liniște, scrieți direct câtorva utilizatori și folosiți acele conversații ca să scrieți mesaje mai bune.


Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Documentație pentru dezvoltatori

changeloop
Echipa care construiește un changelog care închide bucla. Utilizatorii cer ceva, echipa ta livrează, cel care a cerut află.