知識とスキルの幅を広げてくれる「受託が好き！」

私がITに関わるようになったのは、アメリカの大学に留学したときのことです。当時はインターネットバブルの時期だったので、「ITをやらないと」という気持ちになって。ビジネススクールに通いつつ、コンピューターサイエンスも学んでいました。

その流れで卒業後は、日本でITコンサルの会社に入社しました。その後、小さなベンチャーを経て、ヴェルクを創業したという形になります。

弊社では自社サービス「board」の開発・運用も行っていますが、主要な事業は受託開発です。様々な業種のお客様と仕事ができて、視野が広がるので、僕は受託が好きなんですよ。

例えば、スーパーマーケットの月間で数十億件にものぼるPOSデータの分析を手伝ったり。自分たちだけでは絶対に持つことができない量のデータを扱うことができて、とても面白いですね。

自分で使うために「board」を開発。公開後のCSも、ひとりで担当

弊社はもともと、受託の会社でした。boardは、最初は自分で使うために作っていたんですよ。

当時、請求書作成のサービスの利用を検討していたのですが、既存のサービスだと不便な部分があるなと。請求書は作れるものの、経営管理や業務管理の概念が入っていないんですよ。

他方で、経営管理や業務管理を行えるSalesforceは、弊社の規模ではやや高価すぎる。

それで両者の中間にあるものを、自分で使うために作ろうと思ったんです。作っていく中で、周りの同業者の方も私と同じことを感じていることがわかってきて、一般に公開することになったんですね。

もともと自分が使うためだけに作っていたので、開発は僕ひとりで行いました。その流れで、サービスを一般公開した後、CSもひとりで担当することになったんです。

お問い合わせのメールフォームを「Intercom」に切り替え

お客様からのお問い合わせについては、最初はメールフォームを用意していました。

しかし、リリース初日に知り合いのエンジニアに「メールはうざいから、これを使って」と言われて（笑）、CS用チャットツールの「Intercom（インターコム）」を勧められたんです。

▼サービス内に「Intercom」を埋め込み（右側）

Intercomを使うと、サービス上にお問い合わせ用のチャットを常駐させることができます。そしてさらに、プッシュ通知を出し分けられる機能もあるんですね。

▼通知内容を出し分けも可能

もともと、新機能を実装したタイミングなどでプッシュ通知を出したい、しかも、ユーザーの属性ごとに内容を出し分けたいと思っていたので、「それに使える！」と思い、導入を決めました。

受託の経験の結果として自然に実現した「カスタマーサクセス」

もともと受託しかやってこなかったので、カスタマーサポートの経験はなく、最初は手探りで進めていきました。はじめのうちは返信ひとつにすごく時間がかかって、苦労しましたね。

ただ、そうやって自分流に進めていたら、いつからか「boardのサポートいいよね」「返信早いよね」と言っていただけるようになって。最近ですと、カスタマーサクセスをテーマにしたイベントなどに登壇させていただくこともあります。

ただ、「カスタマーサクセス」なんて言葉は意識したことがなかったので…。

と言うのも、カスタマーサクセスって、受託開発だと当たり前で。あえて意識することではないんですよ。お客様にとって成功でなければ、受託では次の仕事がもらえないので。

最初の職場の上司は、「プロジェクトを成功させて、お客様側の担当者を出世させよう」とよく言っていました。これもまさしく、カスタマーサクセスの考え方ですよね。

ブログで平均返信時間を公開、ただ返信時間をKPIにはしない

「問い合わせの返信が早いよね」とよく言われていたので、実際どのくらいなのかをブログで公開してみたんです。

当時は、初回のお問い合わせに対する回答時間が平均で15分だったので、「すごく早い」という反響をもらうことができました。

▼Intercomの管理画面では、初回の回答時間などがグラフ化される

ただ、返信時間のデータがIntercomで見られることを知ったのも、使い始めてから半年後ぐらいで。意識して「早くしよう」としていたわけではないんですよ。

「自分がボールを持っている間は、お客様の仕事が止まってしまう」と思って、受託の時から返信は早くすることを心がけていたというだけで。

いまでは初回の返信時間は6分になっています。公開するようになってから、どうしても意識してしまって（笑）。

ただ、時間を早めることを目的にはしないようにしています。そうすると、どうしても回答の質が低くなって、お客様に価値を提供できないからです。

もちろん、何十人ものCS部隊がいるとなれば、そういった返信時間をKPIとして数値で管理することも、マネジメント上、必要になってくると思います。ただ、数人ではそれをやってもしょうがないかな、と。

お問い合わせ数は、最終的には少ない方がいい

初回の返信時間もそうですが、問い合わせ数の「多い・少ない」も、どう判断すべきか難しい数字ですね。

もちろん、問い合わせがしにくいせいで数が少ない、ということは最悪です。そういった意味では、件数は多いほうがいいですね。

実際、弊社では、サービス上の「お問い合わせボタン」をクリックすると、Intercomの使い方が表示されるようにして、問い合わせへのハードルを取り除くようにしています。

Web業界は別として、世間では、まだまだチャットに抵抗がある人って多いんですよ。

ただ、他方で、お問い合わせ数をKPIとしておくのも違うかなと。というのも、最終的にはつまずきの少ないUIを実現することで、操作に関する質問の数を少なくするのが一番ですよね。

最も大切な数字は、解決までの時間と連絡回数

個人的に一番大事だと思う数字は、問い合わせが最終的に解決にいたるまでの時間と、それまでの応答回数です。早く・少ない連絡回数で問題が解決するのが、お客様にとっては一番ですよね。

気をつけているのは、お客様の質問の意図を正確に読み取り、わかりやすく返信することです。お客様からの質問って、いつも分かりやすいわけではないので。そこを慎重に読み取って、回答を組み立てることを意識しています。

また、操作に関する質問の数は少ない方が良いのですが、逆に要望は、いくら来てもいいと思っています。私は、要望は優先順位を7段階ぐらいに分けて、タスク管理ツールの「Trello（トレロ）」に保存し、順次対応しています。

▼タスクを可視化できる、「Trello」（内容はイメージです）

Intercomはお問い合わせごとにURLが発行されるので、それをTrelloに貼り付けておくと分かりやすくて便利です。

カスタマーサポートを効率化するFAQと「教育」

最近はユーザーも増えてきて、問い合わせもさすがにひとりでは捌ききれない量になってきています。

対応策のひとつとして行っているのは、FAQの充実です。何度も同じような質問が来る場合には、FAQに項目を作成して、次回以降はそちらに誘導するようにしています。

もうひとつは、やはり人を増やすことです。最近1人専任の人を雇ったんですが、CSってクオリティがすごく大事ですし、boardの場合はそれがブランディングにまでなっているので、絶対に質は落とせない。

そこで重要になってくるのが教育です。それに使っているのが、チャットツールである「Slack（スラック）」のbotです。

Slack上で「ok board」と打ち込むと、FAQからSlackに質問だけがランダムに飛んでくるようになっています。スタッフには空き時間にそれを使って回答文を作成する練習をしてもらい、後で僕がレビューをする。

▼botを使って対応を練習している、実際の「Slack」の画像

今後とも、このような効率化やシステム化を進めつつ、「サポートがいいboard」というブランディングを守っていけたらと考えていますね。（了）