Zendeskを活用した社内ヘルプセンター導入と業務効率化の軌跡

こんにちは、経営企画推進部のtsuboです。

今回は、現在ピクシブで月間約600件の社員の問い合わせを処理する社内ヘルプセンター「P-ガイドポータル」を導入した背景、効果、導入後の変遷についてお話しします。

なお、今回導入したピクシブのヘルプセンターの主幹ツールには、プロダクトのヘルプツールとしてよく使われるZendeskを採用しています。

社内ヘルプセンター設立の背景

経費精算、勤怠管理、各種業務ルールの運用やオペレーションの効率化は、多くの企業やバックオフィスにとって重要な課題です。

ピクシブでは、これらの業務ルールや指針の案内について、従前バックオフィスの各部署がそれぞれ社内に周知してきました。その際、ルールに関する質問・問い合わせは、特定のSlackチャンネルやDMで自由に受け付け担当者が個別に対応するという運用が常態化していました。

しかし、ピクシブ株式会社はこの5年で急速な成長を遂げ、社員数が300名以上増えました。

結果、この5年間で加速的に社内の問い合わせや相談件数が増え、バックオフィスの個別対応コストが膨らんでいきました。200名規模の対応に最適化した当時の体制は、質問に対して担当者が都度回答やケアを行なっており、ナレッジの蓄積・共有や業務効率向上のための施策が行いづらい環境となっていました。

この状況を改善するため2022年10月に経営企画推進部が中心となり、「社内業務ルールの一元化」と「社内問い合わせ機能の集約」を目指した社内ヘルプセンターの導入を決定しました。

なお、立ち上げ当時はスピードを優先し、別のドキュメントツールにあった業務ルール関係の資料を全て洗い出し、特に精査せずZendeskに一括で移植するという強硬な移行手段を取りました。

これによる功罪は後述しますが、社内では変化が大きく社員が戸惑う声も一定聞かれました。

社内ヘルプセンター設立の目的

上記の経緯を少しまとめると、社内ヘルプセンター導入には以下の3つの主目的がありました。

社内業務ルールの一元化
- 業務ルールや事務手続きに関する情報を一つのプラットフォームに集約し、社員が必要な情報に容易にかつ速やかにアクセスできるようにしたい
社内問い合わせ対応の効率化
- バックオフィスに連絡される多種多様な問い合わせを一元管理することで、応答窓口を統一し、一人に業務量やナレッジを過密させることなく対応コストを削減・標準化したい
- 結果、バックオフィスの業務が効率化され、問い合わせ以外の業務にも集中できるようにしたい
データの利活用による社内業務ルールの改善/更新
- 問い合わせ内容や業務ルールの検索・閲覧履歴から社員の困り事や関心傾向を把握し、業務ルールの案内文やコンテンツの改善に活用したい

この目的意識は現在も変わっておらず、今もこれらの実現のために地道な改善業務を行っています。

なお、社内ヘルプセンターは当初「ピクシブヘルプセンター」と名付けましたが、後に「P-ガイドポータル」へと改称しました。これはプロダクト側の「pixivヘルプセンター」と呼称が被っており、特に口頭での説明時の誤解を防ぐためでしたが、自分たちが目指すツールについて、改めて役割や期待を整理・定義する良い機会となりました。

導入後の課題と地道な改善の軌跡

導入後の課題

前述した通り、「P-ガイドポータル」は導入直後、それまで利用していた社内ドキュメントを無理やり大量に移植した状態からスタートしました。また、問い合わせに関してはこれまで仲の良いバックオフィスの社員に気軽にSlackで質問できていたことがZendeskのリクエスト機能を利用して問い合わせる形式となりました。

これにより当初社員には「集約したい意図は理解するが、掲載されている記事も膨大でわかりづらく、リクエストも億劫で使いづらい」という意見が多くありました。

またバックオフィスの社員からも「とにかく日々リクエストが多く応答で手一杯になってしまい、記事の改善まで手が回らない」という課題も聞かれました。会社組織が急成長を遂げる過渡期だったこともあり、相互に新しいツール・運用に慣れていくことに四苦八苦する日々が続きました。

社員とバックオフィス相互が、より便利に使ってもらうために

突然ですが、私は過去プロダクトを持つ事業部にて、CSとして問い合わせ対応やプロダクトヘルプのナレッジマネジメントを行った経験がある状態で経営企画推進部に異動した経緯があります。そこで上記の課題を持ったこのツールをより便利なサービスにできるよう、CS経験を活かしていくつかの改善活動を実施しました。

今回はその中で、特に効果があったと感じた4つを紹介します。

社員アンケートの実施と要望投書窓口の常設

導入後、全社員を対象としたアンケートを実施しました。

極めて一般的な手法ですが、上記のような社内課題が明確に認知できるようになり、改善に向けた大筋を立てることができました。このアンケートでは認知度、利用状況、改善要望を収集し、この結果に基づき、UIの改善やコンテンツの見直しなど、さまざまな改修を行い、より使いやすいヘルプセンターへと進化させていきました。UI/UXの改善については現在も進行しており、追って続編の記事を出せたらと思っています。

また、アンケートという非日常な立て付けだけでなく、日々使っていて不便な事象や修正してほしい記事を発見した場合、気軽に要望を話せるSlackbotを運用しました。これにより「〇〇という情報が見つけられなかった」「〇〇という記事の内容が古い」など社員の自発的な改善要望をリアルタイムでキャッチできるようになり、改善が大きく捗りました。
業務ルール記事の閲覧傾向分析とコンテンツ整備

運用整備における最も大きな課題は、大量に移植したことにより情報が枝分かれ散逸したドキュメント群の統合と再構築でした。惨状を前に私は、移行が完了していることはポジティブに捉え、社員の閲覧傾向の分析を実施しました。

Zendeskはユーザー動向の数値把握が行いやすく、記事の閲覧数や離脱率などを細やかに算出することができます。この機能を活用し、社員が恒常的に関心を持つ業務ルールは何か、社員が検索したが記事にたどり着けなかったワードは何かなどを定常的に取得し改善に繋げました。人気の高い記事の内容は担当者と話してわかりやすく再構成したり、トップページにPICKUPとして掲載するなど、社員のニーズの高いものから改善を着手することに注力しました。
バックオフィス連携体制の構築と改善定例の実施

当時、日々増加する社員の対応にバックオフィス側は多種多様な苦労を重ねていました。

その結果、業務ルールについては前述の通り、社員からの問い合わせを応答することに手一杯で、なかなかコンテンツの整備や改善までは着手できる体制やリソースがなかったことが導入当初、大きな課題でした。

そこで、記事の体裁管理やZendeskへの反映作業は経営企画推進部にて巻き取り、各部署は制度内容や応答に集中してもらう連携体制を構築しました。不慣れなZendeskのコンテンツ入稿に全員が慣れることは一定後回しにすることを許容し、コンテンツ内容を更新したい場合、それぞれが慣れたツールで書いた資料を共有するだけで反映される状態を作りました。

これにより各部署は応答対応に力を入れることができるようになり、リクエストの処理時間が飛躍的に向上しました。また、この成果や状況を全員で認識するため、問い合わせ件数を週ごと・月ごとに集計し、共有や改善を相談する定例を実施しました。定例の場では例えば「今月はこの部署宛にこういう問い合わせが多かった、なのでこの情報は記事化して問い合わせを減らしていかないか」という提案を行い相互に改善を助け合う環境を作りました。

この定例はリリースから2年経った現在も続いており、小さな改善を日々重ねています。
社員側の立場に立った利便性の向上

前述の通り、私はもともとプロダクトを持つ事業部にいたため、社内ヘルプセンター設立時はバックオフィスへリクエストを送る側の社員でした。Zendeskでは自分が送ったリクエストに返信があるとメールで通知してくれるのですが、ピクシブでは日常的にSlackを使っており職種によってはメールチェックをする習慣がないため、メールを確認しに行かずともSlack上で気づけないものかと思った記憶があります。

その後社内ヘルプセンターの担当になり、他の社員からも同様の声が届いているのを知った私は、返信をSlackで気づくことができれば社員にとってストレスなく利用できるようになるのではないかと考え、すぐに着手しました。Zendeskのwebhookとトリガを元にZapierを経由して、返信の通知メールが届くと同時にSlackで通知する仕組みを作りました。

これにより社員はリクエストの返信にすぐに気づけるようになり、自分が送ったリクエストの結果を都度気にしなくても良い環境を作ることができました。社員からも「状況を都度チェックしに行かなくて済むので助かっている」という声を聞いています。