[tmail21]

At a very high level, email is primarily used for discussions. With this view, successful innovation in the e-mail space requires innovation in the nature of discussions themselves. Tinkering around with better usability or feature improvements will not be sufficient to overcome the massive inertia of 'traditional e-mail'.

We are a startup that just launched (https://tmail21.com) that aims to rethink the discussion itself. In our view, one of the major problems of e-mail (and chat for that matter) is that the discussions are not goal-oriented. So, discussions/threads can meander around with no outcome or accountability.

So, we enhance the notion of discussions to be goal-oriented.

Now, once one has the notion of goal-oriented discussions, a natural next step is to evolve a goal-oriented discussion into a Lean Process (which is basically a goal-oriented discussion with more structure) . Examples of a Lean Process might be a Blog Article process, a Product Deployment Process, a Feature Design Process, an Issue Escalation Process etc.

We've done all this in an email-LIKE interface. I guess we'll leave it to others to decide whether this constitutes innovation in the e-mail space :)

[bitcuration]

Pretty good endeavor that you essentially created a BPM application, that is only as if email used as a BPM platform which is seen prevailing in corporate than other enterprise tools (SAP, Oracle etc.)

I actually propose instead of re-inventing email, create addons to extend what email message can be used/read/interacted with. For example, high school teaching today has been reliant on gmail for offline homework assignment and discuss between teacher and kids. There are some tools in that space aggressively exploited by schools to conduct their "innovative" teaching efforts.

Gmail, or microsoft outlook would be the best go-to destination for the majority of who can afford an in-house IT team, or shadow IT in large enterprise who's tired of the lack of evolution from SAP, IBM etc.

Still, Gmail and outlook are slow in adopting or providing email as an open extendable platform for BPM application purpose.

Then there are everyday use of email other than BPM, notification, online purchase receipt, offline discussion, even transmitting files, photo etc. via email are somewhat common with email client.

The longevity of email is exactly the lack of rigor of the intended use of it, BPM or not, email is flexible to conduct any discussion to an open goal, or without a goal.

To understand email better, one has to compare email to SMS, and social media along with how mass used these tools.

[tmail21]

Thanks for your insights bitcuration. I agree that email is flexible enough to do things like goal oriented discussions, but it is just so painful. The best one can do is fling attachments around and hope to get all the versioning right and avoid inadvertent branching.

TMail21 does other email-like things like transmitting files, notifications, full search etc.

It also does interesting things like giving every thread a unique tracking number, which allows it to be tied into the broader enterprise ecosystem. The idea is that just like the URL transformed the Internet (i.e. the web), Tracking numbers can transform 'email'. Now, TMails can be referred to from Chat, Voice, IM, Apps, Spreadsheets etc.

Another thing we do that is very hard to do in email is things like Certified Mail, Certified Forwards, Transactional Guarantees, Certified Diffs, Non-repudiable audit trails etc.

All of these capabilities are however means to an end to make TMail21 the first true BPM tool for regular business users (rather than for coders and 'process analysts)

[untog]

At a very high level, email is primarily used for discussions.

I guess it depends on what you mean by "primarily" but my inbox is overwhelmingly notifications and announcements, not discussions. There's remarkably little of my inbox dedicated to actually talking to people.

[tmail21]

You are right. There is a mix of notifications and discussions with the mix varying between the two based on the nature of user's communication. In more collaborative scenarios, it may be 80%-20% discussion-notification. In other scenarios the ratio may be reversed.

On the pure notification front, we have friendly tracking numbers (so that notifications can be referred to from other places like spreadsheets, chat, apps, voice etc.). These tracking numbers look something like 124-1234-1234. We also support Certified Mail, Certified Forwards, Certified Read Acks etc.

Having said this, we currently support outbound notifications (from TMail to TMail/EMail). On the inbound side we support TMail to TMail. We do not currently support EMail to TMail notifications although we may add this if we see sufficient demand.