背景
トレジャーデータのテクニカルサポートでは、問い合わせ対応・不具合調査・クエリパフォーマンス改善・ドキュメンテーション追加などトレジャーデータに関わる困ったことを何でもサポートしている。 そこでサポートを通して、より良いサービスを提供できるように、サポートの活動状況・問い合わせ傾向などを知ることが必要になる。
そのため、サポートのKPIダッシュボードを種々用意し、KPIを元にデータドリブンより良いサポートを提供できるようにするための取り組みを進めている。 また、サポートのためだけでなく、エンジニア・セールス・プロダクトなどそれぞれのチームに合わせたサポートKPIダッシュボードを用意することでより良い効果が得られると考え、種々取り組みを行なっている。
ざっくりと下記のようなことを実現できると良いと考えている。
- エンジニアのチケットエスカレーション数を見て、特にエスカレーションが多い機能については、サポートで調査範囲などを増やせるようにするための施策をする。
- 顧客のサポート状況を知り、何か問題がありそうであれば、セールス/Sales Engineerチームからも集中的なフォローをする。
- 問い合わせの傾向をみて、どこを改善することで、問い合わせ自体を減らすことができるかをプロダクトチームにフィードバックする。
- サポートの活動状況を見て、サポート自体の課題を見つけ、改善をしていく。
一方で、サポートを円滑に行うために種々のSaaSを利用しているため、Zendeskのレポートの機能であるZendesk Exploreだけでは十分な可視化ができないという課題があった。 チケット管理やアカウント情報の確認のために、主に下記のサービスを使っている。
- Zendesk: サポートセンタ（メール・チャット）
- Jira: バグチケット / 調査チケット管理
- Salesforce: 顧客情報管理
- TreasureData: サービスログ
そこで、トレジャーデータのサポートでは、トレジャーデータのDataConnectorの機能などを利用して、トレジャーデータ上に全てのデータを集めて、Chartio上にてレポーティングを行なっている。
- DataConnector for Zendesk https://docs.treasuredata.com/articles/data-connector-zendesk
- DataConnector for Salesforce https://docs.treasuredata.com/articles/data-connector-salesforce
- Chartio https://docs.treasuredata.com/articles/chartio
KPIダッシュボード例
サポート向け
サポート全体の見える化として、四半期ごとのダッシュボードとしては下図を作成している。 特にエンジニアへのエスカレーション（仕様確認や不具合調査やオペレーション依頼など種々の内容が含まれている）を減らすことと、1週間以内でのチケット解決率を高くすることを現在は目指している。
根本の目的としては、お客さんの期待する返信時間を満たし、サポートへの信頼度を高めることを目指すことにあるのだが、 それを表す明確なKPIを算出することが難しいので、上記などを通過点として定めている。
例えば、お客さんの期待する返信時間を満たしているか、というのを表せればいいのだけれども、SLAといったものはあくまでも一次回答時間でそれはほぼ満たせている。 しかし本当に大事なのは、お客さんが困っている時にいつまでに回答します。とかそういうアップデートを定期的にするということで、それを表す指標というのは難しい。 顧客の返信待ち時間というのは出しているが、緊急の時は高頻度で欲しいし、そうでないときは数日おきでもいいし、というのがあるのでそういう区別はまだあまりうまくできていない。 （あとあまり返信時間のルールをガチガチに縛り、プレッシャーを与えるとサポートするのが辛くなってくるので、というのもある）
また、Engineerへのエスカレーションが低いということは、サポート内で素早く解決できることが増えているはずだし、 1週間以内でのチケット解決が高いということは、それだけお客さんを待たせずに問題を解決できていることに繋がるからである。 また、これらを実現するために、Zendeskにはルール付けやフィルタを設定し、定期的にチェックする形で進めている。
そのほかにも、MonthlyやWeekly用で別途種々の指標を持ったダッシュボードも準備している。
セールス向け
例えば、セールスに定期的に提供するダッシュボードとしては下図のようなものがある。 ここでは、それぞれのセールス毎に担当する顧客のサポート状況を把握するための情報が表示されている。
- チケット数
- 顧客毎のチケット数
- NPS Score (NPSについてはWootricを利用している。https://www.wootric.com/)
- 問い合わせ方法
- 問い合わせのエスカレーション先
- 問い合わせカテゴリ
- など。
例えば、エンジニアへのJira Escalationが多い場合は、何らかの不具合やサポートでは判断が難しい事象の調査などを多いことになったりするし、 自分の知らないIntegrationの問い合わせが多く来ていれば、お客さんが今までとは違う何か新しい取り組みをしているのかもしれない、など想像することができる。
これらがベストではなく、どういう項目があるとセールスが見たときに、このお客さんの状況を確認した方がよいかな？というのを察しやすくできるように、継続して改善をしている。
つらつらと、トレジャーデータのサポートのKPIに関して書いてみた。 サポートというのは、一般的にあまり日の目を見ることがない不人気なイメージではあるが、B2BのSaaSの場合には知識としてソリューションアーキテクトと同じような能力が必要だし、 Customer SuccessやSalesと協力しながら色々仕事を進めるので意外と楽しい職種だと思う。
現在、サポートエンジニアを絶賛募集中なので興味がある方は、@nora96oまでご連絡を。 https://jobs.lever.co/treasure-data?team=Engineering
