Filed 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?