Say you handle support emails privately at support@example.com.

Ideally this email is distributed amongst at least two employees in different timezones: Tom & John.

Q: How does Tom answer a support email and let John knows he's answered it? A: Use BCC

Q: How do you make sure the inquirer keeps to the support@example.com thread/conversation and not the personal email address of Tom?

A: Use Reply-To:

In mutt, you can automate this process like so:

set include
reply-hook .  unmy_hdr Reply-To:
reply-hook "~C support@example.com"  'my_hdr Reply-To: support@example.com'
reply-hook "~C support@example.com" 'push <edit-bcc>,support@example.com<enter>'
set edit_headers

Many thanks to scandal on #mutt on irc.freenode.net for the above ~/.muttc configuration lines.

In Gmail, you can setup the Reply-To: rule, but only for the entire @example.com account which is awkward. Also you must remember to set the BCC: manually.

Now with some luck, you can handle support/issue requests or "bug reports" as conversations in your inbox. This is far from perfect as your supportee may have a crappy MUA and break the thread.

You also would have to manually archive threads to mark them as done. And then you would only know it's "done", as there is no way of telling John is has been archived accordingly without sharing a mailbox. Sharing a mailbox AFAIK is pretty darn hard, though I've heard a rumour of IMAP having such a feature. And you would probably lose some accountability benefit sharing a mailbox.

Futhermore an interim mail BTS hybrid could be better achieved with labels/folders to emulate something like Debian's tags.

In a modern distributed company in order to communicate, businesses use tools like teleconferences (urgh), email, instant messaging (which one?) and more integrated packages like campfire.

Or you can be a little old school and use existing platforms for real time chat like Inter Relay Chat (IRC). IRC does exhibit quite a learning curve, though if your company are engineers, it shouldn't be too much a problem to learn how to use IRC.

Here is a guide to setting up your company with a private channel on Freenode. Whilst running your company on Freenode is not strictly on topic, it certainly isn't off topic.

I think Freenode should definitely discreetly host company channels, since it will only encourage companies to contribute to open source software projects down the line.

NickServ - user authentication

First you need to register with nickserv, /msg nickserv help register

Then you need to configure your IRC client to authenticate (identify) to the nickserv on startup. Ideally all your employees need to do this, though you can restrict your channel to IPs instead.

ChanServ - restricting your channel to your employees

Setup a dialog with chanserv and then begin like so:

help
help register

Which provides help how to register your channel. For the purposes of this tutorial, I'll use #example.

register #example

Then (providing your registered and identified with NickServ), you will become the founder of this channel.

So lets assume all your employees come in from the IP nat.example.com, you can now restrict the channel to those personnel, like so:

FLAGS #example *!*@nat.example.com +V
set #example RESTRICTED ON

So FLAGS sets up the access control list. To see who is on the list:

access #example list

To add an additional admin user:

FLAGS #example ircusername +votsriRfAF

If a user tried to join your restricted channel, the user will be immediately kick banned. So if that user is for example later added on the access list, you need to unban that user for that user to rejoin the channel.

To see the current bans in place for the channel:

/mode #example +b

To remove a ban for say 8.8.8.8:

/mode #example -b *!*@8.8.8.8

Transcripts

What about transcripts? If you run a decent IRC client like irssi, with screen and Apache httpd vhost on /web it's as painless as:

/SET log_create_mode 755
/LOG OPEN -targets #example /web/irc.example.com/%Y-%m-%d

Then if we to refer to our chat yesterday I would simply say check out http://irc.example.com/2010-06-14. To password protect the site, simply use an .htaccess like so:

irc.example.com$ cat .htaccess
Order deny,allow
Deny from all
AuthType Digest
AuthName "acme"
AuthUserFile /web/digest-password
Require valid-user
Satisfy Any