One of the familiar refrains in the halls of Enterprise 2.0 is that social software’s primary value is for knowledge workers or knowledge-intensive industries. This now gets repeated so often that most people don’t even question its truth.

Like so many orthodoxies, this one’s due for a re-think.

The whole notion of a knowledge worker or a knowledge industry is confused. It suggests that there’s a certain class of workers who problem-solve and innovate for a living, and another class of workers that don’t. But that’s just not the case. An assembly-line worker who thinks about how to reduce the failure rate of brake systems rolling off the assembly line is a knowledge worker, at least in my book. A consultant who reads bullet points from a deck that someone else has written is not exactly doing knowledge work. Knowledge is a characteristic of how the work gets done, not of the work itself.

If you don’t believe me, just compare the cappuccino you get at a world-class cafe like Lovers and Madmen in Philadelphia to what they sling down the street at McDonald’s. Both were made by baristas, but only one was made by a knowledge worker.

There is, however, a fundamental difference between activities that are more routinized and those which are more bespoke. Doing warehouse pick-and-pack for the latest James Patterson thriller is a routinized activity. Sourcing a clean copy of Russell and Whitehead’s 3-volume Principia Mathematica is bespoke. Soliciting $10 donations over the phone is routinized; soliciting $5 million donations is bespoke. Building the prototype of a new car model is bespoke; building the 100,000th instance of that same car is routinized.

Routinized and bespoke activities require different types of supporting tools. Routinized activities require process tools to run the activity at scale as efficiently as possible, with as little variation as possible. Bespoke activities require a toolkit, a basket of techniques, tools, tips, tricks, and experts upon which a practitioner can draw to meet the needs of the moment.

In the early days of Enterprise 2.0 (mid-2000s) enterprise social software was good at toolkit-style functionality. Blogs and wikis gave people useful frameworks and reference materials for doing bespoke tasks. But there wasn’t much functionality for businesses that run a lot of routinized process.

These early tools appealed to high-end consultancies, law firms, PR agencies, and tech startups, which lean towards more bespoke activities. I suspect that’s where people first got the idea that enterprise social software was for “knowledge workers.”

But social software has changed, and changed fast. In the past year, business has started to embrace social software for more routinized processes as well.

The combination of activity streams, robust APIs, and mobile means that social software now integrates with–and improves–industrial-strength process. In London, for example, Southeastern Railway is using social software to automatically alert railway staff when trains are delayed–and to enable those staff to collaborate in real time to get the trains back on track (sorry…couldn’t resist the pun). In Ohio, Industrial Perfection Mold and Machine uses social software on shop floor iPads to regulate and improve the manufacturing process.

Which type of activity should your business try to optimize? My answer: Both.

Every business runs on a combination of routinized and bespoke activities. Running the trains in and out of London may routinized, but when a train breaks down the work becomes very bespoke. Tier 1 customer support is routinized; Tier 2-3 customer support is bespoke.

What businesses really need is an integrated combination of the two: Stream-based tools for routinized activity and wiki-based toolkits for the bespoke stuff.

To borrow a line from the Anita Bryant of my youth: “Social software. It’s not just for knowledge workers anymore.”

I’m going to take a swipe at another cherished social software notion: Serendipity. We should ban that word from the social software lexicon. It’s misleading and it makes enterprise social software seem about as relevant to the business as the plastic mistletoe hanging at the office Holiday party: Something amazing could happen, but it probably won’t.

The idea behind serendipity is that social software enables colleagues who have shared or complementary interests and expertise to discover each other and collaborate. It’s serendipitous because, hey, who knew that Theresa in Tucscon was a certified blackbelt in Six Sigma, the very methodology that Victor is trying to implement in Virginia?

It’s true that social software teases out those kinds of hidden connections. But when social software is implemented properly, there’s nothing serendipitous about it.

Imagine Victor in Virginia works for a 10,000-employee defense contractor that has successfully implemented an enterprise socials software tool as its social intranet. If he goes to that intranet and asks who can help him with a Six Sigma implementation, he is almost guaranteed to get five, ten, maybe twenty responses. While Victor may not know who will respond, he can be reasonably confident that someone will. So from Victor’s standpoint, there’s a high probability that asking the question will get the kind of responses he’s looking for.

It’s simple mathematics. Consider the following statistical fact. For any two people, there is a very low probability (roughly 1/365) that they share the same birthday. And when two people discover they have the same birthday, it’s serendipity. But if you fill a room with just 57 people selected at random, there’s a 99% chance that some two people in that room will share the same birthday. That’s probability.

Victor and Theresa may be surprised to discover that they share an interest in six sigma. That’s serendipitous. But we should not be at all surprised that Victor got the response he needed. The odds were quite high. From the moment Victor posted his question, he was almost guaranteed to get a response. That’s probability.

The point is that social software doesn’t enable serendipity; it transforms serendipity into probability. Serendipity is when Victor happens to sit next to Theresa on the red-eye to London and discovers that they’re both interested in Six Sigma. It’s a random event, neither reliable, nor repeatable, nor scalable.

But when Theresa is first to respond to Victor’s company-wide post looking for Six Sigma expertise, that’s probability. It worked, we knew it would work, and the fact that it worked this time makes it even more likely that it will work next time.

What’s that you say? My distinction between serendipity and probability is mere semantics? Maybe, but words matter. Companies and their leaders only take social software seriously when they see it as part of mainstream business process. Mainstream business process is all about repeatability and scalability.

Imagine the response you’ll get if you tell your CEO, “We’re implementing a system to make serendipitous connections among staff members.” I can hear your CEO yawning from here.

Now imagine telling your CEO, “We’re implementing a system to ensure that all staff get the help they need, when they need it, from knowledgable colleagues across the company.” That CEO conversation just got a whole lot more interesting.

So let’s get serious about making business process social, and leave serendipity to the mistletoe.