지원 티켓 대 기능 요청: 무엇을 신뢰해야 하는가

기능 요청 게시판은 사용자가 앉아서 무엇을 원하는지 설명할 시간이 있을 때 요청하는 것을 포착한다. 지원 티켓은 사용자가 바로 지금 막혀 있는 것을 포착하는데, 흔히 짜증이 난 상태로, 흔히 근본적인 요청을 깔끔하게 설명할 어휘도 없이. 둘 다 진짜 신호이며, 둘 중 하나만 보는 팀은 결국 자신만만하게 잘못된 문제를 해결하게 되는데, 각 채널이 체계적으로 서로 다른 유형의 사용자와 서로 다른 유형의 필요를 과대 대표하기 때문이다. 기능 요청 우선순위 매기기는 이미 게시판에 있는 것의 순위를 매기는 것을 다룬다. 이 글은 애초에 게시판에 도달하는 것과 지원 티켓으로만 나타나는 것 사이의 격차에 관한 것이다.

왜 같은 근본적인 문제가 한 채널에는 나타나고 다른 채널에는 나타나지 않는가

두 채널이 서로 다른 활성화 비용을 가지고 있고, 그 비용의 크기가 누가 그것을 넘어서는지를 결정하기 때문이다. 기능 요청을 제출하는 것은 주도성을 요구한다. 사용자는 그 요청을 명확히 표현할 가치가 있다고 믿고, 게시판을 찾고, 일관된 무언가를 써야 하는데, 이는 이미 제품에 투자한 참여적이고 인내심 있는 사용자를 선별한다. 지원 티켓을 제출하는 것은 그에 비해 거의 주도성을 요구하지 않으며, 흔히 작업 도중에 그냥 “도움”을 클릭하는 것뿐인데, 이는 게시판을 전혀 사용하지 않았을 사용자를 포함해 그 순간 좌절한 사용자를 포착한다는 의미다. 제품의 진짜 격차는, 그것을 마주치는 사용자가 공식 요청을 제출할 가능성이 가장 낮은 사람들이라는 이유만으로 기능 게시판에서는 보이지 않고 지원팀에서는 시끄러울 수 있다.

누락된 기능에 대한 티켓 양은 그것에 대한 투표 수와 같은 것을 의미하는가

아니다, 서로 다른 조건에서 서로 다른 모집단을 측정하기 때문이다. 백 표를 받은 기능 요청은 기존 요청을 찾아 지지하는 데 시간을 들인 백 명을 대표하며, 이는 지속적이고 신중한 수요의 강한 신호다. 같은 기간에 제출된, 같은 근본적인 격차에 관한 백 개의 지원 티켓은 아마도 그 순간 벽에 부딪힌 사용자를 대표하며, 그중 일부는 즉각적인 마찰이 지나가면 완전히 잊어버릴 것이다. 둘 다 “백 명이 이것을 원한다”는 동등한 신호로 취급하는 것은 티켓 양을 과대평가하는데, 티켓은 생성하기 저렴하고 투표는 그렇지 않기 때문이다.

기능에 지원 티켓은 있지만 게시판에는 투표가 거의 없을 때 무엇을 의미하는가

흔히, 요청은 존재하지만 그것을 마주치는 사용자가 게시판이 존재한다는 것을 모르거나, 투표가 무언가를 바꿀 것이라고 믿지 않거나, 문제를 너무 드물게 마주쳐서 공식적으로 등록하기 위해 채널을 바꾸는 수고를 하지 않는다는 것이다. 이것은 정확히 기능 요청 게시판이 구조적으로 놓치는 모집단이며, 여기서 낮은 투표 수는 낮은 수요의 증거가 아니라 측정 격차의 증거다. 해결책은 티켓을 불신하는 것이 아니라, 누락된 기능을 둘러싼 지원 티켓 클러스터를 투표 수만 가지고 우선순위를 매기는 사람에게 보이지 않게 남지 않도록 여러분 스스로 사용자를 대신해 게시판에 기록하는 자체 신호로 취급하는 것이다.

게시판은 낮은 우선순위로 읽힘:
"Export to CSV": 6개월간 4표

지원팀은 다른 이야기를 전함:
"Export to CSV": 같은 기간 31건의 티켓, 각각 다른
계정에서, 각각 "현재 지원되지 않음, 피드백을
전달하겠음"으로 종료됨

지원 티켓의 급증은 항상 근본적인 문제가 누락된 기능이라는 것을 의미하는가

아니다, 그리고 여기서 두 채널은 반대 방향으로 오도할 수 있다. 티켓 급증은 이미 존재하는 기능을 둘러싼 혼란스러운 인터페이스, 버그, 또는 충분한 설명 없이 나온 변경으로 인해 그만큼 자주 발생하는데, 그중 어느 것도 새로운 것을 만드는 것으로 해결되지 않는다. 모든 티켓 급증을 “사용자가 우리에게 없는 기능을 원한다”로 읽는 것은 실제로는 문서 격차이거나 위장된 사용성 문제였던 것들로 가득한 로드맵을 만들어낸다. 지원 티켓은 마찰이 어디에 있는지 알려준다. 그것 자체로는 해결책이 새 기능인지, 인터페이스 변경인지, 더 나은 도움말 문서인지 알려주지 않으며, 그것을 혼동하는 것은 잘못된 해결책에 엔지니어링 시간을 낭비하게 한다.

무엇을 만들지 결정할 때 두 신호는 실제로 어떻게 결합되어야 하는가

티켓을 사용해 마찰이 어디에 있는지 찾고, 게시판이 부실한 곳에서는 직접적인 접촉과 함께 기능 요청 게시판을 사용해 실제로 원하는 결과가 어떤 모습인지 확인하라. 티켓 클러스터는 진짜의, 느껴지는 문제를 식별한다. 그것에 맞서 무언가를 만들 수 있을 만큼 정확하게 해결책을 명시하는 경우는 드문데, 지원팀과의 대화에서 좌절한 사용자는 사양이 아니라 증상을 설명하기 때문이다. 기능 요청 게시판은, 같은 근본적인 문제에 충분한 투표가 있을 때, “실제로 무엇이 이것을 만족시킬지”에 대한 세부 사항을 더 많이 담는 경향이 있는데, 요청을 쓰는 것 자체가 무엇이 잘못됐는지 보고하는 것이 아니라 원하는 것을 명시하는 행위이기 때문이다.

지원 상담원은 스스로 티켓을 기능 요청으로 기록해야 하는가

그렇다, 그리고 이것이 두 채널 사이의 격차에 대한 가장 레버리지가 큰 단일 수정이다. 티켓을 위장된 기능 요청으로 인식하는 상담원은, 그것을 그냥 해결하고 넘어가는 대신, 고객을 대신해 게시판에 기록할 수 있는데, 이는 고객이 스스로 두 번째 채널을 발견하고 사용하도록 요구하는 대신 측정 격차를 직접 메운다. 이것은 기록하는 것이 상담원에게 몇 분이 아니라 몇 초 걸릴 때만 작동하며, 그래야 그렇게 하는 마찰이 그냥 티켓을 닫고 다음으로 넘어가는 마찰보다 낮아진다.

FAQ

기능 요청 투표는 모두 하나의 계정이나 팀에서 온 경우 할인되어야 하는가? 그렇다, 순수 투표 수 대신 별개의 계정이나 조직으로 가중치를 매겨라. 같은 회사의 다섯 명에게서 나온 다섯 표는 다섯 개의 독립적인 수요 확인이 아니라 한 고객의 우선순위를 대표하기 때문이다.

티켓에는 많이 나타나지만 투표는 거의 없는 기능을 만들 가치가 있는가? 흔히 그렇다, 티켓 양이 진짜로 별개의 계정에서 나오고 근본적인 필요가 가정이 아니라 확인된 경우라면. 낮은 투표 수를 수요가 진짜가 아니라는 증거가 아니라 게시판의 활성화 비용에 대한 측정 부산물로 취급하라.

UI 혼란 티켓과 진짜 누락 기능 티켓을 한눈에 어떻게 구별하는가? 해결책이 기존 기능을 설명하는 것인지 아니면 누락된 것에 대해 사과하는 것인지를 보라. “아, 사실 바로 거기 있네요” 해결의 패턴은 인터페이스나 발견 가능성 문제를 가리키고, “그건 아직 지원하지 않습니다” 패턴은 진짜 격차를 가리킨다.

이 구별은 아주 작은 지원 규모에서도 똑같이 중요한가? 기계적으로는 덜 중요한데, 소수의 티켓은 집계 분석 없이도 개별적으로 읽기 쉽기 때문이다. 하지만 티켓이 좌절한 사용자를 과대 대표하고 인내심 있는 사용자를 과소 대표한다는 근본적인 편향은 어떤 규모에서든 존재하며, 여러분이 직접 모든 티켓을 읽을 때조차 명심할 가치가 있다.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 도구 비교