A recent trend in Web Content Management is publishing to social networks -- Twitter, Facebook, LinkedIn, et. al. -- out of your Web CMS. Not surprisingly, some of the hosted CMS vendors are more advanced here (part of my thinking crystallized after a demo with SaaS vendor CrownPeak yesterday). We're in the process of evaluating how different vendors accomplish this, and it turns out there are advantages and demerits to alternate approaches. Working with Facebook in particular brings some tricky issues.
We'll share those findings with our WCM research customers, but in the meantime let's explore some more fundamental questions, like, why do this at all? And why on earth would you use a CMS tool designed for organizational publishing when you can employ lightweight client applications for interacting with social networks as an individual?
I think there are at least five reasons why you may want social media publishing functionality in your Web CMS. Perhaps you can add more via the comments below.
In theory, your CMS can allow you to put updates through some sort of workflow. In practice, you'd probably never do this for individual tweets or status updates, but you might want to have someone sign off on corporate-account tweets or updating a corporate Facebook page. I think this is a weaker rationale, but vendors say some customers are doing this.
2. Scheduled publishing
This is where CMS tools typically excel: time-based publishing. Of course there are other tools in the twitterverse to schedule tweets, but they don't all work well, and by scheduling updates through your CMS, you can time them more arbitrarily to coincide with content you may be highlighting. Ditto for Facebook pages.
Here you're basically replacing 3rd-party tools (that convert website RSS feeds into tweets or status updates) with an internal service that's potentially more timely as well. This could prove especially handy for broadcasting via internal micro-blogging networks, e.g., broadcasting certain Intranet updates via your Yammer feed. Don't go overboard here, though.
If you want to keep all your social content and messaging, do you trust the services themselves to maintain them long enough for your liking? This is a particularly big deal in regulated or heavily litigious sectors. Like it or not, e-discovery requirements are real, but they don't have to keep enterprises from participating in social networks. There's another benefit here that relates to the perishability of link-shortening services. If bit.ly gets shut down, you could theoretically regenerate a separate archive using a different service.
A CMS can allow you to repurpose tweets, status messages, and the like to a separate collection, or push them elsewhere without having to extract them from that social network via its API. This is also related to archiving: if Twitter somehow goes away, or your LinkedIn account gets zapped, your content stays accessible (and searchable) in another location of your choosing.
Now, some perspective. Publishing to social networks is not the most important attribute of a CMS. It's often something you can jerry-rig yourself, or you can employ various 3rd-party tools.
Also, let's not confuse publishing with interacting. Your CMS won't help you participate in a LinkedIn discussion or retweet an interesting post.
Still, it's convenient to have social publishing capabilities built into your CMS. Just don't let your marketing department go overboard now that they can broadcast content with ease. Because you can, doesn't mean you should.