届かないピザ
久々にピザでも食べたいなあと思い、インターネット経由で宅配ピザを注文する。
最近はこういったサービスも WEB から注文できるので便利だねえ。WEB2.0 万歳ですな。それ以前は、WEB のメニューを見ながら電話で注文していたのだけれども、メニューの閲覧と注文が直結しているのはうれしい。
んが、注文後 2時間経っても届かない。流石におかしいなと思い店舗に電話をかけて注文状況を確認する。そしたら、注文は届いていないとのこと。幸いまだピザを食べたいという欲求は衰えていなかったので、確認電話でそのまま注文を行うことに。
このサービスは度々利用するけれども、不具合が生じたのは初めてだ。
さて、こういう場面に出くわすと私のエンジニア魂がうずき始めますよ？
いつもは不具合報告を叩きつけられてへこむ側だけれども、今回は報告する側なのだからー。というわけで、そこそこにプロ根性を発揮しつつサービス提供会社に報告、「発生日時」「注文番号」「店舗確認時の状況」「不具合の詳細」状況確認願いますとトレースに必要な情報をまとめて送信。
その後 TV を見ながら、届いたピザをもぐもぐと食べていたらサービス提供会社と店舗の両方から詫びの連絡が入る。おやまあ、迅速だねえこりゃ。
話によると、店舗までの注文は無事完了していたけれども店舗側でそれをロストしてしまったらしく、というのが顛末らしい。ラスト10フィートに問題が生じた感じやね。
クレーム付けることが目的じゃないし、不具合発生の箇所が分かったので個人的にはそれですっきり。やわらかく納めて終了。
不具合が生じたとき、クオリティ向上のために報告をしたい時がままあるのだが、その時の窓口がはっきりとしておらず途方にくれる事が結構あったりする。そういうとき、明確な窓口を設定しているかどうかがサービス会社のクオリティかなあと思う。
通常は、ユーザーサポートというとユーザー側からの「どうなっているのですか？」という質問を受けて返答をするものがメインなのだよね。よくわからないんだけれどどうなっているのですか、という質問とバグ報告というのはエンドユーザーから見て区別が付きにくいけれども本質は別なんだよなあ。
オープンソースだとそこに「仕様要求」が加わることになる。
それらをうまく裁くことが出来るというのがクオリティになるのだろうな。
—–