Church Web Design Part 12: Developing a Website Update Policy
With my church’s new website launched (see part 11), there was a strong, natural temptation to let off the throttle. Those of us working on the site had pushed hard to get the site ready for launch and now just wanted a break. But continuing the NASA metaphor from last article, what happens immediately after the launch of a new website will determine whether it reaches a sustainable orbit or comes crashing back down to earth.
Crash and Burn
I don’t know about you, but I am very much a goal-oriented person. When I have a project deadline coming up, rather than dread it and get stressed out, I actually get excited about it. I get a surge of adrenalin and enjoy doing whatever it takes to meet the goal or deadline. I push through problems and skimp on sleep. The exhilaration of the “final push” is only exceeded by the accomplishment of the goal itself.
But once the goal is met, I have a tendency to crash and burn.
I’m physically tired and need rest. There’s a backlog of other things to be done which I neglected during the final push.
That content that was deemed non-critical to the launch of the website isn’t really critical the week after the launch… or the week after that… or, well, you get the picture.
Potential Failure Points
The great temptation once a new website is launched is to think its done and you can turn your attention elsewhere. But it only takes is one week of neglect for a church website to communicate inaccurate, out-dated information.
Additionally, a new website can fall into disrepair without anyone slacking off or neglecting assignments. A new website brings with it a bunch of new responsibilities for upkeep that no one has ever had before. So, even if the church staff and volunteers perform all their existing responsibilities with excellence, if responsibilities for the new website are not clearly outlined, upkeep will slip through the cracks.
It’s absolutely critical to determine all the processes necessary to keep the site up to date, determine when and how often those processes need to be implemented, and assign the responsibility for those processes to specific individuals.
Creating Processes
About a week after the launch of my church’s new website I wrote up a “Proposed Website Update Processes” document. I started by listing the various parts of the website that would need to be updated:
- News/Calendar
- Ministry pages
- Sermon Series
- Main Church eNewsletter
- Ministry eNewsletters
- Photo Galleries
- Sermon blog/notes/audio
As you look over the list, you can probably already see that the process for maintaining each of these aspects of the website will be different. The calendar needs to be updated more often than the ministry pages. The sermon blog and photo galleries may be updated by different people. The people providing information for the news and the ministry pages will be different.
As I began writing the update process document, I started to notice 8 common elements – 8 parts of the process that were different for each aspect of the site but needed to be defined for all of them. They include:
- Source of the content. Who provides the information, document, graphic, or audio?
- Format of the source. For example, if a ministry team leader wants to announce an upcoming event on the news page, they need to know how long the title needs to be, how long the announcement can be, etc.
- Deadline/frequency for the source. If the eNewsletter is distributed every Wednesday, then what time do entries for the newsletter need to be received by the person publishing it?
- Source approval process. If a ministry team leader wants an announcement placed on the homepage, do they simply send that announcement to the person responsible for maintaining the homepage, or does it have to be approved by someone first?
- Person responsible for updating that part of the website.
- Format of the update. For example, if you podcast sermons you’ll want to define the file format and bit rate of the audio files. You don’t want every ministry page to use a different font and text color, so you’ll need to define acceptable text formats.
- Deadline/frequency for the update.
- Update review process. For example, you may want the weekly eNewsletter read by a proofreader for spelling and grammar. The senior pastor may want to review information posted about upcoming sermons.
If you look closely, you’ll notice these 8 elements define the who, what, when, and how of both the input and then the output of each update.
Church Communications Policy
Other forms of communication at a church – Sunday morning announcements, the Sunday program, monthly newsletters, mailings, etc – should also have similar update procedures with these elements defined. Therefore, these website update procedures and the elements defined for each can form the basis for a larger communications policy document that encompasses all communications in the church.
It just so happened that the same week I wrote up the “Proposed Website Update Processes” document our church hired Chuck, our first director of communications. Our church is mid-sized (about 400 attende on an average Sunday), so Chuck also oversees children, youth, evangelism, and he cleans the bathrooms (just kidding about that last one). But it’s the first time we’ve had someone specifically responsible for communications.  One of his first priorities was to create a church communications policy, so this document fit nicely with what he was doing.
If your church doesn’t have a communications policy yet, I would strongly recommend creating one. If you’re not sure how to do that, start by reviewing the communications policies of churches that you know communicate well. Some additional resources that may be helpful include:
- WiredChurches.Com Communications Bundle (from Granger Community Church)
- Kem Meyer, Granger’s Director of Communications, also has a great blog.
- Yvon Prehn is a church communications consultant leading seminars all across North America
- Center for Church Communication
With a clear set of processes for updating your church website defined in a church communications policy (and a commitment to following them), you can prevent your website from losing altitude and ensure it continues to propel your church forward with consistent, effective communication.
If you found this article interesting or helpful, please vote for it on Blogs4God so others will see it.
November 20th, 2007 at 12:36 pm
[…] Two weeks ago I posted an article entitled Developing a Website Update Policy, part 12 in this series about the development of my church’s new website. If you’ve been following this series, you know I’ve been posting one article each week. Except for last week. Last week I was really busy trying to make a project deadline and didn’t have time to write an article. Maybe you noticed… or maybe you didn’t because you’re so busy with work, family, ministry, cleaning the house, baking pies, getting your fantasy football roster done early this week. (Note to self…) […]