Your CMS Is Only As Good As Your Workflow: Setting Up Content Operations That Scale

The one person keeping the website from falling apart

Most organizations have one. The person who reviews every page before it goes live. The one who fixes the heading hierarchy after a department admin accidentally makes three things bold and calls them headings. The one who gets a Slack message that says "the homepage looks weird" at 7pm and knows exactly which well-meaning colleague published over a template with a wall of unformatted text.

This person is not a bottleneck. They're a symptom.

They exist because the CMS was set up without a workflow. Without defined roles. Without templates that guide contributors toward the right output. Without the structures that make it hard to publish badly and easy to publish well.

Removing that person from the critical path doesn't mean lowering standards. It means moving the standards upstream, into the system, so that multiple contributors can produce consistent, on-brand content without every piece passing through one set of hands for cleanup.

That's what content operations actually means. And most organizations are one staff departure away from realizing they don't have any.

What content operations is (and what it isn't)

Content operations is the combination of people, process, and tooling that makes content production repeatable. It is not a job title. It is not a platform feature. It is not something that happens automatically when you upgrade your CMS.

It is:

Knowing who is allowed to publish what, and configuring your system to enforce it

Having templates that encode your style and structure standards directly into the editing interface

Building approval flows so that the right people review content before it goes live, without requiring them to stay up until midnight doing it

Making the correct path the path of least resistance for contributors

The goal is not control for its own sake. It is consistency at scale. When your organization has five content contributors, informal coordination works fine. When you have fifteen, across four departments, with turnover every few years, you need the system to do the coordinating.

Step 1: Map your contributors before you configure anything

Every CMS decision about roles and permissions lives or dies on how well you understand who is actually creating and managing content. Don't start in your platform settings. Start with a spreadsheet.

For each person who touches content, capture:

|---|---|---|---|---|

Fill this in for your whole team before you open your CMS settings. Two things will immediately become obvious:

You probably have more content contributors than you think.

They have very different levels of trust, accountability, and technical comfort.

Those differences should map directly to different roles in your system. If everyone has the same level of access, your "workflow" is just hoping for the best.

Step 2: Configure roles that reflect real accountability

Every major CMS supports some version of role-based access. The default roles (Administrator, Editor, Author, Subscriber in WordPress; similar structures in Drupal and headless platforms) are a starting point. They are almost never the right structure for your organization as-is.

The goal is to match system permissions to real-world accountability. Here is a practical four-tier model that works well for most mid-sized organizations:

Tier 1: Contributor

Who: Department staff, subject matter experts, anyone who creates content but should not publish it directly.

Can do:

Create and edit draft content in their assigned section

Upload images and documents

Submit content for review

Cannot do:

Publish content live

Edit content outside their assigned section

Delete published content

Change page templates or structural elements

Why this tier exists: Most content accuracy problems come from department contributors who publish things directly because they can, not because they should. Moving them into a Contributor role removes that failure mode without removing their ability to contribute.

Tier 2: Section Editor

Who: Communications generalists, department leads, anyone accountable for a defined section of the site.

Can do:

Review, edit, and publish content submitted by Contributors in their section

Create and publish their own content

Manage media within their section

Schedule content to go live at a specific time

Cannot do:

Publish to sections they don't own

Change site-wide settings or navigation

Create or modify content templates

Tier 3: Publisher / Web Manager

Who: Your web lead, digital communications manager, or the person currently doing all the cleanup.

Can do:

Publish to any section of the site

Manage navigation and site structure

Create and modify content templates

Access analytics and audit logs

Override or escalate content that fails review

Cannot do:

Change platform configuration or user management (that stays in Tier 4)

Tier 4: Administrator

Who: IT lead, web developer, platform owner. One or two people maximum.

Can do: Everything. Including breaking things.

Why keep this tier small: Administrator access is not a reward for seniority. It is a liability. Every person with admin access is a potential source of unrecoverable changes. Keep this tier small and intentional.

Map your contributor spreadsheet to these four tiers. Wherever you have a mismatch (a low-trust contributor with Publisher access, a department head with Administrator rights because IT set them up that way in 2019), that's where your content quality and security problems are coming from.

Step 3: Build approval workflows that match your risk tolerance

Not all content carries the same risk. A typo in a recreational program description is annoying. A typo in a permit fee schedule is a liability. Your approval workflow should reflect that difference.

A practical three-track model:

Track A: Publish directly (low risk)

For: experienced Section Editors and Publishers working in lower-stakes sections (event listings, staff bios, news items with short shelf life).

Process: Create, self-review, publish. No approval gate.

Safeguard: audit log so changes can be traced and reversed.

Track B: One-stage review (medium risk)

For: Contributor-created content, new page types, updates to high-traffic service pages.

Process: Contributor creates draft → Section Editor reviews and edits → Section Editor publishes or returns with notes.

Turnaround expectation: 48 hours for non-urgent content. Define this and tell your contributors upfront. The most common source of workflow frustration is not the review itself: it's not knowing when to expect a response.

Track C: Two-stage review (high risk)

For: Legal disclaimers, fee and tax information, policy pages, anything with regulatory implications.

Process: Contributor creates draft → Department lead reviews for accuracy → Web Manager / Publisher reviews for standards compliance → Publisher publishes.

Turnaround expectation: 5 business days. Again: define this. Put it in your editorial guidelines. Undocumented workflows become ad hoc workflows the moment the person who built them leaves.

Setting this up in your CMS:

Most platforms handle this through a combination of user roles and content status fields. In WordPress, this looks like custom statuses (Draft → Pending Review → Approved → Published) typically via a plugin like PublishPress. In Drupal, the Content Moderation module handles this natively. In headless platforms like Contentful, you configure editorial workflows in the space settings.

Wherever you're building it: document the expected flow as a one-page diagram and publish it somewhere your contributors will actually find it. A workflow that lives only in someone's head is not a workflow.

Step 4: Build templates that make the right thing the easy thing

Templates are where content operations become real for your contributors. A good template doesn't just provide a blank canvas. It provides guardrails. It makes the expected structure visible so that contributors don't have to remember your style guide while they're trying to explain how to apply for a parking permit.

What a content template should do

Pre-populate structure: headings, field labels, placeholder text that shows contributors what goes where

Constrain format choices: limit heading levels to the ones that make sense for that content type, not all six

Include inline guidance: brief instructions inside the fields explaining what good content looks like here ("Write 1-2 sentences explaining who this service is for and what it costs. Plain language, no jargon.")

Surface required fields: make it impossible to save a page without a page title, meta description, and at least one content section

Include a review checklist: a simple checkbox list at the bottom of the editing interface that contributors complete before submitting for review

Template examples by content type

Service page template:

Page title: [Plain-language name of the service]
Meta description: [1-2 sentences. Who is this for? What can they do here? 120-160 chars.]

--- OVERVIEW ---
What this service is: [1-2 sentences. Start with the resident's need, not the department's mandate.]
Who can use it: [Eligibility in plain language. Use a short bulleted list if there are multiple criteria.]

--- HOW TO APPLY / ACCESS ---
Step 1: [Action verb + what to do]
Step 2: [Action verb + what to do]
[Add steps as needed. Max 7 steps before this should become a separate guide page.]

--- WHAT YOU NEED ---
[ ] [Document or information required]
[ ] [Document or information required]

--- FEES ---
[Fee name]: $[amount]
[If fees vary, link to the fee schedule page rather than listing all here.]

--- CONTACT ---
Department: [Name]
Phone: [Number]
Email: [Address]
Hours: [Days and times in plain language]

--- REVIEW CHECKLIST (complete before submitting) ---
[ ] No jargon or unexplained acronyms
[ ] Active voice throughout
[ ] All fees are current as of [date]
[ ] Reviewed by [department] subject matter expert
[ ] Accessibility: all images have alt text, links have descriptive text

News / announcement template:

Headline: [What happened, in plain language. Max 65 characters.]
Date: [Publication date]
Category: [News | Public notice | Event | Service update]

--- SUMMARY ---
[1-2 sentences: the essential who/what/when/where. Write this for someone who reads nothing else.]

--- BODY ---
[Lead paragraph: expand on the summary. Most important information first.]
[Supporting paragraphs: context, background, details for readers who want more.]

--- NEXT STEPS FOR RESIDENTS ---
[If residents need to do something, say what. Be specific. Include deadlines.]

--- RELATED LINKS ---
[Link 1: descriptive anchor text]
[Link 2: descriptive anchor text]

--- REVIEW CHECKLIST ---
[ ] Proofread by author
[ ] No em dashes or en dashes
[ ] All external links verified
[ ] Reviewed by [name] on [date]

Event listing template:

Event name: [Plain-language name]
Date(s): [Start and end date, or recurring pattern]
Time: [Start - End, with timezone]
Location: [Full address + room/area name if applicable]
Cost: [Free | $ amount | Registration required (link)]

--- DESCRIPTION ---
[2-3 sentences: what happens at this event and who it is for. Write for someone who has never attended.]

--- REGISTRATION ---
[How to register, or "No registration required"]
[Deadline if applicable]
[Contact for questions]

--- ACCESSIBILITY ---
[Confirm or describe accessibility features: step-free access, ASL interpretation, etc. Do not leave blank.]

These templates don't guarantee great content. They do eliminate the most common structural problems, which is the goal. You can't template your way to compelling writing, but you can template your way to consistent headings, populated meta descriptions, and forms that include an accessibility field by default instead of as an afterthought.

Step 5: Make the workflow visible and maintainable

The structures you've built in the previous four steps are only valuable if your team knows they exist and knows how to use them.

Document everything in one place: A single internal content guide, accessible to all contributors, that covers your role definitions, your three workflow tracks, your templates, and your style standards. Not a 60-page policy document. A 3-page reference that someone can read in ten minutes and refer back to.

Run a 90-minute onboarding session for new contributors: Walk them through the CMS, the templates, and the workflow. Have them create and submit a test piece of content before they touch anything live. This is the difference between a contributor who knows what they're doing and a contributor who figures it out on a live page.

Review the system twice a year: Your contributor list changes. Your content strategy changes. Templates that made sense in year one may not match your current needs. Set a calendar reminder to spend two hours reviewing your roles, workflows, and templates every six months. The things that need updating will be obvious.

Audit your audit logs: Most CMS platforms log who published what and when. Review this quarterly. You will find contributors who are bypassing the approval flow, template fields that are being left blank consistently (a signal that the template need adjusting), and content that hasn't been touched in two years and should be reviewed for archiving.

The before and after

Here is what content operations looks like in practice, before and after:

Before:

Eight contributors, all with the same Editor-level access

Content goes live the moment someone hits publish, day or night

Formatting inconsistencies caught during a weekly manual review by the web manager

New contributors learn the style guide by asking the web manager questions

The web manager is the single point of failure for content quality

After:

Contributors, Section Editors, and a Publisher, each with scoped permissions

High-risk content routes through a two-stage review before it can go live

Templates make structural errors unlikely before content reaches a reviewer

New contributors complete a 90-minute onboarding session and publish a test piece first

The web manager reviews the audit log quarterly instead of every piece of content individually

The web manager is still there. They're just doing strategic work instead of perpetual cleanup.

Ready to set up content operations that scale without everything running through one person? Get in touch for a workflow audit and a practical implementation plan for your team.