コワーキングスペースの問い合わせAI｜案内・予約・現地対応の分け方

受付スタッフが見学対応をしている間に、「今日ドロップインできますか」「法人登記は可能ですか」「入口の鍵が開きません」といった問い合わせが重なることがあります。コワーキングスペースの窓口には、定型案内、空席確認、契約判断、現地対応という性質の異なる用件が、同じ問い合わせとして届きます。 コワーキングスペースの問い合わせAIは、すべての質問へ自動回答する仕組みではありません。**案内、希望受付、予約確定、契約判断、現地対応**を切り分け、AIが参照する正本と、外部システムや担当者へ渡す条件を先に決める必要があります。 ## 問い合わせAIの担当範囲を5つの状態に分ける 営業時間や設備は、承認済みの情報から案内できます。一方、「今から必ず席を使えるか」にはリアルタイムの空席情報が必要です。「この会社が登記できるか」は個別の契約判断に当たり、「鍵を開けてほしい」という依頼には本人確認と現地での権限が関係します。 |状態|例|AIの役割|人・外部システムの役割| |---|---|---|---| |案内|営業時間、料金表、設備|正本から説明|内容を承認・更新| |希望受付|見学希望、折返し希望|必要項目を整理|受付可否を確認| |予約確定|予約、空席、利用開始|結果を確認できる導線へ案内|在庫を確認して予約を確定| |契約判断|法人登記、審査、解約|公開済みの一般条件を案内|個別の契約可否を判断| |現地対応|入室不能、事故、騒音|所在と緊急性を確認|解錠、安全確認、現場対応| AIの回答には、現在どの状態にあるかを明記します。「見学希望を受け付けました」と「見学予約が確定しました」では、利用者が次に取る行動が異なるためです。外部システムの処理結果を確認できない場合は、予約確定と表示してはいけません。 運用表には、各状態で表示できる文言、参照元、回答を止める条件、次の担当者を記載します。これにより、AIが説明できる範囲を広げる際にも、担当範囲を確認しながら判断できます。 ## 利用者と用件を最初に分類する 同じ質問でも、入会前の検討者、ドロップイン利用者、月額会員、来訪者では必要な案内が異なります。会話の最初から氏名や会員番号を求めるのではなく、利用状態、対象拠点、用件を少数の選択肢で確認します。 入口では、たとえば「利用を検討中」「ドロップイン・予約」「見学」「契約中の会員」「現地で困っている」に分けます。その後に対象拠点を確認し、料金、設備、契約、現地トラブルなどの用件を特定します。拠点が不明なまま、位置情報などから最寄り拠点を推測して回答しないことが重要です。 複数の用件が含まれる質問は分割します。「料金を知りたい。今日の個室も押さえたい」という質問では、公開済みの料金を案内した後、個室の空き確認と予約確定だけを外部予約システムへ渡します。一つのFAQで両方へ回答しようとすると、固定情報とリアルタイム情報が混在します。 現地で困っている利用者には、通常の分類を続けません。入室不能、けが、煙、犯罪のおそれなどを示す言葉が含まれる場合は、拠点、現在地、発生状況、安全上の緊急性を優先して確認し、承認済みの連絡先へ切り替えます。 ## 料金・設備・営業時間を拠点別に管理する 定型案内であっても、すべての拠点に同じ内容が当てはまるとは限りません。営業時間、休館日、ドロップイン料金、会議室、電話ブース、Wi-Fi、飲食、オンライン会議、郵便受取などは、拠点ごとに確認できる状態で管理します。 正本には、対象拠点、対象プラン、確認日、適用開始日、失効日、更新担当、参照URLを持たせます。料金改定の前後で資料が混在する期間は、利用日や契約開始日を確認できなければ断定しません。臨時休業や営業時間の変更は通常情報より優先し、終了後は告知を失効させます。 設備は「ある・ない」だけでなく、予約要否、利用時間、追加費用、禁止事項を分けて登録します。ただし、設備の存在と個別の空き状況は別の情報です。会議室があることや公開料金は案内できても、希望時刻に空いているとは限りません。 拠点を特定できない質問には、候補となる拠点を示して利用者に選んでもらいます。旧版と新版で内容が競合している場合や、適用日を判断できない場合は回答を止め、更新担当者へ確認を回します。 拠点情報の更新手順は、[AIチャットボットのナレッジ更新方法](/usage/ai-chatbot-knowledge-update-process)を参考にできます。新しい情報を追加するだけでなく、旧版の失効、公開前の確認、更新責任者まで決めてください。 ## ドロップインと見学は受付状態を明示する ドロップインについては、利用可能時間、受付方法、本人確認、支払方法、満席時の扱いを、公開済み情報の範囲で案内します。予約・決済機能との連携可否を確認できていない運用では、承認済みの予約ページや申込ページを会話中に案内し、確定処理は結果を確認できる仕組みへ渡します。 「今から一席使えますか」と聞かれても、リアルタイムの空席を参照できなければ利用可能とは回答しません。ドロップインを受け付けている時間帯や利用手順を案内したうえで、最新の予約ページまたは受付窓口を示します。 見学希望をチャットで受ける場合は、希望拠点、候補日時、人数、利用目的、連絡方法に項目を絞ります。受付後は「希望を受け付けました。予約はまだ確定していません」と表示し、次の確認者と連絡経路を示します。根拠のない折返し時刻は約束しません。 送信に失敗した場合は、「受付済み」と表示せず、代替フォームや電話を案内します。利用者側の送信完了表示と担当者側の受信状態が一致しているか、公開前テストで確認する必要があります。 ## 空席と予約確定は外部システムへ渡す 空席は随時変わるため、固定ナレッジから回答してはいけません。予約システムとの連携がなく、最新状態を確認できない場合は、「空席があります」と断定せず、最新の予約ページまたは受付担当へ案内します。 外部予約URLへ誘導する方式、空き状況だけを参照する方式、予約を書き込む方式では、AIが負う責任の範囲が異なります。自施設で採用する方式を検討するときは、[チャットボットと予約システムの連携](/usage/chatbot-reservation-system-integration)で、それぞれの違いを確認できます。 予約確定と表示するには、外部システム上で予約ID、対象拠点、日時、人数、処理結果を確認できることが前提です。利用者への通知も必要な運用であれば、その通知が成功したかも確認対象にします。 処理結果が不明な場合は、自動で再送しません。同じ内容を再送すると、二重予約につながるおそれがあるためです。「確認中」または「担当者が確認します」と表示し、予約記録を確認できる担当者へ渡します。 ## 法人登記・郵便・契約条件は担当者が確認する 法人登記、住所利用、郵便受取、来客対応、追加カード、最低利用期間、解約は、プランや契約によって条件が変わります。対象プラン、必要書類、審査の有無、追加費用、利用開始日など、公開済みの一般条件は案内できます。ただし、個別の申込可否や審査結果をAIが確約してはいけません。 「登記できます」と一律に回答すると、対象プランや審査条件が抜け落ちます。質問の対象を特定できない場合は、一般条件であることを明記し、正式な可否は担当者が申込内容を確認した後に決まると伝えます。 郵便受取や住所利用についても、公開情報に記載された対象プランと利用条件までを案内範囲とします。申込者の業種、利用目的、提出書類などを踏まえた判断は、契約担当者へ引き継ぎます。 契約書や本人確認書類を通常のチャットへ入力させる前に、安全な受付経路を確認してください。見学受付や契約相談で扱う情報の境界は、[AIチャットボットに個人情報を入力する前の確認項目](/usage/ai-chatbot-personal-information)も参考になります。 ## 入退室・騒音・事故は現地対応へ切り替える 入室できない、カードを紛失した、他の利用者とトラブルになった、設備が動かない、けが人や煙を確認したといった相談では、FAQを続けるより現地対応を優先します。拠点、現在地、発生状況、安全上の緊急性、連絡可能な方法を短く確認し、時間帯別の窓口へ渡します。 夜間に「入口の鍵が開きません」と連絡があった場合は、料金や営業時間の案内を挟みません。どの拠点のどの入口にいるかを確認し、承認済みの夜間窓口へ切り替えます。AIは解錠できるように振る舞わず、本人確認が終わる前に入室方法や機密情報を開示しません。 火災、急病、犯罪のおそれがあり、差し迫った危険がある場合は、通常の聞き取りを中断します。まず利用者自身の安全を確保できる場所への退避を促し、次に消防・救急・警察など状況に応じた緊急機関への連絡を案内し、その後に施設が承認した緊急窓口を示します。AIは安全性を判断せず、煙、意識障害、暴力など緊急機関への連絡条件に該当する申告があれば、現地責任者からの返答を待たせません。 騒音、席の占有、設備故障については、利用者の申告と確認済みの事実を区別します。「入口の機械が故障している」は利用者からの申告であり、AIが故障を確認した事実ではありません。相手の責任や対応結果を断定せず、場所、時刻、状況を担当者へ渡します。 ## 引継ぎ要約と拠点別連絡先を決める 担当者へ会話全文だけを送ると、確認すべき点が埋もれ、利用者が同じ説明を繰り返すことになります。引継ぎ要約には、利用者区分、対象拠点、用件、希望、AIが案内した内容、未確認事項、緊急性、希望する連絡方法を含めます。 要約では、利用者の申告、正本で確認済みの事実、未確認事項を分けます。AIの推測を事実として記録せず、担当者が次に確認する項目を残します。たとえば入室不能なら、対象入口、発生時刻、表示されたエラー、本人確認の実施状況を区別します。 連絡先は拠点と時間帯で管理します。通常受付、夜間、設備故障、安全上の緊急事態で窓口が異なる場合は、それぞれの対応時間、失効日、代替連絡先も必要です。担当者が不在のときに同じ連絡先を繰り返し案内しないよう、次の窓口まで定めます。 契約判断や現地トラブルの切替条件を具体化するときは、[チャットボットの有人切り替え設計](/usage/chatbot-human-handoff-design)で、引継ぎ要約や時間帯別の担当範囲も確認できます。 ## 変更日と公開前テストを運用表へ残す 料金、営業時間、キャンペーン、設備、契約条件、連絡先が変わった場合は、正本とテスト項目を同時に更新します。新しい資料を追加するだけでは、AIが旧資料を参照する可能性が残ります。旧資料を失効させ、適用開始日と変更内容を運用表へ記録します。 公開前には、通常の営業時間、別拠点の料金、今日の空席、見学希望、法人登記、郵便受取、夜間の入室不能、事故、送信失敗をテストします。回答文だけでなく、選ばれた状態、参照した拠点、受付結果、引継ぎ先、利用者への表示を確認してください。 テスト結果は、合格、条件付き合格、保留、不合格に分けます。条件付き合格には「空席質問は予約ページへ案内する」などの公開条件を付けます。保留には確認担当と期限を記載し、不明な状態でAIに回答させません。 運用開始後に問題が見つかった場合は、回答文だけを直すのではなく、分類、正本、送信処理、担当表のどこで起きたかを切り分けます。原因を特定してから、正本の更新、質問分類の修正、代替窓口の追加など、対応箇所を決めます。 ## 拠点別の回答範囲表を作る 複数拠点を運営する場合は、共通情報と拠点固有情報を分けます。ブランド共通の利用マナーは共通正本で管理し、営業時間、設備、料金、休館日、連絡先は拠点正本で管理します。回答時に対象拠点を特定できなければ、候補を示して確認し、推測で最寄り拠点を選びません。 回答範囲表には、質問例、回答に必要な前提、参照元、回答できる内容、断定しない内容、引継ぎ先、更新責任者を記載します。たとえばWi-Fiの有無は案内できても、通信速度や特定の会議ツールを安定して使えることまでは保証しない、といった境界を明文化します。 会議室に関する質問では、「設備が存在する」「予約が必要である」「公開料金はいくらか」という固定情報と、「希望時刻に空いている」という在庫情報を分けます。後者を確認できない場合は、予約ページまたは担当者へ渡します。 新拠点の準備中は、公開開始日より前に予定情報を確定情報として案内しないよう、適用開始日を設定します。閉店や臨時休業では、通常営業時間より優先する告知と失効日を用意します。キャンペーンも、対象期間、対象プラン、併用条件を確認できない場合は一般化しません。 ## 問い合わせ場面ごとの確認表 前段の判断を会話へ反映するときは、回答を重ねるのではなく、質問ごとに状態と完了条件を確認します。 |質問|選ぶ状態|完了条件| |---|---|---| |見学したい|希望受付|送信成功を確認し、未確定表示と次の確認者を示す| |今から一席使いたい|予約確定|最新の空席と処理結果を外部システムまたは担当者が確認する| |料金を知り、今日の個室も押さえたい|案内と予約確定に分割|料金は正本から回答し、空き確認だけを予約導線へ渡す| |法人登記をしたい|契約判断|一般条件の案内後、個別可否を契約担当者へ渡す| |入口の鍵が開かない|現地対応|拠点、入口、緊急性を確認し、時間帯別の窓口へ渡す| 利用者への表示と実際の処理状態が一致しない場合は完了扱いにせず、未確認事項と次の担当者を示します。 ## 導入前の運用チェックリスト - 拠点、利用者区分、用件を少ない質問で分類できる - 案内、希望受付、予約確定、契約判断、現地対応の表示を分けている - 料金、営業時間、設備に確認日と更新責任者がある - 拠点不明、適用日不明、旧版との競合時に回答を止められる - 空席を固定ナレッジから断定しない - 外部予約の成功を確認できないときに確定表示をしない - 法人登記、郵便受取、解約の個別判断を担当者へ渡す - 個人情報や本人確認書類を扱う安全な別導線を決めている - 夜間の入退室不能と安全上の緊急事態を短い確認で切り替える - 引継ぎ要約で申告と確認済み事実を分けている - 時間帯別の連絡先、失効日、代替窓口を管理している - 送信失敗時に代替フォームや電話を案内できる - 旧料金、別拠点、複合質問、外部システムの障害を公開前に試している 各項目には担当者と、未充足の場合の公開制限を記録します。たとえば空席参照を確認できない場合は、空席回答を公開せず予約ページへの案内に限定します。夜間窓口が未整備なら、夜間トラブルを通常FAQで受け続けず、利用可能な代替連絡先を先に確定させます。 チェック結果の判定方法は、公開前テストで定めた合格、条件付き合格、保留、不合格に統一します。このチェックリストでは各テスト結果への参照先を記録し、未確認の項目をAIの推測で補わないことを公開可否の判断基準とします。 ## 運用開始後に見る記録 公開後は、質問件数だけでなく、拠点を特定できなかった会話、空席に関する質問、予約ページへの移動、有人引継ぎ、誤案内、送信失敗を分けて記録します。件数の多さだけで成果を判断せず、利用者が予約ページ、担当者への連絡、現地窓口など、必要な次の行動へ進めたかを確認します。 回答不能が多くても、すべての質問をAIへ追加する必要はありません。現地判断が必要な質問なら、回答を増やすより、引継ぎまでの質問を短くする方が適切です。一方、営業時間や持ち物に関する表現違いが多い場合は、正本へ質問例を追加し、更新責任者が承認します。 送信失敗が続く場合は回答文ではなく送信処理を確認します。別拠点の情報を案内した場合は、利用者分類や拠点選択の処理を見直します。古い料金を案内した場合は、旧版の失効と適用日の管理を確認します。このように問題を分類、正本、送信、担当表へ分けると、直す場所を判断しやすくなります。 引継ぎ後の結果も、必要な範囲で「見学調整」「契約説明」「現地対応」「連絡不能」などに分けます。分析のために会話本文や個人情報を過剰に残さず、記録する項目と保存期間を運用方針に沿って決めます。 ## 一拠点から段階的に広げる 最初から全拠点と全用件を公開すると、料金や設備の違い、引継ぎ先の誤りを検証しにくくなります。まず情報が整っている一拠点を選び、営業時間、アクセス、公開設備など、個別の在庫を参照しない案内から始めます。 次に、外部予約ページへの案内、見学希望の受付、有人引継ぎを追加します。この段階では、利用者への表示と担当者側の受信状態が一致するか、送信失敗時に代替経路へ移れるかを確認します。 法人登記、解約、夜間トラブルは、担当表と本人確認の導線が整ってから対象を広げます。一般条件を説明する担当範囲と、個別判断や現地対応へ切り替える条件を別々に承認します。 別拠点へ展開するときは、最初の拠点の回答をそのまま複製しません。拠点固有の正本、連絡先、休館日、設備、テスト結果を作り、共通部分と差分を承認します。展開後も拠点別の問い合わせを確認し、共通化できる回答と現地判断として残す用件を切り分けます。 Socratesで実現可能な公開案内と運用範囲を確認したい場合は、拠点別の正本、回答停止条件、外部予約システムへ渡す範囲、有人対応へ切り替える条件を整理したうえで、公式窓口へご相談ください。 ## よくある質問 ### AIだけで見学予約を確定できますか 空き枠を参照し、予約処理の結果まで確認できる連携がなければ、見学希望の受付または外部予約ページへの案内までにします。「希望を受け付けた状態」と「予約が確定した状態」を明確に分けて表示してください。 ### 今日の空席を回答できますか 最新の空席を参照できる仕組みを確認できる場合に限ります。固定ナレッジから空席を断定せず、最新の予約ページや受付窓口へ案内します。 ### 法人登記の可否をAIが判断できますか 対象プランや必要書類など、公開された一般条件は案内できます。ただし、個別の申込可否、審査結果、契約確定は担当者が判断します。 ### 入退室トラブルもAIで対応できますか 状況を確認して適切な窓口を案内するところまでは可能です。本人確認、解錠、安全確認、現地判断が必要な場合は、拠点と時間帯に対応した担当者へ渡します。 ### 複数拠点の情報を一つのAIで案内できますか 複数拠点を扱う設計は可能ですが、回答前に対象拠点を確認し、料金、営業時間、設備、休館日、連絡先を混同しない正本管理が必要です。拠点ごとに公開前テストを行い、共通情報と固有情報を分けて承認します。