Skip to main content
Shakewell

Checklist

The Structured Content Readiness Checklist

Sixteen symptoms, three groups. Score honestly: every one of these is something we've watched a real publishing operation live with — and none of them is a people problem.

Part 1

Authoring symptoms

What it feels like to write and edit when the tools have been outgrown.

  1. Your biggest documents crash, corrupt, or take minutes to open.

    The single-file model is past its limit. Large documents need to be aggregates of managed pieces, not one fragile monolith.

  2. Charts and tables are pasted in as images to keep files stable.

    Your most expensive content — the data — is being flattened into pixels in self-defense. The publication of record carries souvenirs of the numbers, not the numbers.

  3. Co-authoring produces conflict warnings nobody can trace to a person or a change.

    Simultaneous editing without real version control. You need branches, merges, and conflict routing — not paragraph locks and hope.

  4. Numbering is maintained by hand, and 6.1 is sometimes followed by 6.5.

    The template is advice, not enforcement. Structure that matters must be held by the system, not by the most careful person in the room.

  5. One person is the unofficial help desk for the big documents.

    A tooling deficit has been converted into a human role. That person's calendar is the truest measure of what the current stack costs.

Part 2

Version and governance symptoms

Many versions of the same controlled item
Eight files named _FINAL_v3_amended are not a version history — they're a symptom.

What happens between draft and approval.

  1. The same document exists as eight or nine near-identical files distinguished by filename suffixes.

    Versions are being managed by convention. You need supersession as a system property — one document, one place, its whole timeline intact.

  2. A future version must not be visible before its start date, and today that's enforced by a calendar reminder.

    Effective-dated publishing is a solved problem. Commencement should be executed by the clock, not by a person at midnight.

  3. People edit past the pens-down date, and you find out later.

    Freezes are requests, not states. Workflow gates should lock the version at the deadline and record any authorized exception.

  4. Sections only certain people may touch are protected by asking nicely.

    Responsibility is divided by section and role, but the tooling only knows whole files. Permissions need to attach where accountability lives.

  5. "Who changed this clause, and when?" takes an email archaeology project to answer.

    No audit trail at the level that matters. Regulated publishers eventually get asked this question with a deadline attached.

Part 3

Publishing and delivery symptoms

What happens between approval and the reader.

  1. Publishing means Word, then InDesign, then PDF, then a CMS upload — and corrections queue up because re-running the line is expensive.

    The assembly line problem. Single-source publishing turns presentation into a rendering step and makes a correction a same-day event.

  2. Documents live in the website CMS's media library.

    A page tool is being used as a document platform. Versions, permissions, and document search all need a system that has them.

  3. Files over the CMS's size limit go to an external developer for backdoor upload.

    Distribution has already escaped your governed channels. Whatever route the big files take, the audit trail doesn't follow.

  4. The web version and the PDF version of the same document quietly disagree.

    Two hand-maintained renditions with no common source. Only one of them can be the document of record — and readers can't tell which.

  5. Integrations, partners, or AI projects keep asking for your content "as data" and there's nothing to give them.

    Delivery is interface-only. Machine consumers need addressable, permission-scoped APIs — the content services platform gap.

  6. Accessibility remediation is a separate per-document project, every time.

    Meaning lives in the formatting, so every assistive-technology fix is manual. Structured content passes most of it as a by-product.

Reading Your Score

Clusters, Not Counts

A couple of symptoms in one group is a workflow problem; symptoms across all three groups is an architecture problem, and patching them one at a time just moves the pain. The deeper pattern to notice: every item on this list traces back to the same root — documents managed as files in a world that needs them managed as structured, addressable content. That's also why the fix sequences so well: delivery first, then authoring for the worst document families, then the rest on their own revision cycles. Our enterprise and regulatory publishing practice exists to run exactly that sequence.

FAQ

Questions We Hear

How many symptoms should worry us?

It's less about the count than the clusters. One or two symptoms in one group usually means a workflow fix inside your current tools. Symptoms across all three groups — authoring, governance, and delivery — mean the estate has structurally outgrown the file-based model, and patching any single symptom will just move the pain. In our experience organizations that recognize five or more are already paying more in workarounds than a structured platform would cost.

Which symptoms are the most urgent?

The governance ones, because they carry liability rather than inconvenience. An unenforceable pens-down date, missing clause-level audit trails, and future versions protected by calendar reminders are all fine until the day they aren't — an audit, a dispute, a leaked commencement. Authoring pain costs time; governance gaps cost trust, and occasionally lawyers.

Does fixing this mean replacing everything at once?

No, and the big-bang replacement is usually the wrong plan. The stable sequence we see: put delivery right first (a platform that owns published documents, their versions, and their APIs — legacy PDFs can be ingested as they are), then move authoring for the document families with the worst symptoms, then let the rest follow on their own revision cycles. Each step pays for itself independently.

What's the first concrete step?

An audit that maps your document families against these symptoms: which documents, which volumes, which workflows, which failures. That's typically a short discovery engagement, and it produces the thing executives actually need — a ranked list of where structure pays first, with the licensing and migration costs attached to real numbers instead of vendor decks.

Get In Touch

What Did You Score?

Five or more, and the workarounds are already costing more than the fix. A short discovery engagement turns this checklist into a ranked plan with real numbers.