月曜日の朝、ある顧客がログインできなくなりました。彼らはサポートチケットを発行せず、Xにこう投稿します。「アップデート以降、acmeから10分おきにログアウトされるんだけど、同じ人いる?」。2人のユーザーが自分も同じ問題が起きていると返信します。あなたのチームの誰かが偶然そのスレッドを見つけた時にはすでに水曜日になっており、最初に投稿したユーザーはすでに競合他社にデモを依頼してしまっています。
貴社のヘルプデスクは、自ら問い合わせてくるユーザーを前提に設計されています。しかし、サポートを求める声の少なからぬ割合は、そうした直接窓口には届きません。それらは公開されたソーシャル上に書き込まれ、時には社名や製品名が誤ったスペルで記載されることもあり、誰かが能動的に探しに行かない限りサポートの受信トレイに届くことはありません。
私はKWatch.ioの開発に携わっているJulienです。KWatch.ioは、Linkedin、X、Facebook、Youtube、Reddit、Hacker News向けのキーワードアラートツールです。この記事では、そうした苦情を検知し、サポート担当者が日常的に使用しているキューにそれぞれ自動投入することで、Redditの投稿をメールと同じように処理できるようにする方法をご紹介します。
多くのサポートチームはソーシャルメディアを監視していますが、それは自社宛てに直接届く範囲にとどまっています。Xとの連携機能を備えたヘルプデスクなら、公式アカウントへの直接メンションを拾うことができます。これはユーザーがタグ付けしてくれた場合には機能しますが、実際にはタグ付けしないユーザーも大勢います。
ユーザーは「@acme」ではなく単に「acme」と書きます。r/sysadminで「他に同期が壊れている人はいないか」と尋ねたり、全く別の話題に関するHacker Newsのコメントの途中で貴社に言及したりします。これらはメンションのフィードには一切届かず、シフト勤務中の担当者の目にも届きません。
もう1つの問題は担当責任の所在です。ソーシャルメディア上の苦情がマーケティングチームによって発見された場合、誰かが転送してくれるまでマーケティングのSlackチャンネルに放置されがちです。チケットには担当者、期限、ステータスが存在しますが、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 (操作方法を尋ねるユーザー向け)
各行はそれぞれ独立した1つのアラートです。これらの単語をすべて1つのアラートにまとめてしまうと、投稿がそのすべてを含んでいないと一致しなくなってしまいます。1週間運用したら、どのアラートがトリガーされたか、ユーザーがどのような言葉遣いをしているかを確認し、設定を調整してください。ブランド名を入力する代わりにタグ付けするユーザーもいるため、公式ハンドルのキーワード登録も試してみる価値があります。
フィルターはキューを清潔に保つ役割を果たし、ここでは他のどこよりも重要になります。なぜなら、誤検知が発生するたびに誰かがそのチケットをクローズしなければならないからです。ご自身のサポートアカウントやブランド公式アカウントを「Excluded Users」に追加し、自社の返信によって新しいチケットが作成されないようにしてください。RedditやHacker Newsでは、ブランド名が短い場合は「Whole Words Only」を有効にして、「acme」が「acmeplex」に一致しないようにします。自社に言及している求人投稿など、明らかなノイズはいくつかの除外キーワードで排除できます。除外キーワードが1つでも含まれると投稿全体が除外されるため、このリストは短く抑えてください。各フィルターの詳しい解説は、こちらの記事をご覧ください: キーワードアラートのノイズを減らす方法に関する記事。
検知速度はプラットフォームによって異なるため、顧客に応答時間を約束する前に把握しておく価値があります。以下は当社の公式ドキュメントに記載されている更新頻度です:
| プラットフォーム | 新規コンテンツの確認速度 |
|---|---|
| Hacker News | 1秒〜1分 |
| Linkedin、Youtube | 1〜10分 |
| Reddit、X、Facebook | 10分〜1時間 |
したがって、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フィールドにはユーザーの氏名とフォロワー数も含まれており、担当者が優先順位を判断するのに役立ちます。
1. 「Webhooks by Zapier」アプリと「Catch Hook」トリガーを使用してZapを作成し、生成されたWebhook URLを苦情アラートの「API Webhook URL」フィールドに貼り付けます。
2. 一致した投稿の一部のみをチケットに変換したい場合は、Filterステップを追加します。一般的なルールは、 sentiment が「positive(肯定的)」ではないもののみを通過させることで、「acmeが5分で問題を解決してくれた」といった投稿をスキップできます。
3. ヘルプデスクのチケット作成アクションを追加します。Zendeskの場合は「Create Ticket」です。 content を説明にマッピングし、件名を platform および authorから組み立て、 social のようなタグを追加して、レポートでの集計や分析を容易にします。
同様のフローは、Webhookノード、 sentimentを判定するIFノード、そしてチケットを作成するように設定したZendeskまたはFreshdeskノードを使用して構築できます。これまでにKWatchをいずれかのツールに連携したことがない場合は、当社の Zapierおよびn8nガイド で、Webhookの設定手順をステップバイステップで詳しく解説しています。
センチメントフィルターについて補足します。これはキーワードに対する感情を測定するものですが、皮肉(サーカズム)表現によって誤判定されることが稀にあります。そのため、最初の数週間は緩やかなフィルターとして運用することをお勧めします。まずはすべての通知を送信してポジティブと判定された内容を確認し、挙動に納得できた段階でチケットの自動除外を有効にしてください。
Redditから届いたチケットは少し特殊なチケットです。顧客があなた宛てに直接送ってきたものではないからです。どのように返信するかによって、それが真に助けになるかどうかが決まります。
最初の返信は、簡潔で、公開されており、かつ具体的な内容に留めることをお勧めします。自分が誰であるかを名乗り、問題を把握したことを伝え、回避策や次の対応手順を案内します。アカウントの詳細情報が必要な場合はダイレクトメッセージを送るよう依頼し、スレッド上で個人情報を求めることは絶対に避けてください。問題が解決したら、スレッドに戻って解決した旨を報告します。その最後の返信こそが、同じ問題を抱えてGoogleで検索してきた次のユーザーの目に留まる重要な情報になります。
スレッドの中には、ユーザーに不評な価格改定など、サポートチームでは解決できない問題に関するものもあります。そうした投稿にも担当者を割り当てる価値はありますが、サポートが直接返信するよりも、タグ付けしてプロダクトチームに連携する方が適切な場合がほとんどです。そして、もし1時間の間に1件の苦情が20件に急増したなら、それはもはや通常のサポートチケットの問題ではありません。そのような事態への対処法については、当社のガイド「 ソーシャルメディアでPR危機を察知する方法 」で詳しく解説しています。
サポートチームが少数の主要顧客(キーアカウント)も担当している場合は、当社の姉妹製品である MultiFollow をご活用ください。LinkedinやXの特定の人物が投稿した際にアラートを受け取れるため、主要な支持者(チャンピオン)が製品名を挙げていなくても、不満を抱えている投稿をいち早く察知できます。
製品名と、何かが壊れた際にユーザーが最もよく入力するフレーズを1つ選び、RedditやHacker Newsで設定してみましょう。 KWatch Freeプラン には、メール通知付きでRedditで2件、Hacker Newsで2件のキーワードアラートが含まれており、これまで見落としていた苦情の多さを把握するには十分です。XのアラートやExcluded Usersなどのフィルターは月額19ドルのEssentialプランから、チケットを作成するAPIウェブフックは月額79ドルのBusinessプランから利用できます。
Julien, Product Manager at KWatch.io