ユースケース
クラウドIVRは同じ決定ツリーを、自社所有のハードウェア上ではなくサービスとして動かすものです。変わるのは発信者の体験ではありません。自社チームが保守しなくてよくなるもの、負荷時の容量の振る舞い、変更が本番に届くまでの速さです。
プラットフォーム · ルーティング
音声メニューは不要
インバウンド · ルーティング
適切なキューへ振り分け
アウトバウンド · 連絡
障害発生の通知
インバウンド · あふれ呼
あふれ呼と時間外対応
プラットフォーム · ルーティング
音声メニューは不要
インバウンド · ルーティング
適切なキューへ振り分け
アウトバウンド · 連絡
障害発生の通知
インバウンド · あふれ呼
あふれ呼と時間外対応
対応範囲
同じメニュー階層をサービスとして動かすもので、チームが保守すべき対象が変わります。
ホスティングはクラウドではない
ホスティングは同じソフトウェアを他社のハードウェアに移すだけですが、クラウドはマルチテナントで、容量が伸縮し、メンテナンス時間帯がありません。
保守しなくてよくなるもの
テレフォニーカード、メディアサーバー、パッチ適用サイクル、季節ごとの容量計画、災害復旧サイトのすべてが、自社の責任ではなくなります。
メニュー設計は依然として必要
設計の悪いメニューは、地下室から動いていたときと同じくらいクラウドでも煩わしいままです。提供形態は設計の良し悪しに関与しないからです。
障害時に何が起きるかを確認する
障害時に通話がどこへ流れるのか、そしてフェイルオーバーが自動で作動するのか、誰かが気づくまで待つのかを確認してください。
設備投資が運用費に変わる
オンプレミスは大きな一括購入と減価償却ですが、クラウドはチャネル単位または分単位の課金なので、費用は成長に比例します。
番号ポーティングが日程を決める
ポーティングは切替日が固定される最長工程なので、稼働開始をそれに合わせて計画し、通話ツリーは書き写すのではなく作り直してください。
プレイブック
それぞれが設定済みのエージェントです。どんな質問をするか、何を記録するか、どこへ引き継ぐかが決まっています。まず一つ選び、必要な箇所だけ変更してください。
Outbound障害通知
インシデント連絡エージェントのSentinelをご紹介します。Sentinelは障害発生中に影響を受けた顧客へ電話をかけ、状況を共有し、オンコールチームのために影響レポートを収集します。
プレイブックを表示支払い受付ライン
回収アシスタントの Remy をご紹介します。Remy は支払いのためにかけてきた顧客に応対し、口座を確認し、残高を読み上げ、カード情報に一切触れずに支払いの意思を記録します。
プレイブックを表示
Inbound小売カスタマーサービス
小売事業者向けのAIアシスタント、ShopBotをご紹介します。包括的なカスタマーサポートを提供し、ショッピング体験を向上させます。
プレイブックを表示仕組み
着信する
通話は、メニューに届く前にキャリア、SIPトランク、その間のネットワーク、そしてサービスを経由します。
サービスはマルチテナントであるため、誰かが別のインスタンスを用意するのを待つのではなく、処理能力が通話量に追随します。
メニューが動く
再生されるのは自社で作ったツリーであり、選択肢4が今も妥当かどうかについて、デプロイ方式は何も関与しません。
10年かけて選択肢が積み重なったツリーには、何年も誰も選んでいない分岐が含まれており、それは削る価値があります。
通話が課金される
課金は使用量に連動するため、成長に比例してコストがかかり、ピーク時に合わせて購入したハードウェアのように遊休資産が生じることはありません。
通話量が読める場合、表計算上はオンプレミスのほうが安く済むこともあり、弾力性の価値が最も高いのは通話量が急増する場合です。
導入事例
従来の IVR を上回る、
より賢く直感的な AI
ソリューション。
本物の人間と話しているかのような、
自然で心地よい会話。
必要なときは、ストレスなく
担当者へおつなぎします。
"コンバージョン率は 65% から 82% に上昇。担当者の作業負荷は 40% 削減。リードへの反応時間は 2 分未満。"
Ayush Pateria
Snazzy 最高経営責任者・共同創業者
"通話放棄率は約 30% から 5% に低下。着信の 75〜80% を Finn が完結。24 時間体制の AI 対応が 80 名超のオフショア担当者に取って代わりました。"
Shikha Chouksey
Orbit Wallet 最高執行責任者・共同創業者
詳細
形態は3つあり、混乱の大半は真ん中のものが原因です。オンプレミスは自社の建物内の自社ハードウェア上で動く自社ソフトウェアで、完全な管理権を持つ代わりに、アップグレード、障害、容量の判断はすべて自社の責任です。ホスト型は通常、その同じソフトウェアを他社のハードウェア上で動かすもので、再設計ではなく移設にすぎず、依然としてバージョン管理があり、インスタンスごとの上限も残ります。クラウドはマルチテナント型のサービスで、容量は伸縮自在、アップグレードはメンテナンス枠なしで届きます。
ベンダーは「ホスト型」と「クラウド」を同義に使いますが、購入するものとしては別物です。両者を切り分ける問いはこうです。月曜に通話量が3倍になったとき、容量は自動的に追随するのか、それとも誰かがプロビジョニングするのか。
これが正直な利点であり、発信者に見えるものではなく運用上のものです。テレフォニーカードとメディアサーバー、パッチ適用のサイクル、季節的なピークに向けた容量計画、そしてテストのために存在し実際には使われない災害復旧サイト。これらすべてが自社の担当から外れます。
なくならないのはコールフローです。ツリーは依然として設計が必要で、設計の悪いメニューは、地下室から流れていたときと同じだけクラウドからでも苛立たしいものです。デプロイ方式は、選択肢4に意味があるかどうかについて何の見解も持ちません。
稼働率の数値はプラットフォームについて示されたものであり、プラットフォームは経路全体ではありません。通話はキャリア、 SIPトランク、その間のネットワーク、そしてサービスを経由します。最後の区間について示された数値は、その最後の区間のことしか教えてくれません。
どのくらいの頻度で落ちるかではなく、落ちたときに何が起きるかを聞いてください。通話はどこへ行くのか（代替番号か、録音メッセージか、話中音か）、そしてそのフェイルオーバーは自動的に発動するのか、それとも誰かが気づく必要があるのか。後者はよくあることで、めったに開示されません。
資本的支出から運用的支出への移行であり、コストを感じる主体が変わります。オンプレミスは多額の購入とその後数年の償却なので、成長はほぼ無償です。ただし容量を超えた瞬間、突然そうではなくなります。クラウドはチャネル単位または分単位で、成長には比例したコストがかかり、無駄になる資産はありません。
安定して予測できる通話量であれば、オンプレミスのほうが表計算上は今でも安く済むことがあります。これは譲歩ではなく事実です。急増する通話量に対しては、伸縮性のほうが単価より価値があります。代替案はピークに合わせて買い、年の残りを遊ばせておくことだからです。
番号のポーティングが最長の工程であり、切り替え時期は動かせません。稼働開始日は構築ではなくポーティングを軸に計画してください。ツリーは書き写すのではなく作り直してください。10年にわたって枝を継ぎ足してきたIVRには、何年も誰も選んでいない選択肢が含まれており、移行はそれらを削除する最も安上がりな機会です。
どのみち移行するのであれば、メニューの形が今も適切かどうかを問う好機でもあります。 IVRとAIボイスエージェントの比較をご覧ください。クラウドIVRが踏み台だからではありません。多くの現場は、よくできたメニューをクラウドで運用し、そこで止めてかまいません。ただ、移行時こそこの問いに答えるコストが最も低く、引き継ぐことになるレイテンシ予算を先に理解しておく価値があります。 レイテンシ計算ツール は時間が実際にどこで消えているかを示します。それはたいてい、想像されている場所ではありません。
よくあるご質問
