The Knowledge Bases (KB) are a simple and efficient way of organizing your Questions & Answers function of their subject and, potentially, their audience.

Let's use an example. Foundware, a software company providing infrastructure products, may want to create the following KB:

• “InBetween development” -> for the R&D team to exchange ideas and innovate (from a technical point of view) around the company's flagship product, InBetween.
• “Project delivery” -> allowing consultants and project managers across the company to share production stories, customer knowledge and lessons learned
• “Human resources” -> for all the employees for an easy access to answers HR related: vacation, benefits, expense reports, internal tools, recruitment, etc.

The exact approach and the number of KB depends a lot on the organization, but in general, some simple rules should be followed when deciding how to split Quandora into KB:

• Don't oversplit. A KB must generate a minimum level of activity in order to be worthwhile. If there's not enough content in it, nobody will come and create more content. So when in doubt, start with few (maybe one) KB and use the tagging system to organize content. You can always split later if the content grows and you need more structure.
• Sometimes the level of confidentiality can define the KB. For instance, you may not want all the employees to have access to the exchanges the executives have around company's strategy. Or you may want to keep sensitive customer knowledge away from temporary workers.
• Don't forget that the power of a tool like Quandora resides greatly in its capacity to improve communication between teams that aren't traditionally talking too much to each other. Examples: consultants/developers and sales; support and sales; or even marketing and sales. So, don't necessarily map your KB on your organizational chart.