Do automated review dates work?
Categorised under: Content management
Keeping content up to date is hard. Whether on a website or intranet, organisations constantly battle with outdated or incorrect information.
One of the primary goals of a content management system (CMS) project is therefore to improve the quality of content on the site (or sites). One of the key mechanisms for achieving this is the use of automated review dates on all content.
Review dates
The idea is simple: when a new page is created, the author specifies when it should be reviewed. This could be in a week, six months or a year. When this date is reached, the author or owner of the page receives an automated email reminding them to review (and potentially) update the page.
This helps to ensure that pages don’t quietly “rot away” without anyone noticing. It also reduces the burden on the central team to keep track of all of the content.
So, does it work?
Not a silver bullet
One of the fundamental reasons why content is not kept up to date is that authors often publish content as a hobby. Without sufficient time to maintain content, having an automated reminder will have little effect.
Receiving an email reminder is also no guarantee that the content will actually be reviewed. These messages are easily seen as ‘corporate spam’ and deleted. Even if the page is looked at, the author may not actually make the required changes.
In our experience, organisations using review dates in a CMS still wrestle with the same content currency challenges. The situation is a little better, but not dramatically so. Realistic expectations should therefore be set for review dates, and they should not be seen as a silver bullet that will make decentralised authoring ‘work’.
Making the best of it
A few tips for using review dates:
- Don’t set a single review period. Having every page come up for review in six months makes no sense, as some content needs looking at every month, while other content may only need reviewing once a year. (Some content, such as policies, may be valid until a change in legislation.)
- Make sure every page doesn’t come up for review at the same time. A terrible byproduct of setting a single review date is that six months after the site is migrated into the new CMS, every page comes up for review. Hundreds of emails later, all the notifications are deleted and the review process is dead.
- Make it easy for authors. Don’t make authors pick a specific date (and time!) for the page to be reviewed, as having a review date of 9am on December 24 is rarely meaningful. Instead, allow authors to pick from a drop-down list of options such as “1 month”, “3 months”, “6 months”, “1 year” or “never”.
- Send good emails. The automated emails generated by the CMS should be human-readable and meaningful. They should also provide a link directly to the page requiring review.
- Make sure there is still an author. Organisations restructure all the time, and staff steadily move between roles (or leave). This may leave pages without a current author, and therefore nobody to send review emails to. Keeping a current list of authors and site owners is therefore critical
- Provide effective reports. Site owners and administrators should be provided with an overall report listing content that is coming up for review, or past the review date. This will help the centralised team manage the content (and the authors).
- Recognise the limits of review dates. Don’t ‘bet the farm’ of review dates, and recognise that authoring is fundamentally a people process. Work closely with all authors to help them be effective and to manage the overall publishing process.
Summary
Do automated review dates work? Maybe. While they are not a silver bullet, they may help a little in keeping content up-to-date. Set expectations accordingly, and put the effort in to set up the review process to be as simple and as effective as possible.
What have your experiences been?
James Robertson is the Managing Director of 
3 Comments:
At my last job I wrote an ad-hoc content review system for our website, which was itself sort of an ad-hoc CMS. (A templating system plus a bit extra.) In that system, I was doing the actual updating, but the information “owners” got an automated reminder to tell me about any changes every 3 months IIRC.
It was certainly a LOT better than before the system, when months or even years would go by, facts would change, and no-one would tell me about it.
But I think part of what made it work was having me as an active participant in the system. Not only did the auto emails come from my address, but I sent personal follow-up emails, and had a professional relationship with most of the info owners.
When we started using a new knowledgebase system at my current job, I really missed my little adhoc reminder system! The software didn’t even have as good a setup as the rickety code I wrote myself.
Some organizations I work with have designated “content coordinators” associated with each SharePoint site they develop. This acknowledges your point, well-made, that ensuring updated content is more a people process than a mechanical one. Coordinating content is part-and-parcel of a specific team member’s job description. A SharePoint site is not allowed until a team or department has designated its content coordinator. So refreshing content is not then just a matter of a technology-generated update notification and a (sometimes unwilling) author, but rather, there’s a team-based middle-man who manages and facilitates content quality. This arrangement seems to be a key success factor for many enterprises’ KM initiatives.
I agree completely with both these points. It’s about putting a “human face” to the content updating process, much more than the technology behind-the-scenes. Both good solutions.