소프트웨어 제품에서 고객 피드백을 요청하는 방법
6분 분량
소프트웨어 제품에서 고객 피드백을 요청하려면, 사용자가 방금 한 일에 대해, 그 일을 한 바로 그 자리에서 구체적인 질문 하나를 던져라. 내보내기를 막 마친 직후의 “그 보고서 내보내기는 어땠나요?”에는 답이 돌아온다. 푸터에 놓인 “저희 제품에 대한 생각을 들려주세요”에는 침묵만 돌아온다. 이 글의 나머지는 요청하기에 좋은 순간, 채널, 그리고 정확한 문구를 다룬다.
이 주제의 조언은 대부분 매장이나 고객 센터를 위해 쓰였다. 소프트웨어 팀은 사용자가 1초 전에 무엇을 했는지 정확히 알고 있으므로, 질문도 바로 그것에 대한 것일 수 있다.
| 순간 | 질문할 곳 | 바로 쓸 수 있는 질문 |
|---|---|---|
| 작업이 끝난 직후 | 앱 안, 결과 옆 | “방금 내보내기가 필요한 대로 됐나요?” |
| 새 기능을 처음 쓴 뒤 | 앱 안, 한 번만 | “일괄 편집으로 무엇을 하려고 하셨나요?” |
| 지원 티켓이 해결된 뒤 | 지원 스레드 안 | “그걸로 해결됐나요, 아직 이상한 부분이 있나요?” |
| 사용자가 멈추거나 흐름을 떠난 뒤 | 하루 뒤 이메일 | “설정 3단계에서 멈추셨네요. 무엇이 방해가 됐나요?” |
| 30일 동안 꾸준히 쓴 뒤 | 실명을 밝힌 사람이 보내는 이메일 | “딱 하나만 바꿀 수 있다면 무엇인가요?” |
| 사용자가 해지할 때 | 해지 과정 안 | “오늘 떠나기로 한 이유는 무엇인가요?” |
| 요청받은 것을 출시한 뒤 | 요청했던 그 자리 | “CSV 가져오기를 요청하셨죠. 지금 출시됐습니다. 쓰시는 경우를 충분히 다루나요?” |
피드백을 요청하기에 적절한 때는 언제인가
적절한 때는 사용자가 무언가를 끝낸 직후, 세부 사항이 아직 머릿속에 남아 있을 때다. 행동 뒤에 따라오는 질문은 그 행동에 대한 답을 얻는다. 난데없이 도착한 질문은 그 사람의 그날 기분에 대한 답을 얻거나, 아예 답을 얻지 못한다.
가입할 때는 묻지 마라. 아직 아무것도 써보지 않았기 때문이다. 작업 도중에도 묻지 마라. 알고 싶은 바로 그 일을 방해하는 셈이기 때문이다. 한 번 답을 받았다면, 알려줄 소식이 생길 때까지는 그 사람을 그냥 두어라.
고객 피드백은 어디에서 요청해야 하는가
경험이 일어난 바로 그 자리에서 물어라. 앱 안의 프롬프트는 화면에 대한 질문에 맞는다. 지원 스레드는 수정에 대한 질문에 맞는다. 이메일은 일주일 동안 써본 소감이나 사용자가 중간에 그만둔 흐름에 대한 질문에 맞는다. 통화는 예측할 수 없는 질문에 맞는다.
채널마다 얻는 답의 종류가 다르다.
- 앱 안: 짧고, 즉각적이며, 구체적이지만, 그 자리에 있는 사람들에게서만 나온다. 이미 떠난 사용자에게서는 아무 말도 듣지 못한다.
- 지원 스레드: 글을 쓸 만큼 이미 답답했던 사람들에게서 나온다. 고장 난 곳을 찾는 데는 좋지만, 나머지 제품을 판단하는 데는 부족하다.
- 이메일: 더 적은 사람에게서 더 긴 답이 오며, 조용해진 사용자에게 닿을 수 있는 유일한 방법이다. 실명을 밝힌 사람이 보내는 짧은 메모로, 질문은 하나만 담아 써라.
- 인터뷰: 사람들이 왜 그렇게 하는지 알아내는 방법이다. 일하는 방식을 보여달라고 부탁하고, 그동안 조용히 지켜보라.
각 채널이 알려주는 내용에 얼마나 무게를 둘지는 피드백 신호의 품질에서 다룬다.
피드백은 어떻게 정중하게 요청하는가
대상을 구체적으로 짚고, 왜 묻는지 밝히고, 답하는 데 1분이 들지 않게 하라. 정중한 요청은 그 순간을 명시하고, 사람이 답을 읽는다는 것을 분명히 하며, 방해한 것에 대해 사과하지 않는다.
정확한 행동(“방금 실행하신 내보내기”)을 말하고, 한 가지만 묻고, 필수 입력란이 없는 자유 서술 칸을 쓰고, 이름으로 서명하라.
피드백을 요청하는 좋은 문장은 무엇인가
좋은 문장은 특정한 순간에 대한 질문이며 몇 마디로 답할 수 있다. 아래 두 열을 비교해 보라. 왼쪽은 어깨를 으쓱하는 것으로 답할 수 있다. 오른쪽은 사람이 실제로 있었던 일을 떠올려야 한다.
| 약한 요청 | 더 강한 요청 |
|---|---|
| “피드백 있으신가요?” | “설정하면서 가장 어려웠던 부분은 무엇인가요?” |
| “저희 제품은 어떠세요?” | “지난주에 이걸 무엇에 쓰셨나요?” |
| “경험을 1점에서 10점으로 평가해 주세요.” | “오늘 하려던 일을 끝내셨나요?” |
| “어떻게 개선하면 좋을지 알려주세요.” | “이번 주에 작업 속도를 늦춘 한 가지는 무엇인가요?” |
| “저희를 추천하시겠어요?” | “마지막으로 이걸 누구에게 보여주셨고, 뭐라고 말씀하셨나요?” |
거의 어디서나 통하는 질문이 하나 더 있다. “이게 맞지 않을 때는 대신 무엇을 쓰고 계신가요?” 이 질문은 진짜 경쟁자를 드러내며, 그 경쟁자는 흔히 스프레드시트다.
피드백을 요청하는 최악의 방법은 무엇인가
최악의 요청은 너무 넓거나, 너무 이르거나, 너무 길거나, 유도하는 것이다. 공통된 문제는 사람이 답하려면 요청하는 쪽이 했어야 할 생각을 대신 해야 한다는 점이다.
- “20문항 설문에 응해 주세요.” 끝까지 마치는 사람은 시간이 가장 많거나 의견이 가장 강한 사람들이다.
- 로그인 직후 첫 페이지의 팝업. 사용자는 무언가를 하러 왔는데 그것을 막았다. 닫아 버리는 것이 유일하게 합리적인 대답이다.
- 질문 없이 “피드백을 기다립니다!”만 쓴 경우. 사용자에게 주제를 직접 만들어 내라고 요구하는 셈이다.
- 유도 질문: “새 대시보드가 얼마나 마음에 드시나요?” 동의는 얻지만 배우는 것은 없다.
- 후속 질문 없는 점수. 10점 만점에 6점은 기분을 알려줄 뿐, 무엇을 바꿔야 하는지는 알려주지 않는다.
- 묻기만 하고 입을 닫는 것. 이는 다음 라운드를 잃게 만든다. 아래에서 다룬다.
제품에 대한 고객 피드백은 무엇이라고 부르는가
제품에 대한 피드백은 보통 제품 피드백이라고 부르며, 두 종류로 나뉜다. 버그 리포트는 무언가가 의도대로 작동하지 않는다는 말이고, 기능 요청은 무언가가 빠졌다는 말이다. 이 구분이 누가 먼저 살펴볼지를 결정하며, 그 선은 기능 요청과 버그 리포트의 구분에서 긋는다. 세 번째 종류인 칭찬은 간직해 두고, 허락을 받아 인용할 가치가 있다.
첫 선택지로 “버그”와 “기능 요청”을 제시하는 피드백 양식은 이 첫 분류를 대신 해준다.
받은 답은 어떻게 처리하는가
모든 답을 팀이 이미 일하고 있는 곳에, 그 사람의 말을 그대로 둔 채 넣어라. 인용문 한 줄이 그것을 요약한 글보다 낫다. 유형과 대략적인 긴급도로 태그를 달고, 반복되는 것은 합치고, 결정하라. 만들 것인가, 보류할 것인가, 거절할 것인가.
거절도 하나의 답이다. “이것은 만들지 않을 것이며, 그 이유는 이렇습니다”라고 말하면 기다림이 끝나며, 기능 요청 거절에 그 문구가 있다. 배관 작업은 기능 요청 추적이 다섯 개 채널의 요청을 하나의 목록으로 모으는 방법을 설명한다. 요청을 글로 받는다면 기능 요청 템플릿이 요청들을 비교 가능한 상태로 유지해 준다.
Changeloop의 위젯은 접수되는 각 항목을 GitHub issue로 만들어, 피드백이 그것을 고칠 코드 바로 옆에 놓인다. 어떤 도구를 쓰든 규칙은 같다. 목록은 하나, 담당자도 하나, 누군가의 받은 편지함에 방치된 답은 없어야 한다.
왜 출시된 내용을 알려야 하는가
답한 것이 시간을 들일 가치가 있었음을 그 사람에게 보여준다. 무언가를 말해 준 사용자가 나중에 “출시되었습니다, 감사합니다”라는 말을 들으면 다시 답할 이유가 생긴다. 아무 말도 듣지 못한 사용자는 그 상자를 아무도 읽지 않는다고 결론짓는다.
그래서 요청의 마지막 단계는 답장이다. 요청한 사람 각자에게, 그들의 언어로, 그들이 쓴 채널에서, 요청이 출시되는 때를 알려라. 고객 피드백 루프 닫기가 그 메커니즘을 설명한다. 발행된 체인지로그 항목이 메시지를 촉발하므로, 요청자는 변경이 실제로 적용된 뒤에야 연락을 받는다. Changeloop에서는 위젯 피드백이 GitHub issue가 되고 병합된 풀 리퀘스트가 그 issue를 닫았을 때 항목을 승인하면, 그 issue에 “Shipped” 댓글이 달리고 위젯에서 제출자에게 그 항목이 보인다. 직접 만든 issue와 GitLab, Bitbucket 저장소에는 댓글이 달리지 않는다. 위젯과 피드 설정은 문서에 나와 있다.
답장은 짧아도 된다. “3월에 CSV 가져오기를 요청하셨습니다. 오늘 출시되었고, 사용 방법은 이렇습니다.” 이 답장은 다음에 던질 가장 좋은 질문, 즉 필요한 것을 충분히 다루는지도 마련해 준다.
시작하기 위한 계획
맨 위의 표에서 사용자가 가장 자주 성공하거나 포기하는 순간 하나를 골라라. 그 순간을 위한 질문 하나를 쓰고, 한 채널에 놓고, 두 번째 프롬프트를 추가하기 전에 2주 동안 모든 답을 읽어라. 구체적인 내용을 준 사람에게는 모두 답장하라.
FAQ
고객에게 얼마나 자주 피드백을 요청해야 하는가? 요청은 달력이 아니라 이벤트에 묶어라. 사용자가 일주일에 프롬프트를 하나 넘게 보아서는 안 되고, 답한 직후에는 하나도 보여서는 안 된다. 피드백 다음에 보내는 메시지는 그 피드백이 어떻게 되었는지에 대한 답장이어야 한다.
사용자를 귀찮게 하지 않고 피드백을 요청하려면 어떻게 해야 하는가? 작업 도중이 아니라 작업이 끝난 뒤에 묻고, 질문은 하나로 제한하고, 쉽게 닫을 수 있게 만들어라. 닫았다면 몇 주 동안은 그 선택을 존중하라.
피드백에 대한 보상을 제공해야 하는가? 대개는 필요 없다. 구체적인 질문과 눈에 보이는 답장이 상품권보다 더 큰 무게를 지니며, 보상은 그 보상을 원하는 사람들을 끌어들인다. 20분의 시간을 부탁하는 인터뷰에는 아껴 두어라.
아무도 답하지 않으면 어떻게 하는가? 질문을 좁히고 그 순간에 더 가까이 옮겨라. 예를 들어 화면 하나를 사용한 직후에 묻는 식이다. 그래도 조용하다면 소수의 사용자에게 직접 이메일을 보내고, 그 대화를 바탕으로 더 나은 프롬프트를 써라.
이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.