第595話：アンケート回答期限、もうひとつの設定方法

前回、「イベント参加者アンケートに回答期限を設定」では、サービス工程を利用して『7日後に締め切り』をセットしました。アンケートに期限を設けることで、未回答であった場合にも、業務プロセスが滞留し続けることを防ぐことができます。

[イベント受付フロー-アンケート（期限セット）]

『7日後』の設定には、データ設定式を利用しています。
「#now.addDays(7)」と書くことで、「回答期限設定」工程にトークンが到着した時点（#now）から『7日後』を「回答期限（日付）」にセットすることができます。

＜「回答期限設定」設定画面＞

日付日時を表すデータ設定式には、他にも、

• ・2時間30分後：#now.addHours(2).addMinutes(30)
• ・月末：#now.getLastTimeInMonth()
• ・翌月5日：#today.getFirstTimeInMonth().addDays(4)

といったものがあります。
（他のデータ項目でも「データ設定式」を利用可能です。詳細は「M227: 業務データの結合や四則演算が自動実行されるように設定する」を参照）

第594話：イベント参加者アンケートに回答期限を設定

前回は、「少人数セミナー」といったイベント受付を行うためのワークフローに、イベント開催後にアンケートを行うための仕組みを追加しました。参加者にアンケート回答してもらい、イベントの感想やフィードバックをもらうことで、次のイベントをより良いものに変えていくヒントになります。

ただ、前回のワークフローでは「アンケート回答されるまで待ち続ける」必要がありました。全ての参加者がすぐにアンケートに回答してくれたら、業務もスムーズに進みますが、残念ながらそういう訳にもいきません。（自分も含めて）アンケートに回答しないときもありますよね。。。

ということで、今回は、「アンケート回答に期限を設ける」ようにワークフローを改良します。期限を過ぎても回答がない場合、案件は自動的に終了するようになっています。

[イベント受付フロー-アンケート（期限セット）]

第593話：イベント終了後に参加者にアンケートを依頼

前回は、「少人数セミナー」といったイベント受付を行うためのワークフローを紹介しました。

担当者によるメール対応を卒業し、受け付けの仕組みをワークフロー化しておくことが、A. データ管理、B. フロー改善、の視点からも望まれます。

イベントが無事に開催された後には、参加者にイベントの感想やフィードバックを聞きたいものです。参加者の声を聞き、次のイベントに反映することで、「イベント開催業務」自体もカイゼンしていくことができます。そのイベントが、セミナーであれば、セミナー内容の見直しにも繋がりますね。

「イベントアンケート」収集用のワークフローを準備して、回答用URL（フォーム開始）をイベント参加者に一括でメール連絡する方法もありますが、今回は、「イベント受付フロー」の後工程にて、アンケートの入力を待ち受ける方法（フォーム待ち受け）を紹介します。

[イベント受付フロー-アンケート]

第592話：ワークフローでイベント申し込みを受け付ける

イベントやセミナーの参加受付、どうしてますか？

申込件数が100人、500人、1000人の想定なら「自動処理システム」を必死に考えるのが良いでしょう。

一方で、10人、20人、50人と言った規模ならどうでしょうか？？？

例えば「少人数セミナー」などのイベント受付。。。
イベント用のメールアドレスを設定し、受付業務は≪担当者によるメール対応≫とするのが手っ取り早いかもしれません。それはそれで良い面もあります。何事にしても素早く行動に移すコト、とても大切です。

しかし、「繰り返し開催されるイベント」になる様なら、どこかのタイミングで≪担当者によるメール対応≫は卒業すべきかも知れません。すなわち、その業務について「担当者しか知らない」と言う状況をやめ、キッチリと（できるだけ半自動的に）【記録】される様にしておきたいものです。

• A. データ管理
• B. フロー改善

２つ視点を踏まえてワークフロー化しておけば、受付担当者の【交代引き継ぎ】も容易になります。受付担当要員の【増員】の際にも協調的な対応が素早く実現できるようになるでしょう。そして、仮に「１年に１度」のイベントであったとしても「去年どうしたっけ？」と言う状況に陥らなくなります。

[イベント受付フロー-公開フォーム]

第558話：クレーマーを減らす「受付番号」の採番工夫

業務：「資料請求」の受付

1. 資料請求の受付件数
2. 見積の提出件数
3. 契約件数

古典的なマーケティング手法ではあるが「1.資料請求の受付件数」は「3.契約件数」に直結する指標だ。その相関は極めて強い。したがって多くの会社で KPI 設定されている。車会社、保険会社、引越会社、設計事務所、、、規模の大小や業種業態を問わないのだろう。

今どき、スムーズなワークフローを実現すべく、顧客からの申込をクラウド型ワークフローの「フォーム開始イベント」で受け付ける会社も少なくない。ワークフローを使うことで、「宛名印刷」や「配送」といった下流工程もヌケモレなく実行される。

そして「受付完了メール」の自動送信（メール送信イベントの配置）も「王道」と言ってイイ。顧客は「リクエストを受け付けてもらえた」と認知することができる。また、本文には『受付番号』を記述する。そうすれば『受付番号』をたよりに電話やチャットで疑問点を問い合わせることができる。

課題：受付番号だけの本人確認

『受付番号』は「プロセス連番」（#{processInstanceSequenceNumber}）が都合良い。何と言っても KPI 管理がラクだ。

しかし同時に「類推されやすい番号」でもある。たとえば電話やチャットで「申込のキャンセル」が来た際、「本人確認」をせざるをえない状況になりうる。つまり、誠実そうな声で「受付番号123番をキャンセルして下さい」と言われればそのまま受け付けても良いのだろうが、悪意のありそうな方を相手にした際に「エントリの氏名」や「メールアドレス」を聞いて本人確認することになる。これは顧客差別とも言われかねない。

かと言って、「類推されにくい番号」として暗号文のような長い番号にするとイロイロ不便だ。「KPI 管理」がメンドウになるだけではない。電話口で伝えてもらいにくいし、一意であることを担保するのも意外とムツカシイ。うーむ。。。

[資料請求への対応プロセス]

第544話：Google Group 連携で、ラクラクML管理(2)

※この記事には「改善編」があります

メーリングリストの管理

前回記事では、ワークフローの流れの中で、「メルマガ購読希望者」（のメールアドレス）が自動的に『Google Group』に追加される業務プロセス定義を紹介しました。（資料請求に対応する業務）

これは、１つのメールアドレスが「１つのメーリングリスト」に自動追加される仕組みです。

しかし、社内で運用されているメーリングリストを見渡せば、（いわゆる『チャットツール』の普及によって減少傾向にあるとは言うものの…）、「方針の通達」「部署内限定にしたい情報の共有」「システムアラートの受信」など、様々な業務において、様々な社内メーリングリストが日常活用されていることでしょう。

メーリングリスト管理の観点においては、「複数のメーリングリスト」に一括追加したいケースの方が、むしろ多いのかも知れません。

複数の Google Group に一括登録

以下の業務プロセス定義は「アカウント申請フロー」です。

社内からの『アカウント申請』があれば、「アカウント新規発行」や「LDAPの設定変更」など、情報システム部は必要なシステム設定を行います。

特筆すべきは「複数のメーリングリスト」への追加削除工程が自動化されている点です。（工程の無人化）

すなわち、案件が［Groupメンバ追加］や［Groupメンバ削除］の工程に到達すれば、ワークフローシステムから追加・削除のリクエスト（OAuth2）が送信されます。つまり、「メーリングリストへの追加削除」という作業について情報システム部の担当者は『メンバ追加されるGoogleGroup』（Checkbox）や『メンバ削除されるGoogleGroup』（Checkbox）が正しく選択されていることを確認するだけで良く、『G Suite』の管理画面にアクセスして Group 設定を一つ一つ編集する必要はありません。（Admin SDK Directory API v1）

[アカウント発行およびML登録]

第543話：Google Group 連携で、ラクラクML管理(1)

メールでの情報共有

メーリングリストは便利です。

組織内の「情報共有」に使ったり、お客様への「情報通知」に使ったりと、多くの企業で日常的に活用されています。しかし、その「メンテナンス作業」がオロソカになってしまうケースは少なくありません。

• メールが届くべきではないヒトに届いている（情報漏洩？）
• メールが届くべきヒトに届いていない（新入悲劇あるある？）

そんな状況が、世界中で発生していることでしょう。

購読メンバーの自動追加

以下の業務プロセス定義は「資料請求対応フロー」です。

このワークフローはお客様の「Web申込」によって開始されます。そして、その申込案件が自動工程『メルマガ追加』に到達すれば、自動的に「お客様のメールアドレス」がメーリングリスト（Google Group）に追加される仕組みとなっています。

この様な処理の「無人化」は、G Suite 管理者が管理画面にアクセスして手動でデータコピーする手間を無くすだけでなく、設定ミスやタイムロスによるトラブルを未然に防ぐことにも寄与します。また手動設定では困難だった「アドレス追加の履歴記録」をも実現します。

[資料請求対応]

第514話：政治家こそ「生産性向上」を実践して見せよ！

政治家や官僚達のワーク・ライフ・バランス

日本も他の先進国と同様、既存の「福祉国家の路線」に限界を感じている。

つまり「行政のスリム化」（簡素な効率的政府）という基本方針については、どの政党も合意するところとなっている。時代の流れには逆らえない。

※ ◆1930年代に起きた倒産の連鎖（世界恐慌）を経て、人類は「単なる自由放任主義」を否定し、大きな政府による「社会保障」を肯定するに至った。　◆1970年代に起きた経済の停滞（オイルショック）を経て、人類は「福祉国家の非効率」を自覚し、小さな政府による「競争社会」への回帰を容認するに至った。　◆1990年代以降の企業活動は国境を越え税収確保も困難となり、またインフラ維持や医療費増加もあり、結果として既存の「福祉国家路線」は立ち行かなくなる。


しかしながら「国会における行政効率化の議論」は全くかみ合わない。

たとえば、(1)「ハンコ行政」をやめる、(2)「特殊法人の民営化」を推進する、(3)「健保・年金・所得税などのバラバラ徴収」を一元化する。。。 議論すべき改革の方向性は多種多様だ。しかしどんな方向であっても、大きくなってしまった政府を「小さくする方法」や「小さくする手順」について、合意を形成するのは容易ではないようだ。

その結果、国会議員達は同じような質問を繰り返し、内閣は同じような答弁を繰り返す。

『質問書』は深夜に提出され、『答弁書』は夜中に作成され、『大臣レクチャー』は早朝に行われる。国会自身が「行政の肥大化」を助長させている。彼らの言う「生産性向上」は、もはや寝言でしかない。

国会議員による質問方法

そもそも国会議員の仕事は、テレビ映りの良い「議場パフォーマンス」ではない。

民間に言わせれば、朝9時から夕方まで大臣ほか時給の高い人達を拘束しつづける委員会審議なんぞ、単なる「長時間会議」にしか過ぎない。もし「取締役会」が朝から晩まで開催され、挙げ句の果てに一部の取締役達が「退席アピール」をしているとすれば、投資家達はどう思うだろう？

内閣提出法案や国政全般について正すべき事項があると感じるなら、「質疑」よりも「質問」（質問主意書）をもっと多用すべきだ。そして、（民間のFAQサイトではないが）、質問をするときは過去の質問（FAQ）を参照すべきだ。あえて同じ質問をしたいなら、「FAQ-20161213-01 の答弁内容に変化はないか？」と聞けば良い。そうすれば内閣は「はい」とクリックするだけでよくなる。

「審議時間が短い」とだけ連呼する議員に、「国益」を語る資格はない。（むしろ質問の数をKPIとせよ）

[内閣答弁作成プロセス]

第477話：社外からの依頼で始まる業務プロセスは改善のしがいがある

『発生源』が社外にあるワークフローは、「改善プロジェクト」を進めやすい。

• (a) 社内トリガー（社内開始）
• (b) 社外トリガー（社外開始）

つまるところ、(a)社内トリガーの業務は、「社内に閉じたワークフロー」なのだ。

たとえば、『社員』に始まる休暇申請フローであったり、『部下』に始まる稟議フローであったり。。。 そんな場合、ついつい「急いで改修しなくてもイイかな？」「運用でカバーできるさ！？」などという雰囲気になってしまいガチだ。

しかし、(b)外部トリガーの業務フローは、そうはならない。

たとえば『お客様』の依頼に始まる資料送付フローであったり、『仕入元』からの請求に始まる調達代金送金フローであったり。。。それらは会社の評判に直結するのだ。つまりメンバー内で「少しでも早くミスなく完了するプロセスに改善したい！」といったモチベーションを共有しやすいのだ。


以下のワークフローは、「イベント参加費」の入金確認フローだ。

クレジットカードや銀行振込など、イベント参加者からの入金を事務局がが確認できれば、「領収書PDF」を自動的に参加者にメール送信するプロセスだ。

• 一刻も早く、「参加エントリ、ありがとうございました」を伝えたい
• ヌケモレなく入金（＝着金）を確認したい

という意気込みが感じられる。

[入金確認フロー]

第468話：SLA のサービスクレジットを発行する

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

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


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

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

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

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

[SLA申請対応フロー]

取引先マスターを参照するクレーム管理

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

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

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


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

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

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

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

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

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

[問合対応プロセス]

資料請求への対応、「完全自動化」できるか？

• 商品カタログ、
• 製品マニュアル、
• 取扱説明書。。。

この「ペーパレス」な御時世(!!?)、、、情報は『データ』(PDF)で流通させるべきだ。「紙資源」もモッタイナイし、「本棚スペース」も埋まってしまう。

しかし、一方で『紙の冊子』にも長所はある。情報種類によって、アクセス頻度によって、読者状況によって、『紙の冊子』の方が都合が良いケースは少なくない。

• 見やすい。（←高解像度）
• 書き込みやすい。（←鉛筆でも）
• そしてコンピュータに依存しない。（←電源イラズ）

しばしば比較される「情報を探し出す」と言う ≪機能≫ も、コンピュータの検索とは違った "不思議な方法" で素早く見つけ出せるケースだってある。（手垢、折り目、情報のレイアウト、ニオイ…？）

以下のビジネスプロセスは、マニュアル冊子（紙の冊子）を郵送する業務（郵送サービス）を定義している。希望者が Web サイトで「住所」や「宛名」などの情報をエントリすると、ワークフローが自動開始される仕組みだ。エントリフォームは、既存の Web サイトに埋め込む方式になっている。（「Web 資料請求」への対応業務）

[冊子郵送サービス]

メールで仕事するな!!

申込件数が100人、500人、1000人の想定なら「自動処理システム」を必死に考える。
しかし一方、10人、20人、50人と言った規模なら？？？

イベント参加証を PDF で送る （ワークフローの自動化） (ワークフローサンプル 2014-03-17)

例えば「少人数セミナー」などのイベント受付。。。

イベント用のメールアドレスを設定し、受付業務は≪担当者によるメール対応≫とするのが手っ取り早い。それはそれで良い。何事にしても素早く行動に移すコト、とても大切。

しかし、「繰り返し開催されるイベント」になる様なら、どこかのタイミングで≪担当者によるメール対応≫は卒業すべきかも知れない。すなわち、その業務について「担当者しか知らない」と言う状況をやめ、キッチリと（できるだけ半自動的に）【記録】される様にしておきたい。

• A. データ管理
• B. フロー改善

２つ視点を踏まえてワークフロー化しておけば、受付担当者の【交代引き継ぎ】も容易になる。受付担当要員の【増員】の際にも協調的な対応が素早く実現できるだろう。そして、仮に「１年に１度」のイベントであったとしても「去年どうしたっけ？」と言う状況に陥らない。

[イベント受付フロー-公開フォーム]

イベント参加証を PDF で送る （ワークフローの自動化）

（電話口）「他社宛の請求書が届いたんですケド・・・」

コレ、、、かなり、、、サムイ。。。

まぁ、多くの会社で1度や2度は経験している事とは思う(?!?)が、果たしてコレ、「事務担当者の気合が足りない！」と言う類の問題なのだろうか？

あなた自身が作業する姿を想像しよう。もし「業務に必要な書類をその都度 Excel や Word で作成する」と言う前提があるなら、おそらく100枚に１枚くらいはミスする。仮にダブルチェック体制（←さいはつぼーし策）を施したとても、1000枚に１枚くらいはミスが発生するだろう。つまる所、ミスの発生は「時間の問題」なのだ。

以下のワークフローは、イベント受付の対応業務だ。『イベント参加証 PDF』の作成工程と『領収書 PDF』の作成工程が自動化され、各書類の送付がメール添付によって自動化されている。（入金確認作業は人手）

[イベント受付フロー]

社外からの通報、どう対応しているの？ （回答業務フロー）

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

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

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

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

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

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

無料クラウドでWebやメールの問い合わせ管理

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

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

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

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

[問合回答業務フロー]

問合受信と同時に回答文ドラフトを自動生成

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

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

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

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

目指せコンシェルジュサービス！ 回答所要時間を自動記録

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

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

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

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

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

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

クラウド型ワークフローで「問合対応業務」を可視化する

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

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

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

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

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

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

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

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

個人情報の「追加ログ」は、とても大事です！

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

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

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

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

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