AI로 만든 앱에 전담 지원팀이 필요해질 때 (그리고 대신 할 일)
AI로 만든 앱이 성장하면 지원 문의가 쌓입니다. 사람을 고용하기 전에 이걸 처리하는 방법을 알려 드립니다.
주말에 Proyecta로 앱을 만들었습니다. 잘 돌아갑니다. 사용자들이 실제로 돈을 내고 있고요. 그런데 이제 지원 이메일에 파묻혀 있습니다.
많은 인디 빌더가 바로 이 지점에서 “고객 지원을 위해 사람을 고용해야겠다”고 생각합니다. 언젠가는 맞는 말일 수 있습니다. 하지만 보통은 그 전에 할 수 있는, 훨씬 저렴하고 종종 더 나은 서너 가지 수가 있습니다.
”이 이메일을 다 답할 수가 없어”의 세 단계
1단계: 아직 모든 이메일에 답하고 있지만, 하루에 여섯 시간이 걸립니다. 지칩니다.
2단계: 가장 급한 것들에만 답하고 있습니다. 어떤 사람들은 답을 사흘씩 기다립니다. 미안하지만, 한편으로는 기능도 출시하고 있죠.
3단계: 답장 안 한 이메일이 50통이나 받은편지함에 쌓여 있고, 당신은 그걸 열어 보는 걸 그만뒀습니다. 죄책감이 밀려옵니다.
대부분의 빌더는 그 중간 지대를 살펴보지 않은 채 2단계에서 곧장 “지원 담당자를 고용하자”로 건너뜁니다.
저렴한 수들 (실제로 효과 있는)
1. 가장 자주 답하는 질문 세 개를 찾아라
일주일 동안 모든 이메일을 읽어 보세요. 두 번 이상 나오는 질문을 적어 두세요. 장담컨대 이런 것들이 보일 겁니다:
- “이걸 Stripe에 어떻게 연결하나요?”
- “우리 팀이 함께 써도 되나요?”
- “당신이 서비스를 닫으면 어떻게 되나요?”
상위 세 개를 골라서 이메일이 아닌 영구적인 곳에 답을 적어 두세요. 웹사이트의 FAQ 페이지. 영상. 앱 안의 도움말 문서. 목표는 질문이 받은편지함에 닿기 전에 가로채는 것입니다.
화려한 문서화 소프트웨어는 필요 없습니다. 헤더가 명확한 Google 문서면 충분합니다. 아니면 웹사이트의 간단한 페이지 하나도요. 기준은 이렇습니다: 누군가 검색하면 그걸 찾고, 답을 얻고, 당신에게 이메일을 보내지 않는다.
대부분의 인디 빌더는 이걸 건너뜁니다. 이미 해결된 문제처럼 느껴지거든요. 누구나 FAQ가 있으니까요. 하지만 대부분의 FAQ는 창업자가 무엇이 헷갈렸는지 잊어버린 뒤에 쓰입니다. 당신은 똑같은 세 질문 때문에 한창 짜증이 난 지금 이걸 쓰고 있는 겁니다. 지금 쓰세요.
2. 간단한 자동 응답을 써라
누군가 이메일을 보낼 때, 그들은 사실 엿새를 기다리고 있는 게 아닙니다. 언제 답할지를 알고 싶어서 기다리는 겁니다.
이렇게, 사실인 무언가를 말하는 자동 응답을 설정하세요(Gmail에 기본으로 있고, Mailchimp나 Zapier 등 무엇이든 됩니다):
“저는 모든 이메일을 읽습니다. 보통 48시간 안에 답할 수 있어요. 급한 일이면 제목에 URGENT라고 적어 답장 주시면 우선 처리하겠습니다.”
이건 두 가지를 해 줍니다:
- 당신이 무시하는 게 아니라는 안심을 줍니다.
- 황급히 답하는 대신 생각할 시간을 벌어 줍니다.
URGENT 신호 덕분에 빠르게 분류할 수 있습니다. 일부는 이걸 남용하겠지만, 대부분은 그러지 않습니다 — 그저 불안할 뿐이고, 언제 답을 받을지 아는 것만으로 그 불안이 해소되니까요.
3. 공개 상태 페이지를 만들어라 (트윗 한 줄이라도)
뭔가 고장 나면, 사용자는 상태를 확인하기도 전에 그것 때문에 이메일을 보냅니다.
이렇게 알려 주는 간단한 페이지를 만드세요(Statuspage.io는 월 29달러지만, GitHub gist나 Slack 상태로도 됩니다):
- “모든 시스템 정상 작동 중”
- 혹은 무언가 다운됐다면: “대시보드가 지금 느립니다 (조사 중)”
푸터나 이메일 서명에 링크를 걸어 두세요. “당신 서비스 고장 났나요?”라는 이메일이 오면, 답장을 쓰는 대신 링크로 답하세요: “저희 상태 페이지를 확인해 주세요.”
사소하게 들립니다. 하지만 앱에 사용자가 100명 있고 뭔가 고장 났다면, 상태 페이지는 같은 문제로 이메일 15통 이상을 쓰는 일을 막아 줍니다.
4. “체인지로그 우선” 문화를 만들어라
버그를 고치거나 기능을 출시할 때마다, 사용자가 알아채기 전에 먼저 알려 주세요. 이건 지원 이메일 한 부류 전체를 막아 줍니다.
Loom으로 60초짜리 영상을 녹화하거나, (있다면) “새 소식” Slack이나 Discord에 올리거나, 활성 사용자에게 이메일로 보내세요. 목표는 화려함이 아니라 — 빠르고 정직한 것입니다.
“가져오기가 가끔 멈추던 버그를 고쳤습니다. 불편을 드려 죄송해요. 그리고 이번 주에 다크 모드도 추가했습니다.”
이건 두 가지를 해 줍니다:
- 무엇이 바뀌었는지 맥락을 주어, 사용자가 헷갈리지 않게 합니다.
- 당신이 제품을 적극적으로 개선하고 있다는 느낌을 줍니다.
정말로 도움이 필요해질 때
이 네 가지 수를 다 썼는데도 여전히 허우적대고 있다면, 그렇다면 정말로 사람이 필요한 게 맞습니다.
그 시점에는 다음 일을 할 사람을 시간제로 고용하세요:
- 일상적인 질문에 답하기(당신의 FAQ와 템플릿을 활용해서).
- 까다로운 질문은 요약해서 결정용으로 당신에게 넘기기.
- 무엇이 헷갈리게 하는지 패턴을 포착해, 어떤 문서를 보강해야 하는지 알려 주기.
두 번째가 결정적입니다: 지원 담당자는 단지 이메일에 답하는 로봇이 아닙니다. 당신의 제품, 가격, 문서에서 무엇이 고장 났는지 알려 주는 조기 경보 시스템입니다.
하지만 대부분의 인디 앱은 한동안 거기까지 가지 않습니다. 그동안 이 네 가지 수가 당신을 “허우적대고 있어”에서 “관리되고 있어”로 데려가 줄 수 있습니다.
핵심은 이것입니다: 지원은 관리 잡무가 아니라 제품 기능입니다. 사람을 고용해 제품을 설명하게 하는 대신, 제품을 더 명확하게 만드는 데 투자하세요. 좋은 FAQ는 이메일의 50%를 답합니다. 좋은 온보딩은 또 다른 30%를 막아 줍니다. 그러면 정말로 사람의 사고가 필요한 20%만 남습니다.
그건 풀 수 있는 문제입니다. 아직 고용은 필요 없습니다.