/draft-response

見慣れないプレースホルダーがある場合、またはどのツールが接続されているかを確認したい場合は、CONNECTORS.md を参照してください。

状況、顧客との関係、コミュニケーションのコンテキストに合わせて、専門的で顧客向けの対応案を作成します。

使い方

/draft-response <顧客の質問、問題、またはリクエストに関するコンテキスト>

使用例：

• /draft-response Acme Corp が新しいダッシュボード機能のリリース時期を尋ねている
• /draft-response 顧客からのエスカレーション — 統合が 2 日間ダウンしている
• /draft-response 構築する予定のない機能リクエストに応答している
• /draft-response 顧客が請求エラーに遭遇し、至急解決を望んでいる

ワークフロー

1. コンテキストを理解する

ユーザーの入力を解析して以下を判定します：

• 顧客：誰に対するコミュニケーションか？ アカウント情報が利用可能な場合は確認します。
• 状況のタイプ：質問、問題、エスカレーション、告知、交渉、悪いニュース、良いニュース、フォローアップ
• 緊急度：時間に敏感か？ 顧客がどのくらい待っているか？
• チャネル：メール、サポートチケット、チャット、その他（それぞれに応じてトーンを調整）
• 関係のステージ：新規顧客、確立された関係、フラストレーション/エスカレーション
• ステークホルダーレベル：エンドユーザー、マネージャー、経営層、技術者、ビジネス側

2. コンテキストを調査する

利用可能なソースから関連する背景情報を集めます：

メール：

• このトピックに関する顧客との過去の対応
• 以前共有されたコミットメントやタイムライン
• 既存スレッドのトーンとスタイル

チャット：

• この顧客またはトピックに関する内部ディスカッション
• 製品、エンジニアリング、リーダーシップからのガイダンス
• 同様の状況とそれらがどのように処理されたか

CRM（接続されている場合）：

• アカウント詳細とプランレベル
• 連絡先情報と主要なステークホルダー
• 以前のエスカレーションや機密情報

サポートプラットフォーム（接続されている場合）：

• 関連チケットと解決状況
• 既知の問題または回避策
• SLA ステータスと応答時間に関するコミットメント

ナレッジベース：

• 参照すべき公式ドキュメントまたはヘルプ記事
• 共有可能な製品ロードマップ情報
• ポリシーまたはプロセスドキュメント

3. ドラフトを生成する

状況に合わせたカスタマイズされた対応を作成します：

## 対応案ドラフト

**宛先：** [顧客の連絡先名]
**件名：** [件名/トピック]
**チャネル：** [メール / チケット / チャット]
**トーン：** [共感的 / 専門的 / 技術的 / 祝賀的 / 率直]

---

[ドラフト対応文]

---

### 注記（内部用 — 送信しないこと）
- **このアプローチを取る理由：** [トーンと内容の選択の根拠]
- **確認が必要な事項：** [送信前に確認すべき事実またはコミットメント]
- **リスク要因：** [この対応に関する機密事項]
- **フォローアップが必要：** [送信後に実施すべきアクション]
- **エスカレーション注記：** [送信前に誰かに確認してもらう必要があるか]

4. 品質チェックを実行する

ドラフトを提示する前に、以下を確認します：

• トーンが状況と関係に適切か
• 認可範囲を超えたコミットメントがないか
• 外部に共有すべきでない製品ロードマップの詳細がないか
• 過去の会話の正確な言及
• 明確な次のステップと所有権
• ステークホルダーレベルに適切か（経営層には技術的すぎず、エンジニアには曖昧でない）
• チャネル別に適切な長さか（チャットは短め、メールは充実した内容）

5. 改善案を提示する

ドラフト提示後：

• 「トーンを調整しましょうか？（より形式的に、カジュアルに、より共感的に、より直接的に）」
• 「特定のポイントを追加または削除すべきですか？」
• 「これを短くするか長くするか？」
• 「別のステークホルダー向けにバージョンを作成しましょうか？」
• 「内部エスカレーション注記もドラフトしましょうか？」
• 「応答がない場合に [X 日後] に送信するフォローアップメッセージを準備しましょうか？」

---

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

基本原則

1. 共感をもって始める：解決策に飛びつく前に、顧客の状況を認識します
2. 直接的である：要点に到達してください — 顧客は忙しいです。重要な情報を最初に。
3. 正直である：決してオーバープロミスをしない、決してミスリードしない、決して悪いニュースを専門用語で隠さない
4. 具体的である：具体的な詳細、タイムライン、名前を使用する — 曖昧な言葉を避ける
5. 責任を取る：必要に応じて責任を取りましょう。「システム」や「プロセス」ではなく「私たち」を使う
6. ループを閉じる：すべての対応に明確な次のステップまたはコール・トゥ・アクションがあるべき
7. エネルギーを合わせる：フラストレーションしているなら、まず共感を示す。興奮していたら、熱意を示す。

対応構造

ほとんどの顧客コミュニケーションは、この構造に従います：

1. 承認 / コンテキスト（1～2 文）
   - 彼らが言ったこと、尋ねたこと、または経験していることを承認する
   - 状況を理解していることを示す

2. メッセージ本体（1～3 段落）
   - メイン情報、回答、または更新を伝える
   - 具体的かつ明確である
   - 必要な関連詳細を含める

3. 次のステップ（1～3 項目）
   - あなたが何をいつまでにするか
   - 彼らが何をする必要があるか（該当する場合）
   - 次に連絡をいつするか

4. 締めくくり（1 文）
   - 温かみがありながらも専門的な署名
   - 必要な場合は利用可能であることを強調する

長さのガイドライン

• チャット/IM：1～4 文。すぐに要点に。
• サポートチケット対応：1～3 短い段落。構造化でスキャン可能。
• メール：最大 3～5 段落。受信トレイを尊重してください。
• エスカレーション対応：徹底的である必要なだけの長さですが、ヘッダーでしっかり構成されます。
• 経営層への報告：短いほうが良い。最大 2～3 段落。データドリブン。

トーンとスタイルのガイドライン

トーンのスペクトラム

状況	トーン	特性
良いニュース / 成果	祝賀的	熱心、温かみがあり、祝賀的、前向き
日常的な更新	専門的	明確、簡潔、有益、フレンドリー
技術的対応	正確	正確、詳細、構造化、根気強い
遅延の伝達	説明責任	正直、謝罪的、行動志向、具体的
悪いニュース	率直	直接的、共感的、解決志向、尊重的
問題 / 障害	緊急	即座、透明性がある、実行可能、安心感
エスカレーション	経営層向け	冷静、所有権の取得、計画の提示、自信
請求 / アカウント	正確	明確、事実的、共感的、解決志向

関係のステージ別トーン調整

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

• より形式的かつ専門的
• 追加のコンテキストと説明（知識を想定しない）
• プロアクティブにヘルプとリソースを提供
• 信頼性と応答性で信頼を構築

確立された顧客（3 ヶ月以上）：

• 温かみがあり、協力的
• 共有履歴と過去の対応を参照できる
• より直接的で効率的なコミュニケーション
• 目標や優先事項への認識を示す

フラストレーション/エスカレーション顧客：

• 追加の共感と承認
• 応答時間の緊急性
• 具体的なアクション計画と特定のコミットメント
• より短いフィードバックループ

ライティングスタイルルール

すべきこと：

• 能動態を使う（「We'll investigate」であって「This will be investigated」ではない）
• 個人的なコミットメントは「I」を使い、チームのコミットメントは「we」を使う
• アクションを割り当てる際に特定の人を名前で明記する（「our engineering team's Sarah will...」）
• 内部用語ではなく、顧客の用語を使う
• 相対的な用語ではなく、具体的な日付と時間を含める（「in a few days」ではなく「by Friday January 24」）
• 長い対応はヘッダーまたは項目で分割する

してはいけないこと：

• 企業用語やバズワードを使う（「synergy」「leverage」「paradigm shift」）
• 他のチーム、システム、プロセスに責任をなすりつける
• 所有権を避けるために受動態を使う（「Mistakes were made」）
• 信頼性を損なう不要な留保や躊躇を含める
• 不要にCC する — 会話に含まれる必要のある人だけを含める
• 過度に感嘆符を使う（メール当たり最大 1 個、あれば）

状況別のアプローチ

製品に関する質問に答える：

• 直接的な回答でリードする
• 関連するドキュメントリンクを提供
• 必要に応じて適切なリソースとの接続を提供
• 答えがわからない場合：正直に言う、見つけることを約束する、タイムラインを提供する

問題またはバグに対応する：

• その問題が彼らの作業に及ぼす影響を認識する
• 問題について知っていることと状態を述べる
• 利用可能な場合は回避策を提供
• 解決のタイムラインに関する期待値を設定
• 定期的な間隔での更新をコミット

エスカレーションに対応する：

• 重大性とフラストレーションを認識する
• 所有権を取得する（言い訳や責任転嫁なし）
• 明確なアクション計画とタイムラインを提供
• 解決に責任を負う人を特定する
• 重大性に応じてミーティングまたは電話を提案する

悪いニュース（機能廃止、遅延、修正不可）を伝える：

• 直接的に — ニュースを埋めない
• 理由を正直に説明
• 特に彼らへの影響を認識
• 代替案または緩和策を提供
• 明確な前進経路を提供

良いニュース（機能リリース、マイルストーン、認識）を共有する：

• 肯定的な結果でリードする
• 彼らの特定の目標またはユースケースに関連付ける
• 良いニュースを活用するための次のステップを提案
• 本物の熱意を示す

リクエストを断る（機能リクエスト、割引、例外）：

• リクエストとその理由を認識する
• 決定について正直である
• 却下的でなく理由を説明
• 可能な場合は代替案を提供
• 将来のための会話の扉を開いておく

よくあるシナリオへの対応テンプレート

バグレポートへの応答

こんにちは [名前]、

これを報告していただきありがとうございます — [特定の影響] があなたのチームに
とってフラストレーションになることがわかります。

問題を確認し、エンジニアリングチームに [優先度レベル] として
エスカレーションしました。これまでのところ以下のことがわかっています：
- [何が起こっているか]
- [原因（既知の場合）]
- [利用可能な回避策]

[具体的な日付/時刻] までに解決タイムラインでアップデートします。
それまでの間、[回避策の詳細]。

ご質問やこれが他の方法で影響を及ぼしている場合は、
お知らせください。

よろしくお願いいたします。
[あなたの名前]

請求またはアカウント問題への応答

こんにちは [名前]、

これについてお知らせいただきありがとうございます — 請求の問題には
迅速な対応が必要であることは承知しており、これを素早く解決したいです。

アカウントを確認しました。以下が見えています：
- [何が起こったか — 明確な事実の説明]
- [アカウントへの影響 — 請求、アクセスなど]

この問題を解決するための対応を以下の通り行っています：
- [アクション 1 — タイムライン付き]
- [アクション 2 — 該当する場合]

[即座に解決できる場合：「これは修正されており、[期間] 以内に変更が反映されます。」]
[調査が必要な場合：「請求チームにエスカレーションしており、[具体的な日付] までに
アップデートがあります。」]

ご不便をおかけして申し訳ございません。アカウントについてご質問があれば、
お知らせください。

よろしくお願いいたします。
[あなたの名前]

構築しない機能リクエストへの対応

こんにちは [名前]、

このリクエストをお知らせいただきありがとうございます — [機能] が
[ユースケース] にとって有価値である理由がわかります。

製品チームとこれについて話し合いましたが、近い将来これを
構築する予定はありません。主な理由は [正直で尊重のある説明 —
例えば、利用例が限定的、アーキテクチャの方向性と競合するなど]。

とはいえ、あなたがゴールを達成できるようにしたいです。
以下が代替案です：
- [代替アプローチ 1]
- [代替アプローチ 2]
- [統合または回避策（該当する場合）]

また、あなたのリクエストをフィードバックシステムに記録しており、
方向性が変わった場合はお知らせします。

これらの代替案のいずれかはあなたのチームにとって機能しますか？
どれについても詳しく掘り下げる準備ができています。

よろしくお願いいたします。
[あなたの名前]

障害またはインシデント通知

こんにちは [名前]、

あなたのチームが依存していることを知っている [サービス/機能] に
影響を与える問題についてお知らせしたいと直接連絡しています。

**何が起こったか：** [明確で技術的でない説明]
**影響：** [特にどのように彼らに影響するか]
**ステータス：** [現在のステータス — 調査中 / 特定済み / 修正中 / 解決済み]
**解決予定時刻：** [既知の場合は具体的な時刻、不明な場合は「X 時間ごとに更新します」]

[該当する場合：「それまでの間、[回避策] ができます。」]

これを個人的に追跡しており、解決するとすぐにアップデートします。
[ステータスページ URL] でリアルタイム更新を確認することもできます。

チームの作業に対する中断をお詫びします。これを真摯に受け止めており、
[既知の場合は再発防止のための対応]。

[あなたの名前]

沈黙後のフォローアップ

こんにちは [名前]、

チェックインしたいと思いました — [何を送ったか] を [日付] に
送信しており、見落とされていないか確認したかったです。

[あなたが彼らから必要としているもの、または提供しているもののの短い思い出し]

今が良い時間でない場合は問題ありません — いつが良いか教えてください。
その時は喜んで再接続します。

よろしくお願いいたします。
[あなたの名前]

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

フォローアップペース

状況	フォローアップタイミング
未回答の質問	2～3 営業日
オープンなサポート問題	クリティカルは毎日まで解決、標準は 2～3 日
会議後のアクションアイテム	24 時間以内（メモ送信）、その後期限時にチェック
一般的なチェックイン	進行中の問題に応じて必要に応じて
悪いニュース配信後	1 週間で影響とセンチメントをチェック

エスカレーションする時期

以下の場合はマネージャーにエスカレーション：

• 顧客がキャンセルまたは大幅なダウンセルを脅迫する
• 顧客が承認できないポリシー例外をリクエスト
• 問題が SLA 許容時間より長く解決していない
• 顧客がリーダーシップとの直接接触をリクエスト
• エラーを犯し、解決に上級者の関与が必要

以下の場合は製品/エンジニアリングにエスカレーション：

• バグが重大で顧客のビジネスをブロック
• 機能ギャップが競合上の損失を引き起こしている
• 顧客が標準サポート範囲を超えた独自の技術要件
• 統合問題がエンジニアリング調査が必要

エスカレーション形式：

エスカレーション：[顧客名] — [1 行の概要]

緊急度：[クリティカル / 高 / 中]
顧客への影響：[彼らにとって何が壊れているか]
履歴：[簡単な背景 — 2～3 文]
試したこと：[これまでのアクション]
必要なもの：[必要な特定のヘルプまたは決定]
期限：[いつまでに解決する必要があるか]