「小さなクレーム」は「大きな問題」～些末なトラブルを黙認していると大きなしっぺ返しがくる

情報システムにトラブルはつきもの。とはいえ、「起こしてはいけないトラブル」もあります。それが外部に提供しているサービスならばなおさらです。「β板だから」、「めったに起こらない問題だから」、「システム改修に膨大な時間を要するから」などと問題を甘く見てリリースしてしまうと、重大なクレームの温床となる可能性があります。

チケットサービス会社のトラブルをSNSで告発

以前、とあるオンラインチケット発行サービスで起こったあるトラブルが話題になりました。

入手するのがなかなか困難な人気イベントのチケットがあり、あるユーザーはその抽選に当選し、オンラインで決済も終えました。しかし数日後、チケットがなぜか勝手にキャンセルされてしまいました。

不審に思ったユーザーはTwitterでこの問題を告発。その投稿は広く拡散されて、「私もそのチケットサービス会社でトラブルになった」という被害者の声がたくさん投稿されるなど、ちょっとした話題になりました。

そこで会社側は素早く対応し、このユーザーに連絡を取ったうえで、「勝手にキャンセルになったという事実はなかった」と公式に発表しました。つまり、このユーザーがTwitterで投稿したことはデマだったと判明したのです。

トラブルは収束したが、クレームや批判がネット上に噴出

この発表により騒動は収束するかに思われましたが、ネット上ではその後もしばらく、この会社の話題で盛り上がっていました。

「今回の件はデマだったにしても、関連して出てきた“私も被害に遭った”という話はなんだったのか」

「あの会社のシステムはそもそもひどい。クレームを入れても改善されない」
 
「日頃の対応の悪さを反省せよ」

などなど……。

どうやら、日頃からこの会社のチケットサービスには些末なトラブルが多発しているようで、溜まりに溜まったユーザーの不信感がデマ投稿事件を契機として一気に噴出してしまったのです。なかには、「今回のトラブルも金を使って解決したのでは？」と疑ってかかる人もいました。

トラブルは解決したものの、この会社の評判の悪さがクローズアップされる結果となりました。

なぜそれほどまでに評判が悪いのか？

その原因はもしかしたらチケット発行サービスを運用しているシステムに問題があるのかもしれません。

問題のあるサービスを放置しておけばクレームの温床に

開発段階の詰めが甘く、些末なトラブル発生を認識しているが、修正するには膨大な時間とコストがかかってしまうので、内に留めておくなど、ある程度のクレームが発生するのを容認してシステムの運用を行う。

また、試作段階である「β版」としてリリースし、ユーザーに使ってもらいながら、不具合や不適切な箇所がないかを修正して「正式版」の開発につなげる。

いずれもROI(投資収益率)の視点からみると妥当な開発手段かもしれません。ただしそれが許されているのは、予期せぬエラーやトラブルがあったとしても、顧客やユーザーに迷惑をかける範囲が限定されているソフトウェアやサービスだけ。

資金決済や契約などビジネスの根幹に関わるような重要なソフトウェアやサービスならば、中途半端な状態でリリースするのではなく、完成度を高めてからリリースするのが当然です。

　みずほ銀行は2016年12月に予定していた新たな勘定系システムの完成時期を遅らせる検討に入った。システムの一部で実施中の動作確認テストを延長する必要があると判断した。遅らせれば２度目の延期となり、新システムの運用開始は18年夏以降になるとみられる。みずほは過去に２回の大規模なシステム障害を起こしており、今回も万全を期すことにした。～2016/11/12　日本経済新聞

完成度の低いままリリースしてしまえば、トラブルが多発し、クレームに追われることになります。場合によっては、損害賠償問題に発展することもあるでしょう。今回話題となったオンラインチケット販売会社のサービスもこのようなケースに当てはまるのかもしれません。

システム開発に限らず、もし自社の商品やサービスで些末なクレームが多発しているようなら、何らかの重要な問題が隠れていると認識するべきです。その要因を取り除かない限り、クレームは減らないし、顧客からの信頼も徐々に失われていきます。そして、何らかのきっかけでインターネット上にネガティブな口コミが一気に広まることもあるのです。

同じカテゴリの記事を見る

この記事を監修をしたのは

地村健太郎(ちむらけんたろう)

株式会社C-SOS
代表取締役社長

〒143-8530 東京都大田区平和島1-1-2 NTTロジスコ平和島物流センタ7F
URL.http://claim-csos.com/