Vision for a public sector intranet of the future

I recently attended the IBF London Member meeting, a two day, confidential event for intranet professionals.  During the first day, one of the exercises was to brainstorm what the corporate intranet would be like in 5 years.  And I found the task terribly difficult to do.  That’s probably because I work on a public sector intranet and a lot of web 2.0 technologies that we take for granted on the web are just not available inside the firewall.

But it got me thinking.  

What if?

If we start with the idea of a staff microblogging tool.

The internal communications department can use it as a broadcast device to get across “must read” corporate announcements and campaigns.  Board and CEOs can be visible and connect to the staff.

Staff, already used to posting status updates on Facebook and Twitter, can microblog within the work environment, generating their own news.  And staff can “follow” other staff.  They’ll start to create links to other people, building relationships across the business, talking to each other.  Regions get connected to the central business.

They have opinions and knowledge.  The microblogging tool will capture it.  We’ll be able to dip into the pot of knowledge, the pot of opinion, to gain insight.  No more spending money on surveys and research.  We’d also be able to see current “trending” topics.

We’ll see the language that staff are using, enabling us to build the corporate taxonomy and improve intranet naming, labelling and search results.

Staff can rate and comment on intranet content.  Highlight out of date content.  Request missing content.  Tag and organise content.  They’ll be able to sift through recommendations, ask questions and get help from each other.  They can search for content and compare comments based on the wisdom of the crowd.  They can subscribe to content instead of having it rammed down their throats.  We can localise content and make it available where it matters.

And perhaps a solution to a problem that the majority of intranets must face; the staff directory. Since staff will have their personal profile in front of them, their contact details are more likely to be up to date.  And through microblogging and profile updates, staff can find other staff based on expertise and knowledge.

But what about frontline staff and those who don’t have desktop access all the time?  The microblogging tool will be available on handheld, mobile and tablet devices, outside the office.  So staff can still stay connected.

And that’s without thinking of blogs, wikis, or discussion forums.

Should we worry about moderation?  The general consensus is not to worry.  In most cases where social media tools are already in place or being trialled, we are getting reports back that staff have tended to manage themselves and adhere to posting policies.

We’re already seeing companies experimenting with these tools.  I saw a demo of the Thomson Reuters “Colleague Finder” on their intranet and it wowed me.  I know other companies are trialling Yammer.  Why can’t public sector follow suit?

The technology is clearly available.  Private sector companies, with similar security issues to the public sector are starting to use the technology.


We’ve already talked about reduced costs for surveys and research.  Sharing information, collaborating.  More important, I believe, is the issue of employee engagement.  These internal social tools will help to improve employee engagement.  Staff will feel more involved and listened to, with more information at their fingertips. And engaged staff are more likely to perform better, be proactive and aligned to the organisation’s goals and as a result, stay with the company.  This saves money on recruitment, training & development and gives brand a better reputation.  What about lower helpdesk costs?  Staff will help themselves through shared knowledge and so won’t need to call helpdesks.

What if all this is hosted in the cloud?  Did away with inefficient IT departments and hosting companies.  How much money and time could we save?


The experience of pioneers who are already experimenting with these tools tells us to manage and communicate the changes well.  Particularly showing what benefits there are for the business and what’s in it for staff.

See also:

Bounce rate on the corporate intranet

We’re starting to look at “bounce rate” as a metric for staff engagement on the intranet.

I work with two definitions of bounce rate:

1) Google’s official definition: one page view in one visit
2) Google’s unofficial definition: “I came, I puked, I left”

On the web, analytics packages work on the concept that people visit a website from a search engine or from another campaign medium.  Websites require something to “bring in” the visitors.

On the intranet, we have a captive audience. But if the intranet homepage is given to staff by default when they open the browser, then I think we have a reason not to include it in bounce rate metrics.  Measuring staff interaction should start when they make the first click on the homepage, not when the homepage loads.

The intranet homepage essentially signposts people to other content pages lower down in the intranet structure. I don’t care too much about how many people viewed the homepage.  What I care about is whether they got to the sub-layers of the intranet and consumed content.

For most of my analytics, I exclude the homepage as part of the user journey.  The journey starts when someone “lands” on a lower-level page.  That’s when I start counting bounce rate. If these pages bounce then I know that I have a problem.  If I were to count the homepage, then by definition, these secondary pages would never bounce and would always appear to be working well.

How to setup Google Analytics on an intranet

This post highlights what you need to think about when setting up Google Analytics on an intranet.  Where detailed instructions are available elsewhere I have included links.

Your intranet and web access

Check that staff can access specific Google pages on the web and that your intranet URL is ok.  For example http://intranet won’t work. See specific Google pages.

If your company imposes restrictions on web access you may have to ask to add these addresses to the whitelist of allowed URLs.

In addition, your browser must run javascript and allow cookies.  See first-party cookies.

Get yourself some Google accounts

You need a Google account.  You can register your work email address; this makes it easier when setting up reports later.

You need a Google Analytics account.  Sign up for a Google Analytics (GA) account using the email address registered against the Google account.  You’ll need to create a profile in GA in order to get a profile ID, something like UA-1234567-1. This is the magic profile number that you need to include in your intranet pages.  See examples of the tracking code.

Add the google code to every page

In the process of creating your profile, you’ll see a piece of javascript code that you need to embed into your intranet pages.  This code needs to appear in your published HTML pages.  You’ll need to add the code into your HTML templates or includes or manually into every page.  Google only tracks pages that have the code.  See how to install the tracking code.

Decide how to tackle downloads

The Google tracking code only tracks HTML pages.  It will not automatically track Word documents or PDF files etc.  There are two methods to use in order to track downloads, depending on whether you publish via CMS or manually.

Tracking downloads with a content management system

Inside every anchor link for documents that you want to track, you’ll need to add an extra piece of javascript that will be triggered when the user clicks the link.  See how do I track files?
To track documents, I’d recommend using the URL as it would appear in the natural intranet folder structure:
onClick=”javascript: pageTracker._trackPageview(‘/pensions/docs/membership-form.pdf’); ”

Tracking downloads with manually published HTML pages

Tracking documents for manually published HTML pages is a little trickier, since you won’t want to add bits of javascript to your pages every time you add a link.  There is a javascript trick that we use which runs when the HTML page is loaded and will then seek out all links to documents and add the necessary Google tracking code.
The code will vary depending on your browser and intranet configuration.  I’m not a javascript programmer so please check these websites for ideas (we had to tweak the code to make it work for IE6 – no surprises!)

Tracking downloads from your search engine

Similarly to links to documents within your HTML pages, you’ll need to add code to your search engine results page to track links to documents.

What else do you want to track?


  • Track links from an email promoting an intranet page
  • Track links from a PDF newsletter

Add a bit of code to the end of your URL links from any medium (email, PDF, Word doc etc.)
See the Google campaign URL builder and guidance on using the buider.

Events or user interactions

  • Track “clicks” on a voting button
  • Track “plays” of a video

See the Google event tracking guide.


There are a few loopholes and some situations where you can miss tracking.  For example, if you have embedded URLs in a document that link to another document then Google Analytics won’t know about it.  If other intranets or websites link to a document on your intranet then this won’t be tracked. Where possible, encourage external sites to link to your intranet page that contains your download document, rather than the download document itself.