Key takeaways
- Most modular content pilots stall on the same four problems: building the library, keeping it up to date, localizing it for markets, and getting local teams to actually reuse it.
- Nearly 80% of approved pharma content is rarely or never used in the field (Veeva Pulse), while roughly 80% of marketing spend goes to originating new concepts and only 20% to derivative content (Indegene). Modular content exists to fix both imbalances.
- A module is more than a claim. Treat it as a structured unit: claim header, supporting evidence (text and visual), non-medical glue text, reference links with cite text, and footnotes.
- The critical success factor is not the module library — it’s the content authoring solution (CAS) on top of it. Without self-service authoring and end-to-end automation, “modular content” is just agency assembly with extra steps.
- Localization decides scale. If translating a module still requires an agency to redo charts, tables, and graphs, global-to-local remains a bottleneck.
Modular content is one of the most discussed ideas in pharma content operations — and one of the least successfully implemented. Nearly every large pharma company has run a pilot. Very few have turned that pilot into an operating model where local teams routinely assemble compliant content from pre-approved modules.
This article lays out what a modular content strategy actually needs to cover, why most initiatives stall, what a module really is (it’s more than a claim), and the success factors we see across implementations at global pharma companies. If you’re looking for the basics first, start with our explainer on modular content in pharma — this piece assumes you know the definition and want the operating model.
What is a modular content strategy?
A modular content strategy is the operating model that turns approved content into reusable, pre-approved modules — and gets those modules actually used across channels and markets. It covers five things: how modules are defined and structured, how the library is built and maintained, how governance splits responsibility between global and local teams, which platform makes modules accessible to authors, and how reuse is measured. The strategy is not the library. The library is an asset; the strategy is everything that makes the asset productive.
The problem modular content is supposed to solve
The economics of pharma content are lopsided, and the data is consistent across sources:
| Finding | Source |
|---|---|
| Nearly 80% of approved content is rarely or never used by field teams | Veeva Pulse Field Trends Report, 2025 |
| Content production rose 7% globally and 29% in the US in 2023, and the pace isn’t slowing | Veeva, MLR/AI research |
| ~80% of pharma marketing spend goes to originating new concepts; only ~20% to derivative content at scale | Indegene |
| Pre-review processes add 5 to 150 days per asset before MLR even starts | Veeva |
| A typical global-to-local waterfall takes 7–8 weeks per marketing asset; automated modular content can cut this to 3–4 weeks | Indegene |
| Content-driven HCP engagement more than doubles new treatment starts | Veeva Pulse |
Read those together and the picture is clear: pharma produces more content than ever, most of it goes unused, the spend sits at the wrong end of the funnel, and the content that does work — content shared in HCP interactions — is proven to drive treatment adoption. Modular content promises to invert the 80/20: spend on strategy and origination once, then produce derivatives cheaply, quickly, and compliantly.
So why do so many pilots stall?
Why most modular content pilots stall
In practice, modular content initiatives fail at one of four gates. Each gate is harder than the one before it.
1. Creating the library. Breaking approved assets into modules is slow, manual work: identifying claims, linking references, writing cite text, classifying content. Many programs burn their budget here and never get further. The teams doing the work are often agencies, which means the library is built at agency speed and agency cost.
2. Keeping the library up to date. A claims library is not a one-time project. Labels change, new data reads out, references get superseded. Without a maintenance process — and tooling that makes updates cheap — the library decays, and authors stop trusting it. An untrusted library is a dead library.
3. Global-to-local: localizing the library. A global module library in English is of limited use to a brand team in Japan, Brazil, or Germany. Modules need translation, local regulatory adaptation, and — the part everyone forgets — localization of visual components. Translating text is easy; a chart with English axis labels still needs a designer.
4. Local teams actually using it. This is where most programs quietly die. If reusing a module still means writing a brief, sending it to an agency, and waiting for assembly, local teams will do what they’ve always done: brief the agency to build the asset from scratch. Reuse only happens when it’s the path of least resistance.
The anti-pattern: a global team builds a module library in Veeva PromoMats, announces it to markets, and measures “modules created.” Eighteen months later, reuse is in the single digits. The library was built; the operating model wasn’t.
What a module actually is (hint: more than a claim)
Many programs start from a claims library and treat a module as a single approved statement. That’s too limited. A claim on its own isn’t usable content — it’s an ingredient without a recipe. In real assets, a claim travels with evidence, visuals, references, and connective text. A module should reflect that.
Here’s the anatomy we recommend:
| Component | What it is | Example |
|---|---|---|
| Claim header | The core approved statement | “Product X reduced exacerbations by 57% vs. placebo” |
| Supporting evidence (text) | Approved copy that substantiates or contextualizes the claim | Study design summary, patient population, endpoints |
| Supporting evidence (visual) | Charts, graphs, tables, MoA imagery tied to the claim | Kaplan-Meier curve, forest plot |
| Non-medical supporting text | Headers, captions, transitions — the glue that makes a module render as content, but carries no medical statement itself | Section header, image caption |
| References + cite text | Links to the underlying references with correctly formatted citation text | “Smith et al. NEJM 2024;390:123–34” |
| Footnotes | Cited and non-cited footnotes attached to the module | Study limitations, abbreviation expansions |
Defined this way, a module is a self-contained, pre-approved unit that an author can drop into an email, a detail aid, or a landing page — with claims, evidence, and referencing intact. That’s what makes derivative content fast and review-ready.
Working with the Veeva Content Modules model
Veeva Vault PromoMats’ Content Modules is the de facto industry standard for storing modules, and it’s a solid foundation. But the out-of-the-box model has limitations worth knowing. Some can be worked around with custom fields; others genuinely require the authoring layer on top:
| Out-of-the-box gap | Why it matters | How to address it |
|---|---|---|
| No rich text for citations, bullets, superscripts (markdown support is no longer available out of the box) | Cite markers and formatting get lost or hand-rebuilt per channel | Possibly a custom field with a markdown convention — but rendering still depends on the authoring layer |
| No layout classification (H1–H5, body, caption) | The same text needs different treatment in email vs. web vs. detail aid | Add a custom layout-class field so each channel can render correctly |
| No native persona/segment versions | A brand-benefit module often needs different framing per audience | Model audience variants via custom fields or related modules |
| No enforced cite-text format | Inconsistent referencing across markets and assets | Define an official cite-text standard and store it in a custom field |
| Footnotes are not an object | Footnotes get duplicated, drift out of sync, and can’t be reused or governed | No configuration fix — needs a module model where footnotes are first-class, handled in the authoring layer |
| No abbreviations list | Every asset re-solves the same abbreviation problem | No configuration fix — you need an authoring solution that auto-adds abbreviations as authors place modules |
None of these are reasons to avoid Veeva Content Modules. They are reasons to design your module model deliberately before you fill the library — and to recognize which gaps the repository can never close on its own.
The critical success factors
Across the implementations we see at global pharma companies, the programs that scale share the same characteristics.
You need a CAS to make modules accessible. A module library without a content authoring solution is a database. Authors need to search, preview, and place modules inside the channel they’re building for — not copy-paste from Vault into an agency brief.
The CAS must be self-service. If module reuse routes through a briefing-and-handoff process, you’ve automated nothing — you’ve added a step. Reuse rates only climb when the local brand manager or digital lead can assemble a compliant email or detail aid themselves, in minutes, without a production queue. (This matters for adoption too: local teams that own the tool actually use it.)
Everything downstream must be automated. Here’s an uncomfortable truth: Veeva modular content today is often operated by agencies. They still do manual assembly, still hunt through source files, still find references and format cite text by hand. The modules exist; the labor didn’t go away — it just got renamed. Genuine automation means assembly, reference linking, cite-text formatting, tagging, and channel rendering happen in the platform, not in a production studio.
Edited text must keep its pre-approved lineage. Authors will edit module text — a shorter subject line here, a local phrasing there. The failure mode is losing the connection to the approved original, forcing MLR to review from scratch and spawning uncontrolled text variants. The fix: the CAS stores the pre-approved original alongside the edit, preserving the relationship to claims and references, so reviewers see exactly what changed against an approved base.
Localization must include visuals — and work in both directions. Two capabilities separate programs that scale globally from those that stay a headquarters project:
- Duplicate-and-translate including visual components. Translating module text is table stakes. If every chart, graph, and table still needs an agency round-trip for the localized version, global-to-local stays slow and expensive. Shaman is currently the only CAS that localizes visual components alongside text.
- Extraction from locally approved assets. Most markets already have a locally approved detail aid — the “bible of claims” for that market. Shaman can extract its content and turn it into structured modules automatically. Instead of asking each market to rebuild a library from global source, you harvest the library they already had approved. This is unique in the market, and it collapses the time-to-library from months to days.
Measuring the strategy: KPIs that prove it
Novo Nordisk’s commercial operations leadership frames content supply chain performance around five KPIs: use of content, reuse of content, cost of content, quality of content, and time to market. That’s a good starting frame. In practice, we recommend tracking:
| KPI | What it tells you |
|---|---|
| Reuse rate (% of assets built from existing modules) | Whether the library is productive or shelfware |
| % self-service (assets created by local teams without briefing) | Whether the operating model changed, or just the tooling |
| First-pass MLR approval rate | Whether pre-approved modules actually de-risk review |
| Cycle time, brief-to-live | The headline speed metric leadership cares about |
| Cost per derivative asset | The 80/20 inversion, made visible |
| Library freshness (% modules current vs. superseded) | Whether gate 2 — maintenance — is under control |
If reuse and self-service rates aren’t rising within two quarters of launch, the problem is almost never the library. It’s the authoring layer.
How Shaman makes modular content work
Shaman’s modular content capability — Content Cards — is built on the success factors above, working together with three other components of the platform:
- Content Cards are Shaman’s module format: claim header, evidence text and visuals, glue text, references with formatted cite text, and footnotes, structured exactly as described in the module anatomy above. Authors drag them into any channel — email, detail aid (CLM), web, banners — and the module renders correctly per channel, with referencing intact. When authors edit text, the pre-approved original and its claim/reference relations are preserved for review.
- Atlas extraction turns existing approved content — including locally approved detail aids — into structured, machine-readable modules automatically. This is how you build and localize the library without a year of manual harvesting.
- MLR X-Ray structures a full document into its claims, references, and study data, giving reviewers a complete MLR-readiness view of any asset — so derivative content built from modules moves through review in days, not weeks.
- Reference Manager governs the reference layer: correct cite text, current versions, and live links between claims, modules, and their sources — solving the maintenance problem at the root.
Technology alone doesn’t change an operating model. Shaman’s Professional Services team — highly experienced pharma content experts — works alongside customers to set up modular content end to end: defining the module model, building and localizing the library in the CAS, and training end-users so local teams actually adopt self-service authoring.
The result, in customer numbers: content production from 4+ weeks to hours, MLR review from 4+ weeks to 2–3 days with up to 70% fewer review loops, and over 80% active users among local teams — the reuse metric that decides whether modular content is real. Idorsia, for example, went from 3–5 weeks to 3–5 days per asset by bringing self-service production in-house.
A 90-day starting plan
- Weeks 1–2 — Define the module model. Agree the module anatomy (claims, evidence, glue text, references, footnotes), cite-text standard, layout classes, and abbreviation handling. Decide your Veeva Content Modules configuration before creating module #1.
- Weeks 3–6 — Build the seed library from what’s already approved. Extract modules from your best-performing, recently approved assets — ideally per market, from locally approved detail aids — rather than authoring modules from scratch.
- Weeks 5–8 — Stand up self-service authoring for one channel. Pick the highest-volume derivative channel (usually email) and let local teams assemble from modules without briefing.
- Weeks 7–10 — Wire the automation. Reference linking, cite-text formatting, tagging, and MLR pre-checks must run in-platform. If any step still routes through an agency queue, fix it now.
- Weeks 9–12 — Measure and expand. Track reuse rate, % self-service, and first-pass approval from day one. Expand to the next channel only when reuse in the first channel is climbing.
Frequently asked questions
How do you build a modular content strategy?
Start with the operating model, not the library: define the module anatomy, the governance split between global and local, the authoring platform, and the reuse KPIs. Then build a seed library by extracting modules from already-approved content and stand up self-service authoring for one high-volume channel. Expand channel by channel as reuse climbs.
What KPIs measure modular content success?
Reuse rate, percentage of assets created self-service by local teams, first-pass MLR approval rate, brief-to-live cycle time, cost per derivative asset, and library freshness. Reuse and self-service are the two that predict whether the program scales.
Do you need Veeva PromoMats for modular content?
No, but if you’re in pharma you almost certainly already have it, and Veeva Content Modules is the industry-standard place to store approved modules. What PromoMats doesn’t provide is the authoring layer — the self-service CAS that makes modules usable by local teams. That’s where a platform like Shaman comes in, working natively on top of PromoMats.
How long does a modular content implementation take?
A working pilot — module model, seed library, self-service authoring in one channel — is achievable in 90 days, especially if you extract the library from existing approved assets rather than authoring it manually. Scaling across markets typically takes 6–12 months, with localization capability as the pacing factor.
Modular content vs. content reuse — what’s the difference?
Content reuse is the outcome; modular content is the method. You can reuse content ad hoc (copy an old email, adapt it), but without pre-approved, structured modules, every reuse triggers a full review. Modular content makes reuse systematic: the approved building blocks, their references, and their relationships are preserved, so derivatives are fast to create and fast to approve.
Sources: Veeva Pulse Field Trends Report (2025) — content usage and engagement impact on treatment starts; Veeva Content Benchmark — production volume growth; Veeva, “Building the Future of MLR with AI” — pre-review timelines; Indegene, “Agency of Scale” — origination vs. derivative spend; Indegene, “Automated Modular Content” — waterfall timelines; Indegene / PMLiVE, “Re-imagining Content Supply Chains” — Novo Nordisk’s content KPIs; Shaman customer data and the Idorsia case study.
