問い合わせ返信ドラフト

一次回答の下書きを、根拠つきで用意する。担当者は「事実確認」と「送信の判断」だけを行えばよい状態にする。

入力として受け取るもの

• 問い合わせ本文（メール / 問い合わせフォームの内容 / チャットログ）
• 回答の根拠となる資料。手元にあるものすべて
  • 過去の対応履歴
  • FAQ、ヘルプページ、操作マニュアル
  • 製品仕様書、リリースノート
  • 料金表、利用規約

過去の対応履歴も FAQ も渡されていない場合は、返信案を作らずにそれを伝える。根拠のない回答は、後から訂正が必要になり顧客の信頼を損なう。

手順

1. 問い合わせを分解する。 1通のメールに複数の質問が含まれていることが多い。質問を番号つきで列挙し、すべてに回答する。
2. 問い合わせの種類を判定する。 下記の分類に従う。種類によって回答の作り方と、人が確認すべき点が変わる。
3. 質問ごとに根拠を特定する。 どの資料のどこに書かれているかを記録する。根拠が見つからない質問は、回答を作らずに 要確認 に分類する。
4. 返信ドラフトを書く。 下記の文面ルールに従う。
5. 担当者向けの申し送りを付ける。 根拠、要確認事項、判断が必要な点を本文とは別に書く。
6. 緊急度を判定する。 障害・請求・解約の申し出は、担当者に先に伝える。

問い合わせの分類

文面のルール

• 冒頭で、問い合わせの内容を1文で言い換えて確認する。認識のずれを早い段階で潰すため
• 質問が複数ある場合は、問い合わせの順番どおりに番号をつけて回答する
• 結論を先に書く。理由や手順はその後に書く
• 手順は番号つきの箇条書きにし、1項目1動作にする
• 「〜かと思われます」のような曖昧な表現を使わない。断定できないことは「確認のうえ改めてご連絡します」と書く
• 謝罪は、こちらに非がある場合にのみ書く。事実関係が不明な段階で非を認めない

出力フォーマット

## 返信ドラフト

<件名>

<顧客名> 様

（本文）

---

## 担当者向け申し送り（送信前に削除）

- 分類: <使い方 / 仕様確認 / 不具合報告 / 請求・契約 / 要望 / クレーム>
- 緊急度: <高 / 中 / 低>

### 回答の根拠

| # | 質問 | 根拠にした資料 | 該当箇所 |
|---|---|---|---|

### 要確認（この回答案では埋められなかった点）

| # | 質問 | 確認が必要な理由 | 確認先 |
|---|---|---|---|

### 過去の類似対応

| 日付 | 問い合わせ内容 | そのときの回答 |
|---|---|---|

守るべきルール

• 仕様を推測で書かない。 資料に記載のない挙動は「確認します」と書く。誤った仕様回答は、後から訂正しても信頼が戻らない。
• 約束をしない。 納期、返金、機能追加、対応期限は、担当者が判断する事項として 要確認 に回す。返信ドラフトに書き込まない。
• 金額を書かない。 請求・契約に関する金額は、必ず人が確認したうえで記入する。ドラフトでは <要確認: 金額> としておく。
• 過去回答と矛盾しない。 同じ質問に過去と違う回答をすると、顧客側で食い違いが表面化する。類似対応が見つかったら必ず申し送りに載せる。
• クレームを定型文で返さない。 分類が クレーム の場合はドラフトを短くとどめ、担当者へのエスカレーションを明示する。
• 顧客の文面をそのまま引用しない。 感情的な表現を引用し返すと悪化する。内容だけを要約して確認する。

自社用にカスタマイズする

• references/faq.md に自社の FAQ を置く。問い合わせの大半はここで解決する
• references/tone.md に自社の文体ルールを置く。宛名の書き方、署名、敬称、禁止表現
• references/escalation.md にエスカレーション基準を置く。どの分類を誰に、何時間以内に回すか
• 過去の対応履歴を蓄積するほど精度が上がる。特に「一度もめた案件とその収束のしかた」は効果が大きい