What should not be missing from a CMS/website query?

This past weekend I read an article about the obstacles you may face when adopting a headless CMS. In this article was this tantalizing quote:

“Failed CMS projects are mostly poor implementation and less so poor CMS”

This quote reminds me of the article I recently wrote about the differences in implementation between a headless and a traditional CMS. Conclusion of that article was that if you want to implement a headless CMS with traditional glasses it is doomed to failure.

Even though much of the success of a CMS project lies in the implementation it is still important to ask the right questions during the query or selection of your CMS. Then you know which CMS is the best fit and you can also map out a CMS implementation project. We see at Plate that many clients actually have no clue about the options and thus pluck standard lists from the Internet and bombard them into RFP / RFI.

A CMS RFP, RFI.... what?

For those unfamiliar with the abbreviations, RFP, RFI or RFQ: these abbreviations stand for Request for Proposal, Information or Quote. An RFP for a CMS often contains dozens of questions or criteria that a CMS must meet. For a company, it is helpful to use a format that allows you to assign points to different criteria to see which CMS scores best.

In the RFPs that come to us or our partners, we often see questions that are couched in fairly general terms. One example is that it is frequently asked if the solution is "open source," but in many cases the inventor (the customer) does not know the fundamental differences between open or closed source. Recently, we see the same thing happening with headless. Many RFPs for CMSs ask "if the CMS can also work headless" without any knowledge on the part of the inventor, or being sure if "headless" is the right direction.

To help you formulate good questions, in this article I share with you some crucial RFP questions including context and explanation. You can rewrite these questions appropriately (to your own company/organization's situation) and include them in your CMS solicitation.

RFP-template

The questions below can be divided into a number of categories. For each category I outline the context so you can either include or exclude the corresponding questions in your questionnaire, or specify them to your specific situation.

1. Hosting and infrastructure

It is wise to decide for yourself what form of hosting you prefer. Will you choose a CMS that you have to host yourself, or a hosted CMS? If you prefer to host a CMS yourself, or place it with your website provider, you or your website provider will be responsible for hosting and storage, uptime, CMS maintenance and (security) updates. You have more control and can add or remove specific things.

With a hosted CMS, you put the responsibility on the software provider. In many cases, the vendor works with a multi-tenant system for hosting, so updates are made centrally and security issues are monitored. Hosted CMSs typically require less maintenance and offer out-of-the box solutions for security, among other things. With a hosted CMS, however, be aware of the different bandwidths in terms of data storage and data consumption.

Additionally, it is wise to ask if you can operate the CMS entirely through the browser or if there are still local installations to be done.

2. Licences

There are more and more CMSs on the market that you pay a license for. It is important to understand the pricing model of the license and ask around for this. Because once you've started your CMS implementation, you won't go back anytime soon.

The pricing model of a CMS often differentiates itself on three different parts:

• Usage: e.g., based on fair use policy, number of API requests or GBs of data storage;
• Users: how many employees have a login to the CMS;
• Modules: which parts of the CMS you do or do not need for a successful implementation.

In your query, it is important to map out the various price components as best you can.Also, don't forget to ask what happens the moment you cancel the contract. Can you export the data and content? How much time is there for a migration after canceling the license?

3. Services and partner network

We go back for a moment to the quote at the beginning of this article. Failing CMS projects are often due to the implementation and not the tooling. If this is the case, it is important to check with the CMS vendor about how they handle implementations. Do they offer implementation services themselves and you must use them, or is it optional to purchase these services from an implementation partner or from the vendor? Or do they divest all services to a partner network at all? And is there certification on the knowledge level of partners or can just anyone become a partner? Also inquire about training options.

4. Content and data model

The complexity that a CMS must be able to handle strongly depends on the needs of the organization. To get proof of whether your business case fits the CMSs you are orienting on, it is advisable to request a comprehensive demo. Ask the CMS vendor to demonstrate a CMS configuration that incorporates many of your questions.

Pay extra attention to the dynamics and scalability of the data model and to what extent there is room to do - if possible no-code - extensions.

Also ask how you can create relationships within the content structure so that there is a healthy hierarchy. For example, can you create a "mother-daughter" relationship in your data model? This can be useful if you want to use the same data model on other sites or in e.g. a different language. It is also worth looking at validations and the possibilities of conditional fields.

5. Edit content

With the explosion of Web site builders and the adoption of inline editors from traditional CMSs, you would almost think that content editing no longer needs attention. But nothing could be further from the truth. With the rise of the headless CMS and the accompanying separation of data/content and front-end, it is no longer a given that you, as a content editor or marketer, compose your content in a visual editor. Again, this is where a demo needs to find out to what extent, despite the complexity of the solution, you have the ability to set up content in a visual way for your channels.

It is also important to see if and how you can upload files, if it is possible to add files in bulk, and if you can create versions of files and content.

A feature that is easily overlooked but greatly enhances the user experience is the ability to schedule and/or archive content after a certain date. This is another important tool to have at your disposal.

6. Roles and rights

Do you want to be in maximum control? Then make sure the CMS allows you to manage individual users or groups of CMS administrators. You want to prevent that certain components can be edited by colleagues who have no say in the matter. You also reduce the risk of someone accidentally making unsolicited changes.

7. Version management

If multiple CMS users are going to be editing and adding (new) content to your site, it makes sense to take a close look at the version control capabilities within your future CMS. Is this present at all and can you only go back to a specific moment in time, or does each page have its own version control. Especially when producing content at scale, with multiple users, this feature is not a luxury because an accident is in a small corner.

8. Content publication

How do you want to publish your content and through what channels? Are you working with a traditional, coupled CMS? For 'feeding' websites an excellent choice, but as soon as you have multiple channels (sites, apps, IWBs, portals, intranet, shops, etc.) you have to ask yourself whether it is wise to work with a coupled CMS.

One CMS variant that is becoming increasingly popular is a decoupled CMS. A decoupled CMS sits between a headless CMS and a traditional CMS. A decoupled CMS has a back-end and a front-end that are decoupled by an API. So you then have the ability to develop a specific experience for an app or other channel.

Whereas in a traditional CMS, content (back-end) and front-end are intertwined, a headless CMS separates the two parts. In the back-end you organize the information into models and using APIs you can send the information to the right channels (website, apps, IWBs, etc.). This way, 1 product in your headless CMS can be shown in multiple places in different guises, which is of course super efficient, because the same content no longer needs to be added separately in different places. With a headless CMS, you have all the freedom at the front end to set up your channels. So you are not dependent on the CMS you are using, but you can, for example, use modern front-end frameworks like Vue.js, Angular or React to set up the ideal front-end solution for your client.

So do you have a strong preference for a particular front-end framework or are you pursuing an omni-channel content strategy? Then you really have no choice but to go for a headless CMS. But beware: a headless CMS often gives you fewer or no options on the content management side to edit content inline, or it results in high licensing costs if you do want to deploy these capabilities.

In addition, the basis of your content may not be in your own CMS, but in another application. To what extent does the CMS support multiple sources from which content comes in?

If local pagespeed is an important component, you can look into CDN options by country / continent. Especially if you choose a hosted CMS, it is important where the server of that CMS is located. For example, if it is located in Australia, it will take some time before a visitor in the Netherlands sees the website. A CDN ensures that your website or application is served to a local visitor from a local server.

9. Localization

Want to rig an international website with multiple languages or a site that needs to support a country strategy? Then pay close attention to the localization features of the CMS. Is it at all possible to distinguish multiple languages within 1 domain, for example a .com and .de variant, but also a .com/nl and a .com/be version. And to what extent must the content of these localizations be linked or not linked. It may also be applicable that global content and local content are mixed together.

Should localization be important to your organization, work this out very well in advance. You do not want to run into this once you have started the implementation process. It is also good to investigate whether - if you work with an API - you can access local versions of the content through the API and whether there are 'fallback' scenarios if, for example, a version of a page is not available in a certain language ('en-au' with a backfall to 'en').

Should you have to write a lot of content in many different languages, it is good to check if there is a possibility to use AI to automatically translate the text.

Also ask how you can manage and edit content for different languages. Is the CMS user-friendly or are you clicking your way to the bottom? A demo often provides the perfect proof of whether the solution is workable.

10. Multisite management

Companies and organizations today have multiple Web sites to serve different audiences. Within those Web sites, they choose a certain uniformity in branding and elements. If you have to set up and maintain a separate environment for all these different types of sites, it becomes quite costly at some point. Multisite can be a solution. With a multisite you create multiple sites from a template with functionalities, which are maintained centrally. This way you can use the same template to set up both your corporate website and a separate work-at-home website.

With multisite, look closely at the options for user management, content sharing between sites and the ability for custom custom customizations for sites within the multisite.

11. Personalization

If personalization and AB testing are important to you, you should query the CMS vendor for functionality for these needs. To what extent does the CMS support you to create different cohorts and distribute incoming traffic within these cohorts and do analysis on this? Also note that there is a difference in whether a CMS offers this "native" or uses another vendor's application. Indeed, this can lead to a significant increase in cost. It is also a good idea to test the CMS for the extent to which you can personalize and thus AB-test. One question might be whether you can AB-test at the page level or at the section or element level.

Normally, a headless CMS should allow you to personalize just fine; after all, you can create multiple versions of content. Still, it is good to verify this and look at the analytics options provided.

12. Integrations

A Web site almost never stands alone anymore without integration with other systems. Therefore, it makes sense to test the CMS for different ways to integrate. You can connect in different ways, via a GraphQL, REST API or Zapier. It makes sense to ask to what extent the CMS also supports webhooks and whether they have public documentation of the API. If the latter is the case, a technical college can take a moment to review the documentation for usability and completeness. In a number of cases, API documentation still leaves something to be desired.

Those were them: the parts where I think it's important to have the context behind the questions clear. Are there parts you're missing? You can always email me at pieter@getplate.com and I'll add them to this article.

Would you like to talk through the (im)possibilities of the various CMSs? Feel free to get in touch via mail or phone or schedule an invitation for a demo of Plate, for example.