第9話で整理した声には、すぐ直すべきものと、まだ判断できないものが混ざっています。第10話では、問い合わせ分類、FAQ、商品情報、発信の反応を一緒に見て、会社が検討する改善候補を作ります。
要望をそのまま施策にしない
「分かりにくい」という声があっても、説明文、申込み手順、価格表示、提供内容のどれが原因かは分かりません。声の原文、起きた場面、影響を受けた人、既存の根拠をセットで残します。
AIには「事実から考えられる改善仮説を複数出し、根拠不足のものは検証案として分けてください」と頼みます。決めるのは人です。
小さく試せる順に並べる
影響の大きさ、実施の手間、確認すべき相手、試す期間を入れた候補表にします。たとえばFAQの順番を変える、案内メールに説明を足す、申込み前の確認を追加する、といった小さな試行から始めます。第11話の定例会議では、この候補表を報告の材料にします。
実践
改善候補を三つに絞り、各候補に「根拠」「最初の試し方」「見たい変化」を一行ずつ書きます。お客様への影響がある変更は、実施前に担当者が確認してください。
例：同じ質問が続く理由を分解する
「予約方法が分からない」という問い合わせが多い場合、回答を増やすだけでは改善になりません。案内ページの場所が見つからない、手順が多い、必要な情報が途中で分かる、返信まで時間がかかる、といった仮説があります。第2話の経路、第9話の声、第4話の正式情報を見て、どの仮説に根拠があるかを分けます。
最初の試行は、申込み画面を大きく変えるより、FAQの順番を変える、確認メールに準備物を追記する、担当者の案内文をそろえる、といった戻しやすい変更が向いています。AIには案を複数出させても、優先順位は費用、影響、確認先を知る人が決めます。
試行の結果を残す
試した期間、対象、変更内容、起きたこと、次に決めることを一行で残します。変化が見えなければ失敗と決めず、仮説が違ったのか、期間が短いのか、記録が足りないのかを会議で確認します。
変更を同時に複数行うと理由が分かりません。一度に変えるのは一つを基本にし、元へ戻す判断も決めておきます。
