January 2008 Archives

I had an “I’m glad I’m not Catholic” moment during church on Sunday.

In some variants on Christianity, grace is imparted through such things as taking communion or getting baptized — rather than being symbolic, your salvation depends on eating the bread, drinking the wine, and getting wet in some form.

Some would call this a pretty low barrier to entry. It’s hard to mess up eating a cracker or something that in most other circumstances would be considered a bread crumb.

And yet, I managed, through an act of sheer dextrous incompetence, to drop the body of Christ when I was supposed to be eating it in remembrance of him.

It was a very clear reminder that it’s by grace that we’re saved, and not by works, so that no man can boast… even in something as simple and straightforward as eating, which you’d think most of us would have figured out by this age.

This is another in an occasional series of commentaries on various companies’ attempts to get me to give up the security of paper statements so that they can save money on postage and printing.

First it was the ability to hide your Christmas purchases from your spouse (who presumably doesn’t have your password to look at online statements, but would closely examine your credit card statement if it came in the mail, looking for that one Amazon.com purchase that stood out).

Then they offered to plant a tree, which would make you feel better about all those poor, defenseless trees you killed by not switching to paperless statements earlier.

Then, shock of shocks, they offered a $5 statement credit (just once, I checked) if you switched to paperless statements. They clearly weren’t looking at my monthly totals when they came up with that offer.

But now, they’re really raising the stakes. If you switch to paperless statements by such and such a date, you’ll be entered to win one of three MINI Cooper cars, 3 outdoor adventures, 5 kitchen appliances, 10 bicycles, and 100 gift certificates for $100 to a store I’ve never heard of.

“It’s Time to Go Paperless. It’s the smart thing to do.”

Assuming I never get audited, or have a dispute over a bill. Until I’m offered a satisfactory solution for what would happen if the bank were to go out of business tomorrow, and six years down the road I have to produce a statement for the IRS, I’m not interested.

I’d also like to see some admission that they’re doing this solely out of their own interests, rather than making up excuses (or lying outright) about it being better for me. This one comes close (why else would they be spending all this money on prizes if they didn’t stand to gain a lot more?), but no cigar yet.

(Also, regarding the whole “smart” thing. This is also the bank that sends me an E-Mail every month telling me about how great it would be if I paid my bill online, apparently without noticing that I do.)

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:

1. 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).

2. 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.

This is a new one. I just called Verizon’s business sales line to see what Internet options there are for a property I’m considering, and after struggling through the voice-activated phone menu (it: “Please say or enter your ten-digit number. If you don’t know it, say ‘try another way’ or ‘new service.” me: “New service.” It: “Please say or enter your ten-digit number. If you don’t know it, say ‘try another way’ or ‘new service.” Me: “New service.” It: “Please say or enter your ten-digit number.” Me: “New service.” It: “You must enter a ten-digit number.” Me: [0]. It: “Please hold for the next available agent.”), got a new message — “due to unusually high call volume, no agent is currently available to take your call, and we are unable to put you in the queue” (paraphrased — the gist is that they’re out of circuits).

Do they really have that many people trying to order new service? Or are the customer service lines on the same system? And what’s this with a phone company running out of phone lines?

(This was shortly after calling Verizon to have my current office DSL upload speed fixed after they goofed the most recent change… again… and having to go through three different departments to get that done.)