このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

対顧客の窓口としてのメールアカウント

発言者:今泉克美
( Date Monday, July 23, 2001 17:39:49 )


お世話になっております。

対顧客の窓口としてのメールアカウントの件です。
以下、とても変な発想ですが
1.利用者が使いやすい仕組みの知恵
2.運用上の注意点
などございましたら、
自由な発想で
お教え願いたく
お願い申し上げます。
メーリングリストだけではうまくいきそうにないので。

したいことの簡単な例題
1.営業マン「A」,「B」,「C」は
それぞれメールアカウント「a」「b」「c」を持っているが
外部には公表しない。社内連絡用にのみ使用。
2.「営業部」用のメールアカウント、「x」を用意し
公開しておき、外部の顧客からのメールは、こちらで受ける。
また、返信も「x」で行う。
3.アカウント「x」あてに来たメールは、
営業マン、A、B、Cが使っているメーラに「も」一通づつ
到着するようにしたい。
ただし、a、b、cに来ようが、xあてに来ようが、
ここでは問わない。受信できれば良い。
4.営業マン3名のうち、最初に受信メールに気がつくか
もしくは、担当としてふさわしい者一名が
顧客に返信をするものとする。
返信をしたさいには、前項2にもあるとおり「x」の
アカウントで行いたい。
5.返信をした者が、仮に、Aだとすると
どのような返信をしたかのメールが、B、Cにも
送付される必要がある。でないと、2重に処理したり
処理のモレに誰も気がつかなかったりするので。

−−−−−−−−−
以上の仕組みは、運用上、ルールをしっかりきめて
気をつけて操作すれば、もちろん、人間系の力で
実現できます。
しかし、やってみるとわかりますが、なかなか
うまくいきません。
そこで
営業マンにしてみると、できるだけ簡単な操作で
「自分あてに来たメールを返信処理した結果が
残りの営業マンにも自動的に伝わる」
「誰かが処理した結果が自分にも通知されるので
処理しなくてもいいのだな、とわかる」
というようなものが欲しいわけです。
−−−−−−−−−
MLと代行受信の仕組みを組み合わせればうまく
いくのかなーと思いましたが、なかなか
思いつきません。
パズルのようですが、何か良い知恵がありましたら
お願いいたします。
−−−−−−−−−

#実は、私どもの職場のホテルでの予約処理の問題なのです。

もれなく、複数のPCで、処理したいのです。

今泉克美 さんからのコメント
( Monday, July 23, 2001 17:46:46 )

付帯する状況です。

ホテルのインターネット宿泊予約画面サービスって
あちこちで行われています。サーバもまちまちで
複数あります。会社の取引のギリで、複数契約
せざるを得ません。
そちらから送られてくるメールを処理したいのです。
自前のサーバで予約を受けれラレレバ、それなりの
処置は可能なのですけれども。

うーん。
ほか様はどのようにしているんでしょう。謎。

稲垣 さんからのコメント
( Monday, July 23, 2001 17:56:57 )

 それなりのシステムを組まれた方が確実かと思います。
 私が知っているのでは、WebObjectsのセミナー等で良く紹介されているMailCenterという
商品です。ただ、業務パッケージソフトなのでそれなりの価格になっています。

フレームワークスソフトウェア
http://www.frameworks.co.jp/

 自作とすれば、この辺のソフトのコンセプトにあるように、すべてのメールをそのまま扱う
のでは無く、一旦データベースに格納しておき、Webベースで管理をする方法であれば、ある
程度排他処理ができるかと思います。
#って、書いて単純にWebメールソフトを入れれば半分は解決するかも知れませんね。

 各種雑誌等をみれば、カスタマーセンター向け?の統括ソフトは幾つかあると思いますので、
その辺を調べればあるかと思います。
#日経コンピューターなどをみれば、あった気がします。


→  MailCenter

今泉克美 さんからのコメント
( Monday, July 23, 2001 18:07:16 )

なるほど。
稲垣さん、すごいものを
迅速にありがとうございます。

Webメール系、、、で
全然アイデア浮かびませんでした。


snappish さんからのコメント
( Monday, July 23, 2001 20:32:34 )

>自由な発想で
との事ですので
友人の会社の公開アドレスは
PC用のアドレスとは別に
携帯電話を意識して
123@myconpaney.co.jp
と携帯電話でも打安いようなアドレスを
別に用意しているって言っていました
どうでしょう(^^;

寺山 さんからのコメント
( Monday, July 23, 2001 22:54:52 )

MLのアドレスをxとする
MLにa,b,cのアカウントを登録する
で着信はいいのでしょうか?

各営業マンは返信時にfromをxとし
bccでxへも送信する
ではダメ?ややこしいでしょうか?

田中求之 さんからのコメント
( Monday, July 23, 2001 23:36:47 )

開発にかけられる資源(予算と人間)次第でしょうが、もし、私が、今手元にあるマ
シンを使って動かせ、とりあえず使えるものを自作するとすれば、稲垣さんの書かれ
ているように、

>一旦データベースに格納しておき、Webベースで管理をする方法であれば

という路線で考えますね。使用するツールは FileMaker, UVJ Mailer, mboxer そして
開発言語は AppleScript (とファイルメーカーのスクリプト機能)。

mboxer を使ってファイルメーカにメールを取り込む

担当者はファイルメーカのデータベースを開く(ネットの共有で開く)

返信もファイルメーカーで書いて、UVJ Mailer で発送。もちろん。返信の記入者や返
信の日時などもデータベースに記録する。

というのでやれば、最低限のことは可能になると思います。もちろん、Web コンパニ
オンなどを使って、Web 経由で処理を行えるようにするなどの機能拡張も可能でしょ
う。この辺は、開発者のスキル次第でなんとでもなりますね。

また、バックアップ用のカウントを作っておいて、そこにアカウント x へ届いたメー
ルのコピーを forword し、また発送したメールの Bcc を送るようにしておけば、何
かの際には、このバックアップアカウントのメールをたぐっていけばよいので、便利
だと思います。

今泉克美 さんからのコメント
( Tuesday, July 24, 2001 10:34:19 )

レスです。みなさまありがとうございます。(深深と頭を下げます)

>稲垣さん
CRMという世界が垣間見エルことになってしまいました。
なかなか大変なモノ作りが既に行われているのに知らなかった
私、アンテナが立っていないなぁと痛感しました。

>snappish さん
123@、、、
これもGOODアイデアですね。
私、頭が固いので
おもわず、info@
で処理しようとしてました。
携帯からももちろん来ますので
アイデアいただきます。

>寺山さん
>>MLのアドレスをxとする
>>MLにa,b,cのアカウントを登録する
>>で着信はいいのでしょうか?
そうなんです。最初に発想したのはML系でした。

>>各営業マンは返信時にfromをxとし
>>bccでxへも送信する

全く同じ発想を考え、実行すらしました。
これで、2重返信したり、内容の違うものを
複数の担当者が送信したりすることが
bccの操作忘れが原因で起こりやすいのですね。

当面、予算がおりるまではこれで行こうと
思っています。

で、HTMLのFORMとCGIを使って
Bccしわすれを禁止しようとさえ思っていました。
でも、これでもダメそうな感じがしたのです。
MLからどうやって情報を取り出そうとか
悩んでしまいました。

>>田中先生
やはり、データベースを使って
排他をかけていくしかなさそうです。
運用上の安全性を考えるとこれが一番ですね。
オーダーの仮引当、引当、処理済、くらいの
ステータスをもたなくてはいけなそうです。

人的予算をいただければこのせんで考えたいと
思います。

#ありがとうございました。

今泉克美 さんからのコメント
( Tuesday, July 24, 2001 17:15:32 )

田中先生の
>また、バックアップ用のカウントを作っておいて、
>そこにアカウント x へ届いたメールのコピーを 
>forword し、また発送したメールの Bcc を
>送るようにしておけば、何かの際には、
>このバックアップアカウントのメールを
>たぐっていけばよいので、
>便利だと思います。

は、素晴らしいアイデアです。
最初読んだときにわかりませんでした。
ありがとうございます。


田中求之 さんからのコメント
( Tuesday, July 24, 2001 17:58:01 )

ちょっと分かりにくい書き方になってしまいました (^_^;;

この方法は、昨年、日本水産学会の大会オンライン受付システムを組んだとき、
メールのやり取りを確実に記録するために用いたものです。運用後にちょっと
したトラブルが出たんですが、それでも、このバックアップのメールをダウ
ンロードして確認がとれたので、結果的に重宝しました。

寺山 さんからのコメント
( Wednesday, July 25, 2001 00:25:24 )

2重返信が起こる原因はわかりませんが、
複数の担当者からの返信を避けたいのなら
まず最初に複数の担当者に配送するのをや
めるべきだと思います.
もしくは複数の担当者に配送する時点で、
その案件の担当者を決めて置くべきではな
いでしょうか?
どういうシステムを作るにしても担当を決
めないまま仕事を割り振ると、誰も作業し
ない、又は、誰かが無駄な(使われない)
作業をすることになるように思われます.

今泉克美 さんからのコメント
( Wednesday, July 25, 2001 09:28:33 )

寺山さん、ご提案ありがとうございます。

担当者を決めて割り振る、、したいのはヤマヤマです。
機械的なシステムは非常に単純になります。
人間的なルールもシンプルです。
この意味でメリットがあります。

しかし、顧客にしてみると
レスポンスの遅れを生じるという
デメリットがあります。

電子メールではなくて
着信の電話でしたら、
いま、着席していて
電話を取れるものがまっさきにとります。
電話の着信音は全員に聞こえます。

この意味で
「最初に複数の担当者に配送する」
のです。

メールのやりとりの履歴などを参照して
担当者が、決まる場合がありますが
そのときには振ればいいのですね。
これは電話と同じです。

顧客に対するスピードを考えた場合に
しかも、失礼のない応対を考えたときに
機械的なサポートをよく考えたやりたいと
思っています。
機械にとってはシンプルでなくなりますが
人間にとっては自然な運用をめざしたいと
思うのです。

ろばたろう さんからのコメント
( Wednesday, July 25, 2001 22:12:32 )

>担当者を決めて割り振る、、したいのはヤマヤマです。
今泉さんのご心情はなんとなくですが私もわかります。

私も勤務先のWEBページのお問い合わせ用メールアドレスとか
対象者を特定できない(社員がグループとして使っている)メールアドレス
がありまして、いったい誰が最初に知って、誰がその後の処理をしたか?は
よくあります。

特に会社という組織では、ネットワークでの協調作業をすすめるほど、
ヒューマンファクターがのしあがってきます。
後者の対策は、前者以上に体力と気力を消耗します。(今日もそうだったあ!!)

で、コンピュータ化を進める前にいま手作業で行っている作業のフローを
まず整理しないといけないというような本を読んだことを思いだしました。

<目的>
1.顧客から情報を迅速に受け取る。
2.応対は、2重にならない。
3.担当者はそれらの処理の仮定を共有できる。

<手段>
1.X宛てにきたメールはプリンタで(自動的に)印刷される。
2.そのプリンタは担当者のデスク(群)の見えやすい位置に置く。
3.プリンタの排紙トレイに気付いた担当者はXのアカウントを受信する。
4.受信した担当者は、返信を行う。
5.返信が終われば、それも印刷する。
6.1.の印刷物と5.の印刷物をバインダーにセットで綴じる。
7.そのバインダーも担当者のデスク(群)の見えやすい位置に置く。

担当者はまず、プリンタを目視し、次にバインダーを閲覧することが
必須のルールになりますが、これができないとなると何でやっても
同じことだと思うのですが...

http://www.jci.co.jp/products/jetlan31.html

この製品を使ったことはありませんが、これでメールを×分おきにチェックする
という機能があれば、初動対応は向上すると思います。
(添付ファイルの印刷までは無理かも)
値段も手ごろですし、デモ機も貸し出してくれるようです。

マシンにも人間にもシンプルで自然でわかりやすいと思いのですが...

質問をはずしていましたらごめんなさい。

寺山 さんからのコメント
( Thursday, July 26, 2001 03:16:21 )

顧客に対するスピードを考えたとき、電話と違いタイムラグを
生じるメールは不利ですね.携帯電話へ送れば少しはましでしょ
うか?
2重の応対を避けたいのならやはり担当を決める必要があると
思います.
>電子メールではなくて
>着信の電話でしたら、
>いま、着席していて
>電話を取れるものがまっさきにとります。
>電話の着信音は全員に聞こえます。
電話の場合受話器を取ったものが担当に決定するというシステム
を採用しているのですね.
これに倣ってこんな方法はいかがでしょうか?

  MLのアドレスをxとする
  MLに各営業マンのアドレスa,b,c(携帯電話)を登録する
  MLにもうひとつのアドレスmを登録する

  各営業マンはそれぞれのアドレスでメールを受信し依頼状況を確認する
  各営業マンは手の空いたとき?アドレスmでメールを受信する(サーバーから削除)
  アドレスmで受信した依頼は受信した営業マンの担当とする

どれくらいの頻度でxへメールが来るのか
営業マンはどれくらいの間隔でメールを読むのか
によって担当する依頼の数が偏る可能性はありますが・・・

アドレスmで受信した営業マンがその依頼を処理するということで、手の空い
たものが受話器を上げ処理するという動作をなぞってみたのですがいかがでしょ
うか?mで受信したときにサーバーからメールを削除すれば担当が重複する事
もないと思われます.

メールを件名リストで受信してから必要なものだけを受信できるMUAとか
IMAP4なサーバーを使うことで処理数の偏りも補正できるのでは?

Junnama さんからのコメント
( Thursday, July 26, 2001 09:29:27 )

非常にシンプルに考えるならば、この会議室システムのシステムの考え方で一部
分のインターフェースをメールに変えれば実現できるのではないでしょうか。

新規発言部分を顧客からのメールに差し換え(機能的に)
#つまりメールを受け取ったら自動的に新規発言にポストされる.

返信は掲示板にコメントをつけるかたちで行う

返信された内容は、発言者に転送される

全ての発言/コメントを全営業マンに転送する

#これで、発言に対するコメントが既になされているときの発言または、そのス
レッドを読み込んだ後に誰か別の人がコメントしていた時は、コメント時に警告
(エラー)を表示する機能を付加すれば二重返信は防げます

というものを組めばいいと思うのですが。

EasyBBSを改造してできるような気がします。

今泉克美 さんからのコメント
( Thursday, July 26, 2001 17:03:42 )

みなさんのお知恵には脱帽です。

重ねて御礼申し上げます。

ちょっとTinyな
パッケージってあるのかな?
と思っていましたが
断念しました。

これだけ意見があるのですもの
正解なんてありそうにありません。
ということは、運用上の汎用性をねらうと
パッケージはでかくなるということです。

担当者決めで「仮引き当て」
決められた担当者が、実際に処理を開始で「引き当て」
処置完了で「出庫」
という在庫管理的な発想がありまして
それにみあうようなパッケージも探そうと
思っていたのですが
どうも商品説明だけではわかりませんでした。