Building a social employee feedback system on Confluence wiki

Building a social employee feedback systemCorporations need feedback to evolve. Feedback from customers is vital, but so is feedback from employees: employees see what is happening under the hood regarding products, processes, and tools. Social collaboration tools provide unparalleled opportunities to create feedback systems where thoughts are shared and discussed and changes are implemented, sometimes at lightning speed. This is a story of one such system.

The problems of suggestion boxes

It is not the case that social networking tools enable feedback gathering for the first time, corporations have been doing it for a long while now. However, technology enables a number of cool things that help, which were not possible before.

Some typical issues with traditional feedback systems include:

Lack of visibility. Dropping a suggestion into a box, or even entering it in a pre-social electronic feedback system gets the suggestion into the attention of whoever is appointed to handle them in the company. The handling process is then launched, but who is aware that such a process is taking place until some results are announced? Very few people. This is a problem, because many people could have something to contribute to the improvement effort, but it is not possible to consult everyone separately.

Lack of transparency. Likewise, as the suggestion is being processed, it is very difficult to ascertain who is working on it and what is going on. Ultimately, a decision is communicated, but whatever happened before that happened in a black box.

Lack of feedback back to people. In worst cases, the suggestion does not end up in a black box, but in a black hole, and nothing is heard back about it ever again.

Slow speed. As the suggestion makes its way through the wheels of bureaucracy, time goes on. Sometimes, a lot of time goes on. It is difficult, albeit, admittedly, not impossible,  to craft a quick workflow with traditional tools, especially as the size of the organization grows.

Social collaboration tools enable better processes

The problems that plague many traditional feedback systems can be all but eliminated through the use of social collaboration tools. However, it is important to note that only the combination of the right tools and the right process brings success. Social tools are useless without processes that take advantage of them.

Social collaboration tools help solve the traditional issues:

Visibility. Social tools are superstars when it comes to improving visibility. In practice, I have found activity streams to be the key element. There are also various opportunities to use RSS feeds and page and user followers as well as advanced search functionality and categorization, which all serve to improve visibility.

Transparency. A wiki is as transparent as it gets with full version history and information on who has edited the content and when. Some platforms also provide opportunities for discussion (comments and replies) and visible task management.

Feedback. Return feedback to the person who made the suggestion is easy to arrange in a social environment by setting him to follow or watch a page.

Speed. Through improved visibility, transparency, and discussion, issues can be solved faster.

Social employee feedback system on a Confluence wiki

To make this more tangible, let’s take a detailed look at how a social employee feedback system can be built on Confluence, a popular collaboration platform by Atlassian. It can, of course, be built on a number of platforms, but as I have built one on Confluence, I can discuss that in proper detail.

Ingredients needed:

Setting up the space and template

First, you need to set up the environment for feedback handling. I recommend creating a separate space for it within your Confluence wiki, as that will help a lot when configuring workflows and reporting.

In this example, I will call this space Quality. As you may want to use this space for some other things as well, also create a page under the home page called Feedback.

Next, you will need a template to guide the user in giving feedback. Create a space template, let’s call it feedback, and set it to automatically create a label called feedback as well. This label will be used to initiate the correct workflow.

The template should be as simple as possible. In my implementation, the template consisted of five things:

  • Picture of the person giving feedback (with Profile picture macro @creator), to create an improved sense of relatedness
  • Feedback keywords, to be filled in by the person giving feedback, to help give context to the feedback
  • Feedback itself, to be filled in by the person giving feedback, with Confluence this can also easily include images
  • Result / decision, to be entered by the feedback handling team when closing the feedback
  • Optionally, you can also automate the creation of some dynamic labels with the Label tools and Replace and render plugins. For more complex dynamic labels, you may also need the Run plugin.

With the template ready, you can edit the home page of the space and insert the Create page macro to create a page based on this template under the Feedback page.

Setting up the workflow

In order to create workflows within Confluence, you need the Ad hoc workflows plugin. The plugin enables creating tasks for pages through the workflow but also on ad hoc basis, as the name implies, and to easily assign tasks to people.

Again, I prefer to keep things simple, so I created a rather simple workflow that goes as follows:

  • When a new page with the label “feedback” is created (or a page is assigned the label “feedback”), the feedback workflow is initiated.
  • The first state in the workflow is “In process” and the workflow automatically creates a task to the appointed feedback handling team to get started. The workflow also adds a new label “fb_inprocess” and removes possible label “fb_complete”.
  • When all tasks in the first state are completed, the workflow advances to the second state, “Completed” and the workflow automatically creates a task to the appointed feedback handling team to review the decision. The workflow also adds a new label “fb_complete” and removes possible label “fb_inprocess”.

Setting up the process

From a system point of view, you’re good to go. However, you still need a process to manage the system. Here is what I have come up with:

  1. When a new feedback is entered into the system, it goes to the feedback handling team, who perform a number of actions:
    • The feedback is categorized according to a predetermined taxonomy with labels on the page
    • The feedback is prioritized according to a predetermined set of criteria, and the priority is recorded as a label on the page
    • Preliminary analysis is performed, and the proper workflow is determined (we have both the above-described lightweight workflow in use as well as a full PDCA cycle – similarly configured with Ad hoc workflows and initiated by changing the feedback label into a pdca label)
    • Appropriate people are consulted and tasks are created and assigned to them
  2. People working on the feedback document their progress as comments on the page, thus forming a story on how the handling has progressed. If necessary, new tasks are created and assigned.
  3. Finally, the feedback returns to the feedback handling team, who review the decision and actions and either close and archive the feedback or return it back to “In process” state for another round. When the feedback is archived, the final decision is edited to the page itself for easy access even after long periods of time.

Throughout the process, the person who gave feedback is kept up-to-date automatically, as he is registered as a watcher of the feedback page and receives email notifications of all actions. He can also jump in to discuss the progress at any time.


You probably want to get some reports out of the system as well. This is where the work on those labels pays off. Confluence can easily display a list of all the labels used, either alphabetically or in a heat map, and with the Content by label macro it is also possible to create reports on combinations of labels with Boolean operators. Want to get a list of all feedback that is currently in process and related to a certain version of a certain product? Can do!

I do not know if there is a way to get statistics on, for example, feedback handling lead times. All the dates are saved on the pages though, so perhaps that too can be done with some of the reporting plugins available for Confluence. So far, I have not needed these statistics.

Time to reap the benefits

The potential benefits are closely tied to the number of people in your organization who use the wiki: the more, the merrier.

Luckily, as wikis can have a large number of uses (for examples, see my earlier blog post, Internal corporate wiki is an information sharing powerhouse), the platform can attract people into using it. This is different from a stand-alone feedback system where people do not spend time and thus there are no opportunities for serendipity.

I have witnessed cases where engineers have spotted feedback regarding projects they are working on and made the corrections before the official organization has had an opportunity to assign the task to them.

I have also witnessed cases where an esoteric issue reported by someone has received echoes from multiple other people and resulted in a fundamental correction because many seemingly insignificant pieces of a puzzle that would not otherwise have been connected could all be pulled together to form an accurate picture of the whole.

This is the real power of the social, helping create information that would otherwise be inaccessible.

Why not just use JIRA?

Incidentally, Atlassian has another software product specifically designed for issue management, primarily on software development. The product is JIRA. So, why build all this functionality on a wiki instead of using JIRA or another issue tracking software to accomplish the same?

That is a question I have asked myself a few times while building and launching the system, and I have come up with a few answers:

  • A wiki can be used for many other purposes as well, so you do not need to invest in multiple platforms, especially if you do not already have them.
  • People work a lot in the wiki anyway, so they are used to the interface and regularly exposed to the activity streams, promoting serendipity.
  • Issue trackers are primarily configured for software development, but not all companies create software, and even for ones that do, not all feedback is about the products. Including feedback on general issues and processes takes some work on issue trackers as well.

Future improvements

Finally, we get to the point of why I am writing this post. I want to make this system even better! In order to do so, I need your input. What can be improved? How to make this better?

I have a few ideas already:

  • I am exploring the option of accepting feedback through email. The Send Email To Confluence Page plugin by Artemis Software is an interesting candidate, but I am not yet fully sold on it.
  • Utilizing the “Like” feature in some way. Including Likes in determination of handling priority? So far I have not utilized them in any way.
  • Improved reporting would be nice to have: charts on number of feedback, lead times, subjects. Still, I have not yet actually needed these, and I have always resented gathering data for gathering’s sake, so this is quite a low priority for me.

What do you think?

Photo: Suggestion box by disrupsean on Flickr (CC)

Author: Ville Kilkku

I run my own consultancy business, so if you find the ideas on this blog intriguing, contact me at or call me at +358 50 588 5043 and we can discuss how I can help you solve your business problems. I am currently based in Denmark, but work globally.