ミールデリバリーサービス

顧客は定期購入と単品注文に対応する調理済みミールデリバリーサービスです。月に数万件の注文があり、平日の夕方に負荷が高まります。サポートはコールセンターとチャットに依存し、ピーク時の待ち時間は最大40分。オペレーターの採用は利益率を圧迫し、問い合わせの70%は「注文はどこ？」「住所を変えるには？」「何が入っている？」「配達を延期するには？」という同じ内容でした。利用者のほぼ全員がTelegramを使っているため、サポートもそこへ移すのが自然でした。

サービス品質を落とさず、よくある問い合わせを自動化します。自然な言葉で回答し、実際の注文情報を参照し、配送変更やチャット内でのサブスクリプション決済に対応。複雑な場合は会話の文脈を添えて丁寧にオペレーターへ引き継ぎます。品質基準は明確で、問

い合わせを解決せず「サポートを装う」だけならプロジェクトは失敗です。

「メニュー付きチャットボット」ではなく、注文データへのアクセス、定型操作の権限、明確なエスカレーション範囲を持つサポート担当者として設計しました。

• 3か月分のサポート問い合わせを分析し、よくある50のシナリオ、その割合、顧客の実際の表現、オペレーターの典型的なミスを整理しました。
• サービスのナレッジベースを作成しました。配送規則、料理の原材料、サブスクリプション料金、返金手順を、モデルが参照できる構造化情報にしました。
• 対話エンジンを開発しました。ナレッジベースを検索する言語モデル（RAG）、サービスの事実にない回答の禁止、ブランドの一貫した口調を実装しました。
• API経由で運用システムに接続しました。注文状況と履歴、住所と配送時間の変更、サブスクリプションの一時停止と決済に対応します。
• エスカレーションを設計しました。複雑または感情的な問い合わせは会話の文脈ごとオペレーターに渡し、顧客が同じ説明を繰り返さなくて済むようにしました。
• 対話分析を設定しました。引き継ぎの理由、回答できないシナリオ、ナレッジベースに追加すべき情報を分析し、実際の会話に基づいてボットを改善します。

プロジェクトの原則は、自動化を自動化だと気づかせないことです。ボットは数秒で返答し、1〜2通で解決し、同じ回答を繰り返しません。定型外なら、文脈をすべて引き継いだうえですぐ人が対応します。その結果、サポート評価は3.4から4.7に上がりました。顧客が評価するのは「ロボットか人か」ではなく、速さと結果です。この規律が、役立つボットと苛立たせるボットを分けます。

ボットの次の発展方向：

• マルチチャネル化。共通のナレッジベースと対話エンジンを使い、WhatsAppとVKでも同じシナリオを提供します。
• プロアクティブ通知。顧客が問い合わせる前に遅延の可能性を知らせます。
• 音声アシスタント。サービスのモバイルアプリで音声による注文やサブスクリプション管理を可能にします。