Would You Manage CRM with a Wiki?

Or human resources with a blog? How about project management with forums?

Funny questions to ask, no doubt. Of course it’s not possible to effectively address many of the critical business functions using basic Enterprise 2.0 tools. Yet when it comes to social software, it often seems that the only game in town is to be a provider of such tools. For instance, Gartner’s Social Software Magic Quadrant requires that vendors have wikis, blogs and forums to be considered (side note – for the record, Spigit has all three social software tools and more).

I am fully on board that there are great opportunities for new types of communication, collaboration and information discovery in these tools. For instance, see my post, Microblogging Will Marginalize Corporate Email.

But there’s an enormous opportunity for applying the ethos and value of  ‘social’, ‘transparency’ and ‘collaboration’ to a wider range of business processes. Key here is not to force specific processes into a general purpose tool, but to bring social software ethos to longstanding enterprise activities.

Hmm…sounds Dachis Group-like (“social business design”), eh?

Activity-Specific Social Applications

In the recent Gartner Social Software Hype Cycle, analyst Anthony Bradley introduced a new category, Activity-Specific Social Applications:

“As social software implementations mature, application patterns are evolving, and the software industry is responding with activity-centric social application offerings rather than with generic social software capability suites. Delivering a targeted social solution with a general purpose social tool (such as wikis and blogs) can involve significant development, configuration, and templating effort.”

Bradley has identified the next opportunity in enterprise social social software. Integrating the valuable characteristics of social software into the in-the-flow activities that make up our days. As a percentage of employees’ time, activity-specific social applications will be quite large.

Back in March 2009, Sameer Patel wrote, don’t confuse Enterprise 2.0 with social computing concepts. He was making this exact point, and included this illustrative diagram:

Credit: Sameer Patel, Span Strategies

Credit: Sameer Patel, Span Strategies

His point is that the left side are tools, whereas the right side are results-based activities. Key here is to create applications aligned with the processes for those activities. That means going deeper than a general purpose tool.

Successful Applications Will Be Designed for Results

So back to the original question. Would you manage CRM with a wiki? Could you? Perhaps there’s a geek hack to do this, but for mainstream business, the answer is ‘no’. Customer relationship management includes:

  • Case management
  • Customer revenue analytics
  • Sales pipeline
  • Individual prospect opportunity workflow
  • And lots of other stuff

It would be really hard to use generic off-the-shelf social software to deliver the above functionality. Yet, going back in time, here’s what was prescribed for CRM success in April 2002:

People [who fail] don’t integrate CRM into the other parts of their business or implement CRM as a stand-alone and don’t have it communicate with core systems. A bigger and more frequent stumbling block is forgetting to address the people issues around a CRM implementation. In almost all of the cases we described earlier, CRM is a behavior modification tool.

There is a need for the “hard” functions that CRM can provide, like case management, campaigns and analytics. But that’s not enough (e.g. see social CRM), and enabling the customer-centric firm seems to require a good bit of what makes Enterprise 2.0 tick: cross-organizational perspectives, contributions from different departments, a more collaborative orientation to an end-goal. Integrate CRM into “other parts of their business”.

Wikis, by themselves, don’t provide the necessary CRM functions that are table stakes to be useful for companies. But CRM platforms could benefit from integrating more social software tools and conventions.

And that’s the case for a lot of the current processes that define companies today. They aren’t going to be addressed by off-the-shelf generic social software tools. But they benefit by incorporation of social software tools.

“Activity-specific social applications”. A few examples:

Dachis Group talks about social business design as “the intentional creation of dynamic and socially calibrated systems, process, and culture.” Indeed, there’s a huge opportunity to apply social software to the multitude of applications and processes that make up organizations, beyond the insertion of standalone generic tools.

Watch this space.


Tragedy of the Commons: Twitter vs Online Forums

Riding on board a Virgin America flight, I have CNN on my seat media screen. I’m watching CNN much more than I’m usually able to.

I notice those tweets flashing along the bottom of the screen. Some are good. Many aren’t. They are examples of the tendency for online discussions to devolve into name calling, stereotypes and ad hominem attacks.

They remind of the worst sort of comments found on online message boards. The problem with inline message boards is that there is little control by the individual for what they see. It’s not just political discussions. Marketers pollute LinkedIn message boards with their spammy webinar solicitations.

It’s the tragedy of the commons. A common resource – message boards – is overrun by those not providing quality contributions.

With Twitter’s one-way subscribe model, this particular attack on the commons is limited. Why? It’s easy to unfollow those who post irrelevant or non-productive things.

Want to be a participant beyond the amen chorus and fellow polemicists, or get people to actually care about your webinar? Figure out how to engage in an intelligent discussion.

A benefit of Twitter: managing the tragedy of the commons. It should be noted, however, that enabling discussions among multiple people is quite important. Letting multiple people on a thread while preventing the spammers is the next step in protecting and improving the value of the commons.

How Much Scale Is Needed in Enterprise 2.0 Employee Adoption?

A couple recent items caught my eye with regard to the issue of employee adoption of social software.

In Reversing the Enterprise 2.0 Pricing Model, Julien le Nestour argues that pricing per user for social software should increase as more employees use it, because the network effects of higher participation make the software more valuable. It’s a great theoretical piece, tying pricing to value received. But in the harsh budgeting realities of the enterprise and in the comparison against other software pricing models, it’s not likely we’ll see anything like this.

Atlassian, maker of the Confluence wiki and developers tools, recently passed the cumulative revenue mark of $100 million. In the post announcing this milestone, Atlassian blogger notes that the company has no sales force. People just download the app. I know some of the Atlassian guys, and this kind of viral, bottom-up adoption is core to their philosophy. They don’t sell to upper management, adoption occurs at the departmental level. That being said, I am aware from my work at Connectbeam of some large-scale rollouts of the Confluence wiki by Fortune 500 companies.

What connects these two items? The first post describes the nature of Enterprise 2.0 apps and how their value increases as more employees use them. The second post points to the value that departments have received from Atlassian’s Confluence wiki, even without broad adoption. In other words, network effects are not a critical aspect of the Confluence value proposition.

From these posts, other readings and direct customer experience, the following occurred to me:

You don’t need a high level of adoption to get value from some Enterprise 2.0 apps. Others require broad participation.

In some ways, that may seem obvious. Yet I don’t tend to hear this distinction being made. Usually, all social software is lumped together under ‘Enterprise 2.0’ and there is a collective view that wide-scale adoption by employees is a necessity. It’s actually more nuanced than that.

Varying Adoption Levels Required

The graphic below depicts the relative levels of participation required for different apps to “deliver value”:


Here’s a quick summary of the graph:

  • Employee participation is defined as contributions and engagement (views, edits, comments, etc.)
  • Moving from left to right, the percentage of employees involved gets higher

This graph has a couple of implications for Enterprise 2.0 vendors. Before that, here’s an explanation for why I put the different applications where I did.

Consider the Purposes of the E2.0 Applications

Before discussing these applications, I want to note this. All social software applications get better with higher adoption. There is no disputing that. The distinction I want to make is that some apps require increased participation before they deliver value.

Blogs: The nature of a blog is a single person’s thoughts, observations and ideas. Inside companies, these applications can be tools for the ongoing recording of things that fall outside the deadlines and process-oriented activities that make up the day. Making them public is a great way to share these contributions with other employees and establish your record of what’s happening. If only a few key people blogged inside a company, there will be value in that.

Wikis: Wikis actually have two purposes: (1) knowledge repositories, and (2) projects and collaboration. It’s that second purpose that makes wikis particularly valuable even with small participation. I’ll use Confluence as an example. We use it as our low home for putting up documents accessible to anyone else, and for free-form contributions on all manner of things. It is very much a utilitarian use case for us. If we weren’t using Confluence for this purpose, we’d share documents via email. In larger organizations, Confluence may replace usage of SharePoint or the company portal.

Using wikis as knowledge repositories, such as [Company Name]-ipedia type of implementations, requires a larger percentage involvement. Sparsely populated company versions of Wikipedia are of little use. As are wikis that are not updated regularly with new information. I’d put wikis-as-knowledge-repositories up there around prediction markets in terms of required participation.

Forums: The old man of Enterprise 2.0…forums. These are the place where topics can be posted, and a scrum of conversation occurs. To really get value out of these, it helps to have larger participation. Blogs are solo voices with interesting content. Wikis can have a very specific collaboration purpose among a few employees. Conversations around a topic require a wider variety of voices. Otherwise they fail to give people a sense of what others are thinking. Nothing sadder than forum post with no comments.

Social bookmarking: Bookmarking sites you find useful has value by itself. So in that sense, “social” bookmarking can work for very few employees. But it’s not really “social”, it’s simply a replacement for your browser bookmarks. You get value by finding those gems your colleagues deem interesting. The odds that any single bookmark will be useful to you are small, so you need a healthy amount of bookmarks to increase the chances of finding links that will help you. And to get a healthy amount of bookmarks, you need broader participation.

Microblogging: In some ways, microblogging could be compared to forums. Both are public places to serve up topics. But they’re fundamentally different. And that’s why broader participation is more important here. Forums have a distinct purpose – the discussion of a particular topic. You need participation by those who know something around the topic.  Microblogging is a more free-form, personal activity. You don’t need a distinct purpose to post something. You post all the things that occur to you during the day. Some of which will have value, although it can be hard to predict for whom. It also helps to know that people are seeing these posts, because there is a conversational aspect to microblogging. The free-form, who-knows-what-might-be-interesting, conversational aspect of microblogging require larger participation than forums do.

Prediction markets: Prediction markets thrive on having a variety of ideas, events and initiatives. They also require the different perspectives of employees, leveraging different perspectives, knowledge and experiences. This is true wisdom of crowds work. Limited participation limits the value of prediction markets. These benefit from broad employee involvement.

Social networks: I put these at the top of the chart in terms of employee involvement. Perhaps one of the best use cases for social networks is finding colleagues with the knowledge or interest in projects you’re working on. This requires large-scale participation. If a social network only is used at the departmental level, it doesn’t provide value. In terms of expertise location, you’re probably already aware of what others in your deparmtent know. It’s breaking out of that traditional sphere of contacts where social networks shine. I know I’ve heard many instances of large corporations suffering from “reinventing the wheel” syndrome because employees lack visibility about what others know. Broad participation addresses this issue.


Three implications of this view about required involvement come to mind.

Greater required participation correlates to greater impact on a company’s value: Generally, you could change the metric in the chart above from percentage of employee involvement to impact on company value. The increased participation means the associated application will also have a larger effect on the company’s strategies and operations. It’s not an tight correlation, but a general trendline. Exceptions will abound.

Top-down vs. bottom-up: General observation is that broader participation requires a greater amount of senior management support. That’s the way things work inside companies. Employees will listen when the executives of the company push something. For applications that need lower participation, the name of the game is to provide a compelling application with a low entry cost. Departmental budgets and the green-light from employees at lower levels of the organization are all that are needed.

Time for application to gain traction: With applications that require low levels of participation, there is plenty of time for the application to grow virally. It serves its purpose for a select few, and over time others will see the value and elect to participate. These apps can be resident inside companies for long periods of time. Those that require higher participation to see value will need to show results sooner. They are on senior management’s radar, generally cost more and have a greater number of employees who will be watching to see the results.

So it matters what type of application we’re talking about when it comes to Enterprise 2.0. It matters for companies and vendors. It impacts the skills required for everyone’s success.

A nice post that complements this one is Adina Levin’s Scale effects in enterprise social software.


See this post on FriendFeed: