オンプレミスからクラウドコンタクトセンターへリプレースする際の注意点

こんにちは、Twilio Championの西口です。

前回は本格仕様への洗い出し方法をまとめました。今回はいよいよクラウドコンタクトセンターへリプレースする段階になって行うべきことを洗い出していきましょう。

オンプレミスからクラウドへリプレース時に行うべきこと

電話ができない日時調整と周知

リプレースする場合、電話番号が一時的に使えなくなることがあります。

特にフリーダイヤルを番号ポータビリティする場合、移行してすぐにTwilio側で設定しないと動かなくなりますし、ソフトフォンのリリースが遅れたり、バグが出て動かなかったりは往々にしてありえます。

営業時間外にリリースしたりするなどの運用も行いつつ、日程を決めた上でいつからいつまでは電話ができないという旨を電話を利用して仕事する営業などに周知しておきましょう。

各媒体の電話番号変更の周知

01200800といったフリーダイヤルは番号ポータビリティできます。
しかし、IP電話で主に利用される050や、0306といった地域番号を含む「0ABJ」は番号ポータビリティができません(2020年2月7日時点)。そのため、各媒体に表示されている番号の変更を行い、お客様への周知を行う必要があります。

見落としがちなのですが、電話番号は様々な媒体に記載されており、下記などは参考例です。

  • カレンダー
  • 年賀状/暑中見舞い
  • 広告のちらし

メールの署名やウェブサイトといったわかりやすいものもありますし、上記のような紙媒体は見逃しやすいため、営業や総務といった非エンジニアと協力し、見逃しがないか早い段階から確認してください。

番号ポータビリティの日程調整

フリーダイヤルは番号ポータビリティができ、Twilio以外の通信キャリアの番号を引き継いで利用することができます。番号ポータビリティをするにあたり、通信キャリア間での事務手続きが必要で調整に時間がかかるため、決まったら即座に相談しましょう。

複数のフリーダイヤルを持っており、そのうち受電数がほとんどないような番号を持っていたら、本番リリース前に一度、番号ポータビリティを先にやっておくと本番時で慌てることがないのでオススメです。私が以前、リプレースした際はそのような番号で事前にポータビリティのテストを行っていたため、本番リリース時は慌てることなく進めることができました。

リリース後の冗長化について

Webサイトのリニューアルは緊張感がありますが、失敗しても巻き戻しができることが多いと思います。その点、クラウドコンタクトセンターへのリプレースとなると、巻き戻し自体が難しい点について把握し、予め冗長化について考えておく必要があります。

番号ポータビリティは戻せない

番号ポータビリティは通信キャリア側が行うため、依頼後は番号ポータビリティに関してやることはありませんが、戻すこともできません。ソフトフォンにバグがあって戻したいとなっても、再度通信キャリアと事務作業を行ってからやっとポータビリティです。これには数ヶ月はかかる作業になるため、現実的ではないです。

番号ポータビリティは深夜に行われる

払い出し元によるかもしれませんが、僕がフリーダイヤルをTwilioへ番号ポータビリティした際は夜の0時に行われました。そのため、問題があったとしても通信キャリアやTwilioへの問い合わせへの回答は最速翌営業時間からとなる点は把握しておきましょう。

冗長化について

番号ポータビリティはコントロールできない部分で、クラウドコンタクトセンターへの移行が大規模だと、負荷に耐えられずバグが出たりなどが起こりますが、下記のように冗長化をしておくことをオススメします。

  • 固定電話や携帯電話を利用できるようにしておく
  • 移行元番号はすぐに契約を終了せず、保持しておく

特に移行元番号の保持は重要で、変更しましたという案内はもちろん出しますが、変更前の番号に電話がかかってくることはけっこうな期間発生します。そのため、毎月受電数を確認し、必要に応じて契約解除していくようにしたり、旧番号にかかってきたときにはアナウンスを流し、新しい番号があることを周知したりと工夫してください。

SIPからWebRTCへの切り替えを段階的に行う方法

Session Initiation Protocol

上記はSIPからすべて一括で切り替えを行う場合でした。SIPフォンの場合、段階的に移行することも可能です。

SIPフォンを使っている場合、TwilioのSIP Trunkという機能を利用することで、ソフトフォン移行前からTwilioの機能を利用することができます。この機能を利用することで、現場への負担をかけずに順次移行を進めることができます。ソフトフォンの準備ができ次第、小さいチームでソフトフォンへの移行を試し、問題がなければ順次全体への適用を進めるという段階的な以降も可能になるため、SIPフォンを利用している場合は是非、検討してください。

まとめ

クラウドコンタクトセンターへの移行を経験したことあるエンジニアは少ないため、周到に準備しても何か問題が起こることは少なからずあります。また、番号ポータビリティに合わせる必要があるため、リリース日が固定される点も難しいところです。

以前、クラウドコンタクトセンターをスモールスタートするべき理由と仕様例の記事も参照しつつ、クラウドコンタクトセンターへのリプレースを万全の状態で進めて行きましょう。

次回はクラウドコンタクトセンターリリース後に起きた失敗と改善についてのコラムを書きます。お楽しみに。

Webエンジニア 西口瑛一:前職でTwilioを用いた国内最大規模のコンタクトセンターを1から開発。
その経歴が認められ、日本では5人しかいないTwilio Championsに選ばれる。
Twitter ID: https://twitter.com/24guchia
この記事をシェア

すべての記事へ

Blog

Twilioコンソールから電話番号を購入する方法

Blog

新しくなったTwilio Edge Locationsの効果とは!?

Blog

Twilioビジネスセミナー Vol.62 Genesys Cloud × Twilioで実現する”クラウドファースト”コンタクトセンター

Blog

【Insightsシリーズ第3弾】Twilio Messaging Insightsがリリース!

Blog

Media Streamが双方向に対応し、スムーズな音声ボットが作れるようになりました!

Blog

クラウドコンタクトセンターリリース後に起きた失敗と改善について