SaaSの導入事例では、契約を決めた理由だけを聞いても、利用を検討する人の疑問は残ります。社内へどう広げたか、誰が設定し、使わない人が出たときにどう対応したか。契約後に実際の仕事へ組み込む過程まで取材します。
便利な機能があることと、その会社で使い続けられることには、間にいくつもの判断があります。管理者と利用者の両方から話を聞くと、導入を成功という一言で片づけず、必要だった準備や工夫を伝えられます。
目次
選定時は、機能の有無より必要になった理由を聞く
「連携できることが決め手だった」と聞いたら、何と何を連携し、以前のどの作業を変えたかったのかを確認します。連携機能があるという説明だけでは、今回の顧客が選んだ理由は見えません。
比較した条件には、利用する人の操作、管理者が行う設定、既存環境との関係、移行の負担、契約条件、支援体制などが考えられます。その中で何を優先し、何は運用で補うことにしたかを聞きます。製品への評価が一律によい話より、判断の順番が分かる話のほうが、検討中の読者に役立ちます。
トライアルを行っているなら、何を確かめたかも取材します。画面を試しただけなのか、実際の業務を限定して運用したのかで、分かったことは違います。導入後に初めて気づいた点があれば、当時の選定理由と混ぜずに書きます。
データ移行と運用設計で、顧客側がした仕事を残す
導入準備では、データを移す前に項目を整理したり、部門ごとに違うルールを揃えたりする場合があります。これをすべて「スムーズに導入」とまとめると、読者は必要な準備を見落とします。どの作業を自社で行い、どこを支援してもらったかを分けます。
権限や管理者の役割も、今回の運用を理解する材料になります。ただし、具体的な設定や構成をどこまで公開できるかは、取材先へ確認します。公開できない部分を無理に細かくせず、業務上の責任分担として説明する方法もあります。
準備を具体的に聞く質問
「使い始める前に、社内で揃えたルールはありましたか」「以前のデータで、そのまま移せなかったものはありましたか」「管理者が日々確認する仕事は何ですか」「外部の支援が必要だったのは、どの段階でしたか」
社内への定着を、利用者の行動で確かめる
アカウントを発行した人数と、仕事で使っている人数は同じとは限りません。利用人数を掲載する場合は、何を利用と数えているか、どの時点の記録かを確認します。数字だけで定着したと判断せず、どの仕事で日常的に使われているかを聞きます。
説明会や手順書を用意したなら、その存在だけでなく、どんな質問が出たか、誰が対応したか、説明をどう直したかを取材します。使われなかった機能や、従来の方法を残した業務も、同じ条件の読者には参考になる場合があります。
管理者は運用の統一を評価し、利用者は入力の負担が減ったことを評価するかもしれません。評価が違う場合、どちらかに揃えず、役割によって得た変化が違うことを説明します。
成果は、対象業務と運用の変更を一緒に示す
時間短縮を掲載するなら、入力、承認、集計、問い合わせ対応のどこが変わったかを確認します。以前と比べた対象件数、担当者、期間も揃えます。システムの導入と同時に社内ルールを変えているなら、その仕事も成果の背景へ含めます。
数値がない場合は、作業の引き継ぎ、確認する情報の所在、担当者不在時の対応などを聞きます。「属人化が解消」と言い切る前に、誰がどこまで対応できるようになったかを具体的に書きます。
他部門へ利用を広げた場合も、最初の部署と同じ方法がそのまま通用したかを聞きます。業務が違って設定を変えた、説明の担当を置いたなど、広げる際の工夫を残すと、単なる利用拡大の報告から一歩進んだ記事になります。
公開後は、製品と利用状況の変化を点検する
SaaSでは機能や画面、プランが変わることがあります。事例の説明が取材当時のものか、現在の提供内容を案内しているのかが分かるようにします。更新日だけを新しくして、古い画面や条件をそのまま載せないようにします。
顧客側の体制や利用範囲も変化します。続編を作るなら、前回から何が進み、どの期待が実際の運用になったかを聞けます。製品の変化だけを追うのでなく、顧客が仕事へどう組み込んでいるかを主題に戻して更新します。
外部への依頼を検討している方は、導入事例制作のサービス内容をご覧ください。