画面いっぱいに表示されるエラー。アプリ・ソフトウェアを閉じて、再度同じ操作をやり直してみてもエラー。同僚に訊いてもわからない・解決しないので、アプリ・ソフトウェアの提供元のサイトからサポートセンターっぽい電話番号をなんとかゲットし、電話をかける。
Ｑ：○○が出来なくて困っています！助けて下さい！
Ａ：うちは管轄が違うので、○○にお掛け直し下さい。
管轄が違うなら違うで、理想としては正しい部署・担当にそのまま繋げて欲しいところ。が、カスタマーケアは、色々な運用があって、中にはこう言う対応をするところもある。客としてはもう一度別のところにかけ直さなければいけないため、少し面倒くさい。かけ直しても更にたらい回しに遭うケースもある。もう一つのケース：
Ｑ：○○が出来なくて困っています！助けて下さい！
Ａ：お問い合わせありがとうございました。問題について承知しましたが、うちでは対応出来ませんので他部署に連絡をしておきます。
客としてはかけ直しが不要なため、とりあえずの第一印象としては「親切だな」と感じられる。ところが、いつまで経ってもこの「他部署」からも、最初の窓口からも、連絡はこない。再度問い合わせてみると、そこで窓口に「他部署に確認します」と言われる。これで連絡がこれが良いのだが、こういうことなら客が最初から「他部署」に連絡をしていた方が、良かったのではないかとも思えてくる。
「割れせんべい」の袋に入っていたちょこっと欠けているだけの、「当たり」の一枚。このレベルでも商品として扱われないのって日本くらいかと…
カスタマーケアあるある
見積もりの依頼であっても、ユーザーとして問い合わせる場合でも、様々な状況で起こり得ることだが、客としてはもちろん理解に苦しむことであろう。何が起きているのか。サポート窓口の方々は皆が製品について詳しい知識や、問題に対処するための充分な技能を持っているわけではない。会社側で、製品知識・技能豊富な人達にサポート窓口をやらせるのがお客さん目線からしたらベスト。実際、小さなところだと詳しい人がそのままサポートもするということもある。個人事業でやっている電気屋さんなら、その人に直接問い合わせれば、根掘り葉掘り教えてくれることもある。
だが、会社が少し大きくなってくると、当然開発や営業にの為のリソースを犠牲にすることになるので、（会社としては）悩ましいところ。なので（端から見ていてオイッ！って感じるケースはあるものの）ある程度は仕方ないのでしょうね…
感情をピクセル化
窓口となるサポート担当がある程度（例えばマニュアルを読むことで解決出来るレベル）の問い合わせまでは自分で捌き、それ以外のものはもう少し知識・技能に受け渡しをする…それでも解決しない場合（例えば複数部署の連携が必要な場合）は、管理職を巻き込み、トップダウンで解決を模索する。ややこしいのが、本記事冒頭二番目の例にあるように、窓口担当が単なる処理装置になってしまうケース。窓口担当からしてみれば、問い合わせに対して「答えを出してお客さんを満足させた」場合も、「わからなかったから他の担当者に投げた」場合も、等しく「自分の仕事を終えた」ことになってしまう。他の担当者が同じように「処理してみたけどダメだった部長頼むぜ」となった場合に「自分の仕事を終えた」と言う態度だと、案件が複雑であれば複雑であるほど、この業務のサイロ化の弊害が大きいことは容易に想像がつく。
問題は、窓口に連絡が届くまでの経緯をプロセスに組み込んでいないために生じている、という見方をすることが出来る。受話器をとって思い切ってサポートセンターに電話をかけるまで、客には悩みがあり、苦労があり…窓口担当の仕事は「それらが取り除かれたことを確認する」ことを以て「仕事を完遂する」ということにしておけば、業務のサイロ化・タコツボ化も起こりにくくなるのでは、という考え方。
カスタマー・ジャーニー・マップ
問い合わせが入ってきてから、問題が処理されて客に連絡されるまでが「サポート」ではなく、客サイドで問題が実際に発生してから、客サイドで問題が解決するまでが「サポート」と捉える。マーケティングでは良く使われる考え方なのだが、サポートセンターのあり方についても色々ヒントが詰まっていると思われる：
電話にいたるまでの感情、待たせている間の感情もしっかり考慮する。
結局、客にとってはサポートに要件を伝え、対応を一任した時点からブラックボックスである。サポート側でその間色々と苦労や努力があったとしても、見えないし、「待っている時間」がそこにあるだけ。また、サポートに電話をかけるまでに様々なことが起きていた可能性もある。同僚に相談してみたけど解決しなかった、またはサポートセンターの電話番号がなかなか見付からなかったとか…
不具合対応という観点からは全く同じ事象であっても、それにまつわるストーリーは色々なパターンが考えられる。サポートの改良は、単に不具合対応の処理速度を見ているだけでは限界があるということを意識したい。
コメント