Church Marketing Sucks

This is the last of my three guest posts here at Church Marketing Sucks on the best practices for Internet ministry. In my first post, I explained how my research had shown that the churches and other ministries with successful web sites were the ones who had a deliberate planning process. My second post discussed the issue of using volunteers to develop and maintain your web site and how the most successful web ministries did not use volunteers to do this. In this post, I will discuss the last of my preliminary findings, which relates to keeping the site updated.

Internet Ministry Best Practice #3: a successful Internet ministry carefully decentralizes the responsibility for updating content.

In my survey, I asked several questions that related to how the web site gets its content updated. The responses to these questions lead to a definite pattern: web site updates must meet some level of quality before being made, but decentralizing the updates makes for a more successful web ministry. The three specific questions I used to reach this conclusion were:

• Do you require an approval process before updates are made to your web site? Successful churches and ministries had an approval process in place 50% of the time, compared to 41% overall and only 37% for unsuccessful web ministries.
• Do you allow different groups/ministries within your organization to directly update their associated web pages? Successful web sites allowed decentralized updating 50% of the time, compared to 32% overall and 26% for unsuccessful web sites.
• Do you have a blog on your web site? 60% of successful sites had a blog, compared to 33% overall and 26% of unsuccessful sites.

As you can see, the results for this particular best practice are not as convincing as some previous findings, but the difference between successful and unsuccessful web sites was high enough that I felt it was worth noting. The reason I included the blog statistic (#3) as support for this best practice is because a blog is almost by definition a decentralized way of updating a web site.

I also got support for this finding by reviewing the answers to the open-ended question: “Relate the one key factor that you feel has contributed to the successful completion of your web site implementation.” The ability to easily update content across all staff was a given answer several times—not once did I read a response praising a restrictive update policy. Here is an example of an answer that summarizes how the survey respondents felt about this issue:

“[A key factor that contributed to successful completion was] direct access available by individual ministries. Not having to go through one person to get updates, pix, and other resources loaded. We do have standards that all ministries need to follow as they create or edit content.”

How about your church? Who gets to update the web site? What policies do you have in place?

I want to thank the folks at Church Marketing Sucks for allowing me to present some of these preliminary findings on this blog. I will give the full presentation at the Internet Ministry Conference this fall—will I see you there? And if you haven’t taken my survey yet, what are you waiting for?