How to handle group E-Mail
One of the technical challenges involved with going from having just me doing all the customer interaction to having one or more other people doing so, is how to handle the E-Mails. As soon as more than one of us is interacting with the same customer, there’s potential for E-Mails to get missed.
For example, say Christine sends a “your letters are in the mail” E-Mail to someone, and then goes for a month-long horseback riding vacation in Ireland a few weeks later, or something like that. Two days into her vacation, that person sends a new letter, or asks a question. What happens?
If each person has their own E-Mail account, and assuming I’m not the snooping type, the question or letter gets ignored until Christine gets back, even though I’ve been here and working the whole time, presumably. That wouldn’t be good.
An alternative is to have one E-Mail account that everyone uses for all business-related mail, but that gets somewhat messy. How would we keep track of correspondence so that we’re not either repeating or contradicting each other? Searching the Sent Mail folder isn’t a good way of doing that.
A CRM package would do the trick, but every time I look at a package, it seems to be geared towards roving sales people, and centered around leads and goals. Or else it’s just overkill. My software already has a good chunk of the CRM-ish stuff that I need, and the packages haven’t sold me on the need to duplicate effort.
I could add E-Mail support into the software, and this might be a good long-term solution, but there are enough pulls on my time right now that I’d rather find a cheap or open source solution that I can mostly plug in, and give this task to someone else down the road to integrate gradually.
A Web 2.0 company called Sprout-It makes a service called Mailroom, which looks like it’ll do exactly what I want. The problem is that it’s not a downloadable product — all your mail resides on their server(s) — and while lots of people are touting the benefits of web-based services, not many are talking about the fact that if one of these services goes out of business abruptly, or if they lose a server and their backup plan isn’t up to snuff, your odds of getting your data from them aren’t exactly great.
So, that’s a non-starter for me, as much as I’d like the service otherwise. I also like using an E-Mail client for E-Mail instead of a browser — offline access can be nice, and there’s no lag.
In the end, I keep coming back to Best Practical’s RT. I used it and administered it in a past job, and got to know it fairly well during that time. I keep deciding against it, though, because of the ticket numbers in the subject line — I want to keep up the personal connection with missionaries, and an easy way to kill that would be to have a subject line like “[pls #281734] Preview Available”.
(Indeed, if you’re not logged in as an operator, you’ll be hard-pressed to find any identifying numbers on the site. There are a few in URLs, and I occasionally include shortcut URLs in E-Mails, some of which have magic numbers in them, but that’s it, and I’m generally getting rid of those when possible, too.)
Now, the reason for having ticket numbers is to let the computer file the E-Mail in the appropriate bucket, specifically so that replies to previous E-Mails get linked together. It works fairly well most of the time, but it needn’t be necessary. Computers have all sorts of processing power, and a more complex set of rules than match-to-number could be used.
The issue in the past has always been that I don’t know that RT could be easily customized to identify tickets based on other mailing-related information, especially since there have been a few major version releases since I last used it for production purposes, so I’m rather rusty on its changing internals. I also don’t think it’s a good idea to try and customize an open source product before you start using it for its intended purpose.
But, as I was chewing on the problem today, and looking through the wiki, I think I might have something that will work, and be only minimally invasive.
There are two things that need to get done:
Remove the tag from the outgoing subject line if the E-Mail isn’t going to an operator (or just prevent it from being generated in the first place, but I do want the tag to be on the operator E-Mails, if possible).
Parse incoming mail and put the tag back in before it gets to RT.
The first part is straightforward. RT is easy enough to customize, so it’s just a matter of finding the code that puts the tag in, and stopping it from doing so. Hopefully, it’ll be possible in that function to figure out who the recipient is as well, so I can selectively remove the tag. If not, I need to do this through the SMTP server, which I’m not as familiar with, and would rather not need to spend the time familiarizing myself with it right now. Or, I could just make the operators use the web interface, but I’d like to keep using my E-Mail program, as I mentioned above.
The second part has always been the sticking point, but if I send the mail through Procmail instead of funneling it directly to RT, I should be able to get Mail::Audit or something like that to modify the subject line and then pipe it to RT.
Since using Mail::Audit means using Perl, that would also mean I can use my existing libraries to pull relevant info from the database, such as, “does this person have an active mailing?” and “if so, and if the subject line is something like ‘Re: Preview Available’, pull the ticket number for that mailing from the database and stick it on the subject line”.
I’m liking this idea. I wonder if it’ll work, or if there’s something I’m missing.
