名前・おおよその購入時期・受取先の一部など代わりの識別子で候補を絞り、「この人で合っているか」を人に確認してもらい、勝手なマッチングで他人の情報を露出させません。
顧客からの問い合わせ受付
新規も、再度の問い合わせも、急ぎの相談も、見込みのある相談も。どのチャネルから来てもVelros AIが一つの列にまとめ、返信の下書きまで用意します。
- 初回応答時間(FRT)
- 初回接触解決率(FCR)
複数のチャネルから新規の問い合わせ、再問い合わせ、緊急の問い合わせ、相談の見込みに関する情報を集め、重複を取り除いて優先順位を付けます。
中小企業では問い合わせが一つの窓口には来ません。LINE公式アカウント・Instagram DM・個人の携帯・店舗の固定電話が同時に鳴り、一人で対応して取りこぼします。特に新規顧客の購入直前の質問と、すでに買った顧客のクレームが同じ受信箱に混ざり、急ぎのクレームが見積りの問い合わせに埋もれたり、その逆が起きたりします。対応の遅れそのものが売上の損失なのに、誰が何をいつ尋ねたかの記録が残らず、毎回一から対応し直す繰り返しの労働が生まれます。
こうした問い合わせが、こう処理されます。
実際に入ってくる仕事を集め、それぞれの段階で何を基準に判断するのかまで続けて残します。
-
チャネル統合受付
LINE・Instagram・メール・DMから届いた問い合わせを時系列の一つのキューに合流させ、同じ顧客の過去のやり取りを自動でひも付けて文脈を復元します。
判断 発信者の識別子(電話・メール・チャネルID)で既存顧客かどうかを判定。初めての相手なら「新規」、履歴があれば「再問い合わせ」として初期タグを付ける。 -
意図の分類
問い合わせを新規(購入前)・再問い合わせ(進行中の確認)・緊急(今日中に答えないと損失)・クレーム(不良・不満・返金)にラベリングします。
判断 「今日・今・急ぎ・決済したい」のような時間圧の信号と、「傷・不良・返金・怒り」のような不満の信号を優先順位の軸に使う。緊急・クレームは新規・再問い合わせより常に上。 -
ルーティング
見積り系は見積り担当、配送系は注文・配送、不良・返金はカスタマー責任者、請求書は経理に割り当て、担当者不在時は代替の割り当てルールを適用します。
判断 処理に必要な権限(返金の承認・価格の調整など)が誰にあるかで割り当てる。最初の対応者が終結まで行える人であれば、再接触が減る。 -
一次受付の返信と情報の依頼
「受け付けた、いつまでに答える」という確認と、処理に必要な最小限の情報(注文番号・購入日・写真など)を尋ねる下書きを作ります。
判断 即答できる単純な問い合わせ(営業時間・場所・在庫)はそのまま答えの下書き、判断・費用・個人情報が絡む件は受付だけして人へ。 -
ケースカードの生成
顧客・チャネル・意図・締切・担当・次のアクションを載せたケースカードを作り、未解決として追跡します。
判断 終結の条件(顧客の満足・返金の完了・見積りの送付など)を明示。条件を満たすまでキューから消えないようにする。
本人確認ができなければ、むやみに開きません。
現場で実際に引っかかる例外を、あらかじめ決めておきます。ルールが通らない場面を無理に処理せず、根拠とともに人へ渡します。
緊急度の高いクレームを主のケースとして開き、新規の購入意向は別のケースに分けて、両方を生かします。
無理にラベルを確定せず「未分類・人の確認が必要」としつつ、締切のタイマーは最も急ぎの等級で掛けて放置を防ぎます。
補償と個人情報が絡む件は、人が見ます。
お金・契約・個人情報・ブランドがかかる実行は下書きまでにとどめ、送信と確定は人の承認を経てから動きます。
-
緊急・クレームの最終返信の送信
トーンと補償の有無がブランドの信頼に直結するため、人が読んで送ります。
-
顧客の個人情報で履歴を合わせるマッチング
誤マッチングだと他人の情報が露出するため、人が同一人物かを確認します。
-
補償・例外処理の約束(無償の再送・一部返金)
費用と先例が生じる判断なので、人・カスタマー責任者の役目です。
-
重要顧客・取引先の件の特別ルーティング
関係の文脈は、コードではなく人が知っています。
-
自動応答の文面の新規チャネルへの適用
ブランドの声がにじむ文面は、人が承認してから配布します。
何で確かめるか
どれだけ速く、一度で終わらせたかで見ます。
米国のオンライン成人の53%は、疑問への素早い答えが見つからないと購入をやめる(Forrester, Customer Lifecycle Survey, 2015)
初回応答時間とチャット離脱率を顧客ごとに導入前後で測定します。 受付の確認だけでも即座に出せば、離脱が大きく減ります。
業界平均は約70%、優良は80%以上、小売は78%(SQM Group, 2024)。
最初の対応者を「権限のある人」にルーティングするほど上がります。
統合キューでチャネル間の死角をなくし、0に収れんさせるのが目標です。
問い合わせの受付では氏名・連絡先・住所などの個人情報を取得・保存するため、取得・利用の目的を特定・明示する必要があります(個人情報保護法第17条・第21条)。履歴を統合する際に同一人物の確認をしないまま結合すると他人の情報を露出させる危険があるので避けます。
人が自分で抱えていた仕事が減ります。
散らばった確認と繰り返しの返信を先に整理して上げれば、スタッフは確認と例外の処理に集中でき、人は大事な判断だけを見ます。
運用診断確認が人のところに積み上がります。
LINE公式アカウント・Googleビジネスプロフィール・電話・メールで届いた問い合わせを、社員が一つずつ確認してExcelに移し、返信しています。
処理の準備ができた状態で上がってきます。
すべての問い合わせが一つのキューに集まり、分類と下書きまで用意され、社員は確認・送信と例外だけを処理します。
この業務を任せる前に、よく聞かれること
顧客からの問い合わせ受付について、実際に最初に確認されることを集めました。
チャネルが5つありますが、全部つながりますか。
LINE公式アカウント・Instagram DM・メール・電話のメモまで一つの受付箱に集めます。人は窓口ごとにアプリを行き来せず、一列のキューだけを見ます。
急ぎのクレームが見積りの問い合わせに埋もれないようにするには。
時間圧・不満の信号を優先順位の軸にして緊急・クレームを常に上部に固定し、締切のタイマーが過ぎる前に人へ知らせます。
AIが顧客に直接答えますか。
在庫・営業時間のような事実確認は即答の下書きまで、費用・補償・個人情報が絡む件は受付・整理までで、送信は人が承認します。