Amazonのカスタマーサポートで身につけた顧客志向と仕組み化

私は新卒で現KDDIに入社し、その後、マネックス証券の立ち上げや、AmazonでKindle本の出版サポート立ち上げを経て、ココナラに入社しました。

Amazonでは、海外で行っていたサポート業務を日本に持ってくるような仕事をしていたのですが、そこでの文化は衝撃的なものがありました。すべてをお客様中心に考えるんです。

これは有名な話ではありますが、出張は全社員がエコノミークラスを使います。社長も取締役も関係なく。なぜならファーストクラスに乗ることは、お客様のためにはならないから。細かいところまで顧客至上主義を貫いています。

改善もどんどん重ねて、仕組み化も徹底されています。ホワイトボードの黒板消しや、赤ペンを置く位置まで決まってます。2年弱の間、Amazonで学んだものは、今でもココナラのCS（カスタマーサポート）のベースになっています。

数をさばくだけのCSチームの改革に乗り出す！

ココナラは「知識・スキル・経験」を気軽に売り買いできるCtoCのオンラインマーケットです。私が入社した当時、カスタマーサポートは1.5人くらいで回して、週末は全社員がシフトで対応していました。エンジニアであっても、誰であってもです。

でもそうすると、普段サポートに慣れていない人がテンプレートや過去のやりとりを参考にしながら対応するため、クオリティも安定せず「数をさばいている」ような状態でした。

そのような状態を変えようと、CSの組織作りを始めました。まず、お客様と話をするのはCSメンバーの責任だと明確にして、週末に他部署の社員が行っていたものも、CSメンバーがすべて対応することにしました。

他社のCSを体験するワークショップを開催。得られた気付きとは？

次に、自分たちの行動規範を見つめなおそうと、ディスカッションやワークショップを実施しました。ワークショップでは、他社さんに実際にお問い合わせをしてみて、対応される側の立場になってみました。

CSで有名な企業さんに質問をして、対応文面や対応時間、トーン＆マナーなどを共有し、自分ならどういう対応をしていきたいかを話し合ったんです。

▼ディスカッションで話したCSの役割

ひとつ面白かったのは対応の温度感でした。各企業が持つお客様のセグメントが違うだけでこうも違うのかと。

たとえば以前勤めていたマネックス証券であれば、お客様の資産を預かり運用する会社なので少し堅めに。AmazonのKindle本の時はそれなりのネットリテラシーをお持ちの方が多かったりと、それぞれ対応のトーンが変わってきます。

でもココナラの場合はお客様が非常にバラエティに富んでいるので、どのような温度感で接するのかはとても悩ましいポイントでした。

結果的には、かっちりと対応の仕方を決めるというよりは、メンバーに対してある程度の許容範囲を与えて、お客様に合わせて柔軟に対応していく形に落ち着いています。びっくりマークや音符マークの使いどころなど、難しいですよね。

もうひとつワークショップの中で感じたのは、やはりスピードはお客様に良いサプライズになるということです。

問い合わせへの返信時間というのは、つまり課題解決の時間だといえるので、やはり数時間で返ってくると嬉しいですよね。

お客様がどんなクリティカルな状況にいるのかわからないので、弊社では回答のSLA（※）は24時間以内に設定して、必ず守るようにしています。

※Service Level Agreementの略。サービス提供者が利用者に対して保証するサービス品質水準のこと

▼問い合わせへの返信時間を指標に設定している

KPIはPositive Response Rate。Zendeskで可視化

CSチームではSLAの他に、PRR(Positvie Response Rate)、そして取引数に対する問い合わせ数をKPIにしています。

PRRはカスタマーサービスツールの「Zendesk（ゼンデスク）」の機能で計測しています。対応終了から24時間後に自動で「対応に満足したか」というアンケートメールを送り、いまは83%以上が「満足」と答えてくれることを目標にしています。

▼Zendeskで顧客満足度を計測

解決した問い合わせのうち、約4割のお客様がアンケートメールにご協力してくれています。フリーコメントの理由を見ながら「不満」の人がどうしたら「満足」になるのか、チームで定例ミーティングを開催して、事例を振り返りながら改善を繰り返しています。

中には「不満」だけの回答でコメントを残さない人もいますが、その場合は、お問い合わせとその対応からお客様のお気持を想像して原因を探っています。

Zendeskはプロジェクト管理ツールの「JIRA（ジラ）」と連携させて使っています。サービスに問題がありそうだったら、ZendeskからJIRAのチケットを作ってエンジニアに渡しています。

▼zendeskと連携してつくられたJIRAのチケット

最近では、一部の決済画面で数字を入れるときに、カンマが入力されるとエラー表示されるようになるというお問い合わせがありました。

そういうところはお客様から指摘されて初めて気づくことも多いので、JIRAベースで議論を進めて、どう改善していくのか意思決定しています。

CSのコストを削減することは、お客様のメリットにつながる

取引数に対するお問い合わせ件数は、減らしていくことを目指しています。CSのお客様1人あたりの対応コストをどんどん減らして、最終的に私の仕事がなくなってクビになるくらいでいいのではと思っています。

CSの仕事というのはサービスに問題があるから発生しているというものが多いので、やはりそこを解決していきたい。無駄なものをそぎ落として、どうしたらユーザーが使いやすくなるのかを、徹底的に追及している最中なんですね。

ただ、現実的にはCSの活動がなくなるというのは難しいです。なので改善を繰り返して仕組みを作り、コストを減らしていくべきだと思っています。

実際に、ココナラではお問い合わせのチャネルとしてはメールしか用意していません。いたずらにチャネルを増やしてコストをあげても仕方ないんですよね。サービスを運営する以上、その分どこかを削らなければいけなくなってしまいます。

今後ほかのチャネルを増やさないと決めたわけではなく、いまはメールでユーザーにご満足いただけるサポートを提供し、サービスの拡大とユーザーの満足度を上げることに貢献したいと考えています。

ナレッジ化・アウトソースで余裕を作り、企画にも踏み込む

現在ではCSメンバーは6人、アウトソース先にも4名という体制になりました。ここ2ヶ月ほどはCS活動のアウトソースを少しずつ進めています。

問い合わせの内容によって、初期対応できるものを6割ほどアウトソースしています。完全にアウトソースするのは難しいので、それ以外の問い合わせを自社で対応しています。

実際はもっと早くアウトソースに踏み切るということもできたと思います。しかし、そうすると社内にナレッジも溜まらないので、なるべく社内でナレッジを溜めて、溜まったものを外に出すというステップにしました。

▼社内でナレッジを溜めた上でアウトソースを進める、ココナラのCSチーム

アウトソースする前はすべて自分たちで対応していたので、チームに不満も溜まっていたかと思います。メールの顧客対応だけで1日の業務が終わってしまって、改善活動やデータを活かした分析がしたいのに、できていなかった。

今までは、そのようにとにかくオペレーションを回して、問い合わせに対応するというのにフォーカスしてきました。これから先は、新しく生まれたリソースを使ってCSの活動を、より企画やサービス改善につなげていきます。

CSとしてもプラットフォームのクオリティマネジメントであったり、禁止出品サービスを監視するリスク管理の強化など、やるべきことはまだまだたくさんあります。

そういう活動もナレッジを溜めていき、仕組み化して、場合によってはアウトソースを活用していく。それを繰り返して、よりお客様にサービスを使ってもらえるようにしていきたいですね。（了）