AIで作ったアプリに専属のサポートチームが必要になるとき（と、その代わりにやるべきこと）

あなたは週末に Proyecta でアプリを作りました。ちゃんと動いています。ユーザーが実際にお金を払ってくれています。そして今、サポートのメールに埋もれています。

ここで多くの個人開発者が「カスタマーサポートに誰か雇わなきゃ」と考えます。いずれはそれが正しいかもしれません。でも、たいていそれより先に打てる手が、もっと安上がりで、しばしばより優れた手が、三つか四つあるのです。

「このメール全部には返せない」の3つのフェーズ

フェーズ1： まだ全部のメールに返信しているけれど、一日に6時間かかっている。疲れている。

フェーズ2： いちばん急ぎのものに返信している。一部の人は返信を3日待っている。申し訳なく思いつつ、機能も作っている。

フェーズ3： 50通の未返信メールがたまり、受信箱を開くのをやめてしまった。罪悪感が押し寄せる。

ほとんどの開発者は、その中間を探ることなく、フェーズ2から「サポート担当を雇おう」へ一足飛びに進んでしまいます。

安上がりな手（実際に効くもの）

1. いちばんよく答えている質問を3つ見つける

一週間かけて、すべてのメールを読みましょう。複数回出てくる質問を書き留めます。きっと、こんなものが見つかるはずです。

「これをStripeにどうつなぐの？」
「チームでも使える？」
「もし御社が閉鎖したらどうなる？」

上位3つを取り出して、メールではない、ずっと残る場所で答えましょう。ウェブサイトのFAQページ。動画。アプリ内のヘルプドキュメント。狙いは、質問が受信箱に届く前に横取りすることです。

凝ったドキュメント作成ソフトは要りません。見出しがはっきりしたGoogleドキュメントで十分です。あるいはウェブサイトの簡単な1ページでも。基準はこうです。誰かが検索したときにそれを見つけ、答えを得て、あなたにメールしない。

ほとんどの個人開発者がこれを飛ばすのは、解決済みの問題のように感じるからです。誰だってFAQくらい持っている、と。でも、たいていのFAQは、創業者が何に戸惑ったかを 忘れたあとに 書かれています。あなたは、まさに同じ3つの質問にいら立っている今、これを書いているのです。今すぐ書きましょう。

2. シンプルな自動返信を使う

誰かがメールしてくるとき、その人は実は6日間待っているわけではありません。いつあなたが返信するのかを知りたくて待っているのです。

自動返信（Gmailに標準でついていますし、Mailchimp、Zapier、何でも使えます）を設定して、本当のことを伝えましょう。

「すべてのメールに目を通しています。通常48時間以内に返信できます。お急ぎの場合は、件名に URGENT と入れて返信していただければ、優先的に対応します。」

これは2つのことをします。

あなたが無視していないと安心させる。
パニックで返信するのではなく、考える時間を稼げる。

URGENT のシグナルで素早く優先度を振り分けられます。一部の人はこれを乱用しますが、ほとんどはしません — 彼らはただ不安なだけで、いつ返事がもらえるかを知れば、それで不安は解消するのです。

3. 公開ステータスページを作る（たとえそれが1本のツイートでも）

何かが壊れていると、ユーザーはステータスを確認するより先にそれについてメールしてきます。

シンプルなページ（Statuspage.io は月額29ドルですが、GitHub gist や Slack のステータスでも構いません）を作り、こう表示しましょう。

「すべてのシステム稼働中」
もしくは、何かがダウンしているなら「ダッシュボードが現在遅くなっています（調査中）」

それをフッターやメールの署名にリンクしておきます。「あなたのサービス壊れてる？」というメールが来たら、返信文を書く代わりに、リンクで返します。「ステータスページをご確認ください。」

ささいに聞こえます。でも、アプリに100人のユーザーがいて何かが壊れているとき、ステータスページは、同じ問題について15通以上のメールを書くのを防いでくれます。

4. 「変更履歴ファースト」の文化を作る

バグを直したり機能をリリースしたりするたびに、ユーザーが気づく前に知らせましょう。これは、まるまる一種類のサポートメールを防ぎます。

Loom で60秒の動画を撮る、「お知らせ」用の Slack や Discord（もしあれば）に投稿する、あるいはアクティブなユーザーにメールで送る。狙いは凝ることではなく — 速く、正直であることです。

「インポートがときどき固まるバグを直しました。すみませんでした。あと今週はダークモードも追加しました。」

これは2つのことをします。

何が変わったのかの文脈をユーザーに与え、戸惑わせない。
あなたがプロダクトに積極的に取り組んでいると感じさせる。

本当に助けが必要になるとき

これら4つの手を打ってもまだ溺れているなら、そう、おそらく人間が必要です。

その時点で、パートタイムで誰かを雇い、こんなことを任せましょう。

定型的な質問に答える（FAQとテンプレートを使って）。
ややこしいものは要約して、判断のためにあなたに回す。
何が分かりにくいかのパターンを見つけ、どこにもっと良いドキュメントが要るかを教える。

二つ目が肝心です。サポート担当は、メールに答えるだけのロボットではありません。あなたのプロダクト、価格設定、ドキュメントの何が壊れているかを教えてくれる、早期警報システムなのです。

でも、ほとんどの個人アプリは、しばらくそこには到達しません。それまでの間、この4つの手で、「溺れている」から「なんとか回せている」へ移れます。

核心はこれです。サポートはプロダクトの機能であって、事務作業ではありません。 プロダクトをより分かりやすくすることに投資しましょう。それを説明する人を雇うことにではなく。良いFAQはメールの50%に答えます。良いオンボーディングはさらに30%を防ぎます。残るのは、本当に人間の思考が必要な20%だけです。

それは解ける問題です。まだ採用は要りません。