소셜 미디어의 고객 불만을 지원 티켓으로 전환하는 방법

소셜 미디어의 고객 불만이 사각지대에 놓이는 이유

대부분의 고객 지원팀이 소셜 미디어를 모니터링하고는 있지만, 오직 자신들에게 직접 전달되는 내용에만 집중합니다. X 연동 기능을 제공하는 헬프데스크는 공식 계정에 대한 직접 멘션을 수집해 줍니다. 이는 사용자가 계정을 태그할 때는 잘 작동하지만, 태그를 달지 않는 사람들도 많습니다.

사용자들은 "@acme" 대신 그냥 "acme"라고 씁니다. r/sysadmin 서브레딧에 들어가 다른 사람들도 동기화 기능에 문제가 있는지 묻거나, 전혀 다른 주제를 다루는 Hacker News 댓글 중간에 귀사를 언급하기도 합니다. 이 중 그 어떤 것도 멘션 피드에 나타나지 않으며, 당직 근무자에게도 전달되지 않습니다.

또 다른 문제는 담당 책임 소재입니다. 소셜 미디어 상의 불만을 마케팅 팀이 발견하면, 누군가 전달해 주기 전까지 마케팅 팀의 Slack 채널에 그대로 방치되기 십상입니다. 티켓에는 담당자, 마감 기한, 상태(Status)가 존재하지만, Slack 메시지에는 이러한 체계가 전혀 없습니다. 따라서 최선의 해결책은 고객 불만을 가능한 한 빨리 정식 티켓으로 전환하는 것입니다.

고객 불만을 포착하는 알림 작성법

헬프데스크에 연동하기 전에, 브랜드에 대한 모든 언급이 아니라 실제 고객 지원 이슈만을 정확히 찾아내는 알림을 설정해야 합니다. KWatch 알림은 목록에 지정된 모든 키워드가 포함되어야 하므로 쉼표는 'AND' 연산자 역할을 합니다. 이를 활용해 제품 이름과 문제가 생겼을 때 사용자들이 쓰는 단어를 조합할 수 있습니다.

귀사의 제품명을 "acme"라고 가정할 때, 기본 시작 구성은 다음과 같습니다:

1. acme, not working 및 acme, broken (완전한 장애/작동 불능 대응용)

2. acme, can't login 및 acme, logged out (계정 문제 대응용)

3. acme, refund 및 acme, charged (결제/청구 관련 불만 대응용)

4. acme, help (사용 방법 질문 대응용)

각 줄은 개별적인 독립 알림입니다. 만약 이 모든 단어를 하나의 알림에 넣으면, 게시글에 이 모든 단어가 전부 포함되어야만 매칭됩니다. 일주일 정도 운영해 본 뒤, 어떤 알림이 실행되었는지와 사용자들이 어떤 표현을 사용하는지 살펴보고 알림을 조정하세요. 브랜드 이름을 직접 입력하는 대신 공식 계정을 태그하는 사용자들도 있으므로 공식 핸들명도 키워드로 추가해 보세요.

필터는 티켓 큐를 깔끔하게 유지해 주며, 잘못 매칭된 글 하나하나가 결국 담당자가 수동으로 닫아야 하는 티켓이 되기 때문에 이 작업에서 필터의 중요성은 그 어느 때보다 큽니다. 자체 고객 지원 및 브랜드 계정을 Excluded Users에 추가하여 여러분의 답변으로 인해 새 티켓이 생성되지 않도록 하세요. Reddit과 Hacker News에서는 제품 이름이 짧은 경우 Whole Words Only를 켜서 "acme"가 "acmeplex"와 매칭되지 않도록 설정합니다. 자사를 언급하는 채용 공고 등 명백한 노이즈는 몇 가지 제외 키워드로 걸러낼 수 있습니다. 제외 키워드는 단 하나만 포함되어도 해당 게시글이 즉시 제외되므로 이 목록은 짧게 유지하세요. 모든 필터에 대한 자세한 내용은 다음 가이드를 확인하세요: 키워드 알림에서 노이즈 줄이기 가이드.

고객 불만이 얼마나 빨리 전달될까요?

도달 속도는 플랫폼에 따라 다르며, 고객에게 응답 시간을 보장하기 전에 이를 숙지해 둘 필요가 있습니다. 공식 문서에 명시된 새로고침 주기(새 글 확인 빈도)는 다음과 같습니다:

따라서 X의 불만 글이 지원 큐에 도달하기까지 최대 1시간이 걸릴 수 있습니다. 대부분의 고객 지원팀에게 이는 수요일에 뒤늦게 수동으로 찾는 것보다 훨씬 빠른 속도입니다. 하지만 직접적인 @멘션에 엄격한 SLA를 적용하고 있다면, 멘션 대응에는 헬프데스크의 네이티브 X 연동 채널을 그대로 유지하고 태그 없는 게시글, Reddit 스레드, Hacker News 댓글처럼 기존 도구가 볼 수 없는 모든 영역에 키워드 알림을 활용하세요. 또한 KWatch는 DMs(다이렉트 메시지)를 읽을 수 없으므로 비공개 메시지는 기존 도구로 관리해야 합니다.

각 고객 불만을 헬프데스크로 전송하기

알림이 정상적으로 작동하기 시작했다면, 다음 단계는 이를 KWatch에서 내보내 티켓으로 변환하는 것입니다. 가장 깔끔한 방법은 API 웹훅을 사용하는 것입니다. 모든 매칭 결과는 JSON 페이로드로 전송되며, 알림별로 개별 웹훅을 설정할 수 있어 불만 알림은 헬프데스크로 보내고 다른 알림은 다른 곳으로 전송할 수 있습니다. 알림별 개별 웹훅은 계정 전체 웹훅 설정보다 우선 적용됩니다.

저희 공식 문서에서 제공하는 페이로드 예시는 다음과 같습니다:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

티켓 생성에 필요한 모든 필드가 포함되어 있습니다. content 필드는 설명(본문)이 되고, link 필드는 상담원이 해당 스레드를 바로 열어볼 수 있도록 맨 위에 배치되며, query 필드는 어떤 알림이 실행되었는지 알려줍니다. X의 경우 author 필드에 작성자의 실명과 팔로워 수도 함께 포함되어 있어 상담원이 응대 우선순위를 결정하는 데 도움이 됩니다.

Zapier에서 설정하기

1. Webhooks by Zapier와 Catch Hook 트리거를 사용해 Zap을 생성한 다음, 생성된 웹훅 URL을 고객 불만 알림의 API Webhook URL 필드에 붙여넣습니다.

2. 특정 매칭 항목만 티켓으로 전환하려면 Filter 단계를 추가하세요. 대표적인 규칙은 sentiment 가 긍정(positive)이 아닌 항목만 통과시키는 것이며, 이를 통해 "acme가 5분 만에 내 문제를 해결해 줬다"와 같은 칭찬 글을 건너뛸 수 있습니다.

3. 헬프데스크의 티켓 생성 액션을 추가합니다. Zendesk의 경우 'Create Ticket'입니다. content 를 설명(본문)에 매핑하고, 제목은 platform 및 author정보로 구성한 뒤, social 과 같은 태그를 추가하여 나중에 이러한 티켓에 대한 리포트를 쉽게 생성할 수 있도록 설정합니다.

n8n에서 설정하기

동일한 워크플로는 Webhook 노드, sentiment조건을 확인하는 IF 노드, 그리고 티켓을 생성하도록 설정된 Zendesk 또는 Freshdesk 노드를 조합하여 구성할 수 있습니다. 이전에 KWatch를 두 툴 중 어디에도 연동해 본 적이 없다면, 저희의 Zapier 및 n8n 가이드 에서 웹훅 연동 과정을 단계별로 자세히 안내하고 있습니다.

감정(Sentiment) 필터에 대해 한 가지 덧붙이자면, 이는 등록한 키워드를 기준으로 측정되며 가끔은 반어법이나 비꼬는 표현(Sarcasm)을 잘못 판별할 수도 있습니다. 따라서 초기 몇 주 동안은 유연하게 보조 필터로 운영해 보시길 권장합니다. 우선은 모든 알림을 전송하여 긍정으로 분류된 내용들을 검토한 후에, 필터를 적용해 티켓 생성을 건너뛰도록 설정하세요.

공개된 공간에서 고객 불만에 답변하기

Reddit에서 생성된 티켓은 일반적인 티켓과는 사뭇 다릅니다. 고객이 직접 여러분에게 보낸 것이 아니기 때문입니다. 이에 어떻게 대응하느냐에 따라 실제 도움으로 이어질지가 결정됩니다.

첫 번째 답변은 간결하고 공개적이며 구체적으로 작성하는 것을 권장합니다. 자신이 누구인지 밝히고, 문제를 인지했음을 알린 뒤 임시 해결책이나 다음 단계를 안내하세요. 계정 세부 정보가 필요하다면 비공개 메시지를 보내달라고 요청하고, 공개 스레드에서는 절대로 개인 정보를 요구하지 마세요. 문제가 해결되면 다시 스레드로 돌아와 해결되었다고 남겨주세요. 그 마지막 답변이야말로 동일한 문제를 겪는 다음 사용자가 Google에서 검색했을 때 보게 될 소중한 답변입니다.

스레드 중에는 사용자들이 마음에 들어 하지 않는 가격 정책 변경처럼 여러분이 직접 해결할 수 없는 문제도 있습니다. 이러한 게시글도 담당자를 지정해 추적할 필요는 있지만, 고객 지원팀이 직접 답변하기보다는 태그를 지정해 제품 팀에 전달하는 편이 낫습니다. 그리고 만약 한 건의 불만이 한 시간 만에 스무 건으로 불어난다면, 그것은 더 이상 단순한 고객 지원 티켓의 영역이 아닙니다. 그런 상황이 발생했을 때의 대처법은 저희의 가이드 소셜 미디어에서 PR 위기 포착하기 에서 자세히 다루고 있습니다.

고객 지원팀이 소수의 주요 고객(Key Account)도 함께 관리하고 있다면, 자매 제품인 MultiFollow 가 특정 Linkedin 및 X 인물이 게시글을 올릴 때 알림을 보내주므로, 주요 옹호자가 제품 이름을 직접 언급하지 않더라도 불만을 토로하는 글을 즉시 확인할 수 있습니다.