ECサイトが落ちても、顧客は商品を探し続けられる

火曜日の午後。1分前まで注文が入っていたECサイトが、次の瞬間にはエラーページしか出さなくなる。プラットフォームは「調査中」と言い、こちらは待つことしかできない。その間、購入寸前だった顧客はわざわざ知らせてはくれません。タブを閉じて、自分の一日に戻るだけです。何人いたのか、どの商品を探していたのか、いくらの売上が消えたのかは永遠にわかりません。障害は、顧客が商品を見つけて選ぶことができる唯一の場所ごと持っていったからです。

もしそのエラーページが旅の終わりでなかったら、どうでしょうか？「後ほどお試しください」という素っ気ないメッセージの代わりに、顧客が対話型アシスタントにたどり着き、そのままカタログを見て回り、疑問を解消し、気になる商品でほしい物リストを作れるとしたら。そのリストは保存でき、WhatsApp やメールで共有でき、ストアが復旧したときに開き直して購入を完了できます。売上の発生は数分から数時間遅れるかもしれませんが、購買意図はストアと一緒に落ちるわけではありません。

障害が実際に奪うもの

ここは正確に書く価値があります。「ストアが落ちた」という一言が、まるで振る舞いの違う3つの損失を隠しているからです。

• 決済。これは現実で、避けようがなく、直せるのはプラットフォームだけです。ストアが応答しない間は、どこであっても注文は成立しません。
• 回答。サイズ、在庫、配送、返品についての質問が行き先を失います。どの回答も、本来ストアがオンラインである必要はなかったのに。
• 購買意図。誰かが候補を2点まで絞り込み、あと一歩でした。セッション全体で最も価値のあるもので、ページが落ちた瞬間に蒸発するのもこれです。

1つ目は誰もが思い浮かべる損失で、いちばん手が出せないものです。残る2つは静かに高くつくもので、実は障害が原因ではありません。3つの機能を同じ入口の後ろに置いたことが原因です。

ECサイトが止まっても、商品カタログは残る

ECサイトでは、商品を見つけること、疑問を解くこと、支払うことが同じ場所で起きます。それが当たり前に見えるのは、その場所が動いているあいだだけです。止まって初めて、カスタマージャーニー全体を単一障害点に集めていたと気づきます。青いスニーカーの27.0cmがあるか確かめたかっただけの人も、支払いまであと1クリックだった人も、行き着く先は同じエラーページです。

対話型ストアはこの依存を断ち切ります。ECプラットフォームからカタログを直接引くのではなく、自ら最新に保つ同期済みのコピーの上で動くからです。ストアが一時的に停止していても、顧客は商品を見つけ、比較し、疑問を解消し、ほしい物リストを保存して、決済が戻ったときに続きから進められます。購入は中断されますが、会話は—そして購買意図は—中断されません。

仕掛けはこれだけで、意図的に地味です。代替店舗でもなければ、二つ目の決済でもありません。売上を決める質問はストアがオンラインである必要がない、という観察にすぎず、それを一緒に殺す理由もないというだけです。

正直に言ってできないこと

AllHub では誰も買いません。支払いも注文も配送も、あなたのストアで、あなたのプラットフォームで、あなたの条件のもとで起きます。調子のいい日にそうであるのと同じく、悪い日にも変わりません。だからプラットフォームが落ちていれば、注文は成立しません。私たちにも、誰にもです。

「障害中も売り続けられる」と取引の意味で約束するツールは、自前の決済を持っているか（それはまったく別の製品で、結果もまったく違います）、あるいは誇張しています。私たちはより狭く、そして本当のことを言います。残るのは会話とカタログと買い手の判断です。取引は待ちます。

そして結局のところ、そこにほとんどの価値があります。疑問が解け、買うものを決めた買い手は、支払い以外のすべての意味ですでに成立した売上です。関心が最高潮の瞬間にエラーページへ突き当たった買い手は、何も残しません。そこにいたことすら、あなたは知らないままです。

死んだページの代わりに買い手が見るもの

最悪の結果は障害そのものではありません。買う気になっていた人を、説明もなく壊れたタブへ送り込むことです。記憶に残るのはその姿だからです。だからアシスタントは状態を確認し、店頭が応答していないときは会話の冒頭で一度だけ、はっきりと伝えます。

• ストアは一時的に購入を受け付けていない — 買い手の言語で、エラーコードではなく事実として伝える。
• 閲覧はこれまでどおり続く。商品、価格、バリエーション、比較はすべて残り、すべて質問できる。
• 購入ボタンは嘘をつかずに黙る。読み込まれないページへ人を送らない。
• 気に入ったものはほしい物リストに入り、戻ってきたときにもそこにある。

はっきりさせておきます。対話型ストアは障害中のECサイトを置き換えるものではありません。二つ目の店頭でも、並行した決済でもありません。生かしておくのは商品の発見です。カタログを見て、比べて、質問して、決める——支払いのほうはストアの復旧を待ちます。

エラーページを用意する。ないと、買い手は自分がどこへ来たのか分からない

ここはあなたの側の作業です。ストアのオーナー、あるいは保守を担当している人が、エラーページを差し替えるかリダイレクトを設定して、「ストアは一時的に停止している」と伝え、対話型ストアへのリンクを提示する必要があります。なぜこのチャネルに来たのかを顧客が理解できることが重要です。説明のないままチャットに放り込まれた人は戸惑って離脱し、リンクは得られるはずだったものをほとんど失います。

この説明さえ目の前にあれば、あとは自然に進みます。対話型ストアで顧客はカタログを見続け、疑問を解消し、ほしい物リストを作って共有し、ストアが復旧したときに購入を完了できます。狙いはそれだけです——障害が購買意図まで持っていかないようにすること。

言わないこともあります。復旧したら知らせます、とは言いません。ほしい物リストは買い手のブラウザの中にあり、これは意図的なプライバシー上の選択です。ランプを眺めるためにアカウントもメールアドレスも要りません。つまり、こちらから連絡できる相手が文字どおり存在しません。だからアシスタントはそのふりをせず、「選んだものは保存され、ここで待っている」と伝えます。そこは本当のことです。

チェックは定期的に走り、購入ボタンに手が伸びた瞬間にもう一度走ります。セッションの途中で始まった障害を、分ではなく秒で捉えるためです。ストアを「落ちている」と判定することには意図的に慎重です。1回のリクエスト失敗は障害ではありませんし、問題なく売れているストアで購入ボタンを無効化するほうが、防ごうとしている不具合よりはるかに悪いからです。復旧は逆で、最初に成功したチェックが一気にすべてを戻します。

あなたのストアではどう動くのか？

対話型ストアは Shopify、WooCommerce、Wix、Amazon のカタログに接続し、自分側にコピーを保持します。AIショッピングアシスタントが答えるのはそのコピーからで、だから供給元が止まっても立っていられます。混み合ったプラットフォームへの問い合わせ時間ではなく、読むのに要する時間で答えが返るのも同じ理由です。

• Shopify、WooCommerce、Wix、Amazon で数分で稼働 — 開発者もテーマ改修も不要。
• 半年前に書かれたFAQ文書ではなく、現在の商品と現在のバリエーションから答える。
• プラットフォームが不通のあいだも、答え、比較し、保存し続ける。障害中に注文は取らない。注文はあなたのストアのものだから。
• 保存データはEU域内にあり、プライバシーフィルターがいかなるAIモデルに届く前に個人データを遮断する。GDPR第17条に基づく完全削除にも対応。

はっきり言えば、これはプラットフォーム選びを雑にしていい理由ではなく、保険でもありません。障害はまれで、たいていは短いものです。主張は単純で、障害が起きたとき、「悪い午後」で済むか「失われた午後」になるかを分けるのは、まだ誰かが顧客に応対できたかどうかだ、というだけです。

早期アクセス：内容と対価

AllHub はソフトローンチ中です。各プラットフォームの先着10店舗は3か月無料。対価はお金ではなく、週に一度、10分の通話です。

ランディングページに並べるロゴを10個集めたいのではありません。実際の買い手が実際の質問をしているストアで、うまくいかないときにそう言ってくれる人が運営しているところを探しています。返すのは創業者の直接の関与と、渡して終わりではなく一緒に進める初期設定です。

• ストアを見て、プラットフォームとの相性を確認 — 24〜48時間以内。
• 30分のオンボーディング通話を、都合のよい時間に。
• エージェントは1時間以内に稼働。
• 各プラットフォーム先着10店舗に3か月無料。

まとめ

プラットフォームに悪い午後が来るのを止めることはできませんし、それを売り込む相手は疑ってかかるべきです。決められるのは、その最中に買う気だった人に何が起きるかです。いまのところ、ほとんどのストアでの答えはエラーページと、その後の永久の沈黙です。そうである必要はありません。

ストアが落ちても、商品まで落ちる必要はありません。あなたのストアに実際の買い手と実際の質問があるなら、早期アクセスを申し込んでください — 各プラットフォーム10店舗、3か月無料、週10分の率直な会話。