EaaS 사용자 피드백 제출
최근 업데이트로 인해 사용자 경험에 문제가 많았던 Antigravity 에도 Provide Feedback 이라는 피드백 채널이 포함되어 있어요. 그런데 이와 비교해서 회사에서 만든 EaaS(Energy as a Service) 제품에는 사용자 의견을 받을 채널이 없더라구요. 비록 사용자 규모가 적더라도 의견을 전달할 수 있는 채널은 만들어두는 게 중요하지 않을까 생각해요.
피드백 채널이 있어도 사용자는 이탈해요
처음에는 피드백 채널이 없다 고 생각했는데 알고보니까 Copyright 영역에 사업자 정보 를 누르면 연락처가 포함되어있긴 하더라구요. 물론, 사용자 의견을 받기 위해서 넣어둔 건 아니었을거에요. 그나마 직관적인 문의하기 는 누르면 의도와 다른 브랜드 홈페이지로 이동해 버리더라구요.
그리고 피드백 채널이 명확히 있더라도 결국 사용자는 그냥 떠날 것 이라고 생각해요. 하지만, 사용자 이탈을 최소화할 장치가 마련되지 않았던 셈이죠. 백오피스 지표 중 고객 이탈률(Churn Rate) 은 서비스 품질 만족도를 직관적으로 보여주니까요.
사용자 입장에서 보면 피드백 채널을 찾는 것 자체가 어려워요. 그래서 그나마 서비스를 이용중이던 사용자에게도 "의견을 전달할 방법이 없는 서비스" 라는 인식이 굳어져 있었을 가능성이 커요.
Zendesk 같은 CRM 도입을 하지 않는 이유
고객 의견을 수렴해야 할 때 보통 Zendesk 같은 CRM SaaS 를 먼저 떠올리지만, 이번 EaaS 제품에는 과도하다고 보여요. 서비스 운영팀이 없을 뿐더러 자체 구현으로 가볍게 채널만 만들어두는게 더 적합해요.
Antigravity 의 Provide Feedback 은 Settings 화면에 있지만, 사용자에게는 간단한 선택지와 의견만 요구하고 있어요. 피드백 제출 기능 위치는 다소 깊어도 입력을 요구하는게 간단해서 의견을 남기는 행위에 부담이 없어요. 이와 비교해서, AdGuard 의 피드백 폼 처럼 항목이 잘 정돈된 형식은 의견을 남기는 행위라기보다 설문조사에 참여하는 느낌 에 가까워서 의견을 제시하는 입장에선 약간 부담감이 듭니다.
피드백 채널은 어디에 두어야 할까요?
피드백 채널을 어디에 두어야할 지 고민이 됐는데요. Antigravity 처럼 설정 메뉴 안에 넣으면 사용자가 "여기에 피드백 채널이 있다" 는 사실 자체를 인지하기 어렵지 않나 생각해요. 입력 폼이 아무리 간단해도, 채널이 있다는 걸 모르면 의미가 없지 않을까요?
회사 제품을 보니 사이드바 하단의 프로필 드롭다운이 설정 메뉴로 들어가는 진입점이자 로그아웃이 위치하는 자리 더라구요. 사이드바가 모든 화면에서 항상 노출되는 구조이면서 일반적으로 사용자가 자기 계정과 관련된 동작을 찾을 때 자연스럽게 거치는 곳이라, 피드백 채널을 여기에 같이 두는 게 그나마 인지하기 쉬운 위치라고 판단했어요.
피드백 유형은 간단하게
피드백 유형도 간단하게 몇가지 선택지만 주는게 좋아보여요. 선택지가 너무 많으면 사용자가 분류에 부담을 느끼고, 적으면 운영자가 의견을 받아서 다시 분류해야 해요. 고객 지원(CS) 관점에서 보았을때 4개 정도로 정의하면 될 것 같아요. 그리고, 이미지 첨부는 Antigravity 에서 옵션으로 제공하지만 의도적으로 제외했어요. 정말로 간단한 피드백 채널을 만드는게 목표거든요.
- Bug Report (버그) — 동작이 의도와 다른 경우
- Improvement (기능 개선) — 이미 있는 기능을 더 낫게 만드는 의견
- Feature Request (기능 제안) — 지금 없는 기능에 대한 요청
- Etc (기타 문의) — 나머지
접수된 피드백은 백오피스에서 관리
회사에서 서비스 운영팀이 있는게 아니기 때문에 제출된 피드백을 확인할 수 있는 별도의 외부 채널을 만들지 않고 백오피스에 구현했어요. 슬랙 (또는 구글 워크스페이스 채팅) 같은 외부 메신저 채널을 붙이는 작업 자체가 별도 공수이기 때문이에요. 지금은 운영자가 백오피스에 관리자 계정으로 로그인해 피드백을 직접 확인하고, 처리 결과도 수동으로 이메일을 발송할 수 있는 버튼 으로 회신해요.
서비스가 성장해서 사용자 규모가 커지면 파이프라인 자동화가 필요해지긴 하겠죠. 그때는 Antigravity 의 Provide Feedback 하단에 제출하기 전에 있는 아래의 두가지 옵션은 흡수해도 좋을 것 같기도 해요.
Attach Antigravity server logs
OS·브라우저·콘솔 로그 같은 컨텍스트 정보를 자동으로 수집하면, 이미지 없이도 상황을 어느 정도 추적할 수 있어요.
Send feedback as kdevkr@gmail.com
지금은 백오피스에서 수동으로 회신하지만 처리되는 피드백이 많아지면 자동으로 통지되는 파이프라인이 나중에는 필요할 수 있어요.
그래도 사용자는 이탈한다.
솔직히 말하면, 피드백 채널을 명확히 제공하더라도 실제로 의견을 남기는 사용자는 많지 않아요. 서비스에 불편을 느낀 사용자도 의견을 남기기 전에 그냥 이탈해요. 눈에 띄는 버튼이 있어도 대부분의 사용자는 아무 말 없이 떠나요. 제품 회의에서는 고객 피드백을 받아야 한다고 늘 이야기하지만, 막상 제가 사용자가 되어 다른 서비스를 쓸 때는 불편을 느끼더라도 피드백을 제출해 본 경험이 별로 없어요. 제품을 만드는 입장에서도, 사용자로서는 침묵하는 쪽이었던 거예요. 그래서 피드백 채널을 만드는 건 거창한 일이 아니지만 최소한의 사용자 의견을 들을 수 있는 창구를 남겨 두는 일 은 중요한거죠. 지금은 소중한 의견 한 건을 받는 게 우선이고, SLA 같은 지표를 따지는 건 나중 일이에요.
감사합니다.