仕事をしていると、必ずイレギュラーが起こります。
問い合わせ対応でも、顧客管理でも、イベント運営でも、
「そんなケースもあるのか。」
ということは出てきます。
どれだけ事前にマニュアルを作っていても、すべてのケースを最初から想定することはできません。
だから私は、イレギュラーが起きること自体は、それほど問題ではないと思っています。
大切なのは、そのイレギュラーをどう処理したか。
そしてもう一つ。
処理したあと、それをどう残したか。
です。
一度目は、イレギュラーでもいい
例えば、通常とは違う問い合わせが来たとします。
マニュアルには書いていない。
担当者では判断できない。
管理者へ確認して、今回はこう対応することになった。
無事に解決しました。
ここまでは、よくある話です。
問題はそのあとです。
「対応できてよかった。」
で終わってしまうと、数か月後に同じ問い合わせが来たとき、また担当者は迷います。
マニュアルを探す。
書いていない。
前回対応した人へ聞く。
その人も記憶をたどる。
「たしか、前はこうしたと思う。」
必要なら、もう一度管理者へ確認する。
一度決めたはずのことを、また最初から考え直すことになります。
一度目は想定外でも仕方ありません。
でも、同じことが二度目も想定外になる必要はありません。
イレギュラー対応は「解決」で終わらせない
私は、想定外のことが起きたとき、
発生する
→ 対応する
→ 原因や条件を確認する
→ 再発する可能性を考える
→ FAQやマニュアル、判断基準へ追加する
→ 次から通常対応にする
ところまでが、イレギュラー対応だと考えています。
その場を乗り切ることだけが仕事ではありません。
次に同じことが起きたとき、別の担当者でも対応できる状態をつくる。
そこまでできて、初めて組織に経験が残ります。
担当者の頭の中にだけ残っている経験は、その人の経験です。
FAQやルールとして残された経験は、組織の経験になります。
FAQは「よくある質問」だけではない
FAQというと、
「お客様からよく聞かれる質問をまとめたもの」
というイメージがあるかもしれません。
もちろん、それもFAQです。
でも私は、社内のFAQにも大きな意味があると思っています。
「この場合はどうする？」
「この条件なら対応していい？」
「通常と違うケースが出たら誰に確認する？」
現場で実際に発生した疑問と、そのときの回答を残していく。
つまりFAQは、
過去に起きた想定外を、次から想定内に変えるための仕組み
でもあります。
最初から完璧なFAQを作る必要はありません。
むしろ実際に運用してみないと、何につまずくのか分からないことも多いものです。
仕事を始める。
想定外が起きる。
判断する。
残す。
また運用する。
この繰り返しで、FAQやマニュアルは育っていきます。
何でもマニュアルに追加すればいいわけではない
ただし、起きたことをすべてマニュアルに追加すればいいわけでもありません。
一度しか起こらないような特殊なケースまで細かく書いていくと、今度はマニュアルが巨大になります。
情報が増えすぎて、
「結局どこを見ればいいのか分からない。」
となってしまえば、本末転倒です。
私なら、
また起こる可能性があるか。
別の担当者でも迷いそうか。
対応を間違えた場合の影響が大きいか。
通常業務の判断基準として使えそうか。
といった視点で、残すかどうかを考えます。
よく発生する質問ならFAQへ。
通常業務の手順ならマニュアルへ。
判断の分かれ目になるなら判断基準へ。
重大なトラブルにつながるなら、注意事項やエスカレーション条件として残す。
大切なのは、情報を増やすことではありません。
次に同じ状況が起きたとき、担当者が迷わず動ける情報を残すことです。
「自分で判断していい範囲」も残しておく
イレギュラー対応を仕組みにするとき、もう一つ決めておきたいのが、
どこまで担当者が判断していいのか
です。
すべてのケースをFAQだけで処理できるようにする必要はありません。
「この条件なら通常対応でいい。」
「ここまでは担当者判断で進めていい。」
「この金額を超えたら管理者へ確認する。」
「契約条件に関わる場合は決裁者へ上げる。」
というように、判断できる範囲と相談する条件を決めます。
そうすれば、担当者は何でも上司へ確認する必要がありません。
同時に、自分の権限を超えて判断してしまうことも防げます。
FAQに答えがあることと、
自分に判断する権限があることは別です。
だから、
「どう対応するか」と「誰が判断するか」
の両方を残しておく必要があります。
同じ人が何度も呼ばれているなら、仕組みを見直す
組織の中には、
「困ったら〇〇さんに聞けば分かる。」
という人が生まれることがあります。
経験が豊富で、過去の経緯も知っていて、聞けばすぐ答えてくれる。
とても頼りになる存在です。
でも、その人が毎回同じような質問に答えているなら、一度立ち止まって考えた方がいいかもしれません。
なぜ、その質問は何度も発生するのでしょうか。
なぜ、答えがその人の頭の中にしかないのでしょうか。
なぜ、ほかの担当者が自分で判断できないのでしょうか。
本人が優秀だから解決できているだけで、仕事の仕組みとしては何も改善されていない可能性があります。
「〇〇さんに聞けば分かる」は、便利であると同時に属人化のサインでもあります。
一度聞いて解決したなら、その答えを次の人が使える形にする。
それだけでも、特定の人へ質問が集中する状態は少しずつ減らせます。
強い組織は、想定外が起きない組織ではない
どれだけ仕組みを整えても、想定外をゼロにすることはできません。
新しいサービスを始めれば、新しい問い合わせが出ます。
人が増えれば、これまでになかったケースも起こります。
ツールの仕様が変わることもあります。
取引先や顧客によって、通常とは違う対応が必要になることもあります。
だから、想定外が起きたことだけを見て、
「仕組みが悪かった。」
と考える必要はありません。
強い組織とは、想定外が起きない組織ではなく、
想定外が起きたときに対応し、その経験を次の仕組みに変えられる組織
だと思っています。
一度目は、イレギュラーでもいい。
その場では、人の経験や判断に頼ることもあります。
でも、そこで得た経験を残す。
FAQにする。
判断基準にする。
マニュアルへ追加する。
相談ルートを決める。
そして、次に同じことが起きたときは、通常業務として処理できるようにする。
もし同じことで何度も同じ人が呼ばれているのであれば、
それはもう、イレギュラーではありません。
仕組みに取り込めていない、通常業務です。
想定外をなくすことではなく、
起きた想定外を、一つずつ想定内へ変えていく。
それも、仕事が人に依存しない仕組みをつくるための、大切な業務設計だと考えています。
