簡単にウェブサービスやソーシャルアプリなどが作られるようになりました。
「如何にエッジの効いた面白いサービスを作るか！」ということに、自分を含め注力しがちですが、リリースしたサービスを更に発展させていくためには、意外と重要なのが、顧客サポート、いわゆる「運営サポート」です。
サービス規模別に、自分が運営してきて感じた気づきをマニュアルとして、まとめてみました。
サービスリリース前の心得
1. 最低限、お問い合わせフォームは用意する
ウェブサービスにおいて、ユーザーと唯一の接点であることが多いのが、サポートです。サービスに対する印象、サービスに対する意見、使い方の告知、サービス改善へのヒントなど、多くの情報がサポート担当に対して、「問い合わせ」という形で入ってきます。
ただ、サービスリリース前に、そんなことを心配する必要はなく、多くの場合は、お問い合わせフォームを用意するだけで十分だと思います。メールアドレスや、twitterアカウントだけが用意されたサービスもありますが、最低でも簡単に送信できる、問い合わせフォームは設置したいところです。
小規模サービス向け（約100-500万PV/月）
ある程度、サービスが大きくなってくると、必要になるツールや心得があります。
2. 利用規約は必ず整備する
あまり褒められたことではありませんが、この規模のサービスの中には、他のサービスの利用規約をコピーして、変更しただけと思われる規約をみることもあります。。ただ、利用規約はサポートをする上でも、サービスを安定して提供するためにも、最も基本となるユーザーとの取り決めであり、必ずオリジナルの規約を整備する必要があります。作成から弁護士へ依頼するのが好ましいですが、自分で作成した利用規約を「契約書チェック」として、弁護士に確認してもらう方法でも十分に整備ができます。「契約書チェック」の弁護士への依頼形式なら、多くの場合は20万円以下で依頼できるかと思いますので、サービスの為にも必要な支出とわりきって、是非整備をしましょう。完全に依頼する場合でも50万円以下で依頼できることが多いと思います。
3. サポートシステムはGoogleAppsで代用する
この規模になると、サポートシステムの導入を考えたくなりますが、GoogleAppsの機能をつかえば、自社ドメインでGmailが利用でき、Gmailの管理画面は、まさに簡易サポートシステムと同様の機能を有することから、これを使わない手はありません。IMAP形式を利用すれば、複数人でのサポート運用体制の構築も簡単に行う事ができます。
4. メール文章を統一する
この規模では、まだ担当者が1人か2人で担当することが多いかと思いますが、メール文章の書式や、敬語や枕詞の使い方などは統一をすることが望ましいです。例えば、何らかユーザーに対してお願いする文章を書くときは、「ご面倒をお掛け致しますが」とするのか「お手数をお掛け致しますが」とするのかなどは、担当者の裁量でなく、ルールとして統一しておくと、よりスムーズなサポートができます。ユーザーからも、属人性が低く、安定したサービスとした印象を持ってもらえることが多くなります。
5. エンジニアとの共有文化を構築する
エンジニア自身がサポートを一部分でも担当できれば、最も好ましいですが、そうでない場合でも、サポートの重要性を随時責任者が共有し、最低月に1回はサポートにどういう問い合わせがあり、どのような課題があるとサポート担当が考えているかなどは、「サポート会」として、エンジニアと一緒に15分でも共有したいところです。そうすれば、エンジニアとしても、顧客視点で考えることができ、サポートを単なるコスト部門としてではなく、サービスが飛躍するための、利益部門としてとらえることができます。何より、エンジニア自身が「バグ修正」としてではなく「顔の見えるユーザーからの要望」として、開発ができることは、モチベーションの観点からも、大切なことだと思っています。
6. クレームへの対応
サポートの基本は、「いかにサポートを通して、ユーザーに良質な体験を提供すること」であり、ユーザーが求める一歩先の対応ができるかが大切です。しかし、対応にはチームとして、線引きをすることが大切です。その1つにクレーム対応があります。サービス提供者側に問題があるクレームは勿論、ユーザー側に問題があっても、一歩先の対応をすることが基本ですが、中には、悪質なクレームのようなケースもあり、すべてに対して「お客様は神様です」という対応を行っていては、担当者も人間であり、メンタル上の負担となります。このケースは対応しない、このケースは上司が対応するといった、線引きが必要であり、特に1人のみがサポートをするような場合は、1人で背負い込ませない仕組みと、フォローできる責任者が必ず必要です。
中規模サービス向け（約500-5000万PV/月）
7. 専用ツールの構築
この規模になると、メールサポートだけでも、1日50-200通程度の問い合わせ、電話であれば、1日に100-500コールは受付けることになるかと思います。そうなると、GoogleAppsを使ったメールのみの対応では非効率となることから、そのサービスにあった、最適なサポートツールが必要となります。ウェブサービスと連動した、専用のオリジナルツールがあることが望ましく、フレームワーク(ROR, cakePHPなど）であれば、簡単に構築することができます。中途半端な形は最も望ましくありません。
8. お問い合わせの仕組み化
同じ内容のお問い合わせを如何に減らし、システムの問題、サービスの問題をどうやって解決していくのかについては、仕組みに落とし込むことが望まれます。サポート担当者で発生した問題を、いかに意思決定者が判断できるタスクに落とし込み、それを日常のルーチンにするかという”ルール作り”が必要になります。専用ツールから、tracやredmineといったバグトラックシステムと連携をとるなどして、エンジニアとの連携ができることも望まれます。
9. 問い合わせを減らすことをKPIにする
この規模になると、サポート担当者の業務として、月間の問い合わせ数（もしくは率）をKPIにすることが必要です。お問い合わせを仕組み化しても、肝心のFAQが不十分であったり、疑問が発生するページにおいて、その説明がなかったり、UIがわかりにくいといった問題があるサービスであれば、ユーザー数に比例して問い合わせが増加してしまいます。問い合わせ窓口をわかりにくくする、といった解決方法ではなく、なぜお問い合わせを頂いたのか、もっとわかりやすくできないか？を突き詰めていくと、ユーザーにとっても、問い合わせるコストが減り、win-winの結果となります。
10. マニュアル化マニュアル化マニュアル化
最後は、徹底したマニュアル化です。チームとして、同じ問い合わせが3度あった場合は、マニュアルにする。10度あった場合は、FAQに追加するといったルールを作り、マニュアル化作りを徹底することが、業務効率アップと、新規サポート担当の教育期間短縮に繋がります。マニュアルは、wikiなど履歴管理ができるものが最適です。
11. サポート専用ボードの設置
サポート業務は、パソコン画面と向かい合って、一見すると、”見える化”が難しい業務です。また、個人プレーが多く、「後で確認する」といったタスクがどうしてもシステムで管理すると漏れが発生します。そこで活躍するのが、アナログなホワイトボードです。ホワイトボードには、「後で確認する」系のタスクや、今月のKPI、注意すべきことなど、チームとしてのタスク、共有事項を記載します。効率アップ、モチベーション、管理といった意味からも大切なボードです。
そんな運営サポートスタッフの採用情報
Lancers では、そんな運営スタッフを募集しています。上記のようなサポートマニュアルはもちろん、色々とサポートを楽しんでいます！興味のある方はぜひ！
