LONG-TAIL OF INTERNAL COMMUNICATIONS
September 25, 2006
by: jovial_cynic
by: jovial_cynic
I've done it.
After reading Chris Anderson's Long Tail, I've been thinking about ways to bring the long-tail into the work I do. I'm an internal communications web programmer for a large US insurance company, and since I'm not on the customer-facing end of things, I was initially under the impression that I couldn't bring the long-tail into my work.
However... I made a connection today as I thought about my latest web project.
The problem with using e-mail and static internal web pages for communications is that, like a brick-and-morter business, an inbox and a local intranet have limited real estate problems. Communicators want the best "shelf-space" they can get in an inbox, so they flag their messages as "urgent," and then they request that their informational web pages have front-page prominance on the intranet home page. This reflects the underlying "hit-centric" mentality that both communicators and readers have come to expect in a corporate communications setting -- whatever is important shows up on the front page and gets bumped to the top of the inbox.
However, every communicator wants the best spot. They all feel that their message is the most important, so they do the same thing that Hollywood does -- they advertise. Only... it doesn't cost them anything to do it; the communications department just does what the internal client wants, which is to post all kinds of blinking banners and eye-catching doodads all over their pages. Inboxes fill up with more internal junk, and web pages become hideous and unbearable.
Over the last six months, I've been writing a communications application that functions both as a publishing tool and an aggregator (mimicking the RSS/aggregator model, but without RSS; it's all internally database driven; no common language necessary), and I'm scoping the publishing section down to allow any internal communicator in the region to have their own communications space. This will cover everything from messages from the Executive department down to the head of a mini-planning committee. Every communicator can have their own channel.
By scoping it down to this level, I'm effectively moving all internal top-down mass-audience communications out of inboxes and into a web application that allows users to subscribe to information channels they feel is relevant to their daily work. The aggregator portion gives readers the latest updated messages from the communication channel to which they've subscribed, so they never receive junk -- if it's in there, it's because they subscribed, and they can always unsubscribe.
Imagine a world where your work inbox only contains messages from people who are trying to speak to you directly. Imagine a separate place where top-down communications live, housing only the content you wanted!
And it boils down to this: if internal communications is placed on a level playing field, readers can more easily identify which information is most relevant to them. By allowing readers to subscribe, it becomes more easy to filter information based on what's relevant (provided that communicators maintain a particular theme within a channel), and to ignore the additional noise of reader-define irrelevant messages.
EDIT: (added)
By encouraging communicators to use this tool for all of their top-down messages, this will likely create additional channels as the need becomes evident. Many of the communicators in my company have agreed that having a public-facing (and by public, I mean within the organization, but outside of the particular department) channel so people from other departments can get a better idea of what's going on around the company. Perhaps this tool will actually create niches.
This tool I built doesn't necessarily drive traffic down the communications tail. The goal of readers in an internal communications structure isn't to find niche content. If the need arises, I may build in a "suggest this channel" feature, or a "people that subscribe to this channel also read..." feature. I doubt that'll be necessary, though, since my users aren't typically hungry for more internal communications content. Who knows, though?
Anyhow, all this to say that I believe I've effectively brought the long-tail into my place of work.
After reading Chris Anderson's Long Tail, I've been thinking about ways to bring the long-tail into the work I do. I'm an internal communications web programmer for a large US insurance company, and since I'm not on the customer-facing end of things, I was initially under the impression that I couldn't bring the long-tail into my work.
However... I made a connection today as I thought about my latest web project.
The problem with using e-mail and static internal web pages for communications is that, like a brick-and-morter business, an inbox and a local intranet have limited real estate problems. Communicators want the best "shelf-space" they can get in an inbox, so they flag their messages as "urgent," and then they request that their informational web pages have front-page prominance on the intranet home page. This reflects the underlying "hit-centric" mentality that both communicators and readers have come to expect in a corporate communications setting -- whatever is important shows up on the front page and gets bumped to the top of the inbox.
However, every communicator wants the best spot. They all feel that their message is the most important, so they do the same thing that Hollywood does -- they advertise. Only... it doesn't cost them anything to do it; the communications department just does what the internal client wants, which is to post all kinds of blinking banners and eye-catching doodads all over their pages. Inboxes fill up with more internal junk, and web pages become hideous and unbearable.
Over the last six months, I've been writing a communications application that functions both as a publishing tool and an aggregator (mimicking the RSS/aggregator model, but without RSS; it's all internally database driven; no common language necessary), and I'm scoping the publishing section down to allow any internal communicator in the region to have their own communications space. This will cover everything from messages from the Executive department down to the head of a mini-planning committee. Every communicator can have their own channel.
By scoping it down to this level, I'm effectively moving all internal top-down mass-audience communications out of inboxes and into a web application that allows users to subscribe to information channels they feel is relevant to their daily work. The aggregator portion gives readers the latest updated messages from the communication channel to which they've subscribed, so they never receive junk -- if it's in there, it's because they subscribed, and they can always unsubscribe.
Imagine a world where your work inbox only contains messages from people who are trying to speak to you directly. Imagine a separate place where top-down communications live, housing only the content you wanted!
And it boils down to this: if internal communications is placed on a level playing field, readers can more easily identify which information is most relevant to them. By allowing readers to subscribe, it becomes more easy to filter information based on what's relevant (provided that communicators maintain a particular theme within a channel), and to ignore the additional noise of reader-define irrelevant messages.
EDIT: (added)
By encouraging communicators to use this tool for all of their top-down messages, this will likely create additional channels as the need becomes evident. Many of the communicators in my company have agreed that having a public-facing (and by public, I mean within the organization, but outside of the particular department) channel so people from other departments can get a better idea of what's going on around the company. Perhaps this tool will actually create niches.
This tool I built doesn't necessarily drive traffic down the communications tail. The goal of readers in an internal communications structure isn't to find niche content. If the need arises, I may build in a "suggest this channel" feature, or a "people that subscribe to this channel also read..." feature. I doubt that'll be necessary, though, since my users aren't typically hungry for more internal communications content. Who knows, though?
Anyhow, all this to say that I believe I've effectively brought the long-tail into my place of work.
