KCS 記事の作成というのがFY23大きな目標になっている。

Knowledge-centered service—also known as knowledge-centered support or KCS—is when support teams not only provide real-time customer, system, or employee support, but also create and maintain documentation as part of the same process.

『この問題はこのように解決出来ました』という手順を記した記事を作り、顧客・パートナーがアクセス出来るデーターベースにパブリッシュする。”Knowledge Driven”な製品仕様書とは違い、こちらは”Issue Driven”なのが大きな違い。解決したい問題があってサポートに連絡してくるというフローを考えると、その問題解決に必要な知識を仕様書で探すよりも、直面している問題から逆引きで解決策を探せる”KCS”は顧客やパートナーにとってきっと便利なんだろう。

この間あったグローバルのミーティングでDirectorが話していた。Customers reach out to us because they want to solve their issues that they are facing, but they don’t want to bother reaching out to us if they can solve the issues by themself. よく分かる。いちいちケースを起票をして現状を説明してコミュニケーションをとるのって凄い精神的・物理的なコストがかかる。めんどい。Financial Planning appなんて特にそうだ。Csat(顧客満足度)がCX部署全体の一番大きなOKR指標になっていて、KCSはその目標達成に必要なのは凄いよく分かる。なんの異論もない。

いちアナリストとして思うこと。そもそも、このCustomer Facingな記事を作るのって想像以上にとても大変。Ineternal向けな記事だったら多少間違いがあってもいいけれども、外部向けとなるとそうもいいかない。正しい英文法・テンプレートで記事を書いて、内容の整合性を確認・テストして、わかりやすくするためにスクリーンショットを貼り付けて。ひとつの記事を作成するのに３０分から１時間。これを日常的なサブタスクとしてこなしてかなければいけないのだから、時間的にも労力的にもとても大変。休日使って書いたりしている。記事数自体がKPIに盛り込まれているからやらないわけにはいかない。

KCSが充実してくるに伴い起票されるケース数が減少、Headcountが必要なくなり首を切られる、ということにはならないのだろうか。とある記事によると、10% fewer reported issues/support requestsの効用が確認されたらしい。顧客満足度が上がり、なおかつWorkloadが減りHeadcountを減らせるのであればそれはもうマネジメント目線では大成功なんだろう。けどアナリストの立場はどうなの。

最終的に自分たちを殺しにくるかもしれない”集合知”をアナリスト皆で身を削りながら必死に育てているのってちょっとおもしろい。