← 返回列表

問い合わせを発生させない設計：deflection 40% を「分診の前」で狙う

2026/9/15

B 方向·OPC 最佳实践（维度：support の発生抑制）。問い合わせ 索引に専用課題なし（japan-customer-harassment-law は発生後の危機対応）——お困り分診（発生後の振り分け）の前段として別枠。

背景与问题

solo の support 容量は週 2-3 時間——問い合わせ 1 通あたりの対応が多すぎると開発時間が消える。既存設計は「発生した問い合わせを 4 路に分診する」段——本課題は発生する前の段（事前 deflection）を設計する。

发现（访问 2026-09-15）

  • deflection の基准：self-service で 40-60% のチケット削減が上位 SaaS の水準、~40% が現実的目標（Ferndesk）；B2B で 20-60% 削減の事例（Pylon 2025）。AI 対応の実例は 39.5% deflection（Reddit 実装記）。
  • 手順の定石：①intent mapping を先にやる（問い合わせをカテゴリ化してから自動化を組む——先に組むと外れる）②help center はin-app に埋め込む（別ドキュメントサイトに置かない）③繰り返し質問の tier-1 を自動回答。
  • 発生抑制の lever は support だけでなく製品側：オンボーディングの不完備·設定のデフォルト不親切·エラー文言の不明確さが問い合わせの大半の源泉（in-product アシスタント論）。

推测

  • 我々の問い合わせは親側がゼロ·家族側に集中する構造【推测：操作質問が大半、情緒質問は LINE 会話に化ける】——すると deflection の主戦場は「LINE の返信テンプレ+リッチメニューの導線」で、help center というより「返信 3 パターンの事前整備」が 8 割を担う（LINE は doc サイトに誘導しても親でもない家族が読まない）。
  • intent mapping の初回素材は Welcome 序列の未達質問（opc-welcome-sequence）と product の FAQ 予測——問い合わせゼロの段から「予測 FAQ 20」を書いておくと初回対応が定型化する。

结论

可行动启发：

  1. 「予測 FAQ 20」を発売前に書く：操作 10（招待方法/家族追加/通知止め/解約…）+不安 10（データはどこに？家族に見れる？途中でやめたら？）——答えはすべてLINE 返信テンプレとして用意（doc サイトには置かない）。
  2. エラー文言を問い合わせ防止素材として設計：失敗時のメッセージに「次に押すボタン」を含める（「エラーです」で終わらせない）——in-app deflection の最小実装。
  3. 週次で問い合わせログの 3 分分類：発生した問い合わせを intent タグで記録（週次リズムの金曜 3 分）——月 10 件を超えた intent は UI/オンボーディング修正の最優先に（support で直さず製品で直す）。
  4. deflection 目標は 40% ではなく「週 3 件以下」に置き換える：solo の実感値で管理（比率より絶対数）——超えた月は製品側の変更を見直すトリガー。

待办 / 下次继续

关联