draft-response

/draft-response

見慣れないプレースホルダーがある場合や、接続されているツールを確認する必要がある場合は、CONNECTORS.md をご覧ください。

状況、顧客との関係、コミュニケーションの文脈に合わせた、顧客向けのプロフェッショナルな返信案を作成します。

使い方

/draft-response <context about the customer question, issue, or request>

例：

• /draft-response Acme Corp is asking when the new dashboard feature will ship
• /draft-response Customer escalation — their integration has been down for 2 days
• /draft-response Responding to a feature request we won't be building
• /draft-response Customer hit a billing error and wants a resolution ASAP

ワークフロー

1. 文脈を把握する

ユーザーの入力を解析し、次の項目を特定します。

• 顧客：誰に向けたコミュニケーションですか？利用可能であれば、アカウントの状況を確認します。
• 状況の種類：質問、問題、エスカレーション、お知らせ、交渉、悪い知らせ、良い知らせ、フォローアップ
• 緊急度：時間的な制約はありますか？顧客はどのくらい待っていますか？
• チャネル：メール、サポートチケット、チャット、その他（適切なフォーマル度に調整します）
• 関係の段階：新規顧客、既存顧客、不満を抱えている顧客／エスカレーション中
• 関係者の役職レベル：エンドユーザー、マネージャー、経営幹部、技術担当者、ビジネス担当者

2. 背景を調べる

利用可能な情報源から、関連する背景情報を集めます。

~~email:

• この件に関する顧客との過去のやり取り
• 以前に共有した約束やスケジュール
• 既存のスレッドのトーンや文体

~~chat:

• この顧客やトピックに関する社内の議論
• プロダクト、エンジニアリング、経営陣からのガイダンス
• 類似の状況とその対応方法

~~CRM (if connected):

• アカウントの詳細とプランレベル
• 連絡先情報と主要な関係者
• 過去のエスカレーションや慎重な対応が必要な問題

~~support platform (if connected):

• 関連するチケットとその解決状況
• 既知の問題や回避策
• SLA の状況と応答時間に関する約束

~~knowledge base:

• 参照する公式ドキュメントやヘルプ記事
• プロダクトロードマップに関する情報（共有可能な場合）
• ポリシーや手順に関するドキュメント

3. 返信案を作成する

状況に合わせた返信を作成します。

## Draft Response

**To:** [Customer contact name]
**Re:** [Subject/topic]
**Channel:** [Email / Ticket / Chat]
**Tone:** [Empathetic / Professional / Technical / Celebratory / Candid]

---

[Draft response text]

---

### Notes for You (internal — do not send)
- **Why this approach:** [Rationale for tone and content choices]
- **Things to verify:** [Any facts or commitments to confirm before sending]
- **Risk factors:** [Anything sensitive about this response]
- **Follow-up needed:** [Actions to take after sending]
- **Escalation note:** [If this should be reviewed by someone else first]

4. 品質を確認する

返信案を提示する前に、次の点を確認します。

• トーンが状況や関係性に合っている
• 権限の範囲を超えた約束をしていない
• 外部に共有すべきでないプロダクトロードマップの詳細が含まれていない
• 過去のやり取りについて正確に言及している
• 次のステップと担当者が明確である
• 関係者の役職レベルに適している（経営幹部には専門的すぎず、エンジニアには曖昧すぎない）
• チャネルに適した長さである（チャットでは短め、メールでは詳しめ）

5. 調整を提案する

返信案を提示した後：

• 「トーンを調整しましょうか？（よりフォーマルに、よりカジュアルに、より共感的に、より率直に）」
• 「具体的なポイントを追加または削除しますか？」
• 「もっと短く／長くしますか？」
• 「別の関係者向けのバージョンも作成しましょうか？」
• 「社内向けのエスカレーションメモも作成しましょうか？」
• 「返答がない場合に備えて、[X days] 後に送るフォローアップメッセージを用意しましょうか？」

---

顧客とのコミュニケーションにおけるベストプラクティス

基本原則

1. 共感を示す：解決策に飛びつく前に、顧客の状況を認めます
2. 率直に伝える：要点を伝えます。顧客は忙しいものです。まず結論から伝えましょう。
3. 正直である：過剰な約束をせず、誤解を招かず、悪い知らせを専門用語で隠しません
4. 具体的に伝える：具体的な詳細、スケジュール、名前を使い、曖昧な表現は避けます
5. 責任を持つ：適切な場合は責任を引き受けます。「システム」や「プロセス」ではなく「私たち」と伝えます
6. 最後まで対応する：すべての返信に、明確な次のステップまたは行動喚起を含めます
7. 相手の温度感に合わせる：相手が不満を抱えている場合は、まず共感を示します。相手が期待に胸を膨らませている場合は、こちらも熱意を示します。

返信の構成

多くの顧客向けコミュニケーションでは、次の構成に従います。

1. Acknowledgment / Context (1-2 sentences)
   - Acknowledge what they said, asked, or are experiencing
   - Show you understand their situation

2. Core Message (1-3 paragraphs)
   - Deliver the main information, answer, or update
   - Be specific and concrete
   - Include relevant details they need

3. Next Steps (1-3 bullets)
   - What YOU will do and by when
   - What THEY need to do (if anything)
   - When they'll hear from you next

4. Closing (1 sentence)
   - Warm but professional sign-off
   - Reinforce you're available if needed

文章の長さに関するガイドライン

• チャット／IM：1～4文。すぐに要点を伝えます。
• サポートチケットへの返信：短い段落を1～3つにします。構成を整え、読みやすくします。
• メール：最大3～5段落にします。相手の受信トレイへの配慮を忘れません。
• エスカレーションへの返信：十分な説明に必要な長さにします。ただし、見出しを使って構成を整えます。
• 経営層向けのコミュニケーション：短いほど効果的です。最大2～3段落にし、データに基づいて伝えます。

トーンと文体に関するガイドライン

トーンの使い分け

状況	トーン	特徴
良い知らせ／成果	祝福	熱意があり、温かく、祝意を示し、前向きです
通常の更新	プロフェッショナル	明確で、簡潔で、情報が伝わり、親しみやすいです
技術的な回答	正確	正確で、詳細で、構成が整い、丁寧です
納期の遅れ	責任感	率直で、謝罪を伝え、行動につながり、具体的です
悪い知らせ	率直	直接的で、共感を示し、解決策を重視し、敬意があります
問題／サービス停止	緊急	即時性があり、透明性が高く、実行可能で、安心感があります
エスカレーション	経営層向け	冷静で、責任を引き受け、計画を提示し、自信があります
請求／アカウント	正確	明確で、事実に基づき、共感を示し、解決を重視します

顧客との関係段階に応じたトーンの調整

新規顧客（0～3か月）：

• よりフォーマルでプロフェッショナルな表現にします
• 背景や説明を詳しく補足します（相手が知っていると決めつけないようにします）
• 積極的にサポートやリソースを案内します
• 信頼性と迅速な対応で信頼を築きます

既存顧客（3か月以上）：

• 温かく、協力的な姿勢を示します
• これまでの関係や過去のやり取りに触れてもかまいません
• より直接的で効率のよいコミュニケーションを心がけます
• 顧客の目標や優先事項を把握していることを示します

不満を抱えている顧客、またはエスカレーション中の顧客：

• 共感と理解をより強く示します
• 迅速に対応します
• 具体的な約束を含む、実行可能な計画を提示します
• 短い間隔で進捗を共有します

文体のルール

推奨事項：

• 能動態を使います（「こちらで調査します」。 「調査が行われます」ではありません）
• 個人としての約束には「私」を、チームとしての約束には「私たち」を使います
• 対応を割り当てる際は担当者を具体的に示します（「エンジニアリングチームのSarahが……」）
• 社内用語ではなく、顧客が使う言葉を使います
• 相対的な表現ではなく、具体的な日付と時刻を記載します（「数日以内」ではなく「1月24日金曜日まで」）
• 長い返信は見出しや箇条書きで区切ります

避けること：

• 企業用語や流行語を使わないでください（「シナジー」、「活用する」、「パラダイムシフト」など）
• 他のチーム、システム、プロセスに責任を転嫁しないでください
• 責任を回避するために受動態を使わないでください（「ミスがありました」など）
• 自信を損なう、不必要な但し書きや曖昧な表現を加えないでください
• 不必要にCCへ追加しないでください。会話に加わる必要がある人だけを含めます
• 感嘆符を多用しないでください（メールでは、使う場合も最大1つにします）

状況に応じた対応

製品に関する質問への回答：

• まず、質問に直接答えます
• 関連するドキュメントへのリンクを提示します
• 必要に応じて、適切なリソースにつなぐことを提案します
• 回答がわからない場合は、正直にそう伝え、確認することを約束し、回答までの目安を伝えます

問題やバグへの対応：

• 相手の業務への影響を認識していることを伝えます
• 問題について把握している内容と現在の状況を伝えます
• 回避策があれば提示します
• 解決までの見通しを伝えます
• 定期的に状況を共有することを約束します

エスカレーションへの対応：

• 事態の深刻さと相手の不満を認識していることを伝えます
• 責任を持って対応します（責任転嫁や言い訳はしません）
• 期限を含む明確な対応計画を提示します
• 解決に責任を持つ担当者を明確にします
• 深刻度に応じて、会議や電話での相談を提案します

悪い知らせを伝える場合（機能の提供終了、遅延、修正不可）：

• 要点を率直に伝えます。悪い知らせを後回しにしません
• 理由を正直に説明します
• 相手への具体的な影響を認識していることを伝えます
• 代替案や影響を軽減する方法を提示します
• 今後の明確な対応方針を示します

良い知らせを伝える場合（機能のリリース、マイルストーン達成、評価）：

• まず、良い結果を伝えます
• 相手の具体的な目標やユースケースと結び付けます
• 良い知らせを活用するための次のステップを提案します
• 心からの喜びを伝えます

依頼を断る場合（機能リクエスト、割引、例外対応）：

• 依頼とその理由を認識していることを伝えます
• 判断を正直に伝えます
• 相手を軽視することなく、理由を説明します
• 可能であれば、代替案を提示します
• 今後も相談できる余地を残します

よくある状況での返信テンプレート

バグ報告を受け取ったことを伝える

Hi [Name],

Thank you for reporting this — I can see how [specific impact] would be
frustrating for your team.

I've confirmed the issue and escalated it to our engineering team as a
[priority level]. Here's what we know so far:
- [What's happening]
- [What's causing it, if known]
- [Workaround, if available]

I'll update you by [specific date/time] with a resolution timeline.
In the meantime, [workaround details if applicable].

Let me know if you have any questions or if this is impacting you in
other ways I should know about.

Best,
[Your name]

請求またはアカウントの問題を受け取ったことを伝える

Hi [Name],

Thank you for reaching out about this — I understand billing issues
need prompt attention, and I want to make sure this gets resolved
quickly.

I've looked into your account and here's what I'm seeing:
- [What happened — clear factual explanation]
- [Impact on their account — charges, access, etc.]

Here's what I'm doing to fix this:
- [Action 1 — with timeline]
- [Action 2 — if applicable]

[If resolution is immediate: "This has been corrected and you should
see the change reflected within [timeframe]."]
[If needs investigation: "I'm escalating this to our billing team
and will have an update for you by [specific date]."]

I'm sorry for the inconvenience. Let me know if you have any
questions about your account.

Best,
[Your name]

対応予定のない機能リクエストへの返信

Hi [Name],

Thank you for sharing this request — I can see why [capability] would
be valuable for [their use case].

I discussed this with our product team, and this isn't something we're
planning to build in the near term. The primary reason is [honest,
respectful explanation — e.g., it serves a narrow use case, it conflicts
with our architecture direction, etc.].

That said, I want to make sure you can accomplish your goal. Here are
some alternatives:
- [Alternative approach 1]
- [Alternative approach 2]
- [Integration or workaround if applicable]

I've also documented your request in our feedback system, and if our
direction changes, I'll let you know.

Would any of these alternatives work for your team? Happy to dig
deeper into any of them.

Best,
[Your name]

サービス停止またはインシデントに関する連絡

Hi [Name],

I wanted to reach out directly to let you know about an issue affecting
[service/feature] that I know your team relies on.

**What happened:** [Clear, non-technical explanation]
**Impact:** [How it affects them specifically]
**Status:** [Current status — investigating / identified / fixing / resolved]
**ETA for resolution:** [Specific time if known, or "we'll update every X hours"]

[If applicable: "In the meantime, you can [workaround]."]

I'm personally tracking this and will update you as soon as we have a
resolution. You can also check [status page URL] for real-time updates.

I'm sorry for the disruption to your team's work. We take this seriously
and [what you're doing to prevent recurrence if known].

[Your name]

返信が途絶えた後のフォローアップ

Hi [Name],

I wanted to check in — I sent over [what you sent] on [date] and
wanted to make sure it didn't get lost in the shuffle.

[Brief reminder of what you need from them or what you're offering]

If now isn't a good time, no worries — just let me know when would be
better, and I'm happy to reconnect then.

Best,
[Your name]

フォローアップとエスカレーションのガイダンス

フォローアップの頻度

状況	フォローアップのタイミング
未回答の質問	2～3営業日後
対応中のサポート案件	重大な案件は解決まで毎日、通常の案件は2～3日ごと
会議後のアクションアイテム	24時間以内に議事録を送付し、その後は期限日に確認
一般的な状況確認	継続中の問題に応じて実施
悪い知らせを伝えた後	影響と受け止め方を確認するため、1週間後

エスカレーションするタイミング

次の場合は、マネージャーにエスカレーションします：

• 顧客が解約、または大幅なダウングレードをほのめかしている
• 顧客から、自分では承認できないポリシーの例外を求められている
• SLAで定められた期間を超えても問題が解決していない
• 顧客が経営陣との直接の連絡を求めている
• 解決に上位職の関与が必要なミスをしてしまった

次の場合は、製品／エンジニアリングチームにエスカレーションします：

• バグが重大で、顧客の業務を妨げている
• 機能の不足によって競争上の損失が生じている
• 顧客に標準的なサポートの範囲を超える固有の技術要件がある
• 統合の問題について、エンジニアリングチームによる調査が必要である

エスカレーションの形式：

ESCALATION: [Customer Name] — [One-line summary]

Urgency: [Critical / High / Medium]
Customer impact: [What's broken for them]
History: [Brief background — 2-3 sentences]
What I've tried: [Actions taken so far]
What I need: [Specific help or decision needed]
Deadline: [When this needs to be resolved by]