ux-contact-support

お問い合わせとサポートのスキル

このスキルの動作 (最初にお読みください)

これは生成型のスキルであり、不快な事実から始まります: サポートへのお問い合わせの約64%はUXの失敗が原因です — 情報の欠落や不明瞭さ、サービスの問題、行き詰まり、あるいは複雑すぎるように見えるタスク。つまり、既定の直感 (「お問い合わせフォームを追加する」) は症状を扱っているにすぎません。このスキルの最初の一手は、セルフサービスによって必要性そのものを減らすことであり、その後、本当に正当化される場合に人間への連絡を簡単で予測可能にします。よくある失敗: フォームの前にFAQやヘルプがない、「お問い合わせ」ボタンがユーザーを不意のチャネルへ送り込む、待ち時間や期待値が示されていない、自分がボットだと認めないボット、エラー発生時に何の助けも提示されない、そして中断や圧力を伴うフィードバック依頼。そこでこのスキルは次をゲートします:

1. ユーザーがなぜサポートに連絡するのか、チームが何を維持できるのかを明らかにする — これがチャネルの順序を定め、セルフサービスへの投資規模を決めます。
2. 常に当てはまる中核を適用する — 優れたセルフサービスでそらし、連絡を簡単で予測可能にし、ループを閉じる。
3. 文脈に依存する判断 (どのチャネルをどの順序で、チャットボットか人間か、ヘルプボタンの配置) をトレードオフとともに明らかにする。

その後、検証のために ux-heuristics-audit、ux-accessibility-audit、ux-aesthetics-audit、ux-microcopy-audit、ux-dark-patterns-audit、ux-mobile-responsiveness-audit に引き継ぎます。

スコープと構成 (docs/orchestration-policy.md §9 に準拠): このスキルはサポート体験とそのサーフェスを対象とし、より狭いスコープのスキルを再導出するのではなく組み合わせます。中核の子: お問い合わせフォームのフィールド設計を ux-inputs-and-forms 経由で。サブパートを所有するピア (委譲): ヘルプ検索は ux-search へ、ツールチップの作り込みは ux-tooltips へ (到達した場合、それらが当該サブパートを所有します)。下流 (提案はするが自動構築はしない): より深いエラーメッセージ/回復設計は ux-error-recovery 経由で。継承し、再生成しない: 既存のデザインシステムのもとでは、色/タイプ/スペーシングはそのトークンから取得します — ゼロから設計する場合にのみ、それらを設定します。

---

ステップ0 — 設計前に文脈を確立する

不明な場合は尋ねてください。回答なしで進める場合は前提を明言してください:

• ここではなぜユーザーがサポートに連絡するのか? 頻度順の4つの要因: 情報の欠落/不明瞭、サービスの問題 (支払い失敗、商品の破損)、通過できない行き詰まり、複雑すぎるように見えるタスク。ほとんどは上流で修正可能です — 最も問い合わせの多いトピックは、単なる人員配置ではなく、セルフサービスと製品修正のためのバックログです。
• チームは何を維持できるか? ライブチャットと電話はユーザーが好むことが多いものの、タイムゾーンをまたいで人員を配置するのが最も困難です — チャネルの順序は、どちらか一方だけでなく、ユーザーの好みとあなたのキャパシティの両方を反映しなければなりません。
• プラットフォームとエントリーポイント — ユーザーはどこで助けを探すのか (Webのフッター / モバイルの設定)、そしてどの瞬間 (エラーページ) に連絡が予測可能になるのか?

---

常に適用する中核 (ほぼすべてのサポート体験で正しい)

まずそらす — ユーザーが自力で解決できるようにする

• セルフサービスを先頭に置く。 FAQ / ヘルプコンテンツを最初の選択肢として提示し、待たずに問題を解決できるようにします。人間のチャネルは、特定の複雑な問題のために取っておきます。
• ヘルプページをスキャンしやすくする。 よくある質問を先頭に、カテゴリ別に整理し、段落は短く、見出しは太字で、リストや明確な階層、キーワードの強調を — 人は自分の問題を探すためにスキャンし、読むことはしません。
• 平易な言葉で、適切な形式を使う。 専門用語は使わず、短い能動態の文で。簡潔な文脈内ヘルプにはツールチップを使い、ステップバイステップのガイドにはスクリーンショット/短い動画とテキスト版を添えます (誰もが動画を見られるわけでも、見たいわけでもありません)。
• FAQは補助として扱い、時間とともに縮小していく。 実際のシグナル (サポートチケット、アンケート、検索クエリ、フォーラム) から構築します。長期的な目標は、製品とドキュメントがより明確になったことで、「よくある」質問が減ることです。

問い合わせを簡単で予測可能に

• どこからでも到達可能に。 標準的な場所（Web フッター、モバイル設定）にサポートリンクを置き、さらに一目でわかる ? の丸囲みヘルプアイコンを用意します。メニューでは、ヘルプは下部付近に配置します（フィードバックはそのすぐ上、サインアウトは誤操作による退出を避けるため最下部）。
• エラーが起きた時点でヘルプを提供する。 良いエラーメッセージは、何が起きたのかと次のアクションを伝えます。そしてそのアクションが「ヘルプを得る」である場合は、適切なチャネル（単純な内容なら FAQ／記事、複雑な内容ならエージェント）へその場でリンクします。
• ユーザーが判断する前に期待値を設定する。 「お問い合わせ」から、いきなり予期しないビデオ通話に放り込まれることがないようにします。応答時間の目安、提供が必要な情報、そして通話やチャットを録音する場合はその旨を、最初に明示します。

誠実なチャット対応

• 「チャット」／「ライブチャット」とラベル付けする（それ以外の気の利いた名前は使わない）し、ユーザーが期待する場所 — ヘルプ／お問い合わせページ — に配置します。
• ボットであることをすぐに開示する。 チャットボットが最初にトリアージを行う場合は、最初からそう伝えて、ユーザーが言葉遣いと期待値を調整できるようにし、本当の問題については人へ引き継ぎます。ライブサポートがオフラインの場合は、その旨を伝え、代替手段（FAQ、メール）を提示します。

フィードバックを循環させる

• 解決後にフォローアップする。 体験が新しいうちに、「この件は解決しましたか？」という短いメールを送ります。チャットの場合は、ユーザーの記録用にトランスクリプトを添付します。
• 敬意をもってフィードバックを求める。 フォームは短く、評価を最初に（自由記述のコメントは任意）します。満足した瞬間の後（タスクの途中ではなく）に依頼します。押し付けがましいポップアップは決して使わず、フィードバックを必須にすることも決してしません。

---

状況に応じた判断（押し付けず、提示する）

判断	適用する場合	避ける／適応させる場合	既定の推奨
どのチャネルを、どの順序で	ユーザーの好みとチームのキャパシティで順序を決める — FAQ／メールはスケールし、電話／チャットは即時性があるが人員負荷が高い	小規模チームが維持できない 24 時間 365 日のライブチャットを宣伝する（提供しないより悪い）	FAQ を最優先、次にメール。電話／チャットは人員を配置できる場合にのみ目立つ形で提示する
チャットボットか、人優先か	量が多い場合に、ルーティング前にボットがトリアージして情報を収集する	ボットであることを隠す、または人へつながる道を塞いでユーザーを閉じ込める	事前開示付きのボットトリアージと、人への明確な引き継ぎ
そもそも FAQ を用意するか	実際の質問から作られた、クイックリファレンスの補足として	プロダクトの発見性の低さを覆い隠す捨て場として	補足としては「はい」。増え続ける FAQ はプロダクトを直すシグナルとして扱う
ヘルプボタンの配置	常時アクセス用のフローティングボタン（スクロールに追従）。複雑なサイトはヘッダー、単純なサイトはフッター	ユーザーが探し回らないと見つけられないヘルプリンク	サイトの複雑さに合わせる。ヘルプは常に 1 クリック以内に
ビデオとテキストのヘルプ	見たほうが役立つ複雑な操作	ビデオのみ（見られない／見ようとしないユーザーを排除する）	両方を提供する。テキストは常に利用可能に
満足度測定（NPS／CSAT）	長期的にその傾向に基づいて行動する場合	一度きりの見せかけのスコアリング、またはタスクを中断して尋ねること	軽量でタイミングよく。改善と結び付ける（指標の妥当性 → OKR に使う場合は PM が監査する）

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをインストール可能なスキルの name で指定します。そのスキルがインストールされている場合にのみ呼び出してください。インストールされていない場合でも、このスキル自体のコアにこれらのルールがすでに含まれているため、ブロックせずにそのまま進めてください。

生成または改訂した後は、完了と宣言するのではなく、結果を監査レンズに引き渡してください。これらは候補レンズです — 姿勢は docs/orchestration-policy.md で設定するか、全体を ux-design-review 経由でルーティングしてください。ここでは、heuristics、microcopy、dark-patterns は Tier A（自動実行）、accessibility、aesthetics、mobile-responsiveness は Tier B（提案） です — 既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は使用状況に絞り込まれます。mobile-responsiveness はモバイルの場合にのみ適用されます。ユーザーが特定の目的でこのスキルを呼び出した場合は、その範囲を尊重してください。

• ux-heuristics-audit (Tier A) — ヘルプとドキュメント（見つけやすく、タスク指向）、システム状態の可視性（待ち時間、ボットか人間か、チャットの可用性）、適切なチャネルへのエラー回復ルーティング。
• ux-accessibility-audit (Tier B — 提案。デザインシステムがある場合は絞り込み) — ヘルプアイコンのラベリング、スキャンしやすい見出し構造、チャットのキーボード／スクリーンリーダー操作性、ヘルプ動画のキャプション／トランスクリプト。
• ux-aesthetics-audit (Tier B — 提案。デザインシステムがある場合は抑制) — テキストの壁ではなくスキャンしやすいヘルプページ、整理された問い合わせ手段。
• ux-microcopy-audit (Tier A) — このスキルはコピーに依存します。期待値の設定、ボットの開示、エラー時の次のステップ、チャネルラベル、FAQ の文言、フィードバックの促し。
• ux-dark-patterns-audit (Tier A) — サポート特有の罠: 強制的または罪悪感を煽るフィードバック依頼、押しつけがましいポップアップ、人間になりすますチャットボット、人間への唯一の経路を意図的に困難にすること。依頼は敬意を払い、スキップ可能であるべきです。
• ux-mobile-responsiveness-audit (Tier B — 提案) — 問い合わせ手段のタップターゲット、小さな画面でのチャットの使いやすさ、コンテンツを覆わないスティッキーヘルプボタンの配置。

監査で矛盾が浮上した場合（例: ビジネス側が毎回のチャット後に必須のアンケートを求めている）、主要なタスクへと立ち返って解決してください: ユーザーは問題を抱えて来たのです — それを解決し、それから入力を穏やかに求めましょう。決して通行料として求めてはいけません。

---

よくある do／don't のパターン

❌ しない	✅ する
いきなり問い合わせフォームに飛ばす	セルフサービスを先に案内する。ほとんどの問い合わせは修正可能な UX の失敗である
ヘルプテキストの壁	スキャンしやすく: よくある質問を先頭に、カテゴリ分けし、見出し＋リストを使う
専門用語だらけの記事	平易で短く能動的な言葉。簡単なヘルプにはツールチップを使う
「お問い合わせ」→ 突然のビデオ通話	チャネル、応答時間、必要な情報、録画の通知を先に示す
ヘルプリンクを埋もれさせる	標準的な場所＋? アイコン。サイトの複雑さに応じてフローティング／ヘッダー／フッターに配置
エラー発生時にヘルプがない	エラーが起きたその場で適切なチャネルを提示する
人間のふりをするボット	最初にボットであることを開示する。本当の問題は人間に引き継ぐ
対応できない 24 時間年中無休のチャットを宣伝する	ユーザーの好みとチームのキャパシティの両方でチャネルを並べる
タスク中に必須またはポップアップのフィードバック	短く、評価を最初に、任意で、良いタイミングの後に実施する
増え続ける FAQ を成功とみなす	製品の発見可能性を修正するシグナルとみなす
確認せずに出荷する	heuristics ＋ accessibility ＋ aesthetics ＋ microcopy ＋ dark-patterns ＋ mobile-responsiveness に引き渡す

---

出典のレッスン（Uxcel）

• Contact Support
• Design Guidelines for Help Center & Support Pages