はじめに
電話が鳴る。ワンコールで取る。お客様からの問い合わせ。それは楽園の終わりを告げる鐘！開発に没頭していた開発者が突然現実に引き戻され、顧客のなぞかけのような障害レポートからシステムに発生している不具合の原因を探す旅に出る合図である。
スタートアップがソフトウェア・ビジネスを立ち上げる場合は、極めて少人数のメンバーで開発と運用、カスタマーサポートまで対応することになる。圧倒的な仕事量の前に立ち尽くすメンバーたちにとって、一番負担感が高い業務は何か？本番障害？いや本番障害は楽しい。正解はカスタマーサポートである。作業に集中している開発者のアテンションを奪い、障害の内容によっては罵倒され開発者特有の豆腐メンタルをバキバキに叩き折り、平身低頭謝るもなぜか神経を逆撫でしてしまい、高まりすぎたお客様の温度感は収まることを知らない。カスタマーサポートをやった人間であれば誰しも経験することだろう。
カスタマーサポートの負担はツールを使用すればなくせるか？残念ながら完全になくすことは不可能だ。お客様は人間であり、人類が到達した最先端のチャット AI である ChatGPT でもいまだ我々の製品に対する完璧なサポートを提供することはできない。しかしJira Service Management と Slack を上手に使えば、かなり低減することができる。その方法について説明したい。
カスタマーサポートを楽にする方法
結論から言えば次のようにすれば楽になる。
- Jira Service Management を導入してカスタマーには必ずサービスデスクポータルを通して起票してもらう
- Slack と連携し、カスタマーから投稿があればサポート専用のチャンネルに通知を飛ばす
- 通知を受けたら対応について Slack のスレッドで議論し、サービスデスクポータルを通して返信する
言うのは簡単だが、これを実行するのは難しい。お客様はサービスデスクポータルを利用するより電話やメールの方が問い合わせしやすいからである。Jira を使ってもらうためにはライセンスや利用規約に問い合わせ手段として Jira の使用を強制できる条件を入れて契約時にていねいに説明するなどの努力が必要になる。しかし、一度 Jira で問い合わせがくる状況を実現してしまえば極めて楽になる。どのように楽になるかと言うと、
- これまで電話やメール、FAX といった様々なチャンネルで来ていた問い合わせがカスタマーポータルに集約され、今どのような問い合わせがあり何に答えなければいけないのか一目瞭然。お客様とも過去の対応状況や課題のステータスが共有できる。
- Slack で通知が来るので出先のスマホでも簡単にチェックできる。対応について議論が必要であればスレッドを開始して仲間と議論し、方針が決まれば OK リアクションをつけてレビュー完了。デスクに座っている人からお客様に返信してもらう。
特に一番目の恩恵が非常に大きい。カスタマーサポートはやり取りした当事者で情報がクローズしがちであるのをオープンに共有できるため、お客様の担当が変わっても過去のやり取りを履歴できる。今後、過去の経緯に起因する特殊なトラブルがあっても説明がしやすい。サポート担当者も自分ひとりで抱え込まずにグループで対応できるため、負担感は大幅に軽減される。
以上がカスタマーサポートを楽にするためのポイントだ。ここからは少し細かい話をしていく。
保守・保守・保守
Jira Service Management に取り組む上で、法人がお客様である場合、カスタマーにグループを設定できるので利用する。担当者がコロコロ変わる場合でも過去の問い合わせ履歴を共有するためにはこのグループを設定して問い合わせ内容を引き継げるようにする。
サービスデスクポータルを用意していても、電話やメールで問い合わせがくるケースがある。その場合は、要件をとりまとめ、お客様の代理で課題を起票する。Jira にはそのような機能がある。電話やメールで問い合わせがきてもそのまま返さずにサービスデスクポータルから返すことで、応答の履歴が残るし、次回から電話やメールで問い合わせてくる確率を少しでも減らすことができる。
プロキシに阻まれてサービスデスクポータルにアクセスできないお客様がいるケース。この場合はライセンスや利用規約を盾にプロキシの設定を変更するように依頼するが、どうしてもダメな場合はメールで課題を発行できる機能が Jira にあるので利用する。お客様は所定のメールアドレスにメールを送ることで課題を操作できるし、我々は Web インターフェースで課題に返信することでお客様にメールが届く。
Jira Service Management で受けた問い合わせで、ソフトウェアの修正が必要なものがあれば Jira Software の課題を発行する。Jira Software から Bitbucket のブランチを作成し、Bitbucket のブランチからプルリクを作成する。Bitbucket でプルリクをマージすると、今度はさっきとは逆の流れで Jira Software、Jira Service Management と変更が通知されカスタマーへの返信の準備が完了したことが Slack に通知される。これも便利な機能。
Confluence と Jira Service Management を紐づけることで、お客様用 Wiki を開設することができる。いわゆる FAQ といった内容は Confluence に記載するだけで公開できるので問い合わせの数そのものを減らしたり、課題に回答するときに引用先として示すことができる。
法人向けではなくコンシューマ向けのサポートを提供する場合は、Jira では問い合わせに必要なリテラシーが高すぎるため Zendesk の導入を検討する。Jira は課題管理システムであり、利用者は自分の課題を文章にまとめて報告しなければならないが、コンシューマだとこれはハードルが高い。電話やチャットで問い合わせをサポートして、それを課題の形に自動で落とし込むことができる。逆に言えば利用者が自分で課題を登録できるレベルであれば Jira だけで十分である。
おわりに
かつて電話とメールのみで複数の法人カスタマーに対して保守サービスをひとりで提供していました。当時は障害管理票というExcelファイルをメンテしながら PPAP で暗号化しパスワードを手動で送るという正気の沙汰ではない運用をしておりましたが、あまりにも非効率的だったので Jira や Slack といった各種ツールを導入して改善をしました。いまでは日中に担当者ひとりで放置されても保守をワンオペでやれるくらいには効率化しており、カスタマーサポートの苦しみを大幅に軽減することに成功しています