Here's a statistical downer: there will be around 40 trillion inbox-clogging spam e-mail messages delivered this year. Experts know this because there were 30 trillion spam messages last year. With this much hay in the stack, it's hard to find those message needles, and that's why some smart companies are looking beyond public e-mail. (Compare antispam products)
Notice I said “public” e-mail. Some companies use a private e-mail system for messages within the company. If your employees are all under one roof, this becomes very simple and you can use an e-mail system that doesn't need an Internet connection. If employees are scattered around different offices or communicate while traveling, it gets a little more complicated, but not too much.
A private e-mail system works great for messages between employees and no one else. Every e-mail client- or browser-based e-mail system provides filters to put incoming e-mails into the right folder automatically. Every e-mail client I know also allows you to connect to multiple e-mail servers, so you can still use a single application for all your mail, but rely on the fact that some folders contain only work messages.
Two things ruin private e-mail systems. First, some users never get the idea of having different e-mail accounts inside a single e-mail client. A few of these people will function OK when you provide a second application, but some will never understand the public/private idea and send messages from both systems to anyone and everyone.
Second, some idiot (usually a vice president) will load up every name in the private system in the TO: line rather than the BCC: line, and send an e-mail with these names out to the public. When that happens, all bets are off, and your private e-mail becomes just as spam choked as your public e-mail. Once the names are outside the company, you lose control of them, and the spam flood starts.
These two issues tend to kill the public/private e-mail projects I've seen, which is a shame. On the other hand, e-mail isn't the best tool anymore to organize information and collaboration with a group of co-workers.
Instant Messaging fans long ago started relying on quick exchanges via IM in place of e-mail. This works great for employees sitting at their computer most of the day, but IM doesn't do so well when teams include traveling members who are unable to respond quickly.
Worse, IM leaves no history. New members to the project can't get up to speed by reading old messages. Even though e-mail information tends to be scattered around, at least some can be tracked. Regulations in some industries require companies to archive IM messages, but the goal isn't to share the information with co-workers, it's to let management fulfill the CYA requirement.
That has given rise to the move to provide messaging between groups of employees strictly within the application used for their particular team project. Messages aren't really from one person to another, they're mostly one person to a group. The leading technology enabler? Wikis.
Yes, the pseudo blog technology with the funny name can jumpstart group information sharing and boost productivity. Wikis now appear in all sorts of hosted applications, such as project management tools, collaborative team workspaces, and project portal applications.
My favorite, PBwiki, lists over 30,000 businesses using its software for a variety of collaborative projects. Central Desktop built its entire Software as a Service application, which it calls “simple project collaboration tools,” on a wiki foundation. Liquid Planner, a fairly new SaaS project management application, uses wikis to keep track of who's doing what and other messages.
In fact, it's hard to find a hosted collaboration application that doesn't use a wiki somewhere, so we'll stop pointing them out. All offer free trials or even free service for small groups, so check them out yourselves. Search for “online collaboration tool +wiki” and you'll see hundreds of thousands of results.
Using a hosted collaboration application with a wiki isn't technically difficult, but does take a mindset change. Everyone can see how much you contribute, or don't contribute. You must work within the hosted collaboration application, rather than putting everything into a spreadsheet because you like those better than the flat form database the others like.
You can't get away from e-mail completely with these products, because most send you an e-mail alerting you to changes made by co-workers. But if you miss an update e-mail in the spam flood, you'll see the changes when you next log in to the application.
Being hosted applications, the cost is based on per user per month access, not new hardware and software. If it doesn't work, you can kill the project and stop paying. Try the “stop paying” trick for a new server and software if a traditional project doesn't work and see how fast the lawyers call.
If you're particularly paranoid about your data being out “in the cloud” you'll be glad to hear almost every hosted collaboration application vendor offers a version you can host on your own servers. Your users won't really see a difference, but you will control the software. You can start with a small group on the hosted version, then grow and move to the in house version. Paranoia reduced.
We need a new term to describe “hosted collaboration application with a wiki” because that's a lot to type each time. How about collabappiki? Better yet, how about collabapp?
If your job requires you to interact with co-workers and track what happens, you'll be using more collabapps in the future. The more you collabapp, the less you e-mail.