ワークフローサンプル: 一次回答

ラベル 一次回答 の投稿を表示しています。すべての投稿を表示

SLA （えすえるえー）、、、
Service Level Agreement （サービスレベルアグリーメント）、、、

クラウドサービス事業者や通信サービス事業者が自らの「サービス品質」を宣言し、実際のサービスが基準を下回った際には返金等が行われるという仕組みだ。この「クラウドファースト」な時代（？）、ＩＴ業界の方でなくても見聞きしたことがあるかも知れない。

以下のワークフローは、サービス事業者が「返金等」を行う業務プロセスだ。

一般の方には馴染みのない話だが、実はこの SLA という制度、、、多くの場合は「ユーザ側からの申請」を受けてから返金等のフローが始められる。まぁ「クレームを受けてから返金する制度」みたいな感じにも聞こえるが、、、現実はそうなっている。

（「鉄道輸送サービス」において、延着などの際に特急料金の払い戻しをする仕組みと同じ、とも言える。。。）

もっとも、、、どんなソフトウェアにも必ずバグが含まれている。世界中でセキュアと信じられている仕様にも、必ず弱点がある。それでいて、ユーザ側の利用スタイルも千差万別だ。ハマってしまう人もいれば、ハマらない人も出てくる。そんな状況下において「返金等を行う」のだから、仕方がない方式なのかもしれない。

[SLA申請対応フロー]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

理由はカンタンだ。

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

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

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

[問合対応業務フロー]