新卒入社企業　CSでの学び

こんにちは、Sontackです。

今回は、新卒で入社した企業で担当していたCS（カスタマーサポート）業務からの学びと、その時のキャリア観について記述したいと思います。　※少し長文になります。

CS業務は、サブスクリプションモデルで展開するサービスが多いSaaSにおいて、非常に重要な役割を担っており、営業と同等レベルに、強化しておくべき役割と考えています。

CSは主に2種類で、フィールドサポートとデスクサポートです。当時在籍していた企業では、フィールドサポートを活用支援担当として、技術的な支援というより、顧客の業務用件に沿った活用法を中心に提案していました。

対して、デスクサポートは技術的支援を中心に、顧客から直接、もしくは営業やフィールドサポートから寄せられる「こんなことやりたいのだが、○○機能使って実現できないか？」といった質問に回答します。または、製品の問題や顧客の利用方法に問題があった場合に、問題の切り分けから、原因の特定、解決まで、支援していました。

当時、私が配属されたのは買収製品のCSでした。買収後、既存製品との統合を並行で進めていた経緯もあり、製品側の問題として、問い合わせを受けることが非常に多かったのです（要は、クレームが多かったのです..）。

ハイブランドで信用度が高い企業ほど、それに見合った回答の精度・スピードが求めらるもので、新卒でそのような部署に配属されたことは、私にとって非常に大きな経験になりました。以下は、私がそこで得た知見です。

迅速な根本解決より、迅速な回避策の提示

問題が生じたときに、最も最初にやるべきことは「問題の切り分け」で、このあたりで意見が食い違うことは、顧客にせよ営業担当にせよ、ありませんでした。

一方で、食い違いが生じるのは、その次にどんな行動をとるかです。顧客がその時点で求めているものは、「一刻も早い問題の解消」であることには間違いありませんが、その期待値の中には「これまでと同様のアクションがとれる状態」というのが含まれています。

例えば、あなたの乗る電車が事故の影響で、大幅に運行が遅延している場合、「黙って来るのを待つ」か、「10分遅いけど、別の経路で行く」か、どちらを選びますか？　また、それがプライベートではなく、仕事の都合での移動だった場合、多くの人が後者を選択するはずです。

これを業務に置き換えると、原因不明のエラーでこれまで実行できていた操作が、実行できなくなったら、最初にやるべきなのは「問題の解消」ではなく、これまでと同様のアクションがとれる「回避策の提示」なのです。

そもそも、根本解決というのは時間がかかることが多い一方、かけた挙句、顧客にとってあまり有意義なものでないことも多かったのです。

なので、「時間のかかることは、追々やりましょう。まずは、今までと同じことができるようにしましょう」、というのが当時の基本スタンスでした。

チームと自社を守るテクニック

CSは、「最後の砦」的な側面が強く、とにかく間違ったことは言えません。そのため、可能性を頭から否定するような言葉は使わないことにしていました。

これには様々な背景があり、例えば、規模の大きい企業であったため、製品開発チームとの連携が密になっているわけではなく、新たな製品や機能について、多くの情報を持ち合わせていないため、現状を以ってして、将来の可能性の否定につながるような事は絶対に言えません。

また、SaaS営業担当者に散見される事例ですが、機能の全体把握をしていなかったり、未発表・未確定の将来図をもとに販売することで、現在できないことも「できるようになる」として、販売することが多いのです。このため、CSチームで頭ごなしに、「できない」と断言するようなことをしてしまえば、「営業担当の話と違うじゃないか」という摩擦が生じます。

（断言しなかったとしても、こうしたことで炎上することは、企業問わず多いのですが..。）

そのため、テクニック部分になりますが、可能性を0にするような言い方はしないようにしていました。一方、自社やチームを守らなければいけない局面では、なるべく断言するようにしていました。

これは、隠ぺいなどの悪だくみではなく、純粋に「正しく認識されなければ、自社・チームにとって不利益」と判断した時に、断言する言い回しを使っていました。

例えば、顧客の設定間違いによって起こったエラーを、私たち側の操作に起因しているものと認識している場合、「当社側で○○設定を、お客様の許可なく変更することは、一切ございません。」といったような形で、完全否定することで、逆に安心感を持ってもらえることもありました。

言い回し一つで、最終的な印象を変えられるのも、CSの強さだと感じています。

顧客の期待値を超えられるか、どうか

CSのKPIは主に、顧客満足度に設定することが多いですが、この顧客満足度は、顧客の「期待値」に大きく左右されます。

※顧客満足度と期待値の関係性は、様々な企業で研究されており、会社によっては「期待値をコントロールする」というアプローチをとって、顧客満足度を上げているようです。

言うまでもないかもしれないですが、設定された期待値を、常に上回り続けることは、非常に難しいことです。顧客の利用フェーズや製品理解という軸だけでは、顧客の期待値がどの程度なのか測れず、毎回問題の切り分けと同時に、顧客の期待値を探りにいかなければならないのです（顧客との問答のゴールがその顧客が満足してくれたか、なので）。

正直、私自身は在籍期間も短かったため、期待値を探るというテクニカルスキルはそこまで身に着けれられませんでした。とにかく顧客の質問・要望への回答に、＋α（補足情報）をセットで回答する日々でしたが、顧客によってはこれだけでも、期待値を超えるアプローチとなっていたことを覚えています。

「もうそろそろ、いいいか」で簡単に異動できずに、転職。正しい選択だったのか？

上記のような知見を得てきた私ですが、半年もたつと、この職種の魅力とされている「テクニカルスキル（主に技術的知識）」を、これ以上身に着けることに、興味を持てなくなっていることに気づきました。

周囲のエンジニアには、「技術で何かができるようになっていくことにわくわくする」「自分で作ったものが動くのが面白い」など、技術の習得に対して、合理的に説明が付けられない動機付けがありましたが、私にはそうしたものがなかったのです。

そこで、私の適性が「技術面で深く追求していく」方向でなく、「エンジニアと共通言語で話せる」方向だったと気づきました。本来、CSに配属希望を出した理由も、技術観点でなく、サブスクリプションモデルにおけるCSの重要性とその中身を経験しておきたい、というものだったことと、KPIを連続達成していたことから「もうそろそろいいか」と、思ったのです。

そこで、生意気ですが「CS業務に飽きたから、部署異動させてほしい」と、正直にマネージャーに言い放ちました（笑）。マネージャーは、私の言葉をそれとなくかわして、CSの1ランク上の職務を任せるといわれ、がっかりしたことを覚えています。

興味を失っている若者に対して、昇級は「君はしばらくここから出さないよ」といわれているようなもので、その瞬間から、急激に職場が窮屈に感じました。

もう、こうなってしまっては、歯止めがききません(笑)。

翌週から、あらゆる転職サイトに登録し、通勤途中の電車で、情報収集を始め、土日には「本来何をしたかったか」「今何をすべきか」を徹底的に考え抜き、それに一致した企業へエントリを開始しました。

今振り返ってみると（手前味噌ですが）、企業側にとっては大きな損失だったと思います。囲い込みのような手法で異動を阻止しなければ、私は新たな環境でKPI達成に向けて必死に努力したでしょうし、何より、一連の流れを見ていた他の社員の心象が一気に悪化していました。

（その後、いろいろな問題も関連付けられ、当時のマネージャーは降格となったと聞いています。）

そして、従業員側（=私） の行動については、今時点では、正しかったと思っています。自分が次にやるべきこと（やりたいこと）がわかっていて、それが出来ない環境に居続けるのは、大きな機会損失と考えていたからです。挑戦できる環境が世の中には数多あるという機会と、そもそも20代は環境適応能力が高く、それが年々退化していく機会の損失です。

自身が掲げる目的と、業務内容が一致していない場合の転職や異動は、「逃げ」のようなイメージが漂いますし、「最後の手段」のように考えられがちですが、上記の機会損失を考えれば、あらゆる選択肢と同等レベルで考えても良いのではないか、というのが私の考えです。

逃げだろうと、最後の手段だろうと、その先の人生を切り拓くのは自分なので、フラットかつ直観的に選択をすることが重要な気がしています。

：

長文、最後までご覧いただきありがとうございます！

もし、興味がありましたらバックナンバーもご覧いただけますと嬉しいです！　次号では、転職先のベンチャー企業での半年を記述したいと思います。