払込用紙のクレカ払い案内はお節介かもしれない
クレジットカードを変えると面倒なのが番号変更の対応。思いあたるサービスは新しいカードが来たらすぐに変更をしますが、意外と手続きを忘れてしまうものもあります。特に年払いのサービスなどがそうではないでしょうか。
あと厄介なのが番号変更と決済処理のタイムラグがあるパターンで、番号を変えたはずなのに決済エラーとなり払込用紙が届いてしまうもの。今回はキャリア料金の支払い手続きで、この払込用紙パターンでハマってしまったので、なぜそうなったのかをプロセス構造から分析してみました。
クレジットカード変更で味わった二度手間
我が家に届いた払込用紙を見たときには「ああ、カード変更のタイミングが悪かったんだな」と感じただけで、よくあることだと思っていました。
いつもならコンビニに行って支払いをするわけですが、ふと払込用紙を見ると支払い方法が選べるようになっています。
払込用紙で支払い
いつもどおりにコンビニで支払うパターンクレジットカードで支払い
サイト上でクレカ登録の手続きをする
元々クレジットカードの変更処理がエラーになって払込用紙が来ているのに再度番号登録するのも変なのですが、コンビニ払いは面倒なのでクレジットカード払いを選択しました。
案内通りにやって手続きは成功したものの、念の為コールセンターに問い合せすると、カード払いに失敗する可能性がゼロではないため確実性を求めるならコンビニ払いが良いとの回答を頂きました。
再度支払いエラーになるのだけは絶対イヤだったので、結局コンビニで現金払いをしました。
正直、このやりとりは二度手間でしかない。最初からコンビニに行って現金払いするより余計な手間がかかっているわけで、払込用紙の親切心が仇となり「なんでこうなった？」という感じです。
もしコールセンター側で「クレジットカードの変更手続きに成功しているので、払込用紙を破棄して大丈夫ですよ」といった確実な回答を貰えていれば問題解決で終了していました。しかし、コールセンター側も意図して回答をはぐらかしているわけではなく、回答できない業務プロセス上の構造があるということになります。
この二度手間の元凶となっているプロセスについて、ゆるくモデリングしていきます。
二度手間になった原因はどこにあるのか？
今回のモデリングの目的は「クレジットカードの番号変更を問題なく終える」ことなので、クレジットカード変更プロセスをこのように定義してみました。
定義 ：支払い可能なクレジットカード番号に変更すること
ゴール：クレジットカード変更でエラーが発生しないこと
クレジットカード変更プロセスの構造をモデリングした結果はこちらです。今回は消費者(自分)、キャリア(サービス提供者)、クレジットカード会社の3者が登場します。いつもより登場人物が多いです。
次にこのプロセス構造の問題点を分析していきます。手順はこの２つです。
1.矢印が集まる重要な構成要素を探す
2.重要な構成要素から左に遡っていき根本原因を把握する
まず注目する構成要素は利用明細です。次にプロセスを左に遡ってみると、根本原因のクレカ番号がでてきます。
クレカ番号がプロセスの原因を作る根本要因ですが、この要素は点線で繋がれています。これは同期関係と呼ばれるもので、クレジットカード番号が更新前か更新後のどちらかの番号に調整されて決まることを表現しています。
例えば、これまで使っていたクレカ番号「AAAA-AAAA-AAAA-AAAA」から「BBBB-BBBB-BBBB-BBBB」に更新するとしたら「更新成功の通知」がある緑色のプロセスを通ります。このプロセスが終了すれば、次回から更新前のクレカ番号が「BBBB-BBBB-BBBB-BBBB」に置き換わることになります。
クレジットカード番号を更新することは滅多に無いので、ほとんどクレカ番号を更新しない青色のプロセスを通ることになるでしょう。
この更新前のクレカ番号は、クレジットカード会社に問い合わせる番号になります。この問い合わせするクレカ番号(更新前)とクレジットカード会社がもつマスタデータを突き合わせます。新しいクレジットカード番号はクレジットカード会社から発行されるのでマスタデータには「BBBB-BBBB-BBBB-BBBB」の更新済みの番号が記録されています。
このマスタデータと突き合わせるプロセスで同じく同期関係にあるのが「番号エラー」と「利用明細」です。つまりキャリアから来た問い合わせ用のクレカ番号が「AAAA-AAAA-AAAA-AAAA」であれば番号エラーとなり「BBBB-BBBB-BBBB-BBBB」であれば利用明細が発行されます。
これまで説明で使っているモデリング図は、これまで説明してきたプロセスの流れではなく、プロセスの構造を表現しているため、構造的な見方をするとこのようになります。
利用明細の結果を得るためには、マスタデータとクレカ番号(更新前)が必要。
番号エラーの結果を得るためには、マスタデータとクレカ番号(更新前)のが必要。
利用明細と番号エラーは同期関係にあるため、マスタデータとクレカ番号(更新前)の中身によってどちらかの結果に決まる。
そのため番号エラーの結果なら払込用紙が届くプロセスになり、利用明細の結果ならそれが届くプロセスとなります。
クレカ番号の変更プロセスの何が問題なのか？
このプロセスの問題点は2つあると考えられます。
消費者にとって本当に知りたい情報を更新の成功通知では教えてくれない
エラーにならない限り消費者が問題を把握できない
1点目は、クレジットカード更新の成功通知です。これはおそらく更新処理が成功したことを通知しています。つまり「更新処理を受け付けましたよ」ということだけがわかる状態です。
そのためクレジットカードの更新がいつ行われるかは不明です。またこの問題が発生した時点での自分のケースだと、キャリアのサイト上で支払い情報と紐付いているカード番号も確認出来ませんでした。だから消費者側で現状ステータスを把握しようがありません。
そして2点目は、エラーにならない限り問題が分からないということです。更新成功して安心したところに払込用紙が来てしまうのは、消費者が知らないところでキャリアとクレジットカード間での番号照会エラーが起きたことになります。そこで消費者は問題をはじめて認識するわけです。
特に1点目が今回の問題の元凶を生んでいます。更新処理は更新受付をしているだけなので支払いエラーが出る可能性があるということです。
更新と照会の処理のタイミングがズレているので、自分からサイトでクレジットカード更新した場合も、払込用紙が来てクレジットカード更新した場合も同じプロセス構造になっています。
つまり、更新するタイミングが悪いと同じ問題が再現することになります。
そのため二度手間の元凶は、消費者側にクレジットカード番号の更新状況がわからないから発生しています。
クレジットカード更新のプロセスは改善可能か？
今回の問題点については、病院の待ち時間と同じように消費者側ではわからないところで処理されるため発生します。
ただし病院のケースと違い、今回はプロセス構造を見ても対策可能だと感じます。つまりクレジットカード番号の更新処理と切替処理の連携を意識すれば解決できるはずで、下記のようなアイデアが考えられます。
キャリア側が問い合わせに使うクレジットカード番号を表示する
更新が間に合わない時は更新処理が出来ないようにする
更新処理を受け付けても、払込用紙が届くことを連絡する
払込用紙にクレジットカード払いの案内を入れない
払込用紙はQRコード決済のようなプリペイドの選択肢に変える
どれも実行可能なアイデアだとは思います。というかキャリア側も当然考えているはずで、やりたくてもできてないのが実情ではないかと思います。
そう思う理由として、自分が別のサービス(年払いで忘れていたパターン)で払込用紙が来た時にクレジットカード番号を変えて処理が完了したからです。こちらのサービスではコールセンターに確認したところ「処理できたので払込用紙は破棄しても大丈夫です」と言われました。
このことから分かるのは、クレジットカード番号の更新及び切替処理の状況をコールセンター側で確認が可能だということです。これらのケースからコールセンター側で確認可能な範囲が違うことで回答が異なる理由じゃないかと考えられます。
キャリアは様々なサービスの支払いを代行したり取りまとめているため接続するシステムが多いはずです。サービス全体もしくは該当サービス確認の時に、別部門や別企業への問い合わせが必要になる可能性があり、そうすると確実な回答が難しくなってしまいます。
様々なシステムと連携した状態だと、プロセスを少し変えるだけでも莫大なコストが発生する可能性があります。コストが高い場合は問題点をすぐ修正するのではなく一括対応するなど、コストを考えて対応しているキャリア側の事情もあるのではないかなと思われます。
ただ、いち消費者としては二度手間がなくなって欲しいので、払込用紙のクレカ案内はなくしてもいいんじゃないかなと思いました。
ここまで読んで頂きありがとうございました。
励みになるので、よければこのnoteのシェアやスキをお願いします！
この記事が気に入ったらサポートをしてみませんか？