仕組みはつくるだけでは動かなかったーーCSの私がBizOpsを担う理由
この記事は、「現職経験」を通じて、CS業務とBizOpsを兼任することになった経緯と考え方を紐解いたストーリーです。きっかけは「つくった仕組みが使われない」という壁「伝えた」は「伝わった」ではな...
https://www.wantedly.com/users/166574180/post_articles/1054039
この記事は「現職経験」を経て、SaaSでカスタマーサクセスをやりたいという動機を得るまでのストーリーです。
「対応中です」しか、言えなかった時期があった
問題は、構造(仕組み)にあった
待つだけでは、間に合わなかった
「対応中です」を、減らした
終わりに:「成立するか」を大切にしたい
ある日、お客様から問い合わせが入りました。
成果物がいつ手元に届くのか、という内容でした。
私は、答えられませんでした。
当時は、システム導入で滞っていました。
どこで詰まっているのか、いつ解消されるのか、社内の誰も正確に把握できていませんでした。
渡せる言葉は「対応中です」だけでした。
このとき、問題だと判断したのは処理速度でも、対応力でもありません。
お客様も社内も、誰もが「状況がどうなっているのか」を把握できていない。
それがお客様に対する不信感を生み出す構造そのものが問題でした。
現職で扱う健診サービスは、無形商材(データ)です。
お客様にとっての価値は、医療行為を受けることではなく、サービスを利用できるように必要な情報を滞りなくお届けすることにあるのではないかと考えました。
この失敗を起点に、成果物が約束通りに手元に届く「体験」を守るべきだと、考えを改めました。
しかし、
その体験を成立させるには、社内の仕組みが機能している必要がありました。
システムが定着していなければ、お客様に何も届けられません。
データを扱うためには、システムが必要不可欠だからです。
最初は、開発ベンダーや、他部署の対応を待ち続けました。
しかし、待っている間も業務は止まらず、お客様への対応は続きます。
「確認中です」「対応中です」を繰り返すだけの日が続きました。
待つだけでは間に合わない。
そう判断したとき、私は行動に移していました。
誰かに指示されたわけではありません。
CS担当として顧客対応をしながら、社内の業務フローを自分で調べ、
どこで何が詰まっているのかを把握し、業務の再設計を始めました。
具体的には、進捗を可視化し、複数部署をまたぐオペレーションを基幹システム上で繋ぎ直しました。
UIとUXを根本的に見直し、ステークホルダーや開発陣と協力しながら、「対応中です」ではなく「お客様のデータはこういう状況です」「〇日後にご提供できます」と即座に説明できる状態作りを徹底しました。
あれから3年。
気づけば、CS・BPR・BizOpsを兼任している状態になっていました。
現職におけるCSは健診サービスをお客様に提供し、健康維持を支援(成功)することです。
しかし、その手段として、システム導入と定着・業務オペレーション・自社ビジネスへの深い理解が必要不可欠だったことから、現職環境においては複合的な立ち回りをしています。
1件の基幹システム刷新と、段階的な9件のクラウド移行化の中で、それを続けました。業務コストは半減し、成果物の提供精度・速度は大幅に改善しました。
もちろん、収益も結果としてついてきました。
何より、お客様や同僚の感謝の言葉が最高の報酬でした。
あなたの対応は、状況判断しやすいし、丁寧で安心感があるね。
状況をよく観察して対策をすぐに行動に移してくれるから助かっているよ。
等々。
これからの人生を「システム導入による課題解決」に捧げたいと強く考えるようになったきっかけになりました。
私は「とにかく仕組みを作ろう」と言いたいわけではありません。
「お客様の為に出来ることを考え続けよう」と偉そうに言うつもりも、ありません。
大事なのは、システムが仕組みとして成立しているか。
目の前の課題を、自分事として受け止めようとしているか。
その問いを3年間、自分自身に向けながら動いてきたからこそ、大切にしたいです。
この失敗と苦労経験を乗り越える中で生まれた想いがSaaSでカスタマーサクセスをやりたいという動機でもあります。
私は、「お客様の価値提供に向き合い続けた」経験を活かし、より多くの現場をシステム導入で仕組みを作り、ビジネスを救いたい。
この想いを持ち続けたいと思っています。
▼併せてお読みいただけると幸いです。