ワークフローサンプル: メール問合

ラベル メール問合 の投稿を表示しています。すべての投稿を表示

「お客様の声に、誠実にお応えします」。。。

言うのは簡単だが、実践するのはナカナカ難しい。実際「全てのお客様の声に即応する」のが不可能な時だってある。たとえば「人手リソース」を動的にスケールさせる（変化させる）仕組みにも限界がある。いや、待て。そもそも「単純に人手を増やす」という方針は、それは「コスト増」につながる話だ。延いては、お客様の為にならない。

う～む、「誠実にお応えする」とは何か？

大きなヒントは『ISO 10002』だ。すなわち「苦情対応プロセスについて PDCA サイクルによる継続的な改善を行うこと」に主眼を置くのだ。（組織としての成熟度を高めると言っても良い）

具体的に言えば、顧客からの意見要望を受け付けてから、顧客への応対が終了するまでの進捗を捕捉記録する。そして、「苦情対応プロセスの流れ」や「業務マニュアル」を改善し続ける。（まさに Business Process Management (BPM) 活動そのもの）

ISO 10002: Quality management (Customer satisfaction):
Guidelines for complaints handling in organizations (2004)
JIS Q 10002: 品質マネジメント (顧客満足):
組織における苦情対応のための指針 (2005)

以下のワークフロー定義は、非常にシンプルな「苦情対応プロセス」だ。
※ 「クレーム対応プロセス」あるいは「問合対応プロセス」と呼んでも良い。

まずは１週間なり１か月なり、このシンプルなワークフローで実際の「お客様の声」を回す。そして、蓄積された処理記録と実体験とを踏まえ、一回目のプロセス改編を行う。更にその後、その改善サイクルを繰り返す。

なお、このワークフロー定義、、、「顧客マスター」を参照できる点が秀逸だ。「顧客マスター」を用意すれば、「ユラギのない顧客名」が簡単に入力できるようになる。

[問合対応プロセス]

いよいよ、後１か月。。。

日本でも個人番号制度「マイナンバー制度」が始まる（2015年10月5日）。当ブログでも『個人番号の収集プロセス』について、いくつかのワークフロー（業務プロセス）を例示してきた。

そして、次週以降は「法人番号」の利活用についても、その事例を紹介していく予定となっている。法人番号システム『Web-API 機能』の活用事例についても、「事前検証環境」にて動作確認でき次第、順次公開していく予定だ。

今回は「マイナンバー」を取り扱う業務でかかせない「誤り検出」についてまとめておく。
以下のワークフロー定義は、入力データの「正確性チェック」を体験できるサンプルだ。[1] 入力中データが自動的にチェックされる仕組み(入力画面での JavaScript)と、[2] サーバ側にてデータチェックされる仕組み(スクリプト工程での JavaScript)の両方が設定されている。

なお、チェックディジットとは「検査用文字」という意味だ。『クレジットカード番号』や『商品コード』(EAN/JANバーコード)や『国際標準図書番号』(ISBN)などでも幅広く活用されている。日本の『マイナンバー』の場合は、

法人番号（13桁数字）: 左端の数字
個人番号（12桁数字）: 右端の数字

が「一定の計算式」によって算出され、付加されている。

[Check Digit サンプル：「TEST Form」画面]

第三者の生命財産をおびやかす可能性がある情報
業務記録として保存必要のない個人情報
犯行予告など法令に違反する可能性のある記述
わいせつなど公序良俗に反する記述

といった情報が業務データに含まれてしまっている場合、どうすべきか？

あまり考えたくない話ではあるが、"目安箱フロー" や "内部告発処理" といった匿名性を高めた業務フローなど、業務によっては良くある話だ。ここでは、特権ユーザによる [データ編集] について考えたい。

そもそも業務データは、承認者のチェックを受けたり、差し戻し工程で修正されたり、、、最終工程に至るまでに何度も編集されるモノだ。案件が [終了イベント] に到達する頃には、会社の記録として仕上がった業務データになっているだろう。そして、その後は誰も編集しない。
この完成したデータについて多くのワークフロー製品では、（クラウド型ワークフロー Questetra においても同様）、特権ユーザですらデータ改変できない仕様になっている。もし仮に "後で編集ができてしまう" となれば、それはデータ改竄を許す仕組みであり "データ信頼性" あるいは "監査証跡" (コンプライアンス) の視点で問題になる。過去のデータに誤りを見つかけ場合には、新しい案件として然るべき手続をやりなおすべきだ。 (集計上のノイズになるなら、元のデータは [削除] する)

以下のワークフローは、 "Google アラート" (や "Analytics アラート" など) を自動的に取り込み、インターネット上の新着コンテンツ情報等を検知し、必要なリアクションを取ると言う業務だ。機械的に収集される情報であり、多くの場合は "情報共有不要" を選んで終了させる事になる。しかし、中にはその一部を [データ編集] すべきデータが含まれてしまう案件もある。この例は、特権ユーザに対して [データ編集] できる猶予を与えている所が、非常に地味な配慮ではあるが、秀逸だ。

[インターネットネット監視業務]

「業務プロセスを改善せねば・・・」

そう考える経営者や管理職者は多い。しかし「実践にうつす」となると、そう簡単な話ではない。『ウチの課長は、なぜ業務フロー図を書かないのか？』の記事の中にもあるが、まずもって「業務フロー図」を書くのがムツカシイのだ。（う～む）

とは言え『社外の方』に影響のある様な業務であれば、そうも言ってられない。その手順やルールを日々カイゼンしたい。例えば「個人情報苦情相談窓口」への相談案件があった時、いつ誰がどの様な対応を行ったのか（行っているのか）が把握できない様では、やっぱりマズイ。

以下のワークフロー定義は、Web サイトで受け付けた「外部からの相談や通報」に対し、必要な対応を行う業務フローを表している。
この定義（プロセスモデル）をインポートして稼働させれば、全ての問い合わせが自動的に記録され、権限者はその対応進捗をモニタリングできる様になる。秀逸な工夫は、相談者／通報者が「ファイルを添付できる」所だ。つまり、スマホで撮影した画像ファイルも簡単に添付する事ができるのだ。

＃個人的には「街路灯(街灯)の球切れ」を通報するシステムも、「電話受付(9:00-17:00)」ではなく、Web サイトで受け付けてもらいたい。（気付くの、夜だし）

[個人情報苦情相談対応フロー]

「回答メールを、協調作成したい」
「回答メールの作成進捗を、可視化したい」

問い合わせ対応フローは複雑だ。『エスカレーション』や『技術調査』、『営業部門依頼』や『FAQ登録』などなど、複雑な分岐フローが存在する会社も少なくない。「組織規模」による違いも大きい。おなじ業種でも10人組織と100人組織、1000人組織では、その流れは全くチガウだろう。すなわち、問い合わせ回答業務は、自分達にとって「あるべき姿」を模索し続けたい業務の一つだ。イマドキであれば「業務プロセス管理ツール」(BPMツール)で、業務フローの最適化を図りたい。

しかし、「フローの変更や改善」は得意な『汎用的な業務プロセス管理ツール(BPM)』ではあるが、入力画面の使いやすさの観点では、どうしても分が悪い。たとえば、自社の業務を考えてキッチリ設定した『入力項目』もそれら全てが「均一な感じ」になり、「どれが重要項目？」が分かりにくくなってしまう。

『Questetra BPM Suite』の場合、「入力フォーム画面」を徹底的にカスタマイズできる機能を持っている。
HTML の知識が必要になるが、「誰でも処理できる入力画面」や「スピーディに対応できる入力画面」を探究し続ける事ができる。新人社員でも即戦力になれるだろう。（高度なレイアウト機能）

[問合回答業務フロー]

お客様からの「問い合わせ」に対し、『迅速』かつ『正確』に答えたい。

「問い合わせ管理システム」は色々あるが、自社オリジナルの回答フローを反映できるシステムは多くない。品質向上、スピードアップ、再発防止、、、業務フローを改変する動機は様々だが、創意工夫した問合回答フローがシステムに反映できなければ「人間コスト」が増える一方だ。
例えばもし「不具合に関する問い合わせ回答には、必ず技術部隊のレビューを得る」と言った業務ルールが存在するなら、もはや「問い合わせ管理システム」ではなく「業務プロセス管理システム」（BPMシステム）で管理すべきかも知れない。フロー図上に現在進捗（滞留状況）を俯瞰できるようになり、統括責任者の指示も大幅にスピードアップする。（更には、受信窓口が各回答担当の得意領域に応じて案件を手動で振り振る、と言ったフロー拡張が起きるかもしれない）

以下の業務プロセス定義は、「メール問合」や「Webフォーム問合」から、「回答メールの送信」までのワークフローが定義されている。このワークフローを活用すれば、「一次回答の文面」や「最終回答の文面」だけでなく、「先輩社員のチェック時刻」や「他部署からの助言」も、ひとまとまりの業務データとして記録される。ナレッジとして参照できるようになり、また更なる業務改善の基礎データにもなるだろう。

[問い合わせ対応フロー-回答メール自動セット]

ホームページ問い合わせの回答、平均何時間？
土日の問い合わせにも、キチンと対応できてる？

処理件数が増えてくると分析したくなる。例えば『問合フォーム』への「平均レスポンス時間」を分析したい。業務を定量的に観測すると、業務改善は加速する。反省会の基礎データにもなるし、目標も立てやすい。

以下の業務プロセス定義例は、分析のための工夫がされている。すなわち

ホームページの『問合フォーム』に投稿があった場合と、
各所に掲載している『問合アドレス』にメールが届いた場合

に、自動的に【問い合わせ対応ワークフロー】が起動するだけでなく、「最終回答までに要した時間」とこの問い合わせ案件が発生した日の「曜日」が、業務記録として自動的にセットされる仕組みになっている。実は過去に紹介したワークフローとほぼ同じだのだが、データ加工を行う『スクリプトタスク』が足されている点で異なる。

[問い合わせ対応フロー-回答時間記録]

『問合フォーム』からの問い合わせに対して、十分な情報を迅速に回答できているか？

問い合わせ者は「大きな不安」を持っているのかも知れない…。
問い合わせ者は「大きな期待」をしてくれているのかも知れない…。

『電話サポート』であれば担当サポートスタッフの能力に大きく依存してしまう傾向にあるが、『問合フォーム』や『質問メール』への対応であれば、組織として手順を工夫することで一定の品質を担保できるハズだ。

以下の業務プロセス設定例は、

ホームページの『問合フォーム』に投稿があった場合と、
各所に掲載している『問合アドレス』にメールが届いた場合

に、自動的に【問い合わせ対応ワークフロー】が起動する。すなわち組織としての「問い合わせ対応業務」が自動的に開始される仕組みになっている。

簡単な問い合わせであれば、ワークフロー起動後、即座に回答文が準備され対応終了になる。難易度が高い問い合わせであれば、研究開発部門等に助言依頼が回され一次回答だけが送られる。いずれにせよ、問合対応業務をワークフローシステムで管理することで、全ての問い合わせについて、「今誰が担当しているのか」や「どのステータスにあるのか」あるいは「どんな社内議論になっているのか」が一目で分かるようになる。言うまでもないが《進捗》の可視化は、「対応の迅速化」と「成果物品質の向上」につながる。

[問い合わせ対応フロー]

『顧客データ』だけ集めたいな。。。

Web引合対応、問い合わせ対応、外出報告フロー(名刺交換)。。。「顧客候補の情報」は、社内の色々な業務で収集されている。できることならば、一元的に管理したいものだ。（CRM活動の基礎データ）

以下は、顧客候補情報を管理するためだけのワークフローだ。
他の様々なワークフローから、「郵便番号」「都道府県」「組織」「部署」「名前」「メールアドレス」の主要データと、「メール配信同意の有無」(フラグ)「新規取引の可能性」(評点)が、送信されてくる事を想定している。

これは「データベースの様な使い方」と言っても良い。
ただ注意しなければならないのは、データは次々と『追加』されるばかりで、過去データの『更新』や『削除』には主眼が置かれない。すなわち、蓄積データを活用する際には、追加日時で絞り込む、処理者で絞り込むなどの工夫が必要となる。
いわゆる『ビッグデータ』の活用においても必要になる発想だが、新しい情報の『追加』を優先し、『更新』や『削除』のコストを押さえるべきケースは少なくない。具体的に言えば、『３年以上前の名刺情報』なんて、よほどの場合でない限り活用すべきではない。

[顧客データ収集プロセス]

いよいよ今週2013年5月26日に、改正公職選挙法が施行される。
日本でも、インターネットで「選挙運動」ができるようになる。（えっ、イマサラ!?!）

要するに候補者（や政党）は、選挙期間中も Facebook
を毎日更新する様になる訳だ。メールもバンバン送る様になる訳だ。そんでもって「私に投票して下さい」と堂々と書けるようになる。（今まで「電話」をかけまくってたのはナンだったんだろう？）

注意しなければならないのは、一般人もこの「選挙運動をしてしまっている」と言う事実だ。
たとえば、選挙期間中に「Ａ候補がんばれ」とか「Ｂ候補をヨロシク」と発信するなんて事は、誰にだってできる。あるいは「Ｃ候補は、あんな奴は当選させちゃダメだ」なんて、ついつい同調して発信してしまうだろう。
しかし今回決まったルールでは、ブログやSNSで「選挙運動」や「落選運動」をするなら『その者に連絡をする際に必要な情報』を表示しておかなければならない。Facebook
や Twitter で発信している以上、全く問題ないが、ブログやホームページで情報発信したい場合には注意が必要だ。

（少し話はズレルが）、メールでの「選挙運動」は明確に禁止されている。一般人は「メール転送」も含めてメールで「選挙運動」しちゃダメだ（まずもってバレナイんだけど…）

さて、、、
そこで新たな業務が発生しそうなのが、Blog や掲示板の運営会社だ。

A. 誹謗中傷記事に対する削除依頼を、執筆者に連絡する業務
B. メールアドレス等の表示義務違反を、執筆者に連絡する業務

これは、かなりの規模の人間タスクになる様な気がする。。。
「中傷削除」を依頼する人は、候補者その人だ。まずは「候補者の本人確認」から行わなければならない。また人気サイトの場合、表示義務違反の指摘が膨大な数になる可能性もある。インターネット関連会社にとって、関連する業務プロセス整備（ワークフロー整備）は急務だ。

[公開記事の修正依頼フロー]

ワークフローの『クラウド化』が実現すると、必ず「メール問合対応の業務フロー」もクラウド化したくなる。

理由はカンタンだ。

どこに居ても対応できる（自宅からでも、外出先からでも）
誰が対応しているか分かる（リアルタイム監視の視点）
どの工程で滞留したか分かる（パフォーマンス集計の視点）

しかし実際に稼働させると、「回答者を割り当てるフロー」よりも、「社内の助言を得るフロー」の方が重要であることに気づく。
つまり、例えば「サーバが止まっているの？」と言う問い合わせを受けても、窓口担当者には分からないのだ。例えば「技術的な質問になるのですが…」と言う問い合わせであれば、どうしても技術部門に助言を求めざるを得ない。そして、この手の問い合わせに、如何に早く回答できるか、は会社の信用にかかわる！

以下のワークフロー『問合対応業務フロー』は、非常にシンプルな「助言依頼フロー」を内包している。非常に秀逸だ。

[問合対応業務フロー]

『クレーム』には、迅速に対応したい。
実際「ピンチをチャンスに変えよう」は、クレーム対応業務で良く言われるセリフだ。その対応如何によって、お客さんの評価が上がるケースすらありえる。

以下のワークフローは、メールやWebフォームからのクレームに対し、メール(＋α)で対応する『クレーム対応業務』だ。専門のクレーム対応部署がない会社で、様々な部署の人間が『回答文』を書くケースが想定されている。クラウド型ワークフロー Questetra BPM Suite で運用すれば、「どの様なクレームが届いたか」、「どの様なクレームが届いているか」を、いつでも何処からでも把握できる様になる。
※ BPM: Business Process Management （業務プロセス管理）

[問い合わせ対応ワークフロー]