Intranet Portals - Personalisation and Customisation
The key difference between an (old-fashioned) Intranet and a Portal
What typifies a modern intranet portal is that there is a standardised user interface ("UI") with a built in system for user authentication. In other words, the user signs in to the portal rather than simply accessing it. This brings us to the key difference; an intranet portal knows who you are, whilst with an old-fashioned intranet, the user is anonymous.
If the user authentication is properly linked to your employee data, then the portal will know things like (a) what grade the person is, (b) which department they work in, (c) what location they work at and (d) what job they do.
If the portal authentication is also liked to a metadirectory (along with the authentication for all the other systems the user needs to use in their job) then the portal will additionally know (e) which applications the user needs to do their job and (f) the rights the user has (from their security profile) to access different application functionality.
Finally, if an infocube-based web statistics package has been installed, the portal will know (a) which areas of the portal are accessed by the user and (b) the frequency and depth of that access.
The opportunity to personalise the portal experience
Clearly, given the knowledge above, it is possible to personalise the UI for each individual user. For example, if the user works in the sales function, then the homepage that greets them upon logon could be the Sales team homepage. If they work in Leeds, the facilities link on their homepage could be to maps, traffic, fire orders, etc. about the Leeds office (rather than anywhere else). If their specific job is as a field sales manager, then field sales performance graphs and management dashboard could be displayed on the homepage.
If the user is of a grade that places them on the company insider dealing list, then additional (price sensitive) real-time data might be displayed on the screen (which other users would not see). If statistics tell us that they are not reading important communications, then messages could be served to them that draw their attention to what they are missing. Finally, if they use functionality from three different (legacy) systems to do their job, then these could be brought together and surfaced via a portlet application on the portal page.
The prize is clearly a smoother and more integrated user experience, with key information "pushed" at the user in a way they can't ignore and always no more than a single click away.
The depressing truth about personalisation today
Many portal vendors have undertaken research with their existing customer base to explore (a) how many customers have made extensive use of personalisation and (b) how many surface key business applications via their portal. The results do not make encouraging reading (with less than 20% achieving much beyond what Plumtree call "the empty portal").
This prompts an obvious question. If the benefits to the user of personalisation are so obvious, why have companies not taken advantage of them? In fact, based on my experience, there are multiple reasons not to personalise, which I group into "bad" and "good" reasons.
Bad reasons not to personalise
There are a number of typical failings that tend to stem from a lack of courage, poor understanding or personal prejudice:
1) Failure to link through to employee data and/or a metadirectory
2) Failure of vision and/or lack of confidence in personalisation benefits
Good reasons not to personalise
There are actually several valid objections to personalisation, which you would ignore at your peril. The two most notable are:
3) The whole is more than the sum of the parts
4) Log-in as a barrier to user adoption
So is personalisation the right thing to do? If so, how can I make it happen?
On balance, of course, the benefits of personalisation, for most organisations, far outweigh the risks and costs. After all, why buy a Ferrari, then only use it to do the school run? If you were never going to use the portal for these advanced functions, why did you buy one? It would have been much cheaper to invest in your traditional intranet!
If you are looking to make it happen, however, you must recognise the organisational, financial and technical challenges inherent in the work. Firstly, you should ensure that your business case contains the full costs of integrating the portal with employee data and metadirectory capabilities. Ideally, you should also extend this to a single-sign-on solution if you can afford it. Secondly, you should showcase to sponsors what personalisation looks like, so that they can improve their understanding of the opportunity. Finally, you should not underestimate the technical grunt work involved in cleaning up your employee data and systems rights.
Do not neglect customisation
I define customisation as the ability for users to customise their own portal settings and appearance (as distinct from how I am defining personalisation, where the portal provisions information and applications authomatically, based on the user's profile). By letting users "do it themselves" you allow for the possibility that they may wish to share knowledge and collaborate with people outside their immediate role. You can also learn (by observing their behaviour in customisation) where you could improve upon your personalisation.
Some final thoughts
Personlisation should be a key element of your early visioning work with sponsors and drive costs and benefits in your business case. If you find at that stage that the return on investment (ROI) is not there, then you should perhaps question whether a portal investment is really for you! A mini is adequate, after all, for the school run!
About the author:
David Viney (email@example.com) is the author of the Intranet Portal Guide; 31 pages of advice, tools and downloads covering the period before, during and after an Intranet Portal implementation.
Read the guide at http://www.viney.com/DFV/intranet_portal_guide or the Intranet Watch Blog at http://www.viney.com/intranet_watch.
could not open XML input