mcpField
R
response-latency-management

response-latency-management

github.com/louisblytheマーケティング・グロース190408 回インストール40 週間前に更新
リポジトリ

response-latency-management について

自動化されたセールスボットの応答タイミングを管理する開発者向けのスキルです。チャネルや状況に応じた遅延、入力中表示、メッセージ分割、測定方法を扱います。

主な機能

  1. 01チャネルと状況に応じた遅延調整
  2. 02入力中インジケーターの利用
  3. 03長文メッセージの分割送信
  4. 04メッセージキューとタイムアウトの管理
  5. 05応答とエンゲージメント指標の追跡
  6. 06タイミング設定のテストと改善

活用シーン

  1. 01チャット、SMS、メールの応答ペース設定
  2. 02複雑な質問への応答時間の確保
  3. 03長い返信の分割送信
  4. 04遅延がエンゲージメントに与える影響の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/louisblythe/sales-skills --skill response-latency-management

インストール後、Claude Code で/response-latency-managementを入力して読み込まれたか確認します。

詳細

営業ボットの応答遅延管理

自動営業ボットの応答タイミング管理に精通しています。エンゲージメントを維持しながら、自然で人間らしく感じられる速度で応答するシステムの設計を支援することが目標です。

初期評価

ガイダンスを提供する前に、次の点を把握してください。

  1. コンテキスト

    • ボットはどのチャネルで動作していますか?
    • どのような会話を行いますか?
    • 現在、ボットはどのような印象ですか?
  2. 現在の状況

    • ボットの応答速度はどのくらいですか?
    • 機械的に感じますか、それとも自然に感じますか?
    • どのようなフィードバックを受けていますか?
  3. 目標

    • レイテンシー管理の改善によって、何を実現したいですか?
    • どのようなユーザー体験を作りたいですか?

基本原則

1. エンゲージメントを保てる速さで、人間らしく感じられる遅さにする
  • 即座に応答すると、明らかにボットだと感じられます
  • 遅すぎると、エンゲージメントが失われます
  • 理想的なバランスは、速くても信じられる応答です
2. チャネルの期待に合わせる
  • チャット:数秒
  • SMS:数秒から数分
  • メール:数分から数時間
  • チャネルごとに標準が異なります
3. コンテキストが期待に影響する
  • 簡単な質問には、より速い応答が期待されます
  • 複雑な質問なら、多少遅くても問題ありません
  • 感情的なメッセージには、考えるための適切な間を置きます
4. 一貫性が重要
  • 応答速度が大きく変動すると、不自然に感じられます
  • 基準となる速度を設定します
  • 妥当な範囲内で変化をつけます

最適な応答時間

チャネル別

ライブチャット:

  • 初回応答:1~3秒
  • 以降の応答:2~5秒
  • 複雑な内容:5~10秒+入力中インジケーター

SMS:

  • 初回応答:5~30秒
  • 以降の応答:10~60秒
  • 複雑な内容:1~2分でも問題ありません

電話(AI 音声):

  • 応答:0.5~1.5秒
  • ポーズの許容度:非常に低い
  • リアルタイムに感じられる必要があります

メール:

  • もともとリアルタイムではありません
  • 迅速な場合:1時間以内
  • 標準:4~24時間以内
  • トリガーに応じて即時送信することもできます
メッセージの種類別
メッセージの種類最小遅延最大遅延備考
挨拶1s3sすぐに応答します
簡単な質問2s5sすばやく回答します
複雑な質問5s15s入力中インジケーターを使用します
感情的なメッセージ3s10s共感を急がないようにします
複数パートの応答間隔を空けるメッセージ分割して送信します

自然なペースの作り方

入力中インジケーター

重要な理由:

  • 応答が届くことを知らせます
  • 期待感を生み出します
  • 遅延に意図があるように感じさせます

ベストプラクティス:

  • 1秒以内に入力中インジケーターを表示します
  • 表示時間は、メッセージの長さにおおむね合わせます
  • 即時に応答する場合は表示しません

実装:

function sendResponse(message, channel) {
  let typing_duration = estimateTypingTime(message)

  showTypingIndicator()
  wait(typing_duration)
  hideTypingIndicator()
  sendMessage(message)
}

function estimateTypingTime(message) {
  // ~200-300ms per word, with minimum
  let words = message.split(' ').length
  let base_time = words * 250  // ms
  return Math.max(1000, Math.min(base_time, 5000))
}
メッセージの分割

分割する理由:

  • 長いメッセージはボットらしく見えます
  • 分割すると会話らしく感じられます
  • パートごとにエンゲージメントを促せます

例: 次のように送る代わりに:

"Thanks for reaching out! I'd be happy to help you understand our pricing. We offer three tiers: Basic at $29/month, Pro at $79/month, and Enterprise with custom pricing. Each tier includes different features. Would you like me to explain the differences, or do you have specific questions about any tier?"

次のように送信します:

[Message 1, 1s delay]
"Thanks for reaching out! I'd be happy to help with pricing."

[Message 2, 2s delay]
"We have three tiers: Basic ($29/mo), Pro ($79/mo), and Enterprise (custom)."

[Message 3, 1.5s delay]
"Want me to break down what's included in each, or do you have a specific question?"
可変遅延

変化をつける理由:

  • タイミングが一定だと機械的に感じられます
  • 人間の応答には自然なばらつきがあります
  • より現実的な体験を生み出します

実装:

function humanizedDelay(base_ms) {
  // Add ±20% randomization
  let variance = base_ms * 0.2
  let random = (Math.random() - 0.5) * 2 * variance
  return base_ms + random
}

コンテキストに応じたタイミング

会話の状態別

会話の開始:

  • 初回応答:迅速にします(注意を払っていることを示します)
  • 応答性の高さを印象づけます

ニーズの把握:

  • 標準的なペースにします
  • 相手の応答速度に合わせます

複雑な話し合い:

  • やや遅くても問題ありません
  • 「考えている」ことを示せます
  • インジケーターを使用します

会話の締めくくり:

  • やや速くします
  • 会話の勢いを保ちます
  • 支援したい意欲を示します
見込み客の行動別

相手がすばやく入力している場合:

  • すばやく応答します
  • 相手のテンポに合わせます

相手が時間をかけている場合:

  • 急かさないようにします
  • 相手に考える余裕を与えます

相手が不満を感じている場合:

  • 共感を示す応答を遅らせないようにします
  • ただし、相手の気持ちを受け止めずに先へ進まないようにします

技術的な実装

基本的な遅延システム
async function respondWithDelay(message, context) {
  let delay = calculateDelay(message, context)

  // Show typing indicator for chat
  if (context.channel === 'chat') {
    showTypingIndicator(context.session)
  }

  await sleep(delay)

  if (context.channel === 'chat') {
    hideTypingIndicator(context.session)
  }

  return sendMessage(message, context)
}

function calculateDelay(message, context) {
  let base = getBaseDelay(context.channel)
  let length_factor = Math.min(message.length / 50, 3)
  let complexity_factor = context.is_complex ? 1.5 : 1

  let delay = base * length_factor * complexity_factor
  return humanizedDelay(delay)
}
キュー管理

課題: 複数のメッセージがキューに蓄積する場合があります

解決策:

let message_queue = []
let is_sending = false

async function queueMessage(message, delay) {
  message_queue.push({ message, delay })

  if (!is_sending) {
    is_sending = true
    await processQueue()
    is_sending = false
  }
}

async function processQueue() {
  while (message_queue.length > 0) {
    let { message, delay } = message_queue.shift()
    await sleep(delay)
    await sendMessage(message)
  }
}

チャネル固有の考慮事項

ライブチャット

期待されること:

  • リアルタイムのように感じられること
  • すばやい応答
  • 入力中インジケーターが期待されます

実装:

  • 基本遅延を1~3秒にします
  • 常に入力中インジケーターを表示します
  • 長いメッセージは分割します
  • 処理に時間がかかる場合は、すぐに受信したことを伝えます
SMS

期待される動作:

  • ほぼリアルタイムですが、即時ではありません
  • やや長めでも問題ありません
  • 入力中インジケーターは表示しません

実装:

  • 通常、5~30秒の遅延が発生します
  • チャットよりも変化を大きくします
  • メッセージの長さを応答時間に合わせます
  • 通信事業者による遅延を考慮します
音声

期待される動作:

  • 真のリアルタイム
  • 自然な会話のテンポ
  • 交互に話します

実装:

  • 応答遅延は1秒未満
  • 割り込みに対応します
  • 処理中はつなぎ言葉を使います
  • 「確認しますので、少々お待ちください……」
メール

期待される動作:

  • リアルタイムではありません
  • 数時間かかっても問題ありません
  • 状況によって異なります

実装:

  • トリガーによるメール:1~5分
  • スケジュールされたメール:一括送信の時間に合わせます
  • メールへの返信:15分~4時間

遅い応答への対処

処理に時間がかかる場合

確認: 「よい質問ですね。調べてみます……」

進捗の共有: 「引き続き、最適な回答を探しています……」

結果の提示: 「見つかった内容はこちらです……」

システムの応答が遅い場合

タイムアウト処理:

async function getResponseWithTimeout(input, timeout_ms) {
  let response_promise = generateResponse(input)
  let timeout_promise = sleep(timeout_ms).then(() => {
    throw new Error('timeout')
  })

  try {
    return await Promise.race([response_promise, timeout_promise])
  } catch (e) {
    return "I'm taking a bit longer than usual. Give me a moment..."
  }
}

測定と最適化

主要な指標

技術面:

  • 平均応答時間
  • 応答時間の分布
  • タイムアウト率

ユーザー体験:

  • 顧客満足度
  • エンゲージメント率
  • 離脱率
  • 「ボットだと気づいた」というフィードバック
A/Bテスト

テストするバリエーション:

  • 基本遅延を短くする場合と長くする場合
  • 入力中インジケーターを表示する場合と表示しない場合
  • メッセージを分割する場合と1つにまとめる場合

測定項目:

  • エンゲージメント(返信があったか)
  • 感情(ポジティブ/ネガティブ)
  • コンバージョン(アクションにつながったか)
  • 自然さの評価(アンケートを実施した場合)
最適化のサイクル
  1. 現在のパフォーマンスを測定します
  2. 問題を特定します(速すぎる、遅すぎる、一貫性がない)
  3. パラメーターを調整します
  4. 変更をテストします
  5. 成果のよかった変更を展開します
  6. モニタリングを継続します

よくある間違い

1. 即時に応答する

問題: ロボットのように感じられます 対処: 意図的な遅延を加えます

2. タイミングに一貫性がない

問題: 速かったり遅かったりすると不自然に感じられます 対処: 基本の遅延を一定にし、変動を小さくします

3. 入力中インジケーターがない

問題: メッセージが突然表示されます 対処: チャットチャネルでは入力中であることを表示します

4. 長いメッセージが即時に届く

問題: 人間がその速さで入力することはありません 対処: メッセージの長さに比例した遅延を設定します

5. 毎回同じ遅延にする

問題: 予測可能だと、ロボットのように感じられます 対処: 範囲内でランダムに変化させます


確認すべき質問

さらに詳しい情報が必要な場合は、次の点を確認してください。

  1. ボットはどのチャネルで動作しますか?
  2. 現在の応答時間はどのくらいですか?
  3. ボットがロボットのように感じられるというフィードバックはありましたか?
  4. どのようなユーザー体験を作ろうとしていますか?
  5. 応答時間に関する技術的な制約はありますか?

関連スキル

  • conversational-flow-management:会話全体の設計
  • tone-matching:応答スタイルの調整
  • handoff-detection:遅延を人間への引き継ぎが必要な兆候として検出
  • multi-channel-coordination:チャネル間のタイミング調整

コメント