What should you know about CMS as a CRM Manager?

Are you a CRM manager, marketer, product manager, or in other words, a non-tech person, wondering what CMS is and what you should know about it? Are you already a CMS user but you want to get more technical knowledge about the platform? Are you considering changing your CMS but writing a RFP about something you don’t have a slightest idea about is scaring you out? Are you moving into a new position or getting new tasks and will have to work with CMS developers more closely? 

Do not fret, technical concepts around CMS platforms are fairly straightforward and as a non-technical person you are usually not required to know them that much in-detail. The most important thing is to understand a couple of basic definitions, understand the platform your company uses and get to know some basic lingo. Later, if you need to know more, I strongly recommend just asking your developers – there is nobody who knows more about your CMS platform than them. Read more about why learning from your developers is the best way to learn tech and how to start speaking their language here.

Table of contents:

1. What is a CMS? 

• CMS definition
• CMS purposes 
• Why should a CMS system be important for CRM managers?

2. What should you learn to manage content in a CMS?

• Markup language
• How to draft
• How to publish
• Where is the content stored?
• Managing digital assets
• Website analytics 
• Available out-of-the-box modules, widgets, templates
• Basic Design Principles – UX / UI

3. Features of CMS you should know about

• Easiness of editing
• Versioning
• Restoring (rollback)
• Archiving
• Compatibility
• Integrations
• A/B testing
• Personalized content
• Translations management
• SEO optimization
• Multi-platform publishing
• Accesses
• Working collaboratively
  

4. Technical concepts worth understanding

• Is your website static or dynamic? 
• Website release
• Environments
• Out-of-the-box or custom-built CMS?
• Headless CMS
• What is an API?
• What are webhooks?
• What are SDKs?
  

5. Summary

‍What is CMS? 

Content Management System (CMS) – is a software application that can be used to manage the creation and modification of digital content. It is a “database” where you keep your content: digital assets (pictures, videos, podcasts), text, translations, in some cases page layout, parts of the design (tables, buttons etc.). Content stored in the CMS can be served to your website, mobile app or other digital channels (sms, email, smartwatch etc.). Not every company stores all content in the same CMS; often some content “storage” solutions are separate (email content in email sending platform, mobile app content stored as code and updated only by developers etc.). 

CMS can serve more purposes than just publishing the content to your digital channels. Depending on available APIs, plugins, webhooks it can: 

• export and import the translations, 
• push out the content to social media platforms, email platforms and other channels,
• store all digital assets in one place and categorized, 
• prepare A/B testing of content and content personalization, 
• set up on-page SEO,
• return results for on-page search engine,
• and more.
  

Why should a CMS system be important for CRM managers? 

CMS is (or could be, if you set it up that way) the center of every customer-facing communication. It can serve content to your own platforms and integrate with different marketing stack to serve content to paid ads. You can also manage on-page SEO from there. If that’s not enough, you can set-up email collecting forms, upload cookie policies to collect customer data to your CRM system, where you can segment the customers and serve personalized content to these segments from the same CMS. In the CMS, you can set up A/B tests for your content, or set up personalized content. You can feed your chatbot’s database from there. You can also integrate your CMS system with marketing automation tools where you can create segment rules allowing you to push content to specific customers from the CMS via different distribution channels (for example, sending a forgotten basket reminder via email to those who have unfinished shopping in their basket). 

What should you learn to manage content in a CMS? 

Markup language:

Your CMS system either uses a WYSIWYG editor (in this case it is easy to edit the content for content editors) or some kind of a markup language (which you or the content editor would need to learn). 

What is a markup language?

A markup language is a language that annotates text so that the computer can manipulate that text (make it bold, italic, center it, colour it etc.). Basically it is a language with which you can communicate to the computer how you want it to display the text or assets that you are editing. 

HTML is an example of a markup language: 

<p>

This is a paragraph of text written in HTML

</p>

This sentence is made up from an opening tag (<p>), text and a closing tag (</p>). The text between the tags would be displayed on the screen. Each tag includes a "less than" and "greater than" symbol to designate it as part of the markup.

How to learn a markup language? If this is a CMS-specific markup language, you should be able to find it in the CMS manual. If it is a standard markup language, there are many available online resources to learn those, like for example: MOOC, Udemy, EDX, Codecademy or Coursera.

If your CMS does not have a WYSIWYG editor, it might be also beneficial to know some basics of CSS (Cascading Style Sheets) that work with HTML to add styles to web pages you are editing. 

How to draft: 

What you should check in the manual or ask your developers: 

How to create a draft of the content (and not get it published by mistake)? How to test the draft, can you see a preview of how it would look like on the website directly in the CMS? If a preview directly in the CMS is not available, is there any test environment where you could check the newly drafted content? 

How to publish: 

What you should check in the manual or ask your developers: 

How to publish the content to the live website? Can you do it yourself (or the content editor themselves) from the CMS? Do you need a website release for updating the content? Do you need to ask developers for help with publishing? Is it a mixed solution, meaning part of the content is publishable from the CMS by content editors but some changes would need developer support? Which ones need developer support? What are the average timelines if you want to publish something, how long would it take? Whom to contact if the content breaks and you or the content editor cannot fix it on your own? Whom to contact out of office hours if you need urgent support? Can you schedule content publishing in  the future? Can you schedule more than one content “package” in the future? If you schedule a piece of content in the future, can you still change and publish other parts of content or will the scheduled package freeze any other publishing from the moment you create it until the scheduled time? Can you recall scheduled content yourself if for some reason you change your mind? 

Where is the content stored? 

It is an important question you should ask your developers/architect. 

Which content comes from where? Which content is stored in the CMS, which in payment or booking engines/systems, which is directly stored in FE? You should know which content is possible to edit in the CMS, which needs development (or where to find such information when you need it). There should be documentation available about it or your content editors should know it. 

Managing digital assets: 

You should know what kinds of digital assets are supported by your CMS. Can you use videos, pictures, mp3 files? What file extensions are possible to use? What are the requirements for the assets? Check the specifications for image sizes and weight. Will the system resize the images automatically or you should always resize them before the upload? If you don’t want to make your website or other platform slow, you should always aim for having the minimum weight necessary to display the asset correctly. 

Available out-of-the-box modules, widgets, templates: 

You should get to know what you are working with. Do you have any “building blocks” you can use out-of-the-box (or already premade by your developers)? Do you need to always ask for custom building the content modules, page templates? What is the flexibility of the out-of-the-box templates, how much can you change them if you want them to look differently? Are the modules integrated with some FE (front-end) display, so you do not need any additional sitebuilding to make them appear on the website? Having at least some basic library of modules and templates available can greatly shorten time-to-market of new pages creation, from a couple of weeks of development to a couple of hours of picking and playing around with the customization possibilities.

Basic Design Principles – UX / UI:

Basic knowledge about design, especially user experience and user interface (UX/UI) can be very useful. When you are working with designers (for example to create a new subscription form, new microsite) you will know how to talk to them, what to ask for, and how to evaluate their work.

Website analytics: 

To understand your customers, their behaviour, preferences, to evaluate the performance of your newly launched landing pages or subscription forms you will need to learn how to use the website analytics software your company uses (or set up one yourself). It is useful to learn what is currently tracked on the website by default (where the tags are placed) and what kind of tracking you should ask for specifically, for example custom events tracking or custom funnels. 

Features of CMS you should learn about

What should you know about your CMS system? What should you look for when choosing a CMS system? What should you ask your developers about to understand what is possible and what is not? 

Easiness of editing:

How easy is the CMS to use from a content editor’s perspective? This will influence the time-to-market of the content. What can influence the editing speed are: drag-and-drop features, flexible ‘blocks’ to build pages with, automated workflows (for example for sending/receiving translations), content populated from one source (example: dynamic modules, where you update content once and it will appear on various sub-pages and even on different digital surfaces), content synchronization between environments (removes the need to copy-paste all contents across different environments).

Versioning:

If your CMS enables saving previous versions of content, if you create a new version of the content but you change your mind for some reason, you can restore the previous version. Sometimes, it is even possible to see the comparison between the versions and have the parts that were changed automatically highlighted. 

Restoring (rollback):

If your content breaks after a release, you should be able to rollback to the previous content version to fix it temporarily, until your developers can investigate why the content failed in the first place. 

Archiving: 

The CMS should let you archive content. What is important to know is for how long the archives/old content versions are stored. You should carefully consider the legal requirements for different types of content and possibly prolong the lifespan of archived content for high-risk content (for example: terms and conditions, promotion content, privacy policy, cookie consent) that might be required in the future for legal investigations. 

Compatibility:

A basic requirement for a CMS system is compatibility with your architecture, your back-end, front-end, payment systems, booking systems, any external software you are using at the moment.

Integrations: 

A system that provides integrations to other software your company already uses or that can easily integrate other parts of your marketing stack either natively or via API connectivity will save you time and money you would otherwise need to spend on custom integrations.

A/B testing: 

What you should check in the manual or ask your developers: 

Do you have any possibility to create content A/B tests (several content versions that would be placed in the same placeholder and could be toggled with the A/B testing software)? If not, can your developers develop it for the content types (modules, blocks) you need to test? How much time would it take? 

Personalized content: 

Do you have any personalization tools (software) in place? What type of content can be personalized at the moment (what type of content can multiple versions created in the CMS that would be toggled by the personalization system)?

If your CMS system can integrate with the personalization tool, you can keep on using only one system for content storage, which makes it easier to re-use content and to manage it (make changes in the case of a product name changes, translation changes or when you want to implement any other cross-platform changes). ‍

Translations management: 

If you want to serve localized versions of the site, your CMS system should have language support. The minimum functionality means being able to store various language versions of the same content in the same CMS. What I recommend, based on experience with multilingual websites (20+ languages) and other digital platforms, is that the CMS should have all the languages stored in the same place for the same content module/block. What is the difference? If you keep different language versions in the same CMS as a “copy” of the same site structure, to find the same module and update it in all languages you will have to open each language version, find where this module is in each and then update it. If you have the language versions directly on the module level, it is easy to find the same piece of content and update it in all languages, without getting lost looking for it in the CMS. 

Managing various language content versions is hard work. It is time-consuming and has a high rate of error (if you/the content editor copies something wrongly). The easiest way to manage translations is to have an integration with the translation agency software from the CMS. This way, you should be able to send out original content for translation (for example, from English) to various languages directly from the CMS and receive translations from the translation agency. It saves you time (no copy-pasting), cuts down the error risk and improves time-to-market. In some cases, it is even possible to enable showing preview links to the translation agency which makes it even easier for translators to translate the content. Proxy translations are even easier to manage. What proxy translation does is populate your website to proxied, localized versions. The translation agency then creates these language versions and serves them. It greatly reduces the content editing time but works only for websites, not for other platforms like mobile apps, email, SMS. To cover other platforms you would need another type of integration, for example API.

What can also be a useful feature is automatic notifications once the translation arrives from the translation agency or if there are any issues found while exporting/importing the translations (that could be configured with webhooks, if the CMS does not provide it out-of-the-box).

Tip: an expression you will keep hearing from your developers – locales – are like languages but finer-grained. While German is a single language, there are many different German locales: de-DE for German in Germany, de-AT for German in Austria, de-CH for German in Switzerland etc.

SEO optimization:

Can you manage on-page SEO from your CMS? Can you customize the URLs yourself? Do you have fields for metatitle, metadata, metatags? Can you add <h1> tags? Does the CMS create the sitemap automatically and add new pages to it once they are published or you need to ask your developers to do that for you? How can you set up hreflangs and canonical tags if you populate content to more than one place or publish in more languages? You should know what are the possibilities and when you need to contact your developers.  

Multi-platform publishing:

Can your CMS system serve the content to other digital platforms (mobile app, email, smartwatch, chatbot etc.)? Can you configure it to do so? It is an important question, if you are planning to maintain more digital communication channels. Keeping all content in one place has great benefits like reducing the complexity of content management, re-using the content, re-using the translations, reducing risk of having inconsistent content across different platforms. 

Access: 

CMS systems can offer different access types with different rights. It can be useful if you want to have different people drafting, reviewing, approving the content or if some editors should only be able to access certain content types (for example, a specific department only has access to the content that belongs to that department). 

Working collaboratively: 

If you have more editors that edit the content, it would be useful to have an option to work collaboratively on one piece of content. Some CMS systems lock the file if one user has it open, some let you edit simultaneously. 

Technical concepts worth understanding: 

Depending on how closely you need to work with the CMS developers, CMS management, or content editing, you might want to dive a little deeper into more technical topics. Here are a couple of topics worth understanding: 

Is your website static or dynamic? 

Dynamic website means the customers download the content from your servers directly. In that case, you can change the content ad hoc and the changes will be pushed to the live website automatically for all customers who re-load your website. 

Static website means the content (and code) is packaged and released with a website release, from time to time (frequency varies by company/code type). Customers can reach that static version only, creating much less load on your servers. Changing content on the static website is only possible with the website release. If you have such a website, you should learn when the releases are, when the content needs to be ready for them. Sometimes static websites have some workarounds to publish content in-between releases, you would need to understand the constraints of these workarounds (what can be published this way, how long does the crawling – packing the content into a package – and publishing take). 

Website release:

Website release means delivery of new code (and content) to the website. If you need to work around website releases or some content can only be delivered with a website release (because they are stored in FE applications, for example), you should learn what is the cadence of your development team – how often do they pick up new developments? How often the releases are? When do you need to inform them on the new initiative to have it live on the website, what is the time-to-market from the request to the delivery (time-to-delivery)? 

Environments:

Environments are entities within a space that allow you to create and maintain multiple versions of the space-specific data, and make changes to them in isolation. Having various environments allows for parallel developments, testing and continuous integration, which helps your team to deliver more than 1 project at once and work in an agile way (developing and testing at the same time). 

Out-of-the-box or custom-built CMS?

Out-of the box solutions can lack flexibility and it might be hard to customize them. Custom-made solutions require a lot of maintenance and every upgrade will cost you a lot of effort which means unpredictable costs of development (as compared to fixed license costs). The best solution is something in-between: an out-of-the-box solution that provides enough flexibility so you don’t  have to do many customizations. This is another reason why API-based CMS systems are, for most companies, the best available solution at the moment. 

Headless CMS:

“Standard” (not headless) CMS provides a back-end with a simple interface to create content, database to store digital assets and a possibility to publish the content. The content is pulled by front-end and published to a page. The front-end and content are coupled, you cannot update content without the front-end application. Everything is released in one bucket – content, images, HTML, CSS. This can mean that the content has to go in the same releases as the front-end code (therefore, can be less frequently updated), it can also limit the CMS usage to just websites (as the content and code are commingled, content cannot be flexibly published on different digital channels). 

A different approach to serving content is a “headless” CMS — if the presentation layer of a website is the “head” of a CMS, then cutting off that presentation layer creates a headless CMS. In that case, the content repository “body” is separated from the presentation layer. This enables to unify all content in a single headless content hub, from where the same content can be published cross-channel. This makes editing way easier — change the copy or image in one place, and that change will be applied everywhere the content is located. Headless CMSs split back-end and front-end tasks – this means developers can quickly code and design front-end experiences in their preferred language (without being bound by restrictive back-end technologies). Instead, they can use Application Programming Interfaces (APIs) to connect the back-end functions—like content storage and management—to any front-end delivery environment. It makes developing new pages or mobile app screens much faster and easier.

Read more about headless e-commerce platforms here. 

What is an API?

API-first systems (API – Application Programmable Interface) have code that allows for clearly defined communication between two separate apps. They are modern software platforms, which give CRM managers some ready-made building blocks of functionalities that you can put together to match your needs in almost 100%. They are prepared for fast integration with other systems. 

“API: the Mailman

Think of an API as a mailman delivering your app’s request to some other software, and then bringing the response back to your app. A simple example: it’s the API that allows communication between Google Calendar and your travel app so that when a user books a trip, it synchronizes to their calendar.” Source: Clevertap

Read more on what APIs are and what you should know when choosing API-first software here.

What are webhooks?

Webhooks are similar to APIs, but simpler. An API is a full language for an app with functions or calls to add, edit, and retrieve data. With an API, you have to do the work yourself. If you build an application that is connected to another with the help of an API, your application will need to have special ways to ask the other app for new data when it needs it. Webhooks, on the other hand, are designed for one specific part of an app, and they're automated. It's a simple, one-to-one connection that runs automatically.

Example of a webhook could be a notification to your email, triggered when a new translation arrives to your CMS. 

What are SDKs?

SDK stands for software development kit – a set of software tools and programs used by developers to create applications for specific platforms. SDK tools include libraries, documentation, code samples, guides and processes that developers can use and integrate into their own apps, designed for specific platforms or programming languages.

SDK – the Post Office/Hardware Store:

If the API is a mailman, then what is SDK in that context?
It’s the post office AND the hardware store combined. Since it can contain everything necessary to communicate with another software (i.e. one or more APIs) as well as materials that can be used to construct an entirely new app (i.e. code libraries, debugging facilities, technical notes, tutorials, and documentation). (...) it’s a development kit. The SDK can contain one or more APIs plus essential utilities. The API is just one part of an SDK. Think of the devkit as a larger “container” for an entire array of SDK tools and you’ll be correct.” Source: Clevertap

Summary:

As a CRM manager you should know some basics about CMS platforms. In most cases, sooner or later, you will need to publish some content. The absolute basics you need is to know the workflows and processes at your company if you have content editors in place to do it for you. If you need to edit and publish content yourself, you might want to learn some basics of the platform in use, like how to edit, draft, publish the content and what are the possibilities for testing or scheduling content changes. If you need more advanced knowledge, you should learn a bit more about the options for A/B testing, personalization and SEO optimization in your current platform. It is recommended to know a bit about how your development team works and how much in advance you need to plan the developments, if a simple content editing is not enough. You should get more familiar with their processes, especially if you need to release content with website releases (for example, if your website is static or your CMS is not headless). Getting to know some developer lingo will help you to get the conversation started. After you learn the basics and read the manual, I strongly recommend you to just start asking your developers questions to deepen your understanding – they are the greatest source of information about your existing stack!