2018年10月18日、渋谷TechPlayにて「サポートエンジニアNight vol.4 ~Support Team Growth~」と題したMeetupが開催されました。4回目となる今回は、「X人からY人までサポート組織が成長したときに発生した課題や失敗」をテーマに4名のスピーカーが発表しました。
組織規模によってサポートエンジニアの役割は多種多様です。その中でも最初の一人のサポートから成長を支えた経験・十数人から数百人規模、数百人からさらに巨大になっていくサポート組織を生で経験し、その中で得られた知見はとても貴重なもので、これまで共有されてきたこともあまりありません。会社の成長とともにサポートエンジニアとして経験した課題や取り組み・失敗談を赤裸々に語りました。全文掲載にてお送りします。

杉本と申します。本日、サポートチームの成長に伴う経験談ということで、私が入社しました2011年の1月から現在に至るまで、Salesforceのサポートが何を考え、どういうふうに変わってきたかを、経験談を中心にお話したいと思います。よろしくお願いします。

2011年にサポートエンジニアとして入社

最初に自己紹介ですが、2007年に新卒で社会に出まして東京で就職したんですが、よくある話で前職では福岡に行ってこいということで1年ほどお客様先に常駐していました。そこでERPの運用やアップグレード、それ以外にもストレージのアップグレード等いろいろと経験させていただきました。2009年に東京へ戻ってきたんですが、当時リーマンショックのあおりも受けて、社内のリソースを海外のコストが安いところへ移管するようなプロジェクトがたくさんあって、そのプロジェクトに参画した関係でインドや中国でも勤務する機会をいくつかいただいたりもしていました。

その後、2011年に縁あってサポートエンジニアとして、Salesforce.comに入社し、そこから4年半ぐらいは一般的なサポートエージェントとして働いていました。Salesforceでは時差を利用して、日本の夜間の対応を北米でやっていますが、その北米地域に2回程駐在していました。2015年にロールが変わって、お客様と直接対応するエージェントから、開発部門や運用部門とサポートエージェントの間に立って仕事をするようなロールになりました。そこで1年半ぐらい働いて、やっぱりお客様のほうにもうちょっと出たいなということで、2017年からは特定のお客様に向けて、手厚くサービスを提供するようなロールで働き始め、現在に至ります。

本日のアジェンダですが、まずはSalesforce.comについてご説明します。そして、サポート部門についてお話して、そのあとに本題のサポート部門の増員と経験談ということで、少人数時代、小中規模、中規模、大規模のそれぞれの時代での経験談をお話したいと思います。最後はまとめです。

恐縮ですが、この中でSalesforce.comをご存知ない方いますか？　よかった。ご存知無い方はいらっしゃらないようなので、紹介は割愛します。

サポート部門のミッション”Customer Wow”

早速ですが、本題のサポート部門について話を進めたいと思います。皆さんも普段の業務でやられているかと思うんですが、サポート部門のメインは技術的なQ&Aです。あとはトラブルシューティング、障害対応、この辺りをやっています。その中で得られた知見を外部の公開記事として共有する、そういう記事を作る仕事もあります。弊社はクラウドサービスなので、プラットフォームやサービスの内容に変更が生じた場合はお客様に通知しなければなりません。お客様側で作業が発生したり影響があるときは通知しなければならないので、そういったものをお知らせするという作業もあります。また、有償のサービスなんですけども、クラウドサービスなのでお客様のデータはお客様からの許可無しに閲覧する事はできませんが、弊社側に操作ログ等はあるので、そういったログを分析して、お客様の利用傾向を監視・分析し、こちらからプロアクティブに、もうちょっとこういうふうに変更すればより良く使えますよという提案もサポートの一部のサービスでやっています。

そんなサポートですが、我々のミッションは、”Customer Wow” です。これはお客様からお問い合わせをいただいた際に、その期待値を超えるような回答を返して、お客様に驚きを与えましょうということをミッションとしてやっています。その結果、お客様を成功に導くということで、部門名もサポートじゃなくてカスタマーサクセスなんですね。この名前を冠したサービスとして、ベーシックサクセスプラン、プレミアサクセスプランがあります。また、現在はサービス再構築中なんですが、シグネチャサクセスプランという大きくはこの3つのサポートサービスを提供しています。今日は詳細を割愛させていただきますけども、このプランが後ほど出てくるので、簡単に紹介させていただきました。

日本の現在のサポートの体制です。東京で大体100人超の人数が働いています。また、北米に数人いまして、この体制で 24時間365日のサービスを回しています。そんなサポート部門ですけども、2011年からのお問い合わせの数を半年ごとにグラフにしたものです。数字が出せないのが申し訳ないのですが、大体2011年の1月ぐらいから、2倍以上、2.5倍、3倍ぐらいになっているのが読み取れるかと思います。青い線が人数、サポートのエージェントの人数です。これが当時大体10人ぐらいだったんですが、今は100人以上になっています。

小規模サポート時代の課題と対策

ということで、ここまでがサポート部門の話です。本題に移りますが、サポート部門の増員と経験談ということで、まずは2011年1月から2012年6月ぐらいの小規模時代です。この当時の最初のお問い合わせの体制というか対応フローについてです。お客様と、開発部門・運用部門の間にサポートがいます。すごくシンプルな体制をとっていて、メール、もしくは電話でお問い合わせいただきます。それを、ティア1、ティア2、ティア3という階層を持ったチームでやっていました。当時はティア1のほうで受け付けましたという受理応答や、メールアドレスが正しいお客様のものかの確認等、そういう本来の業務外の事を全部やっていました。もちろんティア1で調査をして、そこで大体7、8割ぐらいは返答している体制でした。その残った2、3割ぐらいをエスカレーションというかたちでティア2が対応して、その中でサービスのプラットフォームの問題だったり、製品の問題だったりすると、ティア3へエスカレーションして開発部門が引き続き対応するという体制でサービスを提供していました。余談ですが、お客様と直接コミュニケーションがあるのはティア2までで、ティア3は社内で、運用部門、開発部門とティア2のエージェントとのやりとり等、お客様の前にはでませんが、よっぽど燃えたときは出てきます。

当時私はこのティア2に配属されて、エージェントとして業務を行っていました。当時の課題と施策というか、そのときの状況です。もうとにかく問い合わせに忙殺される日々でした。電話とメールで受け付けて、受理応答や初期応答をティア1で対応してたんですが、すごい雑務が多くて、データのクレンジングや、スパムメールのクレンジングなんかもしなきゃいけなかったんで、ものすごく工数がかかってました。当時全てのお問い合わせを、全てのエージェントが、できるものをやっていたという感じだったので、あまり専門性というものがありませんでした。その他にも、ティア2は早番、遅番、夜オンコール、休日番というシフトを組んで日本で24時間回していましたので、すごく疲弊していました。ティア3は、少ない人数しかいなかったんですが、緊急対応があったらいつでも対応するような状況でした。その忙しかった理由の背景にあるのが、障害対応やお客様にメールを通知するという作業です。メールの中身を翻訳したりレビューしたり、送る作業もエージェントがやってたりしたということもあって、こういう調査以外のところの工数がかさんでいたというのが忙しい要因のひとつでした。

あとはサービスレベルです。さっき出てきましたけど、サービス内容も大きく差異があって、ひとつひとつのお問い合わせで、どのサービスレベルか、というのを確認するのにも工数がかかっていました。そういった背景があって、問い合わせ受けてから回答するまでがすごく時間かかっていたので、もちろんお客様の満足度は低かったです。

あまり一度にすべてを解決できないので少しづつですが、当時取った施策としては全員が全領域のお問い合わせやを対応するのではなく、専門性を持たせようということで、グループを作りました。その中でも特にコーディングや開発という専門知識が要るような問い合わせに対して、素養を持った人たちが専任で対応するようグループを作りました。これをスキルグループというかたちで呼んでいるんですが、日本で初のスキルグループでした。この変更によりナレッジを集約して対応速度を速めました。

次ですが、北米に人員を派遣して日本の夜間対応を移管し、日本のエージェントが平日夜間対応しなくてもいいようにしました。これで夜間対応の負荷がかなり減りました。もちろん夜間はお問い合わせが少ないんで、その間、回答案を使ってもらうということもやっていました。また、サービスレベルでサービス内容にかなり差異があったので、そのグループごとに分けました。これでサービスレベル確認する工数をだいぶ減らせました。最後、顧客アンケートの見直しということで、顧客満足度の低さを分析するような情報すら当時はありませんでした。なので、アンケート内容にアイコンをつけて選択制にしたり、数増やしたり、いろいろ内容を見直したりして回答しやすくするというところをやってみました。

そして、小規模から小中規模への変更後のフローなんですが、相変わらずメールと電話で問い合わせを受けているんですが、サービス毎にチームを分けて、サービス内容の差異を確認する工数を減らしました。また、専門のグループを作って、開発系はそちらに回して効率を高めました。この当時、私はプレミアのグループで働いていました。

3チームに分かれた中規模時代

このプレゼンの依頼をお話しいただいたとき、フォーマットは何も指定がなかったので、せっかくなので当時の私のお話をしようかなと思います。 入社当時私は26歳。オフィスは六本木ヒルズにありました。写真の左下にあるんですが、北米駐在、帰国とあるんで、そのカナダの写真が真ん中です。住んでた部屋が上です。そして、街並みが下で、結構いいところでした。その現地にUSのサービスを提供しているチームがあるので、そこのチームの人たちと一緒にボランティア活動したときの写真が右上です。右下の写真が、英語はそこまでしゃべれないんで、散髪行くのを日和って髪が伸び放題だったんで、人生で初めてくくった記念に撮った写真です。

この頃の、小中規模時代のサポートという組織に所属することについてのお話なんですが、さっきお話した小規模時代の話もあったと思うんですが、このぐらいの規模のサポートチームだと、やはりまだまだプロセスも固まってないですし、色々なことやらないといけません。なので逆に言うと、色々なことを経験できるというのがメリットかなと思います。ただ一方でとても忙しいので、メンタルやフィジカルが強い人が向いてるのかなとも思います。また、ただただ問い合わせを受けて流すというんじゃなくて、そこから何かしら改善して、少しでも良くしていこうというマインドを持った人のほうが向いているかもしれません。

続きまして、中規模時代で、2012年の6月から2015年の6月です。グラフを見てもらうと人数が少し増えました。お問い合わせが2014年の12月ぐらいにどんと増えました。当時、ティア1、最初の初期応答、初期調査をするようなチームの負荷が高いんですが、なかなか生産性が伸びないという状況もありました。また、平日の夜間はなくなったんですが、週末夜間、休日は引き続きエージェントがずっと働いていて、これも負荷がかかっていました。そして、相変わらず問い合わせ以外の様々な業務もやってましたが、顧客満足度はいまいち上がりませんという状態でした。これに対して何をやったかというと、メールでのお問い合わせをやめました。これでかなりお問い合わせのチケットを作るような作業をなくすことができたので、工数を減らすができました。また、セキュリティ上のリスク低減です。誤送信とかをなくすことにもつながりました。

さらに、サポート時間の再定義です。これはサービスの再定義なんですけども、お問い合わせが多い時間帯にもっと人を配置しようという話があり、お問い合わせが少ない時間を削って、リソースをお問い合わせの多い時間帯に回しました。サービスレベルの差異をもう少し近づけるようにすることで、リソースの再分配、最適化を行いました。そうすることで、サポート別のサービス内容を確認するような作業がなくなったので、プラン別のグループというのを廃止できました。新たにスキルグループをもう少し分割して、色々なスキルグループでチームを作って効率化しようという取り組みを行い、ここで3つにチームが分かれます。

3つにチームが分かれると、最初に入ってきたケースを、適切なチームに振り分ける必要があるので、トリアージというチームを導入しました。チームといっても当時はまだ兼任だったんですが、後に専任化されます。トリアージというチームを導入して受理応答、連絡先、コミュニケーションをとる方法が正しいかどうか等、そういった内容をきちんと確認したのちに適切なチームにルーティングするというチームです。
このトリアージというチームを導入したのがこの時期です。また、北米の駐在員の話ですが、こちらもティア3の業務はそれまで対応していなかったんですが、ティア3の業務の一部を移管しました。具体的には、夜間時間帯でUSのメンバー、主に開発部門ですが、彼らとやりとりをする責務の一部をティア3から北米のメンバーに移管しました。これにより、ティア3が徹夜しなくてよくなり、ティア3はだいぶ楽になりました。

プロセスが安定し、顧客満足度も改善

最後に、顧客満足度アンケートの送付頻度を全てに変更とありますが、それまではランダムで10％ぐらいのお客様にしか送っていませんでした。ただ、母数が小さくて分析が全然できないということで、全てのお問い合わせに送ることにしました。これでかなりの数が返ってくるようになったんですが、返ってきすぎて、分析するのも大変でした。

その変更後の体制です。メールのお問い合わせ窓口からお問い合わせポータルに変わり、トリアージチームを設けました。そこから各スキルグループを分け、3つのスキルグループを作って、ナレッジを集約して効率化しました。各ティアでスキルグループができました、というかたちです。当時、私は開発系の問い合わせを受けるチームに移りました。また私自身の話ですが、ちょっと垢抜けて大人っぽくなっています。上の写真が、東京の丸の内ですが、この頃、人数が多くなって六本木ヒルズに入りきらなくなったので、東京のオフィスに移りました。また、左下の田んぼですが、当時、休耕田を有効活用しようというボランティアがあったので、この辺から始めました。

2014年の6月ぐらいからもう1度北米に行く機会があったので、その時の写真も載せてます。その北米チームでのランチ、持ち寄りパーティーなんですけども、みんな男性は散髪に行くのに消極的で日和って、ちょんまげになってました。この規模ぐらいになるとだんだんプロセスが固まってくるようになります。なので、かなりサポートとしてボリュームを捌けるようなチームになってきたかな、というところですが、まだまだ問い合わせ以外の業務もやらなければいけないので、色々な経験がしたいけど、長時間働くのは嫌だなっていうぐらいの人はこの辺のボリューム感のチームがいいかもしれないです。

生産性はかなり改善してきましたが、やはり引き続き負荷が高い状況でした。一方、顧客満足度はこの時期にかなり改善し、グローバルと同じで、10点満点中9.× くらいになってきました。ただ、定型なサポートサービスになってきたので、お客様の中にはより高い品質や、もっと自分たちのことを知った上で対応して欲しいといった、専任のサービスを求めるような声が出てきました。施策として、ポータル上でお問い合わせ自体を減らしましょうというところを取り組んでいます。ポータル上で問い合わせ作成時に、関連記事を提案するような機能をつけたり、チーム構成を変えて効率化していったりというところです。

また、人が足りないという事で、この頃からようやく新卒も育てられるぐらいの規模になったので新卒採用を始めました。その他にも障害通知やサービスの変更のお知らせ等、ティア2が調査以外でやっていた作業を専門でやるチームを作り、さらに、有償の新しいサービスで、特定のお客様向けにより高品質なサポートサービスを提供するチームも作りました。

結果、スキルグループが多くに分かれ、新しくシグネチャサクセスサポートという、緊急対応や手厚いサポートサービスを行うチームができました。その他、お問い合わせポータルの管理者も専任でつきました。

この頃、私はティア3に異動しています。ティア3に異動してグローバルとやりとりが増えたので、海外の開発者の同僚が来るときにアテンドするようなことが多かったので飲み会の写真が多いです。そのあとは、会社全体でアロハのシャツが配られたり、CMを流し始めたりと、結構大きな会社になってきた時期でした。この辺は、普通のサポートエージェントで結構サラリーマン的な感じで、プロセスがカチッと固まってきた時期です。

大規模ゆえの課題と変化

最後、大規模時代なんですが、お問い合わせ自体が多いので負荷は高めな状況でした。スキルグループの細分化に伴い、コミュニケーションの壁ができ、部門自体が大きくなって、情報の周知等、プロセスの徹底が難しくなってきました。また、増員に伴って立ち上げコストが掛かったり、満足度調査の結果が9.×で安定してしまって何が改善点なのかわからなくなったりといった課題もありました。

この頃の大きい変化として、教育システムが出てきました。お客様へも公開されて、誰もが無償で使えるようなものなんですけども、Trailhead というものがあります。これでお客様がかなり自主的に学んでいただけたので、自己解決率が高くなり、さらにユーザーコミュニティも活性化して、コミュニティの中でユーザー同士が解決してくれるということが増えてきました。これらの事により、かなりのお問い合わせが起票前に減ったと思われます。

他にも、調査以外の作業を専任で担うサポートオペレーションズというチームもできました。ここで、ポータルの管理や、技術文書の公開基盤の管理、オペレーションやKPIの分析、また、新入社員の立ち上げを一括してやってくれるので、それまでエージェントがやっていた調査以外のことをここで仕事として引き受けてくれるようになり、かなり工数が下がりました。

最後は先程出てきた、テクニカルアカウントマネージャー、TAMです。弊社でも立ち上げが始まったのがこの時期です。変更後のフローはほぼ今のフローになっています。通常のサポート契約のお問い合わせを受けた際は、各スキルグループにルーティングされて、効率良く対応していくというフローになっていて、シグネチャサクセスご契約のお客様は直接、エスカレーションというオーバーヘッドなしで対応するので、かなり速く対応できるようなチームにアサインされるようになりました。それ以外にも、テクニカルアカウントマネージャーというサポート全体を支えるチームがいたりします。

今、私はシグネチャサクセスサポートにいます。これはクリスマスパーティーの写真です。

左下が、最近ゴーカートとかやっているのでその写真だったり、テレビでYOSHIKIが弾いていたピアノが、この前US本社に行ったらお客様向けのフロアに飾ってあったので写真を撮ってきました。引き続き田んぼボランティアをやっているんですが、暑すぎて、稲刈りはくたびれてました。また、右上もボランティアです。いろんな理由で親御さんと暮らせないような子たちが住んでいる施設に行ってクリスマスプレゼント配るとか、そういったこともやってたりします。この時期は、サラリーマンという感じで、プロセスをかっちり決められたものに従ってやっていればKPIはきちんと満たせて成果も出るというかたちになってきています。ここまでが人数ごと、それぞえの時代のお話でした。

お客様の期待を超えるサポートサービスを目指して

ということでまとめです。繰り返しですが、入社時のプロセスは、すごくシンプルなプロセスでやっていましたが、これが様々な経緯を経て複雑化されました。ただ全ては、効率的にお問い合わせを捌くために行った変更です。結果はどうなったかというと、お問い合わせに対する満足度調査の結果は2013年ぐらいから上がり続けて、最終的には、1年間通して9.2×ぐらいの平均値をとれるにようになりました。10点満点と言っているんですけど、0点があるので、正確には11点満点です。アンケートを途中で変えたので5点満点になったんですが、5点満点になっても、4.3か4.4ぐらいの平均値をとっているという状態なので、効率的に捌けるようになり、満足度はそれなりになってきたかなと思います。

今のはお客様だったんですけど、従業員の満足度はどうなったかというと、先程は負荷が高い、忙しいと言っていたんですが、一例として私の業務時間のグラフを持ってきました。入社当時は本当にまだ組織が小さくて、時間は具体的には出せないんですが、かなり働いていました。今は大体半分ぐらいになっています。すごく自由な時間が多い日々を過ごせています。もちろん社内でアンケートもとっていて、その改善も見られているので、会社全体としてよくなっているんじゃないかなと思います。

今後の時代の課題ということで、お客様がどんどん増え、新機能が拡充され、新しいクラウドのサポートの開始をすることで問い合わせの数が増加したり、内容が複雑化したり、回答まで長期化しますというのがあります。また、新しいサービスの立ち上げもあるので、そういったサービスに適応するような人材を引き続き継続して採用していく必要があります。

また、スキルグループを分けすぎてチーム間のコミュニケーションに壁ができ始めたので、間に落ちた問題をどうするか、という話を仕組み化や、そのほかの対応策を考えないといけないと思っています。ロケーションも、今東京で2箇所に分かれてしまいました。なので、ロケーションが違っても効率良くコミュニケーションして業務の効率化を行う事を考えていかなければと思っています。

これらの課題を解決して結局何がやりたいかというと、お客様の満足度をより高めたいという事です。それによって、お客様の期待を超えるサポートサービスを提供したいというのが最終的な目標です。ということで、弊社ではサポートサービスをよりよくする仲間を募集しております。グーグルかなんかでSalesforce採用情報と調べていただくと、こんな感じの遷移でいろいろ出てきますので、是非興味のある方、一緒にサポートサービスを良くしていってくださる方、お問い合わせください。

質問者1：2014年の12月、チケットの数がすごい跳ねた時期がありますよね。あのときに何か特別なことって起きました？それとも忙しすぎてずっと変わらなかったのか。グラフだけ見ているととんでもないことになっている気がしたんですけども。

—いろいろあるんですけども、クラウドサービスなので、チケットがスパイクする要因は結構あって、例えばプラットフォームの大きな障害や、大きな変更がが最も要因としては大きいんですけど、この時期、お客様がドンと増えた時期でもあったので、主にその3つの要因です。

質問者1：そのときに中の人として、特別に死にかかったとかいろいろあるのかなと思うんですけど。

—死にかかりました。問題が起きて問い合わせ数がスパイクしたんです。で、スパイクしたときはどうするかというと、そういうスパイクもそれまで何回か経験してるんで同じような体制とるんですけど、スキルグループ化と一緒で、その問題に対して対応する人を固めるんですね。で、効率的にお問い合わせを捌き、なんとか乗り切る、というかたちですね。ただ、その固められた人たちは結構泣けますよね。

質問者1：ありがとうございます。

質問者2：先ほどのトレジャーデータさんの発表ですと、属人化を避けるために分散していくという話があって、こっちは逆にチームで専門化していくという話で、それぞれ矛盾する話かなと思うんですけど、どうやってそのバランスをとるように気をつけられてますか？

—レベル感の話だと思っていて、最初トレジャーデータさんの属人化と言っていたのは、全部の領域を全員でやっていた時代だと思います。当時はわれわれも属人化しきっていて、できる人ができるだけ対応するという状態だったんですが、それはおかしいよね、という話で、スキルグループを分けて、その領域に関してはスキルグループが専門家だから、そのチームみんなでやっていこう、という体制になりました。そういう意味で、全体として属人的にはならないという体制に変わったという、レベル感のお話かなと思います。

質問者3：日本の体制とグローバルの体制ってどれくらいアラインしているのかというのが聞きたいです。

—スキルグループという体制はグローバルと一緒です。ただ、グローバルだと人数が多く問い合わせも多いので、担当スキルグループ専任ですが、日本は複数スキルグループを1人で持っていることがあります。

質問者3：ありがとうございます。

質問者4：スキルグループが細分化されて、その間の問題をどうするか、というのが課題であるというお話があったんですけど、スキルグループ間や、あとティア間で人の異動とかはあるんですか？

—結構頻繁にあります。むしろスキルグループ間の異動は、人事上の変更ではないので、結構サポートの中で柔軟に異動ができますね。ただ、ティアの変更は昇格も関係するのでスキルグループの移動ほど頻繁ではないですが、もちろんあります。

質問者4：スキルグループ間の異動は本人の希望が大きいんですか？

チームの状況にもよりますが、本人の希望を必ず聞きます。無理な変更や異動というのはほぼほぼないはず。

質問者4：ありがとうございます。

質問者5：お客様からの満足度、ずっと低い状態だったというお話があって、最後のほうですごく良くなったというお話があって、どの辺が一番効果があったと思われますか？

対応に関しては回答するまでの速度が早くなったことが一番効果があったと思います。それともうひとつ、悪いアンケート結果が返ってくるとお客様に電話しました。もちろんエージェントが電話することがあったんですけど、主にマネージャーが電話して、どういったところが悪かったか、と直接聞いて、ではそれをより良くしていきます、という話をしたりもしていました。この地道な作業が結果に繋がったと思います。

質問者5：アンケート結果が悪かった場合にそこをもうちょっと電話で詳しく聞いた、というのを徹底して、それを直していった、というのが大きかったと。

—そうですね。マネージャーからのアクションとしてはそれが大きかったです。問い合わせに対してはスピードを上げるというところに注力したというのが大きかったですね。