Switching from Confluence to Paligo for Multichannel Publishing and Content Reuse

Founded in 1996 in Switzerland, OPAL Holdings is a leading company in AutoID. As a service provider and systems integrator, OPAL provides innovative solutions to customers throughout the supply chain, including AutoID solutions that optimize barcode and RFID technology logistic processes, simplify manufacturing processes, and facilitate control and quality management.

OPAL offers everything to strengthen your logistics and production, including the latest technologies such as barcode, RFID, pick-by-voice, wireless infrastructure, scanning, printer applications, and its own label management solution.

As CTO, Rony Sieber leads technology, product development, and product management for OPAL’s Professional Services team. One of his primary focuses is supporting the business with good technical documentation.

He discussed the challenges his team faced creating and managing quality technical documentation and why they selected Paligo to support their move to a reusable, structured content model.

OPAL has a long history of managing technical documentation. Initially, they used Microsoft Word, saving Word documents as PDFs and emailing them as attachments to those who needed them.

Later, they adopted Confluence as their CMS for internal knowledge and how-to documentation. They successfully structured their technical documentation in Confluence, enabling the entire team to easily use it and document information.

However, when they decided they wanted to share their documentation with external users, they faced challenges, including licensing costs, security concerns, and the inability to produce the information in different formats (e.g., website, HTML, and PDF).

Also, while the documentation was structured, it was not structured in a way that made it reusable. Nor could they version the documentation to support product releases.

As a result, the customer service team was still producing PDFs to send to customers and having to track what versions customers had.

We wanted to reduce the effort for customer service, but also to give our consultants the documentation they can use in projects, for training, explanations, self-study, and stuff like that.

Sieber said they needed a more efficient, cost-effective way to manage and deliver technical documentation. 

The process of selecting a component content management system (CCMS) started with Google Search. But then, one of their partners in Germany recommended Paligo (the partner used Paligo CCMS for their technical documentation needs).

Sieber said they had a number of requirements, but the most important one was the ability to write their technical documentation once and reuse it as much as possible.

We wanted a system to document content we can later reuse. And we know if we invest one hour in a topic now, it’s a good investment of time because you can reuse it, publish it, and share it with anyone.

The company wanted a solution where if they invested a lot of time into the documentation, it would be valuable. Sieber said they chose Paligo because of its support for the XML open standard, making it easy for them to export and publish their content in different formats.

Another important feature was the ability to version and branch the documentation according to product lifecycles. Sieber said they version entire publications and specific topics and apply filters to remove certain content from older versions of the documentation (like a screenshot or a row in a table).

While translations were not a key requirement for selecting a CCMS, Sieber noted that it was nice to know the capability was there if they decided to translate their documentation at some point.

Sieber said they started with a Proof of Concept (POC) and a demo account to learn how Paligo worked. It was important that they were able to import the content from Confluence into Paligo, and they tested this successfully during the POC.

Also, OPAL needed a process to automate publishing documentation to a central location for customers. They decided to develop a web portal – The Partner Center – to share releases, documentation, training videos, and marketing materials. Because Paligo integrates with many systems they knew they would be able to automatically publish content to the portal in the right format.

Over the period of a year, Sieber’s team migrated and then restructured their documentation in Paligo CCMS. In parallel, they built the new partner center. Integrating Paligo and the Partner Center took three months, fully automating the publishing process. This also included styling the CCS (cascading style sheets) so the HTML content looked good and ensuring the PDF version had their logo and the right fonts and colors.

We can document things in Paligo right now and be sure that it will be the only time we have to do that, and we can reuse and update it later. You click Publish, and it is immediately available in our Partner Center, under the right product, under the right version, in a good layout.

Sieber said the three things he likes best about Paligo include:

1. The ability to reuse content across publications and channels.
2. The ability to create dynamic content with versions and variables.
3. The highly customizable output formats.

Sieber also appreciates Paligo’s customer support, saying the quality and reaction time are good. He said they receive fast feedback, and Paligo takes their ideas and promises to put them on the roadmap.

Working with Paligo has changed the way the team works. Sieber said they create a lot more ad hoc documentation. If they find something is useful, they will document it in the CCMS immediately; they no longer wait for hundreds of changes.

They also ask people to send helpful information, like a how-to, to the team, and they’ll document it. Before using Paligo, the whole team wrote documentation, but Sieber said this new model turned out to be a good thing because they can easily ensure the structure and quality of the documentation remain consistent.

Quality is more important than quantity.

While they don’t have a strict editorial process, developers use Paligo’s collaboration capabilities to review content for important topics to ensure they are described correctly and the technical details are correct.

According to Sieber, the quality of their technical documentation is 300% better because it is well-structured and comprehensive. He said it’s important that it looks good for customers, but it also makes his team happy because they know they are creating something that customers and others can consume.

OPAL is still in the early stages of its Partner Center, running a pilot phase with several customers, but it has been using it internally for six months. The portal provides documentation for consultants, customers, salespeople, vendors, and partners.

Today, Sieber’s team has two authors and four contributors working on technical documentation in Paligo. There are 67 publications, 1,950 topics, and 41% topic reuse.

Sieber provided this advice for others looking to implement a CCMS to support their technical documentation.

Just try it out. Make sure that you really know what and in which way you want to publish your content to your audience and prove if that is possible from a technical perspective. The huge benefit we see in an automated process is that it makes you more effective. You should also always look at the possible integrations into content delivery systems, whatever that will be.