Matrix Structure in Community Service

Functional Characterization of a Community - Where Can We Go?

When we build a community, we use organizational resources and aim to advance its objectives. To achieve this, from day one, we prepare to ensure that the tool primarily builds on the "mindset" of the end user (community member) and "speaks" their language according to needs and knowledge gaps in the field.

Our challenge, therefore, is to provide the user with comfortable and intuitive access to all the information they need to complete their task on time and turn knowledge into action.

In this context, it's important to remember that the end user doesn't care about the format in which knowledge is presented; what's much more important is that knowledge is concentrated in the right place, at the right time, in the appropriate context, and with minimal effort.

We have several sharing tools in our community that support this challenge: a community journal, document repository, frequently asked questions, forums, links to systems and websites, insights repository, etc.

In the traditional approach, all these can be divided into two main axes:

First axis: Content topics - If we take the investment advisors community in a bank as an example, we can assume that the content topics will be stocks, bonds, and foreign exchange. In a safe community, such as firefighting, first aid, etc.

The second axis is the knowledge format axis, which includes forums, frequently asked questions, links, etc.

Let's examine how we can arrange these two axes and how they affect the end user. Here is how two members in different communities that are built somewhat differently use them:

The first member (Yedaoni): Wants to get updated on government bonds due to a dilemma that arose with a client during his workday. For this purpose, he enters the "Documents" format and checks what documents have been written on the subject, then he searches the frequently asked questions to see if there is a knowledge item on the topic, and he does the same in the forum. Since he hasn't yet found a complete answer to his dilemma, he uses the search function and finds that there is also a relevant website link, and from there, he looks for what he needs.

The second member (Gideoni) Goes to the sub-menu called "Bonds," where all the existing knowledge in the field in all existing formats is concentrated for him. He reads all the discussions about the subject and the frequently asked questions on the topic. Unfortunately, he sees that a question-and-answer addressing his dilemma has not yet been formulated, and he sends feedback about this to the relevant content expert from the same page in the portal. He looks at all the existing links and documents that have been concentrated there and, of course, at the relevant insights that have been produced to date by all community members. To get updated on the "ex" days of a type X bond, he looks at the results of the relevant query from the stock exchange system displayed as a content window on the same page. It's important to note that if Gideoni wants to look at all existing forums or all questions and answers formulated on all topics, he has convenient access to do that as well.

So, who do you think is more satisfied?

If your answer is Gideoni, let's examine the tools and processes we'll need to establish such a matrix.

First stage: Correct characterization of matrix components:

• List of content topics. It must be focused and characterized according to the needs of the field and its components to create a complete picture of that content world.

• Formats for knowledge sharing:

  • Traditional sharing tools mentioned above include FAQs (frequently asked questions), forums, and journals.

  • Decision support systems containing relevant information (for example, the Standards Institute in the safety community, incident reporting software, etc.)

Second stage: Menu design:

Design menus to allow convenient access to the required information from anywhere. The approach should include both content topics and formats. A possible structure, for example, is an L-shaped structure with formats and systems at the top and topics as a side menu.

Third stage: Input:

Building a topical characterization system for each sharing format. Here are some examples:

• Links: When a content provider adds a link to the list of links, they will see a list of all topics and can characterize which topic this link belongs to (option for multiple selection).

• Forums: Forums can be opened on each relevant topic, so when a community member wants to open a new topic, they do so from the relevant forum.

• Journal: It may sound strange, but topics can also characterize events. It certainly can't hurt for the user to be able to look at all the inspections that will be conducted this week when they are on the homepage called "Inspections" or at all events in the capital market dealing with government bonds.

• Decision support systems: Predefined queries according to topics, such as all standards relevant to "firefighting."

Fourth stage: Viewing:

Defining a technological requirement whereby everything characterized as belonging to a certain topic will automatically appear on the homepage of that topic.

Fifth stage: Ongoing updates and maintenance:

It's recommended that when deciding to add/remove an important content topic, the list of values in all formats be updated accordingly (if the tool does not allow automatic updating of values accordingly).

The ROM company's experience in building matrix sites has been fruitful, and users have expressed great satisfaction. This is definitely a sincere recommendation.

---

Want to learn more about communities of practice?

Here are some articles you might find interesting:

• Uses in Communities

• Knowledge Management in the Third Sector

• Birthday for a Website/Community/Portal