引っ越しに合わせて、電気の開通を事前に申し込んでいたことがあった。 ただ、その後で事情が変わり、その物件への引っ越し自体がなくなってしまった。 そのため、開通前の段階で申込みをキャンセルする必要が出てきた。
キャンセル方法は電話かチャット。 ただ、電話はずっと混み合っていてつながらず、途中でチャットに切り替えた。
チャットウィンドウは画面の右端に小さく開くタイプで、見た目としてはかなり軽い。 その軽さ自体は悪くなかったし、入りやすさもあった。 最初に申込み番号の入力を求められたので、確認メールを開き直して番号を探し、入力した。
その時点では、自然にこう思っていた。
これで申込み内容は照会できるのだろう。
ところが、その後に求められたのは、申込み時にすでに渡している情報の再入力だった。 氏名、住所、電話番号、生年月日、さらにプラン名まで、一通り確認される流れになっていた。
特に気になったのは、プラン名だった。 確認メールの中でそれがわかりやすく見える形ではなかったので、記憶を頼りに答えるしかなかったからだ。
その時に出てきたのは、単純な面倒さだけではない。
もしここで何かを間違えたら、申込みキャンセルが正しく処理されず、あとで面倒なことにならないだろうか。
不安の中心はそこだった。
やり取り自体は続いていたし、担当者個人の応対そのものに強い問題があったわけでもなかった。 ただ、何度も情報を入力させられ、最後の確認も弱かったため、体験全体としては決してスムーズではなかった。
最後には、申込みキャンセルを受け付けたという短い案内が返ってきた。 ただ、それ以上の確認はなかった。 確認メールも来ない。 何が処理されたのかが一覧で見えるわけでもない。 後から参照できる明確な記録もない。
私が不安を伝えると、担当者からは「スクリーンショットを撮っておいてください」と案内された。
その一言は実務的には親切だったと思う。 でも同時に、少し象徴的でもあった。 やり取りは終わっているのに、ユーザーとしては、本当に処理が完了したのかを自分で補強しなければならない 状態が残っていたからだ。
軽いチャネルで、ユーザーにとっては重い手続きを進めている
今回気になったのは、チャットという手段そのものではない。
チャットは、ちょっとした問い合わせや確認にはとても相性がいい。 電話より入りやすいことも多いし、フォームより会話的に進められるぶん、心理的なハードルが低い場面もある。
ただ、今回のように、申込みのキャンセルや今後の請求・開通有無に関わる話になると、必要になるものが少し変わってくる。
この種の手続きでは、ユーザーが欲しいのは単なる会話のしやすさだけではない。 ユーザー体験として必要なのは、何が処理されたのか、どの申込みが対象だったのか、あとで確認できる記録があるのか まで含めた安心感だと思う。
つまり問題は、「チャットだから良くない」ではない。 UXの観点で見ると、見た目や操作感は軽いのに、ユーザーが背負っているリスクや不安は軽くない というずれの方だと思う。
今回の体験では、まさにそこにギャップがあった。 やり取り自体はなめらかだったのに、最後の確かさが弱かった。 そのため、手続きは終わっているはずなのに、気持ちとしてはまだ終わりきらない。 そんな感覚が残った。
申込み番号があるのに、ユーザーが記憶で再構成している
もう一つ気になったのは、すでに存在しているはずのデータが、ユーザーの負担軽減に十分使われていなかったことだ。
今回の流れでは、最初に申込み番号を入力している。 普通に考えれば、その番号は申込み内容を照会するためのキーとして機能していそうに見える。 だからこそ、私は最初にそれを入れた時点で、ある程度話が前に進むのだろうと期待した。
でも実際には、そのあとで氏名、住所、電話番号、生年月日、プラン名まで、もう一度自分で差し出さなければならなかった。
ここで起きているのは、単に入力項目が多いという話だけではない。
- システムがすでに持っているはずの情報が、ユーザーのために十分使われていない
- その結果、ユーザーが記憶を頼りに申込み内容を再構成することになる
- しかも、その再構成を間違えた時の不安を、ユーザー側が強く背負うことになる
入力の負荷は、単に「たくさん打たされるから面倒」というだけではない。 本当にこれで合っているのかを自分で支えながら進めなければならない ことも、大きな負荷になる。
チャットかフォームか、ではなく、処理の重さに見合った進め方をどう設計するか
こういう体験をすると、つい「チャットよりフォームの方がよいのでは」と言いたくなる。 ただ、今回の論点は単純なチャネル比較だけではないと思う。
重要なのは、その手続きがユーザーにとってどれくらい重いか、そしてその重さに対して、UI・確認方法・記録の返し方が見合っているかどうかだ。
今回のケースでは、UIとしては軽いチャットだった。 けれど、ユーザー側が背負っていたものは軽くない。 申込みキャンセルが正しく通るかどうかで、あとに残る不安がかなり変わるからだ。
その意味では、チャットの軽さ自体が問題なのではない。 軽い見た目のまま進めるなら、その分だけ確認と記録を補う必要がある のだと思う。
逆に、それが難しいなら、最初からもう少し手続きとしての輪郭がはっきりした形に寄せた方がよい場合もある。
1. 一意のキーで照会し、再入力ではなく確認に寄せる
今回いちばん気になったのは、申込み番号を最初に入力しているのに、そのあとでほぼ一通りの情報をもう一度入力させていたことだった。
もちろん、申込み番号だけでそのまま詳細を表示するのは、状況によってはセキュリティ上あまり適切でないこともある。 ただ、だからといって、ユーザーに最初から最後まで再入力を求めるしかないわけではないはずだ。
たとえば、こういう方向は考えられる。
- 申込み番号と電話番号の組み合わせで照会する
- 申込み番号の入力後に、登録済みメールアドレスへ確認コードを送る
- 申込み番号またはメールアドレスを起点に、ワンタイムリンクを送る
- 確認が取れた後は、ユーザーに詳細の再入力ではなく、表示された申込み内容を確認してもらう
こうした流れなら、本人確認をある程度保ちながら、ユーザーの入力負荷と不安をかなり下げやすい。
ここで大事なのは、ユーザーに「思い出して入力してもらう」ことではなく、 システム側が照会できるものは照会し、ユーザーには最終確認をしてもらう 方向に寄せることだと思う。
特に今回のようなケースでは、プラン名まで記憶で答えさせるのは少し危うい。 ユーザーが必要以上に手続きを背負ってしまうからだ。
2. 不安や影響の大きい手続きには、完了の証拠を明確に返す
今回、最後まで不安が残った理由の一つは、完了の知らせ方がかなり軽かったことだった。
チャット上で短く受理を伝えるだけでも、運用としては成立しているのかもしれない。 でも、ユーザーとしては、もう少し明確な「完了した」という手応えがほしくなる。
たとえば、オペレーターが申込みキャンセルを処理したタイミングで、
- チャット上に完了メッセージを出す
- 対象申込みの概要を短く表示する
- 同時に確認メールを自動送信する
という流れがあるだけでも、印象はかなり変わるはずだ。
たとえば、
申込みキャンセルを受け付けました。確認メールをお送りしていますので、ご確認ください。
というメッセージが表示され、その直後にメールが届けば、ユーザーは「たぶん終わったのだろう」ではなく、 終わったことを確認できた 状態で離脱できる。
実際の難しさは既存システムの構成によると思う。 ただ、状況によっては、オペレーター側の処理完了とあわせて確認メールを送る設計は、そこまで大きな複雑性を追加せずに検討できる場合もある。
少なくとも、これは単なる文言の問題ではなく、完了をどう返すか という設計の問題として見る価値がある。
3. 記録をユーザーの工夫に任せすぎない
今回、私が不安を伝えた時に案内されたのは、チャット画面のスクリーンショットを残しておくことだった。
その案内自体は、その場でできる実務的な配慮としては理解できる。 でも、記録という観点で見ると、少し心もとない。
本来ほしいのは、ユーザーが自力で証拠を保存する工夫ではなく、 システム側から正式な確認の痕跡が返ってくること だからだ。
確認メールやマイページ上の履歴があれば、ユーザーは余計な不安を抱えずに済む。 それだけでなく、あとから「本当に処理されているか」を確かめるための再問い合わせも減らせるかもしれない。
この種の設計は、ユーザーに親切かどうかだけの話ではない。 サポート負荷の抑制 という意味でも効いてくる可能性がある。
4. 軽いUIのままでいくなら、確認を厚くする。それが難しいなら、進め方自体を見直す
チャットの軽さには価値がある。 電話より入りやすく、すぐに始めやすいという意味では、よい選択肢になることも多い。
ただ、ユーザーが背負っている不安や影響が大きい手続きでは、軽い見た目だけを維持しても十分とは限らない。
もし軽いチャネルのまま進めたいなら、
- 照会の仕方
- 本人確認の取り方
- 完了確認の出し方
- 記録の残し方
を、そのぶん丁寧に設計する必要がある。
一方で、そこまでの確認や記録をチャット上で十分に返しにくいのであれば、最初からもう少し正式な手続きとして受け取られやすい形に寄せた方が自然な場合もある。
たとえば、
- チャットで相談や導線案内だけ行い、正式なキャンセル処理はフォームで受ける
- チャットから本人確認済みの専用画面へ遷移させる
- 最初から、キャンセル専用のフォームや手続き画面を用意する
といった形だ。
大事なのは、チャットかフォームかを先に決めることではなく、 ユーザーと事業者のどちらに、どんな負荷がかかっているかを見て、そのバランスに合う進め方を選ぶこと だと思う。
今回のケースで言えば、ユーザー側にかかっているのは、入力の負荷だけではない。 考える負荷、間違えたくないという負荷、本当に終わったのかを気にし続ける負荷もある。 そうした負荷が大きいなら、見た目の軽さだけで押し切るより、確認や記録を厚くするか、あるいはフロー自体を少し改める方が、結果として自然になる。
小さく見える引っかかりでも、あとに残る
UX 上の小さな引っかかりは、いつも大きな問題として現れるわけではない。 今回のように、表面上はそこまで大きなトラブルがなくても、ユーザーの中に 終わったはずなのに、少し落ち着かない 感覚だけが残ることもある。
こういう違和感は、数字だけでは見えにくい。 でも、申込み、変更、キャンセル、支払いのような接点では、その小さな不安が、サービスや企業への安心感や信頼感にかなり影響することがある。
だから、フォームやオンライン手続き、問い合わせ導線を見直す時には、単に入力しやすいかどうかだけではなく、
- どこで迷いや確認負荷が生まれているか
- どの文言や状態表示が不安を残しているか
- ユーザーが何を判断させられているか
- 完了後にどこまで確信を持って離脱できるか
まで含めて確認することが、ユーザー体験の詰まりを具体的に整理する入口になる。
