問い合わせ・サポートチケット管理
公開フォームから入った質問や要望を、担当者・状態・履歴つきで管理する実例です。
問い合わせをメールや個人チャットだけで受けていると、誰が対応中なのか、返答済みなのか、過去に何を伝えたのかが見えにくくなります。このページはRoundtableに最初から入っている機能ではなく、下のプロンプトをCodexに貼り付けて、問い合わせ対応を共有管理する業務システムのたたき台を作るためのコピー用サンプルです。
概要
公開問い合わせフォームから質問や要望を受け付け、管理側ではチケット一覧、担当者割当、対応状態、コメント履歴、未対応通知をまとめて確認できる構成です。まずはFBPの標準画面を中心に作り、問い合わせが担当者の記憶や個別メールボックスに閉じない状態を作ります。
こんな会社におすすめ
問い合わせ対応を属人化させたくない
担当者、状態、期限、履歴を一覧で共有し、個人だけが状況を知っている状態を減らしたい会社に向いています。
返答漏れを防ぎたい
未対応、確認中、返信済み、完了などの状態を見える化し、放置されている問い合わせを見つけやすくします。
要望や不具合を蓄積したい
問い合わせ内容を分類し、機能要望、不具合、質問、契約相談などを後から振り返れるようにします。
コピーして使えるプロンプト
そのままCodexに貼り付けて、部署名、問い合わせ分類、通知先、権限名だけを自社向けに調整して使う想定です。顧客固有情報や秘密情報は入れず、まずは業務の型だけを伝えます。
コピー用プロンプト
公開フォームから入った問い合わせを管理側で対応できる、問い合わせ・サポートチケット管理システムのたたき台を作ってください。
目的は、質問、要望、不具合報告、契約相談などの問い合わせを1件ずつチケットとして受け付け、担当者、状態、対応履歴、期限、通知を共有して、返答漏れと属人化を減らすことです。まずはFBPのStandard Screenを基本にしてください。Standard Screen、screen_fields、db_additionals、post_action_class、public_pages、サイドパネル設定で実現できる範囲を優先し、問い合わせ一覧を大きく作り替える必要がある場合だけOriginal Screenを検討してください。
作成するノートは、問い合わせチケット、チケットコメント、問い合わせ分類の3つを基本にしてください。問い合わせチケットには、受付番号、問い合わせ日時、会社名、氏名、メールアドレス、電話番号、問い合わせ分類、件名、問い合わせ内容、優先度、対応状態、担当者、回答期限、最終コメント日時、完了日時、社内メモ、添付ファイル、作成日時、更新日時を持たせてください。チケットコメントには、問い合わせチケットへの参照、コメント日時、投稿者、投稿種別、コメント本文、顧客へ送る本文、添付ファイル、社内メモを持たせてください。問い合わせ分類には、分類名、説明、初期担当者、初期優先度、表示順、利用可否を持たせてください。選択肢は問い合わせ分類、優先度、対応状態、投稿種別をconstant_arrayまたは分類ノートで定義してください。
公開側にはログイン不要の問い合わせフォームを作ってください。入力項目は、会社名、氏名、メールアドレス、電話番号、問い合わせ分類、件名、問い合わせ内容、添付ファイルにしてください。氏名、メールアドレス、問い合わせ分類、件名、問い合わせ内容は必須です。メールアドレスは形式チェックを行い、電話番号は任意入力として形式が大きく崩れていないか確認してください。送信完了後は受付番号と「内容を確認して担当者から連絡する」旨を表示してください。公開URLや環境依存値はコード内で固定せず、既存のURL生成方法を使ってください。
管理側のチケット一覧では、受付番号、問い合わせ日時、会社名、氏名、問い合わせ分類、件名、優先度、対応状態、担当者、回答期限、最終コメント日時を表示してください。検索条件は、フリーワード、問い合わせ分類、優先度、対応状態、担当者、問い合わせ日時の期間、回答期限の期間にしてください。未対応、確認中、返信待ち、完了、保留などの状態を見分けやすく表示し、未対応または回答期限を過ぎたチケットが埋もれないようにしてください。
チケットの追加・編集画面では、問い合わせ分類、件名、問い合わせ内容、優先度、対応状態、担当者、回答期限、社内メモを編集できるようにしてください。管理側で手入力するチケットも想定し、会社名、氏名、メールアドレス、電話番号も編集可能にしてください。件名、問い合わせ内容、対応状態、担当者は必須にし、メールアドレスは入力されている場合に形式チェックを行ってください。
チケット一覧から1件を選ぶと、コメント履歴のサイドパネルを表示してください。サイドパネルには、選択中の受付番号、件名、会社名、氏名、対応状態、担当者、回答期限、コメント履歴一覧、コメント追加フォームを置いてください。コメントを追加したら、チケットの最終コメント日時を更新し、必要に応じて対応状態、担当者、回答期限も更新できるようにしてください。顧客へ送る返信本文と社内メモは区別し、社内メモが顧客向け通知に混ざらないようにしてください。
通知は、公開フォームから新しい問い合わせが入ったとき、担当者が未設定のチケットがあるとき、回答期限が近いまたは期限超過したチケットがあるときに確認できる形にしてください。最初は管理画面上の絞り込み、ダッシュボード表示、またはメール通知でよく、外部チャット連携は後回しにしてください。通知文には顧客固有の秘密情報を入れすぎず、受付番号、件名、分類、期限、管理画面への導線を中心にしてください。
権限は、管理者は全チケットと分類設定を閲覧・編集可能、サポート担当者は自分が担当するチケットと未担当チケットを閲覧・更新可能、閲覧のみのユーザーはチケットと履歴を見られるがコメント追加や編集はできない構成にしてください。公開フォームはログイン不要ですが、管理側の一覧、コメント履歴、添付ファイル閲覧はログイン済みユーザーに限定してください。
検証では、公開問い合わせフォームの送信、必須入力エラー、メールアドレス形式チェック、送信後の受付番号表示、管理側チケット一覧への反映、分類検索、状態検索、担当者検索、回答期限検索、担当者割当、コメント追加、コメント追加後の最終コメント日時更新、未対応または期限超過チケットの確認、権限ごとの表示・操作制限、添付ファイルの登録と閲覧を確認してください。サンプルデータには架空の会社名、氏名、件名だけを使い、顧客固有情報や秘密情報は入れないでください。
目的は、質問、要望、不具合報告、契約相談などの問い合わせを1件ずつチケットとして受け付け、担当者、状態、対応履歴、期限、通知を共有して、返答漏れと属人化を減らすことです。まずはFBPのStandard Screenを基本にしてください。Standard Screen、screen_fields、db_additionals、post_action_class、public_pages、サイドパネル設定で実現できる範囲を優先し、問い合わせ一覧を大きく作り替える必要がある場合だけOriginal Screenを検討してください。
作成するノートは、問い合わせチケット、チケットコメント、問い合わせ分類の3つを基本にしてください。問い合わせチケットには、受付番号、問い合わせ日時、会社名、氏名、メールアドレス、電話番号、問い合わせ分類、件名、問い合わせ内容、優先度、対応状態、担当者、回答期限、最終コメント日時、完了日時、社内メモ、添付ファイル、作成日時、更新日時を持たせてください。チケットコメントには、問い合わせチケットへの参照、コメント日時、投稿者、投稿種別、コメント本文、顧客へ送る本文、添付ファイル、社内メモを持たせてください。問い合わせ分類には、分類名、説明、初期担当者、初期優先度、表示順、利用可否を持たせてください。選択肢は問い合わせ分類、優先度、対応状態、投稿種別をconstant_arrayまたは分類ノートで定義してください。
公開側にはログイン不要の問い合わせフォームを作ってください。入力項目は、会社名、氏名、メールアドレス、電話番号、問い合わせ分類、件名、問い合わせ内容、添付ファイルにしてください。氏名、メールアドレス、問い合わせ分類、件名、問い合わせ内容は必須です。メールアドレスは形式チェックを行い、電話番号は任意入力として形式が大きく崩れていないか確認してください。送信完了後は受付番号と「内容を確認して担当者から連絡する」旨を表示してください。公開URLや環境依存値はコード内で固定せず、既存のURL生成方法を使ってください。
管理側のチケット一覧では、受付番号、問い合わせ日時、会社名、氏名、問い合わせ分類、件名、優先度、対応状態、担当者、回答期限、最終コメント日時を表示してください。検索条件は、フリーワード、問い合わせ分類、優先度、対応状態、担当者、問い合わせ日時の期間、回答期限の期間にしてください。未対応、確認中、返信待ち、完了、保留などの状態を見分けやすく表示し、未対応または回答期限を過ぎたチケットが埋もれないようにしてください。
チケットの追加・編集画面では、問い合わせ分類、件名、問い合わせ内容、優先度、対応状態、担当者、回答期限、社内メモを編集できるようにしてください。管理側で手入力するチケットも想定し、会社名、氏名、メールアドレス、電話番号も編集可能にしてください。件名、問い合わせ内容、対応状態、担当者は必須にし、メールアドレスは入力されている場合に形式チェックを行ってください。
チケット一覧から1件を選ぶと、コメント履歴のサイドパネルを表示してください。サイドパネルには、選択中の受付番号、件名、会社名、氏名、対応状態、担当者、回答期限、コメント履歴一覧、コメント追加フォームを置いてください。コメントを追加したら、チケットの最終コメント日時を更新し、必要に応じて対応状態、担当者、回答期限も更新できるようにしてください。顧客へ送る返信本文と社内メモは区別し、社内メモが顧客向け通知に混ざらないようにしてください。
通知は、公開フォームから新しい問い合わせが入ったとき、担当者が未設定のチケットがあるとき、回答期限が近いまたは期限超過したチケットがあるときに確認できる形にしてください。最初は管理画面上の絞り込み、ダッシュボード表示、またはメール通知でよく、外部チャット連携は後回しにしてください。通知文には顧客固有の秘密情報を入れすぎず、受付番号、件名、分類、期限、管理画面への導線を中心にしてください。
権限は、管理者は全チケットと分類設定を閲覧・編集可能、サポート担当者は自分が担当するチケットと未担当チケットを閲覧・更新可能、閲覧のみのユーザーはチケットと履歴を見られるがコメント追加や編集はできない構成にしてください。公開フォームはログイン不要ですが、管理側の一覧、コメント履歴、添付ファイル閲覧はログイン済みユーザーに限定してください。
検証では、公開問い合わせフォームの送信、必須入力エラー、メールアドレス形式チェック、送信後の受付番号表示、管理側チケット一覧への反映、分類検索、状態検索、担当者検索、回答期限検索、担当者割当、コメント追加、コメント追加後の最終コメント日時更新、未対応または期限超過チケットの確認、権限ごとの表示・操作制限、添付ファイルの登録と閲覧を確認してください。サンプルデータには架空の会社名、氏名、件名だけを使い、顧客固有情報や秘密情報は入れないでください。
作られる機能一覧
公開問い合わせフォーム会社名、氏名、連絡先、分類、件名、内容、添付ファイルを受け付け、受付番号を表示します。
チケット一覧問い合わせ日時、分類、状態、担当者、回答期限、最終コメント日時を一覧で確認します。
担当者割当未担当チケットを担当者へ割り当て、対応中の問い合わせをチームで共有します。
コメント履歴問い合わせごとの顧客向け返信、社内メモ、添付ファイルを時系列で残します。
未対応通知新着、未担当、回答期限間近、期限超過のチケットを見つけやすくします。
自社向けに変えるポイント
問い合わせ分類質問、要望、不具合、契約相談、請求相談など、自社で受ける問い合わせ種別に合わせます。
対応状態未対応、確認中、返信待ち、社内確認中、完了、保留など、現場で使う言葉に変えます。
通知タイミング新着時、担当者未設定、回答期限の前日、期限超過など、対応漏れを防げるタイミングを選びます。
権限範囲全社対応、部署別対応、担当者別対応、閲覧専用など、問い合わせ情報の見せ方を決めます。