ヘルプデスク・チケットシステムの作り方：チケット、ステータス、担当割り当て、メール

ヘルプデスク・チケットシステムは、メール、メッセージ、廊下での「ちょっと質問」などの散らばった依頼を、チケットに変えます。チケットは問題一件ごとに一つの記録で、担当者、ステータス、優先度、会話の全体を持ちます。作るには、チケットを作る手段、ステータスと絞り込みを備えた共有のキュー、担当の割り当て、公開返信と社内メモを区別するスレッド、そして誰も待たされないための通知が必要です。AI アプリビルダーなら、社内のIT、人事、総務の窓口向けの堅実な初期版を一日で作れます。一方、メールのスレッド化、応答目標、レポートを備えた顧客向けサポートは、より慎重な作り込みが必要で、そこが専用のヘルプデスク製品が費用に見合う場面です。

システムに必要なもの

データ

最初の返信と解決の日時を最初から保存してください。 すべてのレポートがこれに基づくため、後から再構築することはできません。

ページ

• 依頼者向け： カテゴリと添付ファイル付きの「依頼を送る」フォーム、「自分の依頼」の一覧、各チケットのスレッド。
• 担当者向け： キュー（自分のチケット、担当者未定、すべての未完了）、絞り込みと検索、返信、メモ、ステータス、優先度、担当者を操作できるチケット画面。
• 管理者向け： カテゴリ、チーム、担当者、定型文、簡単なレポート。

権限

依頼者は自分のチケットと公開の返信だけを見られます。担当者は所属チームのチケットと社内メモを見られます。リーダーと管理者はすべてを見られ、設定を管理します。社内メモが顧客に漏れることは、ヘルプデスクでの典型的な大失敗です。タブを隠すだけでなく、サーバー側で強制してください。役割ベースのアクセス制御をご覧ください。

決めること・トレードオフ

フォームか、メールか、両方か

Web フォーム は最もシンプルで、カテゴリ、優先度、必須項目によってきれいなデータが得られます。メールでの受付（support@ 宛てにメールすると、チケットが作られる）は顧客が期待する方式ですが、メッセージを受信してアプリに送れるメールサービスと、返信を正しいチケットにまとめるスレッド化（通常は件名のチケット番号か、一意の返信先アドレス）が必要です。まずはフォームで始め、流れが固まってからメールを追加しましょう。送信側はアプリからメールを送る方法で扱っています。

割り当て

選択肢は、担当者が担当者未定のキューから選ぶ、チーム内でラウンドロビンに割り振る、またはカテゴリで割り当てる、の三つです。小さなチームなら、キューから選ぶ方式で十分です。チケットが誰にも担当されないまま残るようになったら、自動割り当てが役立ちます。

優先度と応答目標

優先度は二、三段階にし、最初の返信の目標を決めます（「緊急：1時間、通常：営業日1日」など）。残り時間を各チケットに表示するほうが、誰も読まない月次レポートよりも役立ちます。営業時間で計算すると計算が複雑になるので、夜間と週末を目標に含めるかは早めに決めておきましょう。

統合と重複

同じ問題が三回報告されるのは珍しくありません。「このチケット番号に統合」の操作があれば、担当者が同じ回答を繰り返さずに済みます。早めに作る価値があります。

うまくいく最初のプロンプト

60人規模の会社向けの社内 IT ヘルプデスクを作ってください。社員はフォームで依頼を送ります。件名、カテゴリ（ハードウェア、ソフトウェア、アクセス権、ネットワーク、その他）、優先度（低、通常、緊急）、説明、添付ファイルを入力します。各チケットには番号が付き、ステータスは「新規」「対応中」「依頼者の返答待ち」「解決」「クローズ」です。IT の担当者は、担当者未定、自分の担当、すべての未完了のタブがあるキューを見られ、カテゴリ、優先度、ステータスで絞り込み、検索できます。チケットのページには、公開返信と社内メモをはっきり分けたスレッドを表示し、社員には社内メモが決して見えないようにしてください。担当者は、担当の割り当て、ステータスと優先度の変更、定型文の利用、重複の統合ができます。最初の返信と解決までの時間を記録し、各チケットに最後の更新からの経過時間を表示してください。社員には「自分の依頼」ページを用意します。役割は、社員、担当者、管理者です。すべてデータベースに保存します。装飾よりも速さを重視した、シンプルで情報の詰まったインターフェースにしてください。

構築のステップ

1. チケットのモデルとフォーム。 送信、一覧、チケットを開く、返信ができるようにします。
2. キューと絞り込み。 担当者未定、自分の担当、すべての未完了。絞り込み、検索、優先度と経過時間での並べ替え。
3. 役割とログイン。 依頼者、担当者、管理者。社内メモは依頼者からサーバー側で隠します。
4. 担当、ステータス、優先度の操作。 すべての変更を操作ログに残します。
5. 通知。 公開返信があったら依頼者にメールを、新しい担当割り当てがあったら担当者に、自分のメールサービスを通して送ります。
6. 定型文と統合。
7. 応答目標と簡単なレポート。 経過時間ごとの未完了チケット、最初の返信までの時間、カテゴリごとのチケット数。
8. メールでの受付。 他の機能が動いてから、スレッド化を入念にテストして追加します。
9. 一つのチームで二週間試験運用。 全員に切り替える前に行います。

よくある失敗

• 社内メモが依頼者に見える。 画面でだけ隠していたためです。
• ステータスやカテゴリが多すぎる。 担当者は、近そうなものを最初に選んでしまいます。それぞれ最大五つから始めましょう。
• 最初の返信と解決の時間を記録していない。 「対応は速くなっているか」と聞かれた日に、数字が欲しくなります。
• メールの返信が、スレッド化されず新しいチケットを作る。 スマートフォンのメールアプリから返信してテストしてください。件名が変わってしまうことがよくあります。
• 全員が割り当てられ、誰も責任を持たない。 チケットの担当者は一人にし、その他の人は「ウォッチャー」として追加します。
• 公開 URL の添付ファイル。 エラーメッセージのスクリーンショットには、個人情報が含まれることがよくあります。ファイルは非公開にし、そのチケットを見られる人にだけ配信してください。

既製の製品のほうが良い場合

メール、チャット、ソーシャルメディアにまたがる顧客向けサポートで、応答目標の追跡、満足度調査、マクロ、レポート、連携を備えるなら、専用のヘルプデスク製品がほぼ常に良い投資です。こうした製品は、メールのスレッド化、スパム、振り分け、レポートに何年もかけてきました。それは、あなたのビジネスを特徴づける部分ではないはずです。Zendesk の代替サービスのガイドで選択肢を比較しています。

自作が適しているのは、社内の窓口（IT、人事、総務、経理の依頼）、チケットが実際には固有の手順を持つ仕事である特殊なワークフロー、そして依頼を既存のデータと結びつけたいチームです。多くの人が時々チケットを扱う場合に、担当者ごとの料金を避けられるという利点もあります。より広いカテゴリについては社内ツールの作り方で扱っています。

Mythex での構築

Mythex では、ヘルプデスクをチャットで説明し、ライブプレビューで確認して、チームに公開します。チケットは、データの保存が必要になったときにエージェントが追加する Postgres データベースに保存され、添付ファイルはプロジェクトのファイルストレージに入ります。依頼者と担当者のログイン、メールの送受信には、自分のプロバイダーを使います。Mythex には、エンドユーザー向けのログインやメールの組み込みサービスはありません。メール送信のレシピでその方法を紹介しています。チームメンバーは共有のワークスペースで開発に参加でき、Mythex 自体には座席ごとの料金はかかりません。

開始用のプロンプトには、社内依頼キューやバグトラッカーのテンプレートを使ってください。ヘルプデスクにはナレッジベースを組み合わせると、よくある質問は自分で解決されるようになります。

よくある質問