架空の部品販売会社に、「何時まで受け取れるか」「部品P-20は今あるか」「明日着くか」が届いたとします。営業時間は最新の案内から説明できても、在庫や明日の納期は、現時点の記録と担当者の確認が必要です。FAQに「通常は翌日発送」とあるだけで、明日届くと答えることはできません。

まず最近の質問を集め、固定の説明、最新の記録が必要、担当者の判断が必要の三種類に分けます。同じ文章の中に二種類ある場合もあります。「営業時間と今日の在庫を知りたい」なら、説明できる範囲と確認へ回す範囲を分けた回答案を作ります。AIが文を作れることと、会社として約束できることは別です。

分類の完成見本は「Q-12：営業時間は固定の説明、当日の在庫は最新記録、本日取り置きは社内判断」です。質問の一文を丸ごとAI向けとするより、回答の中身を分けた方が、何を確認へ戻すかが見えます。よくある質問でも、今日・この商品・この顧客といった条件が付けば確認先が変わります。一般的なFAQにある説明が、そのまま個別の約束に使えるとは考えないでください。

この章の根拠：出典1出典2

完成見本は「通常の店頭受取は平日17時まで。臨時休業日は別案内。最終確認日を記載。変更の確認先は店頭責任者」です。これは架空の条件です。営業時間だけを抜き出すと、休日や臨時変更を落とします。商品ごとの条件なら対象品目、受付方法なら必要な資料と受付後の流れを添えます。

古いPDFと現在のページが両方あるなら、どちらを正しい資料にするかを決めます。Microsoftの公式資料では指定した情報源を使う機能や制限を説明していますが、指定しただけで内容が新しくなるわけではありません。更新した資料が回答に使われるまでの仕組みは製品ごとに確認し、変更直後の質問で試します。

FAQの更新例では、臨時休業のお知らせを別の文書へ加えるだけでなく、通常の時間を答える欄からもその条件へ進めるようにします。誰が更新したか、いつから適用か、終了後に戻す必要があるかを記録します。古い回答例をテスト資料にする場合は、現行の答えとして使われないよう区別します。参照先が複数あるときは、正しいものを自社が決める必要があり、AIが自動で会社の意図を理解すると期待しません。

この章の根拠：出典1

質問「今日P-20を二個受け取りたい。何時まで行けばよいか」への架空の回答案は、「通常の平日は17時まで店頭受取を受け付けています。本日の在庫二個と営業状況は担当者が確認します。確認後に受取できるかをお知らせします」です。実際の送信では、当日の案内と在庫の確認、社内の対応方法を踏まえて人が確定します。

この案がFAQと違う理由は、説明可能な時間と未確認の在庫を別にしたことです。単に「17時まで来てください」と答えると、在庫も受取も確定したように読めます。AIへの依頼条件には、参照資料、対象の質問、未確認を残す欄、出してはいけない約束を書きます。条件を書けば誤りがなくなるという保証はありません。

「AIが答えに根拠のリンクを付ければ確認は不要か」という疑問には、リンク先に質問への答えと条件が本当にあるかを見ます。営業時間のページへリンクしていても、本日の在庫や個別納期の根拠にはなりません。担当者は回答案の文ごとに、FAQの説明、最新記録の確認、人の判断のどれから来たかを確かめます。根拠がない文を削るか確認待ちへ直すことで、顧客へ送る範囲を決められます。

同じQ-12でも、当日が臨時休業なら完成文は変わります。「本日は店頭受取を行っていません。在庫二個の有無と、別日に受け取れる条件を担当者が確認します」が架空の修正例です。通常の17時を残してから小さく例外を付けると、来店してよいと読まれる場合があります。質問に直接影響する例外を先に示し、根拠の範囲だけで回答を組み立てます。

この章の根拠：出典1出典2

問い合わせQ-12の引継ぎ見本は「P-20二個の本日受取希望／FAQは平日17時まで／在庫と本日の営業状況は未確認／店頭担当が確認／状態：引継ぎ待ち」です。次の担当は質問を読み直すだけでなく、何を確認すれば回答できるかが分かります。不要な個人情報は広い一覧へ載せません。

状態は、引継ぎ待ち、担当が受領、確認中、返答済みなどに分けます。担当が不在の場合の代わり、営業時間外の案内、回答が遅れている件を誰が見るかも決めます。返信を送ったことと、顧客の用件が解決したことは同じではありません。未対応をなくすには、状態の終点を自社の仕事に合わせて決めます。

引継ぎ先が受け取った後に「どの商品か不明」と戻した場合は、受付の聞き方を直します。商品番号が分からない顧客には、必要な写真や名称をどの方法で受け取るかを社内で決めます。一方、最初から全員へ大量の質問を求めると、営業時間だけを知りたい人にも負担が増えます。質問の種類に応じて必要な条件を聞き、担当へ渡す前の不足だけを補う設計にします。

再開の記録は「店頭担当がQ-12を受領。在庫二個は確認できた。取り置き期限は責任者へ確認中。顧客への返答はまだ」です。確認が一つ終わったことを、問い合わせ全体の解決済みへ変えません。複数の担当へ分かれる場合は、質問ごとの結果を最終の返信担当へ戻す場所を決めます。顧客に何度も同じ説明を求めないためにも、最初の質問と追加の確認を同じ番号へ残します。

この章の根拠：出典3

比較の一案は、担当者がFAQを探して返す方法です。質問の数が少なく条件が単純なら、検索しやすいFAQと引継ぎ表だけで改善する場合があります。AI回答案を使う方法では、言い方が違う質問を整理する候補になりますが、根拠と条件の照合、資料更新、引継ぎの運用が増えます。個別の在庫や注文変更が中心なら、回答文章より元の記録を確認できる仕組みが先です。

試行では営業時間変更、在庫なし、希望納期に間に合わない、複数の質問、担当者不在を含めます。答えが出た割合だけでなく、根拠の違い、未確認を約束に変えた例、引継ぎ後に止まった例を見ます。費用も質問量、資料整備、設定、確認時間、保守で変わり、架空の対応例から削減額は言えません。

試行結果の見本は「通常時間の回答案は条件付きで作れた。臨時休業の資料が古く、回答を修正した。在庫の質問は担当へ渡せたが、受領の印がなく返答済みか分からなかった」です。これは想定結果です。次の修正は、FAQの正しい資料をそろえることと受領状態を表示することに分けられます。回答の文章を長くするだけでは、この二つの問題は解決しません。

よくある「チャットのAIを入れれば24時間対応になるか」という問いでは、文章を返せる時間と人が在庫や注文を確かめられる時間を分けます。時間外にも受付できる仕組みを選んだ場合は、確認を始める時間、緊急の連絡方法、返答の見込みを自社の実態に合わせます。人が不在なのに即時解決を約束する回答を、試行で見付ける対象へ入れます。

この章の根拠：出典1出典2出典3

問い合わせ対応をAIへ丸ごと渡す前に、会社として何を説明でき、何を確認してから約束するかを分けます。Q-12の完成見本は、通常の時間と本日の在庫を混ぜず、店頭担当へ確認を渡す形です。

下の試行票で、自社の質問、FAQ、未確認の戻り先を一組にできます。外部への送信を始める票ではなく、担当者が回答案と引継ぎを試すための資料です。

この章の根拠：出典1出典2出典3