Can we read the same email without tears?

December 10, 2007 11:48 AM

Help me use email in a multi-user environment. IMAP is great, but not for more than one user at a time.

My boss operates a business where people register for classes through a website. An HTML form generates an email. Administrator checks email for registration details and enters details in a (hosted) FileMaker database, which then sends confirmation email.

All of this worked fine when all of the business could be dealt with by one person, or even one person at a time. Now, the business has grown to the point where there is often a need for two people to be processing the emails at one time, two people at two different desks in two different locations. We have an IMAP email account, and messages are often duplicated when both email clients (Mail.app) are connected at the same time. We also use third-party software (MailTags) to add keywords and notes to individual emails. We now minimize the errors by turning off automatic synching, but there are still collisions and gaps. Users communicate via iChat.

The business is not large enough to warrant shelling out for expensive large-scale enterprise solution. We want the ability to have two or more people at two or more workstations accessing the same information from the same email account at the same time, and to be able to make other users aware of the actions they have taken on those emails, without having to create a separate log.

The hosted FileMaker database works well enough (two users can update the database at the same time, just not the same record). Is there a similar solution for email? Should we somehow route the email account through its own hosted FM database and work from that?

Ideas? Thoughts? Thanks!

posted by al_fresco to computers & internet (14 answers total)

This is what Request Tracker is for -- allowing individuals to assign or "take" incoming e-mails so toes aren't stepped on and requests are... tracked. It's free and open source, but they also have a hosted solution if you're not Perl or Linux inclined.
posted by eschatfische at 11:53 AM on December 10, 2007

Having multiple people access the same mailbox? That way lies madness.

Several teams at my workplace use RequestTracker for this very process. It seems to work pretty well for them, and for me as an end-user.
posted by grouse at 11:56 AM on December 10, 2007

Sounds like a workflow issue to me. Why not have both users agree on some kind of scheme. One guy does odd numbered requests and the other does even. You can also install a ticket tracking system and have the emails create a new ticket. RT is free.
posted by damn dirty ape at 11:59 AM on December 10, 2007

Or what grouse said.
posted by damn dirty ape at 11:59 AM on December 10, 2007

Just make subfolders, and move emails into per-user subfolders before doing any work at all. Assuming you're doing IMAP with Maildirs, and you leave syncing on, it should automatically update immediately on both machines when you move it with one.

Note that some IMAP servers are better than others. I was using courier-imap for a long time; switching to dovecot was a bleeding revelation. Dovecot is fantastic. It's much faster than courier and supports instant searching. With courier, searching a big mailbox took many minutes, where with dovecot it's instant. If you're having lock trouble, you might just be running a poor server... check into that.

Another thing you could do would be to write a maildrop or procmail recipe (maildrop is easier)... create a tracking file with 0 in it. If the file has 0 in it, write 1 and deliver to person A; if it has 1, write 0 and deliver to person B. (or to subfolders in the main IMAP account, same diff.)

Local mail delivery is virtually always serialized, so this shouldn't result in any race conditions; it should just work.

If you don't want to mess with the mail delivery system, write a tiny perl script that moves the files as they come in to subfolders. It should take, geeze, three minutes to write something like that... even a rank amateur could probably handle it, although it would take longer than three minutes in that case.

If you do the perl script thing, just have nobody touch any files in the root dir... have them wait for the script to start up and move the files.

As a safeguard, have your perl script create a ".separator_running" file or some such, and refuse to run if it sees that file. If, for some reason, it gets bogged down and can't finish by the time the next scheduled run starts, the second and later iterations will quietly exit. Then have the script remove the file when it's finished. Make sure it removes the file whether or not it succeeds at its other tasks.

Remember, this is Unix, you can do damn near anything you want. If it's not doing things precisely how you want, you can always bend it to your will.

If you're using mboxes, this file jiggery can be much more painful. Maildirs are wildly better, and will let you write absolutely trivial scripts to do anything you need. mboxes are one big file, where Maildirs use a separate file for every message. This means you can manipulate and move them trivially, without having to do file locking and surgery on the single huge mbox file.
posted by Malor at 12:10 PM on December 10, 2007

Agree that the right issue lies in moving beyond e-mail. But maybe the best thing is to have the form go directly into the DB automatically, and then have flags for whether a record has been reviewed by a human, and whether it needs follow-up.
posted by Good Brain at 12:41 PM on December 10, 2007

Good Brain is almost certainly right. The only problem is that if this were a realistic solution for the OP, I figured they would have already done it.
posted by grouse at 12:49 PM on December 10, 2007

Don't use the primary mail account. Instead, look at the sender's email address, and forward all mail from address that contains "a@", or "b@, "c@", "d@"... to responder Alice. Else, forward to responder Bob. So, "[e-mail]" would match "d@" and go to Alice every time. If your mail volume grows or you notice an unequal distribution, you can shuffle or subdivide even more.

If you have long stateful information, then email is the wrong place to keep it. Use a free online wiki with the page name being the sender's email address. There are dozens of free ones, if cost is a problem. Some allow you to make it private and only accessible with a password.
posted by cmiller at 1:00 PM on December 10, 2007

I don't think I was clear enough. I mean each person should have a unique address, and the receiving address should /only/ forward email to them. And, divide the labor using something like the email address of the sender, or the message ID or the second of the day or whatever your system permits that will vary; and if it doesn't vary between successive messages of the same sender, then (bonus!) long-term relationships.
posted by cmiller at 1:04 PM on December 10, 2007

You could use a service like Mail Tank http://www.mactank.com/
posted by mac-way at 1:13 PM on December 10, 2007

If you've got ruby this ought to work. Fill in server, username and password and modify the INBOX/ paths to point where you want them to go. It should be able to handle any number of splits and it'll divide them fairly.
posted by Skorgu at 1:23 PM on December 10, 2007

Erm, why not drop email entirely and use a MySQL database to store requests, and another PHP page to browse them? You could even set things up to go straight to filemaker without intervention with something like this.
posted by delmoi at 1:32 PM on December 10, 2007

Technically delmoi is right, this is a poor use of email. Any halfway competent PHP coder could whip together a tracking app in half an hour. I really only took a shot at the IMAP version for kicks but I also don't think we need more halfway-decent half-hour PHP programs that take arbitrary user input and email it floating around on the web. I get enough spam as is.

The two of you who grabbed that before I added the license 1) are freaking fast and 2) should know it's BSD-licensed.
posted by Skorgu at 1:44 PM on December 10, 2007

Wow! Thanks all. I obviously came to the right place.

Here are my initial thoughts to your thoughtful responses:

We thought of having the form data go directly into the database. The type of business and the nature of the various queries means lots of massaging individual customers. Also, not all email is generated by the HTML form, so subject fields can vary widely. Payments are often made by check, and requests need to be processed in the order that the check is received by snail-mail, which can't really be automated. We also get the occasional spambot form. In any case, each request really needs to be looked at by a human. Often one email may need several different kinds of action. Tagging works well in this regard, whereas separating into folders by task does not.

I'm intrigued by the idea of splitting requests by sender into separate folders. that's a possibility that I'll look into, as it's quite easy to implement. MailTank looks very interesting too.

Keep the great ideas flowing! I'll let you know what direction we end up going if we change things in the next few days.

Thanks!
posted by al_fresco at 1:58 PM on December 10, 2007