Email's Role in an Enterprise 2.0 Environment: Signal Not Source

By Ethan Yarbrough posted 08-23-2010 19:59


Is Enterprise 2.0 an evolution of business or a revolution? If I had to be pinned down to an answer, I’d say “evolution”. Or to be more accurate: it's a revolutionary idea that I think will emerge gradually, in an incremental, evolutionary fashion. 

Take the replacement of email for example. I’ve railed against email before. But the fact is it is a foundational tool of internal communications in business and while Enterprise 2.0 flirts with the promise of eliminating it, that’s not going to happen any time soon. What is likely to happen instead is a transformation of the role email plays. I’ve seen that happen in my own company. 

Jason manages our service delivery team. That means he oversees the SharePoint development team that gets called into action if what the client needs involves SharePoint, he oversees the developers who are pressed into service if the project is .asp,, C# or some other specialized dev project and he manages the recruiting team that helps fill staffing roles for our clients. 

When he took over the role, he found himself fielding requests from the business development team to connect them with subject matter experts on his team who could help develop client proposals. 

After a few weeks on the job he realized he was receiving email after email asking the same question every time: who can I talk to on your team who knows X? 

He would forward the email to team leads. The leads would respond to the email with an email of their own asking for more information, they needed to know more about the project to know who to assign to the proposal development. The originator of the first email would respond, sometimes cc’ing Jason, sometimes not. So sometimes he was looped into the whole conversation as it played out in email other times he got dropped from the conversation because someone chose to hit “reply” instead of “reply all”, so keeping track of who was engaged in what proposal development and who was still available was nearly impossible. 

Jason took advantage of SharePoint to solve this problem. I won’t go into all the finer details here. But he developed a tool that has a business development person fill in detail on a standardized “resource request template” in SharePoint. The template asks for project detail in a uniform way, whereas before what project detail was included in the resource request email varied depending on who initiated the email. 

When the form is complete, the business development team member clicks the save button and SharePoint sends an alert email to the appropriate team lead. That person then follows a link in the alert email back to the form on the SharePoint intranet where they can respond with questions and details or can assign a team resource. If a resource is assigned, the form sends an alert email to the team member chosen, who follows the link to the form and can initiate conversation with business development. The business development person receives their own alert email any time the form is updated and can follow the link to view comments, questions or to see who has been assigned to help them. 

Now I bring this up for a few reasons. Not to thrill you with the creativity of our SharePoint implementation -- it is an extremely simple use of SharePoint, I admit that. But it is having a profound effect on the efficiency of our business. Because it collects all conversation about an emerging project in a single form view as opposed to having those details develop through a back and forth email conversation, information does not get lost and anyone from any of the teams can view at any time the latest status of the conversation. Enterprise 2.0 does not have to be complex to be cool – it just has to solve real problems really well, and this tool achieves that. Real cross-team visibility into project status. The quality of our proposals has gone up as a result, our win percentage has gone up as a result. Our revenue has increased as a result. 

The other reason I bring it up is because I’m taken by the dramatic shift in email’s role when you develop a solution like this. Email is still part of the structure, but now it simply serves the role of signal. Email no longer serves as the channel for conversation. Email tells people when the conversation has moved forward, but to see how it has progressed people now go to the SharePoint platform where they can immediately see the latest updates in their full historical context, including the actual proposal document that grows out of this process in each case and which can now be seen in one place with full, historical version control.

I'll admit I dream of a day when email is a museum piece alongside the telegraph. But whether I like it or not, it still carries a lot of the weight in business. If this kind of a solution is a sign that email can still serve a useful purpose while giving up the purposes it is not well suited for, then I can live with that evolution.

#platformvschannel #sharepoint2010 #communication #SharePoint #processimprovement #emailreplacement