Archived at Pineapplesoft
 ananas.org 
  The Pineapplesoft Link newsletter covered a wide range of technical topics, see the archived issues.
The newsletter was first emailed in 1998. In 2001 Benoît discontinued it in favour of professional writing for magazines.
The “September 1998” page was archived in 2003 to preserve the original content of September 1998.
 
  | Home | Contact | Site map | Writings | Open source software |  


 

Welcome to the ninth issue of Pineapplesoft Link.

Last month, a friend asked me if he could forward the newsletter to his colleagues. In case you're asking yourself the same question, here's my answer: please do! I encourage you to forward this newsletter to friends, colleagues or family who would be interested. I only ask that you retain the copyright notice at the bottom.

In the June issue, I introduced the idea of writing lighter articles every two or three months. The response was very positive and I intend to continue. I'm about to leave for a two weeks vacation in Scotland so I thought a lighter issue was appropriate. This one is not about XML, CORBA or Java but it's about my pet Internet medium: email.

If you prefer the more technical issues, wait for next month. I haven't yet made my mind but I expect it will be either a follow-up on CORBA or a in-depth look at web site usability. Please send me your comments, questions or suggestions to [address removed, the newsletter is no longer published thank you for your support].

Pineapplesoft Link, September 98:
Beef Up Your Email Strategy

[Addresses have been changed to defeat spammers. Don't use them.]

In terms of popularity email is second to none. There are more active email users than active web users or, for that matter, active users of any other Internet application. Yet decision makers are mainly concerned about the web. Organizations invest heavily on their web site and they fail to exploit a promising medium like email.

There are many opportunities for an organization to benefit from email as a communication or a productivity tool. I intend to cover some aspects of email strategy in future issues of Pineapplesoft Link and this month I want to start with the basics of an email strategy: roles.

Some Vocabulary

A role represents a service which is delivered by an entity -- human or not. Typically we identify roles when we don't care who the entity is. The best example is the phone operator: when looking for a number, you dial the operator and request assistance. You don't care whether the operator is Paul, Anna or Tania. You are calling "the operator" -- a role. Indeed if there's a problem (say you wrote the number incorrectly) and you have to dial again, chances are you'll talk to somebody else. For you, it's still "the operator."

In email terms some roles are webmaster@company.com, info@company.com or sales@company.com.

Roles are typically implemented either through email aliases or through robots.

An email alias is an email address that works like a PO box. Any mail sent to the alias is forwarded to another mailbox. For instance I have several old, seldom-used aliases, one of them is bmarchal@example.org which forwards to bmarchal@otherexample.com. Writing to bmarchal@example.org is equivalent to writing to bmarchal@otherexample.com.

All email servers support aliases and they are typically very easy to setup. It shouldn't take more than a few minutes to create a new alias or to update one. For small businesses which don't run their own server, unlimited aliases can be as cheap as $50/year as explained in the June issue (http://www.psol.be/old/1/newsletter/19980601_dns.html).

Finally an email robot is any software which processes mails automatically. You are probably familiar with at least two robots: autoresponders which automatically reply to emails and mailing list manager such a majordomo which automatically subscribes to and unsubscribes from mailing lists.

Role or Person

It is common practice to print email addresses on stationery (business card, letterhead) and marketing material (brochure, advertisement). However which address should be printed where?

Experience has taught me that changing an email address after it has been published is a very slow and costly process. Firstly one has to recall all the documents that bear the old address and update them. This itself can be very costly. Secondly one has to inform all one's correspondents and there's typically a huge delay before they are all using the new address. I have been using the address bmarchal@otherexample.com for more than a year but some people are still using my former, CompuServe-based, email address.

To manage email more efficiently, an organization should aim to minimize address changes. Role-based addresses combined with aliases are the solution. Name-based email addresses are difficult to reassign.

Suppose John Smith has been handling orders. When he is promoted to the marketing department, it seems logical that he retains his email address. However what if customers are used to sending their orders to jsmith@company.com? They will continue sending their orders to John that will re-route them internally causing delays and frustration.

It would have been smarter to have two email addresses: jsmith@company.com, for those people who want to write to John specifically, and an alias such as order@company.com to accept orders. When John moves to the marketing department, order@company.com is aliased to mknaupf@company.com, the mailbox of Mary Knaupf the new clerk.

It seems easy but I'm surprised at how many organizations learn this the hard way.

Pros and Cons

It all boils to finding the right balance between flexibility and personalized service. Role-based email addresses ensure the maximum flexibility, as we have seen, whereas person-based email addresses give the impression of a highly personalized service.

When writing to a role, one never knows who will process the email whereas when writing jsmith@company.com, one hopes to reach John Smith with whom one may have established an ongoing relationship.

There is no definitive answer whether you should use roles or persons. It largely depends on the culture of the organization and the expectation of the customers. If the organization has a policy of highly-personalized service and a tradition to boost one to one, personal relationships, then it makes more sense to use few roles and more personal addresses.

Personal Roles

Although it is somewhat contradictory, I have found that the concept of roles can also be applied to a person, leading to a sort of person-role.

For example, I participate in many mailing lists and I subscribe to numerous newsletters. I find that it's more efficient to subscribe to these lists under a specific role: when I hit the road I just redirect this flux of low-priority emails to another mailbox. This dramatically reduces the number of emails I have to go through over the slow, unreliable connections travelers have to use.

You may want to experiment with this approach yourself and create aliases that fit your own criteria: family mail, accounting, etc.

Roles have many other applications. For example, an organization can use them to test the response to a specific marketing campaign: publish the address newspaper@company.com in the newspaper and tv@company.com for TV ads.

Creating Roles

Which brings the next question. If your organization decide to implement role-email, when should it create new roles? And how many roles are required?

There's no definitive answer. Besides the few obvious aliases such as info@company.com and departmental aliases (sales@company.com, marketing@company.com, etc.), the most sensible approach is just to monitor email traffic and create aliases as new patterns appear. For example, you may decide on a given threshold, e.g. when there is more than 10 emails per day on a particular issue.

It means that you must educate your employees about the value of roles. For example explain to them that by using order@company.com, it will be easy to redirect that traffic when they go on holidays.

However it is important to document roles as they are created.

That's exactly what we do at Pineapplesoft. We view creation of roles as a very dynamic process. This month, we're introducing a new role: listmaster@otherexample.com to catch all traffic related to the newsletter subscription. When we started, I would receive all that mail directly. Today it amounts to hundreds of emails per month we are likely to move it to a robot in the future.

Your Policy

If your organization has no policy over email, this is the right time to reconsider that position. As more customers become fluent with email, it makes sense to establish a corporate policy on how to deal with email. There are more aspects to this policy than roles obviously such what is the acceptable turnover to answer email inquiries? Should you have stylesheets and standard forms like for fax and postal mail?

We'll look at these aspects in future issues but defining a policy on roles is a first step in the right direction.

Self-promotion department

I have published three new articles this month. Two articles on WAI, which is a replacement for CGI:

WAI is remarkable because it's based on CORBA providing an easy path to distribute server-side processes. Also WAI is attractive for small businesses who want to host Java server-side processes.

The third article is a look under the hood of an e-commerce server.

In the article I build a simple shop, JSShop in server-side JavaScript. Along the road, I discuss some of the things you should look for when shopping for or building an e-commerce solution. The article includes a complete, documented server-side JavaScript application which will interest anybody studying server-side JavaScript.

About Pineapplesoft Link

Pineapplesoft Link is published freely, every month via email. The focus is on Internet applications in its broadest sense: distributed and mobile computing, e-commerce, Java, XML, etc. The articles target people interested or concerned about technology either personally or professionally. This issue of Pineapplesoft Link may be distributed freely for non-commercial purposes as long as attribution (including the URL: www.psol.be ) is given. For commercial redistribution, please contact me.

Editor: Benoit Marchal
Publisher: Pineapplesoft sprl www.psol.be

Acknowledgements: thanks to Sean McLoughlin MBA for helping me with this issue.

Back issues are available at http://www.psol.be/old/1/newsletter/.

Although the editor and the publisher have used reasonable endeavors to ensure accuracy of the contents, they assume no responsibility for any error or omission that may appear in the document.

Last update: September 1998.
© 1998, Benoît Marchal. All rights reserved.
Design, XSL coding & photo: PineappleSoft OnLine.