It is all about momentum.
Marketing people often face issues with creating landing pages and web assets efficiently. Some approaches are visual but need more design flexibility and quality. Some others depend on too many people, creating friction that slows down marketing team processes.
Those issues mean a waste of hours by marketing teams: 2 hours a week of that waste by person translates into 90+ hours a year. Multiply that by the individuals in your organization and their salaries, and you will get the dollars you can save.
But the most significant opportunity is related to something other than that waste. When marketers have friction in their process, momentum is lost, and they will not execute some ideas. It is there when the real opportunity lives since bright ideas that can be implemented smoothly will translate into more ROI. It is about the money that will come in if your marketing team is allowed to perform at their best.
This article proposes a way to use CMSs (as well as a list of specific ones) that approach those issues. So let's start with the following: what does a marketing team need? (concerning CMS tech and processes).
In no particular order:
I will refer to these as "Sections", "Blocks", "Components" or "Slices" in this article. The idea is that marketers can mix and match blocks from a library to build pages fast and easily. The pages (or other website types of content) would be very custom. For example, a marketer could drop a navbar, then a hero section, then some testimonials, then a section for features, then a video, then a CTA, and finally another row of testimonials. And just like that, get a landing page for an advertising campaign. Similarly, they could create and launch articles, podcasts, price calculators, and more blocks of any complexity by taking blocks from a central library and using them with the needed content.
Purpose and branding are essential. Landing pages and other website areas should look different from a generic template. There are two reasons why. The first one is that templates only sometimes have blocks appropriate for all the pieces of content a marketing campaign might need: new interfaces are to be occasionally built and added to the library. This is why Active Campaign, Wix, Unbounce, and similar visual builders are out of the list of this article: marketing teams need to have a library of custom blocks. The second reason is that branding matters: Gary Vaynerchuk mentioned, "I did not buy this pair of shoes because I got into an automated sales funnel. I bought them because I trust the brand."
To be clear: there is a need to design and code. Otherwise, the reusable sections could not be branded and made available to marketers in the first place.
What I mean by non-dependability is these blocks in the library should be designed and coded once, then marketers should be able to use them and deploy content without needing to rely on anyone else. Again, it is all about not losing momentum.
Marketers and content editors need to avoid the clutter to get things going. They should be able to avoid accidentally breaking things apart when trying to edit something.
It might look like a simple need, but... have you, as a marketer, entered into a complexly structured WordPress website, used Elementor to create a simple page, and realized that something got broken on mobile after hitting the publish button? Here is another example: have you modified a margin for a CTA in Webflow and accidentally adjusted margins on all other website pages? A simple CMS workflow will allow content editors to focus on only what they want to create or change. And having a safe CMS workflow will prevent the website from bursting (how expensive would that be for your business?).
Now, this last one is an optional need, meaning not all businesses will need this, and the ones who do might only need this at certain moments.
Sometimes, landing pages and other forms of web content have exceptional functionality. Raw Revelations, for instance, required a unique integration between DEAR inventory and BigCommerce. As another example, Trivie needed a landing page with an app-like feature that allowed visitors to drag and drop KPIs within the page. The fact is that some scenarios, which will depend on your marketing strategies and the organization's nature, will need a CMS workflow that allows your developer's team to have server-side control. If you feel this need does not speak to you, then you probably don't need to consider it (which is why I tagged it as optional).
First of all, let's get a couple of things clear:
On the one hand, this is not about CMSs competing against each other. Instead, it is about workflows that can be set up with certain CMSs, and your business might benefit from one over the other depending on your current scenario and tomorrow's needs. So please do not read the following as a CMS vs. another CMS.
On the other hand, most of the following recommendations allows marketing teams to solve the needs stated above:
Webflow's editor is good for creating repeatable content (blog posts, podcasts, etc.). But landing pages need flexibility, and the Editor interface doesn't allow that. It means Webflow is not the top CMS for editors and marketing content managers.
How to work this around? The way Webflow offers to acquire more flexibility is to use the Designer interface, which allows marketers to mix and match blocks from a library. Yes, it is more complex than the one meant for editors since it is made for creating UI from scratch. But using "Components" (formerly "Symbols") can get this from impossible to decent. One can have designers/developers build a library of blocks in Webflow, then have them structured as "Components". Editors will then be able to pick up such components for creating pages: they will have an interface to edit their content without being at much risk of breaking things apart (I stress the "much risk" part since there is indeed a risk to do so).
What are the pros of Webflow? First, marketing content managers and editors can use a library of "Components" to reuse sections and build what they require. Second, a business can start setting up Webflow as its CMS, then escalate to another CMS and keep Webflow as part of the equation, so no work will be lost if escalating.
What are the cons? First: the workaround above is to be made on an interface meant for web designers, not marketers. It is not simple, intuitive, or free from the risks of damaging parts of the website. However, landing page creation will work beautifully if your marketing team learns to deal with this. Second: there is a hard limit of 100 static pages. Third: no server-side access.
Something to note, though: at the time of this writing, Webflow's announcement aims (my interpretation) to allow editors to create landing pages by reusing components. Such a potential update looks promising and would eliminate the two first cons mentioned on this platform.
My take on Webflow? As for today, despite the platform cons, a proper workflow of using a library with reusable components can be a heavy-duty machine for content management for marketers. And even with its cons, Webflow is not only a CMS but also an HTML builder, so if it escalates in the future, you will not find it was a lost time to set up your library in Webflow. More on that later in this article.
The cons of Webflow are solved with Hubspot. Hubspot allows developers to integrate their own "components" with the platform. So all of the blocks built in Webflow can be taken into Hubspot. A standard Workflow consists of using Webflow to create components, then having developers make them available for marketing people in Hubspot.
Another advantage of Hubspot is that it does not have a 100 pages limit on the number of static pages.
The third advantage of Hubspot is the ability to do backend code, which is helpful for complex landing pages or website content that requires that.
Finally, there is the "Hubspot" advantage. If your business already uses Hubspot, it makes sense to profit from its CMS capabilities. Hubspot, by itself, is a box of goodies for marketers. However, outside of the Hubspot ecosystem, consider the approaches I will mention in the following paragraphs: I see no immediate reason to use Hubspot as a CMS if your organization does not use Hubspot for marketing and sales.
If you have yet to hear about headless CMS, they are CMS that separate the infrastructure for content management from the website itself. Imagine the site is the body, and the content is its head: take the head away, and there you have the wording for "headless". From a technical standpoint, you can have editors edit content in the headless CMS, which could be loaded up anywhere: your server, a mobile app, or even on Webflow. This brings enormous flexibility for escalating, which is why big companies use this approach: Digital Ocean, Nike, reMarkable, Figma, and Condé Nast, to mention a few. There are no limits on what can be built regarding visuals, functionality, or the number of publications.
Given such a quick intro, let's talk about Primsic.
It is a headless CMS. How to build a library of reusable blocks works the same as with Hubspot: have designers and developers create blocks in Webflow and then integrate them into the Primsic CMS (in this scenario, Webflow is only used to build, not for content management). Once blocks are integrated into Prismic, marketers can reuse them and mix them to create strategic content.
Also, like with Hubspot, content editors will have covered all the necessities I established earlier: reusable sections, branded design, a simple interface, and server-side control.
What are the differences with Hubspot, then?
Hubspot is a group of marketing services, among which is the CMS hub. Prismic, on the other hand, is pure CMS. As a result, we can expect Prismic to be a more complete, robust, and scalable CMS overall. For example, on Prismic, we can structure complex dynamic content (blog posts, articles, podcasts, products) on Prismic, which means a more powerful assembly line for engaging pages, articles, and any other type of content.
Also, Hubspot has a proprietary code language to work with. In contrast, on Prismic, developers can write code in their preferred language and have control over the server stack they decide to establish.
Finally, and obvious but worthy of being highlighted: Hubspot is not headless, while Primsic is. As mentioned, if already in the Hubspot ecosystem, consider it in the decision-making table (I am saying only to consider it, not to go for it straight away, since there are variables that organizations should consider before deciding on one in specific).
It is also headless, just like Prismic is. And when it comes to marketing teams, it is just as good and an equally good alternative to Prismic.
If Prismic and Strapi are both headless, what is different between them? First, Strapi is open source and allows developers even further flexibility in setting up the CMS. Also, Strapi can be self-hosted, which might be necessary for some enterprise organizations.
Should you go to Prismic or Strapi? Either alternative would be safe, and only specifics to your organization may determine which is more convenient.
Just like Prismic and Strapi in terms of being a headless CMS but even more flexible. It is slightly different from the former regarding content architecture for developers. And when it comes to marketers, it is as equally good as the other headless systems.
Should you go with Sanity instead of Prismic or Strapi? Taking either of the three headless alternatives is a safe bet. Only key organizations' requirements could determine whether one is more convenient.
Let's recap.
First, having a library of reusable components means marketers have an efficient assembly line for creating engaging pages, articles, posts, and other types of content. All of the CMSs in this article fulfilled this necessity.
Second, marketing teams need to have these library components to match their brand, be visually appealing and engaging, and at times be custom and complex. Again, all of the mentioned CMSs tick this box.
Third, avoiding dependability on design and development processes to create pieces of content is another requirement for successful marketing teams. These CMS suggestions are based on design and development efforts being done ONCE for adding one new block to the library that marketers would use. From then on, marketers use these blocks in their library without any design and development efforts involved. Once more, all of the former CMSs tick this box.
Fourth, the workflows should also allow marketers an easy and accident-free interface. Again, Webflow can do this partially, whereas all the other CMSs accomplish this with flying colors.
Finally, some businesses may need, at some point, to have backend control. The only CMS on our list that didn't allow this is Webflow (I mean, not at all). Then there is Hubspot allowing this with limitations. And then there are Prismic, Strapi, and Sanity, permitting absolute backend control (these are built with that premise in mind).
Well, that is a complex question to answer. Every business has its own needs, and needs vary at each point of the growth of an organization. However! Here are some general thoughts:
This is because Webflow is both a CMS and an HTML builder. Therefore, if you choose to use Hubspot, Strapi, Prismic, or Sanity instead of Webflow, you will still use Webflow to construct new blocks for the library.
That's my advice. That's how deciding correctly or wrongly on your organization's CMS can move things around! Thanks for reading <3.