The evolving role of a CMS in content creation
When teams are remote and distributed, a content management system should be a place for content analysis, creation, experimentation, and collaboration, not just publishing.
When we talk of “content creation,” we usually mentally register the start of that process when a finger hits the keyboard. When we open our CMS, select “New Content” and start typing, that is when we believe we’ve started "creating content."
This is short-sighted. The process starts earlier than that, we've just unconsciously correlated it with the involvement of our CMS. We've mentally substituted the word "management" with "publishing," and we're worse for it.
This becomes even more important with people working from home, and teams naturally distributing, the CMS needs to become a central rallying point.
Years ago, I claimed that someone only ever opens their CMS at the 85% point. If 0% is when someone thinks, “We should put some new content on the website,” and 100% is when they press “Publish," then normal usage of a CMS only encompasses that last 15%.
This should change. We should stop looking at a CMS as tool for content publishing, but perhaps rather consider it a tool for content collaboration. We should stop counting on our CMS only for the last mile.
Episerver has specific tools and features that make this easier. But first let’s consider all the things that happen with content prior to someone ever opening their CMS, through the lens of Gabrielle, a web manager.
Gabrielle is saddled with an older CMS that her group depends on only for publishing content, not for the dozens of other tasks that constitute a holistic "management" of content.
The CEO has noticed that the conversion rate on the website is down. She doesn’t understand why no one has brought this up before. And why isn't there any content about Topic X? The CEO was at a conference last week, and all anyone could talk about was Topic X, but the website barely mentions it.
Gabrielle spends her morning browsing through the analytics on the website, and manually corresponding that to her Google analytics. She notices that bounce rates are through the roof. She knows she should have checked this sooner, but it's tedious and not top-of-mind.
Gabrielle asks every member of her team to look through the websites of their competitors. John comes back showing how Competitor X seems to be leveraging the Topic X the CEO mentioned. Fred dusts off their inbound search terms report and finds lots of traffic for Topic X.
Gabrielle, John, and Fred sit around and discuss the possibility of creating some new content about Topic X. In the next few days over Slack, they continue to talk about Topic X. The conversation starts and stops among all the other communication flying around Slack. For a couple weeks, the ideas remain half-developed.
After the team finally arrives at some concept of structure, John cracks open Microsoft Word and writes some content that might fit. It doesn’t look at all like it would on the website, but it sort of gets the point across.
The team passes this document around and continues to refine it clumsily through Slack updates and comments in the Word file. It gets accidentally duplicated a couple times, and no one is totally sure if they're looking at the latest version, but they eventually hammer it out.
Once they have a Word doc that reasonably approximates their content, they send it to the CMO. She doesn’t understand what she's looking at, and they have to explain they would convert it into a web page, and how the attached images would fit into it. After much back-and-forth, and a couple office visits, she finally greenlights it.
John sets aside a morning to log into the CMS and recreate everything, hoping he gets it right, and knowing that once he has the content created, he’s going to have to go through the entire review and approval process all over again...
This is just how it goes in most organizations. Content collaboration is an ad-hoc process, and active use of the CMS is considered the final stage. Opening the CMS is the thing you do after you’ve done everything else. It's only the part of the iceberg that's above the waterline.
At Episerver, we’re pushing to bring your CMS further forward in that process.
- What if your CMS was used not just as the end stage tool, but as a key component of the process all along?
- What if your CMS was an ideation platform that help you make decisions about new content creation?
- What if your CMS was a big whiteboard onto which you could sketch and try out ideas?
- What if your CMS was designed for distributed teams to collaborate, rather for a single user to create?
Let’s consider the story of Gabrielle and her team again, this time using the entire suite of Episerver tools.
Using Episerver Content Intelligence, Gabrielle has a constant stream of data points about content consumption versus content volume. She sees early that the content around Topic X is out of balance. A lot of user sessions are consuming what content is available, but demand for content far outstrips the supply.
Using Episerver’s dashboard UI and Google Analytics integration, Gabrielle also notices the bounce rate problem. She has added multiple visual gadgets side-by-side, in one place, to do content analysis. Additionally, a sidebar gadget in the Episerver UI highlights the problem on every page she visits. Episerver draws all these sources together into one reporting location.
Using Episerver Projects, Gabrielle creates a new workspace for “Q2 Content Ideas.” She browses the site and adds content to the project as items that need to be examined in light of the new content need.
Instead of discussing abstract ideas, Fred and John simply create proposed content that gets automatically added to the project. They sketch out article and page ideas by creating them in-context. Episerver Projects enables an embedded content discussion which is about the conceptual project as a whole or can splinter into smaller discussions about individual items of content.
Comments are targeted to specific team members using @-style mentioning. Using Episerver’s pluggable notification system, any notes on content are broadcast into other channels as necessary. For example, Fred and John can tag Brian, their graphic designer, to review content for potential media integration.
Episerver’s editing tools relax the barrier to entry of creating content. Episerver content can delay validation until publication, so John and Fred stub out content freely, trying out new ideas, and keeping only what works. At any time, content might simply be a shell of the final product, and the team simply keeps coming back and fleshing them out as ideas come to them.
Episerver allows asset-scoping, so images and other added media are tied to the lifecycle of a single content item. John and Fred aren't worried about creating content that might not survive the brainstorming process. If a content item isn’t working out, every trace of it is be easily be removed without cluttering up the repository with orphaned assets.
With Episerver’s in-context content editing, the content is created and previewed as it would appear in the final version. Fred and John can try out new ideas, before @-mentioning Gabrielle in their comments and dropping "pins" to specific locations on the page, asking for feedback and for her to add her own edits.
When ready for review outside the team. Episerver provides unique external-review URLs which are be sent to the CMO, CEO, and other people in the company who don’t have an Episerver account. The recipients simply click on a self-expiring URL and view the content as it would appear when published.
When all the content is ready to go, Gabrielle submits it all for publication from the Projects interface. Each content item proceeds down its assigned approval chain. Some approvals are by specific people, and some are by a delegate within a group of people. Some approvals designate content as ready to publish, and others just move the content to the next stage in a chain of approvals.
Formal approvals are tracked in an audit log, and rejections can be commented on and resubmitted. All along, Gabrielle follows the state of the content in her Project from a single interface. When all content in the Project is ready for publication, Gabrielle sets a future publication date for all Project content to coincide with the company’s social media campaign.
(Want to see all of this in action? Scroll to the bottom of this article for a recorded webinar demo.)
Notice that Episerver has not just been a tool for content publication, but it's the core thread running through the entire process of discovery, analysis, experimentation, and production. In fact, at the conclusion of our story, none of the content has been published, yet Episerver has been the single location for all applied work.
"Management" isn't the same as "publishing." Episerver believes that management is a holistic discipline that precedes and envelops the comparatively simple act of publishing.
Let's face it, some ideas don't work. With Episerver, it's easy to try new things, gather feedback, and continue to develop them with the input of your entire team. The system allows editors to develop content inside a virtual workspace, keeping only what works.
This is how it should be. Too many organizations have a deeply formal relationship with their CMS. It becomes a frightening place that they approach with fear and trembling, only when they think their content is finally good enough to rate publication.
Let's move to a world where our CMS is a safe space for play and experimentation, where teams can work together to make better content faster. Some things will work, and some things won't, but being able to iterate faster and more effectively will help us find that answer.
Lest you think this article was hypothetical, know there's an unpublished page in this CMS right now that I started writing three weeks ago. I keep coming back to it every couple of days, tweaking and testing new ideas with it. I'll admit that it wasn't very well thought out at first, but it's getting better.
Occasionally, I send it to people either in the CMS, or through external review URLs. They tell me it's coming along, and I'm 90% sure it will make it to publication.
If it doesn't work, that's fine. Honestly, I created it with the intention of trying something out. If I can't make it work, I'll simply delete it, which will remove all the drafts and media I've attached to it.
I'm using my CMS as a big whiteboard. It's a low-overheard, low-risk, high-feedback environment, optimized for the creation and collaboration of content.
See These Features in Action!
Watch Director of CMS Strategy Deane Barker and Solution Architect James Stout give a hands-on demonstration of these features in a recorded webinar.