Gemini でチケットデータから四半期 SLA サービスレビューを起草する方法

結論から言うと：Gemini は四半期分のヘルプデスクのチケットエクスポートと CSAT の回答を読み込み、サービスレビューの叙述——傾向、外れ値、そして本当に議論すべき具体的な事柄——を約一時間で下書きできます。得られるのは、自社ベンダーの数字に対する独立した読みです。サービスが実際に良いかどうかは教えてくれません。

月次サービスレポートは契約どおり第八営業日に届きます。九ページ、冒頭は緑のダッシュボード、そして 220 名の企業の IT マネージャーは二ページ目より先を読まずにフォルダへ転送します。それが三つたまると、カレンダーに四半期サービスレビューが現れます。

レビューでは、アカウントマネージャーが同じ数字を同じ緑で提示し、全員がサービスは問題ないと合意し、会議は早く終わります。二週間後、財務責任者が「ヘルプデスクが遅く感じる」のはなぜかと尋ねますが、その問いに答える文書はどこにも存在しません。

本当の答えの原材料は存在します。ManageEngine ServiceDesk Plus、Freshservice、Jira Service Management、Zendesk のいずれかにチケットエクスポートとして、そして CSAT メールを送っているツールの中に。欠けているのは、三か月分の行を「視点のある物語」に変える数時間の表計算作業です。

そここそモデルに任せる価値のある部分です。サービスが良いかどうかの判断ではなく、その判断を可能にするデータの読みのほうです。

月次 SLA レポートが積み上がるだけで、本当の会話にならない理由

月次 SLA レポートはコンプライアンスの成果物です。契約上のしきい値が満たされたことを示すために存在し、測定される側が書いています。この二つが形を決めます。契約の目標に対して報告し、しかも取りうる中で最も擁護しやすい形で報告するのです。

そこに不誠実さはありません。しかし「P2 解決 SLA 達成率 97.4%」はしきい値についての記述であって、チケットを起票する人々の体験についての記述ではありません。P3 解決時間の中央値が倍になっても、緩いしきい値の内側にとどまっていれば、全ページが緑で表示されます。

レポートは月次で届き月次で読まれますが、それは何かに気づくには合わない周期です。傾向は四半期の尺度で生きています。単月では、三月以降ずっと同じ五人が全チケットの四割を起票していることも、人員変更以降に月曜朝の待ち時間が十一分伸びたことも見えません。

そのため、本来これが表面化すべき四半期レビューは、ベンダー自身の資料で始まります。顧客側に別の読みを用意した人がいないからです。会議は既定でベンダーの枠組みの中で進み、それは誰のせいでもなく全員の問題です。

Gemini がチケットと CSAT のエクスポートで実際にできること

Gemini は Google Sheets のサイドパネル経由で表計算データを扱え、Gemini アプリではファイルをアップロードして扱えます。どの機能が使えるか、ファイルサイズの上限がいくつかは Workspace のプランによって異なり、内容も変わります。契約中のプランの最新ドキュメントを確認してください。ここで重要な能力は地味です。数千行を丁寧に読み、何が変わったかを記述することです。

一時間を投じる価値のある出力が二つあります。

応答・解決時間の表を傾向の叙述に変える

三か月分のチケット行——作成、初回応答、解決、優先度、カテゴリ、起票部門——を与えると、当然の集計値を計算し、さらに有用なことに、その段落を書き上げます。「初回応答の中央値は 14 分で横ばい。P3 解決の中央値は四月の 4.2 時間から六月の 7.8 時間へ上昇し、主にソフトウェア導入カテゴリが要因」。

この一文こそサービスレビューが本当に必要としているものであり、そしてほぼ書かれることのないものです。書くには誰かがピボットテーブルの前に二時間座り、そのうえで散文として意見を形にする必要があるからです。

比較は明示的に求めてください。今四半期対前四半期、データがあれば前年同期も。基準のない叙述は、形容詞に囲まれた数字にすぎません。

レビューの場で実際に取り上げるべきチケットとパターンを洗い出す

二つ目の出力は短いリストです。最も長期化しているチケット十件、二回以上再オープンされたチケットすべて、件数が四分の一以上増えたカテゴリすべて、そして三点以下の CSAT 回答をすべて自由記述コメント付きで抽出させます。

そのリストがあなたの議題です。レビューを「SLA を満たしているか」から「実際に起きたこの十一件について、どうするか」へ変えます。後者こそサービスを本当に改善する会話であり、やましいところのない提供者ならたいてい歓迎する会話です。

実践的なワークフロー——CSV エクスポートからレビュー用ドラフトへ

1. レポートではなく生のエクスポートをもらう。MSP または自社のヘルプデスク管理者に、四半期分のチケット単位 CSV を依頼します。タイムスタンプ、優先度、カテゴリ、起票部門、対応記録を含めて。契約でこれが権利として保証されていないなら、次の更新の前に把握しておく価値があります。要求として妥当であり、断るには具合の悪い類のものです。

2. 自社環境から出すべきでないものを除去する。起票者の氏名とメールアドレス、対応記録の中でパスワードや内部パスに見えるもの、そして自社の顧客名が入った自由記述。氏名を部門ラベルに置き換えれば、必要な分析はすべて残り、リスクの大半は消えます。

3. 計算はプロンプトではなく表計算側でやる。派生列は自分で追加します——初回応答までの時間、解決までの時間、違反の有無、週番号。四千行にわたって二つのタイムスタンプから計算させるより、すでにセルにある数字を記述させるほうがはるかに信頼できます。

4. まず基準を名指しした傾向の段落を求める。「Q2 と Q1 を、初回応答の中央値、優先度別解決時間の中央値、カテゴリ別件数、再オープン率で比較。四段落で記述。使用した数値を明示すること」。この「数値を明示」という指示が重要な半分です。検証を可能にするのはそこだからです。

5. 例外リストは別のパスとして求める。最長のチケット、繰り返しの再オープン、伸びの大きいカテゴリ、コメント付きの低評価 CSAT。チケット ID を伴う番号付きリストにしておけば、会議中に数秒で参照できます。

6. 残り三十の数字を信じる前に、三つを手で確かめる。叙述から数値を選び、シートと突き合わせます。三つとも正しければ手法は機能しています。一つでも誤っていれば叙述は使えず、それは会議中ではなく会議前に知る必要があります。

7. 解釈は自分で書く。モデルはソフトウェア導入カテゴリで解決時間が伸びたと言えます。同じ四半期に調達がノート PC の機種を変え、新しい端末すべてに追加で三本のアプリが必要になったことを知っているのはあなただけです。その一文があなたの付加価値であり、データの中にはありません。

8. 議題は会議の三日前に送る。具体的な質問を一ページ、事前に送るだけで会議は一変します。ベンダーは同じ十一件をすでに調べたうえで現れ、その一時間はダッシュボードではなく原因に費やされます。

AI が下書きした四半期レビュー叙述 vs ベンダーが書くサービスレビュー vs 正式なレビューなし

• 自社データから AI が下書きした叙述。ベンダーの枠組みから独立し、毎四半期繰り返せるほど安価で、夕方六時の疲れた人間にはできない網羅性があります。自社のビジネス文脈を持たず、統計的な偶然を平然と傾向として記述し、ある数字が許容範囲かどうかを判断できません。正しい使い方は、会議の準備としてであって、会議の結論としてではありません。
• ベンダーが書くサービスレビュー。環境も経緯も、あのチケットが九日かかった理由も知っている人たちが用意します。その知識は本物で、持つ価値があります。同時に、評価される側が、自ら設定に関与したしきい値に対して書いています。特定の提供者への批判ではなく、補正する価値のある構造的事実です。
• 正式なレビューなし。従業員三百人未満の企業で最も一般的な形です。サービス品質は感覚で、たいていインシデントの直後に評価され、その会話は更新時期に起きます。交渉力が最も高く、善意が最も低い瞬間です。

機能する組み合わせは前の二つの併用です。ベンダーが文脈を持ち込み、あなたが独立した読みを持ち込む。会議は一つではなく二つの情報源を持つことになります。

物語を取り違える場面

CSAT は生存者バイアスのかかった標本でありながら、全数調査のように読めてしまいます。アンケートに答えるのは、非常に満足した人と激怒した人です。平均が上がるのは、しばしば「少し不満だった人」が返信をやめたことを意味します。CSAT だけに基づく叙述は、組織の中間層——つまり大多数——について自信満々に誤ります。

見出しの指標が、それが測っているはずの失敗を隠せます。三千件で九十八パーセントの達成率でも、違反は六十件残ります。そのうち五十件が月次決算週の経理チームに属していれば、深刻な問題と緑のダッシュボードが同時に成立します。違反は必ず部門別・週別に分解して求めてください。

傾向と組織変更を区別できません。チケット件数が三割減るのは改善に見えますが、うんざりした部門が起票をやめて誰かの携帯に直接電話し始めた可能性も同じくらいあります。データに影のキューは見えません。あなたには見えます。

対応記録はチケットを閉じるために書かれ、現実を記述するために書かれてはいません。「解決、利用者に案内済み」は、本当の修復から肩をすくめただけまでを覆います。四半期分の対応記録を読んだモデルが出す要約は、打ち込まれた文字には忠実で、実際に起きたことには不誠実です。

これを正しくやるために——チケットデータの機微性、ベンダーの客観性、そして IT を呼ぶべきとき

チケットエクスポートは見た目よりずっと機微です。対応記録にはサーバー名、共有パス、アプリのバージョン、本来打ち込まれるべきでなかった資格情報、そして自社のどのシステムが脆いかの率直な記録が入っています。このファイルはネットワーク構成図と同じ扱いにしてください。

判断ではなくルールでサニタイズする。起票者の氏名とメールの列を落とし、自由記述を資格情報らしき文字列で走査する——この常設の前処理は、忙しい四半期を生き延びます。「気をつけるつもり」は生き延びません。

データを入れる前にツールの条件を把握する。個人向け、ビジネス、エンタープライズの各階層は保持と学習利用の可否が異なり、条件も変わります。契約中のプランの最新ドキュメントを確認し、どのツールが運用データを受け取ってよいかを全社ルールとして一つ定めてください。レビューをたまたま準備している人の裁量に任せてはいけません。

独立した読みを持ってベンダーレビューに臨むのは健全であり、公然と行うべきです。やっていることを提供者に伝えてください。自前の分析を持って現れる顧客を歓迎する提供者は、その働き方について有用なことを教えてくれています。歓迎しない提供者も同様です。

運用レポートの中で AI をどこに置くかを決め、再現可能にするプロンプトとサニタイズ規則を書くのは AI+ サポートの仕事です。その下にある測定の枠組み——定義された応答・解決目標、月次レポート、CSAT の収集、そして本当に会話になる四半期サービスレビュー——が当社の SLA と品質フレームワークであり、それが測る提供そのものがマネージド IT サポートです。他の表計算エクスポートから同種の叙述を組み立てるなら、Google Sheets で月次売上レポートを自動化する方法とヘルプデスクのチケット返信を下書きする方法が隣接する問題を扱っています。

よくある質問

自社ベンダーの実績についての AI の要約を信頼できますか？

渡したデータに対する読みとして信頼し、どの数字に依拠する前にも三つを手で検証してください。ベンダーのレポートに対する優位は正確さではなく独立性です。契約に書かれたしきい値ではなく、あなたが立てた問いに対してエクスポートを記述します。その数字が許容できるかどうかの判断は、あなたの側に残ります。

MSP が生のチケットエクスポートを出してくれない場合は？

書面で依頼し、回答を記録してください。自社の利用者と自社のシステムに関するチケット単位のデータを顧客が保持するのは妥当であり、多くの提供者は難なく CSV を出します。拒否それ自体は何かの証明にはなりませんが一つの材料であり、次の更新こそ、その依頼を明示的な契約上の権利に変える機会です。

すでにベンダーが送ってくるレポートと何が違うのですか？

書き手が違い、問いが違います。先方のレポートは「合意したしきい値を満たしたか」に答えます。契約が発する問いです。あなたのものは「この四半期に何が変わり、どうすべきか」に答えます。事業が発する問いです。どちらも正当で、現状書かれているのは片方だけです。

どのヘルプデスクツールのデータでも使えますか？

チケット単位で CSV をエクスポートできるツールならすべて、つまり事実上すべてです——ServiceDesk Plus、Freshservice、Jira Service Management、Zendesk、Halo。列名は異なりますが、派生列を追加する手間はどこでも同じです。ツールの違いよりはるかに大きいのはチケット分類の規律です。半分が「その他」で登録されていれば、どんな分析でも救えません。

最初の一回にどれくらいかかりますか？

おおむね午前中いっぱいで、その大半はプロンプトではなく表計算の準備です。以降の四半期は約一時間です。エクスポート、派生列、プロンプトがすべて再利用できるからです。会議へ向かう道すがらベンダーの資料をめくるのと比べれば確かに工数の増加ですが、これがサービスに対して誰かが持つ唯一の独立した視点である、という点がその正当性です。