Content Approval Process

Published content on your site, or in your application, needs to be perfect, right? It needs to be revised, precise, and in line with guidelines. But is that really true?

We frequently¬†always get asked about the approval process. And our answer might surprise you: sure, we can implement customized approval processes for customers in genuine need, but we’re honestly against it.

At this point, we’re sure we know what asking: why? We can explain it by taking a look at a couple of examples.

Our first example is an internal knowledge base. In a medium to large organization, the process would start with a team member asking a question. A subject matter expert would be tasked with answering the question to the best of his/her knowledge. A third team member will review and then approve the expert’s response and only after approval will the content be available. This third person not only needs to have knowledge the same or better knowledge of the topic as the expert, but they also need to have the time to read and approve the content. Usually reviewers don’t have the time nor the depth of knowledge and this extra step simply serves to delay the publishing of core team knowledge allowing for the same question to be asked over and over again. This results in a general waste of time for all team members.

Since creating new content in the fastest possible way is paramount to efficiency of the team, the better option is to simply publish new entries immediately. If the content is useful and correct, it will get up-votes from other team members, creating an approval by a “Board of Users”. If the content is invalid or not-useful enough, it will not be viewed by the team and/or generally down-voted. The content author, or even other team members, can then go back and refine the entry until it is acceptable and useful.

Another example case is user support. In support scenarios, approval processes are often created to make sure that a topic/question does not get discussed more than once. The problem is that if you merge multiple questions in to a single topic, you are making it harder for your users to use their words in order to find the answers they need. In the end, this will result in more new tickets. Personally, we want to decrease the number of support tickets that come in; not increase them.

A further advantage is that if your users use Google to search for a problem-solution fit, and your site’s FAQ gets indexed, they will find it on your site. Not in a forum or other site out of your control. In the end, to best help your users, you need to meet them on their level and talk how they talk; not create a fancy formulated FAQ. And as for the quality of the content? The voting system, search history, and support ticket history will help you identify what’s good and what’s bad.

Of course, each and every situation is different and in cases where the information that you publish can have legal repercussions, you will most likely need a mandatory approval process. To put it simply, if the legal department needs to be involved: YES. Otherwise: NO.