サポート担当は同じ質問に1日何十回も答えます。そのたびに正確な情報と適切な言葉づかいが求められます。よいプロンプトがあれば、対応メモを分かりやすい返信に、そっけない下書きを丁寧な文章に、解決済みの案件をお客様自身が見つけられるヘルプ記事に変えられます。以下のプロンプトは、返信文、トーンの調整、エスカレーション、ナレッジベースの記事づくりといった実際のサポート業務のために用意しました。
あなたは{product}のサポート担当です。お客様から次のメッセージが届きました:{customer_message}。分かっている情報は{account_or_context}で、解決策は{resolution_or_next_step}です。1行目でまずお客様の問題を受け止め、修正内容を平易な言葉で説明し、次にすべきことを1つ明確に示す返信を書いてください。トーンは{フレンドリーかつ丁寧に}に合わせます。専門用語を使わず150語以内にまとめ、温かい結びで締めてください。返信の本文だけを出力してください。
あなたはカスタマーサポートチームの編集担当です。以下の下書きを、事実や約束した解決策を変えずに{共感的で落ち着いた}印象になるよう書き直してください。下書き:{paste_draft}。身構えた表現や責めるような言い回しを取り除き、断る場合はその理由を添えてやわらげ、簡潔に保ちます。具体的な数値・日付・ポリシーの内容はすべて書かれたとおり正確に残してください。短めのものと少し温かめのものの2案を、それぞれ明確にラベル付けして出力してください。
あなたは{product}のナレッジベース担当ライターです。この解決済みチケット:{ticket_thread}をもとに、お客様が実際に検索しそうな質問形式のタイトルを付けたヘルプセンター記事を書いてください。1文の要約、前提条件をまとめた短い「始める前に」の注記、解決までの番号付き手順、サポートへ案内する「それでも解決しない場合は?」のセクションを含めます。中学1年生でも読める平易さで、読者を「あなた」と呼びかけ、社内でしか通じない用語はすべて省いてください。H2見出しを使ったMarkdown形式で出力してください。
あなたはチケットを{二次対応/開発チーム}にエスカレーションするサポート担当です。このスレッド:{ticket_thread}から、社内向けの引き継ぎ文を書いてください。お客様への影響を1行で、正確な再現手順、すでに試したこと、影響を受けるアカウントやID{account_ids}、そして必要としている具体的な質問または判断を含めます。深刻度を低・中・高で示し、1行で理由を添えてください。あいさつは省き、事実に徹します。200語以内の箇条書きの要点として出力してください。
あなたは{product}のサポート運用リーダーです。よく来るチケットの種類は次のとおりです:{list_of_topics}。それぞれについて、担当者が個別に埋める必要のある部分を{customer_name}や{order_id}などの{プレースホルダー}にした、使い回せる定型文を書いてください。各返信は120語以内に収め、{フレンドリーで簡潔な}トーンに合わせ、どんなときに使うかを示す短い社内メモを添えます。各マクロを明確にラベル付けした番号付きリストで出力してください。
実際のトーンとチケットの正確な事実をプロンプトに与えれば、そうはなりません。メモに加えて短いスタイル指示を渡し、出てきた下書きを手直しするのが最良です。あくまで素早い初稿ととらえ、送信前提の完成品としては扱わないでください。
氏名・メールアドレス・注文番号・アカウントIDといった個人情報は、貼り付ける前に伏せるか、{customer_name}のようなプレースホルダーに置き換えてください。実際のチケット内容をツールに入れる前に、自社のデータポリシーとAI提供元のデータ保持設定を必ず確認しましょう。
うまくいったプロンプトを保存し、成果の出た返信は変わる部分を{プレースホルダー}にした使い回せるマクロにしましょう。全員が同じプロンプトと同じ定型文から始めれば、担当者が入れ替わってもトーンと正確さが安定します。
はい。解決済みのチケットには問題・手順・修正内容がすでに含まれているので、プロンプトで検索しやすいヘルプ記事に作り替えられます。実際のチケットからナレッジベースを書くと、こちらが想像する質問ではなく、お客様が本当に尋ねる質問を記録できます。
うまくいくプロンプトを保存し、変数を追加し、バージョンを残し、数秒で見つけましょう。
無料で始める