The backstory—references for content ROI
I did not arrive at this from nothing. Content practitioners have been publishing frameworks for content ROI for years, and most of what Loupe does is an attempt to make that thinking usable in a product context—where the reader is mid-task, not mid-funnel.
Content ROI, argued directly
The structure that makes value traceable
Maturity and operations
Where content decisions belong
What it means
Read together, that body of work is almost entirely about acquisition—traffic, leads, attribution, pipeline. It is rigorous, and it does not transfer. The content inside a product is not trying to attract anyone. It is trying to let someone finish something: choose a plan, recover from an error, understand what a permission does, know which of two buttons ends the session.
When that content fails, the cost does not appear in a marketing dashboard. It appears as an abandoned flow, a support contact, a sign-up that never activates, a rewrite three sprints late. Those are the units Loupe works in.
Two questions, in order—what your team can describe before it writes, and what the writing costs once it ships.
First question: can your team describe its content before writing it?
Before any measurement, Loupe asks which content practices your organisation actually runs—ecosystem maps, content models, taxonomy, customer journey work, stakeholder mapping, content audits, message architecture. Each one is marked as practised, partial, or absent.
This is not a scoring ritual. It changes the advice. An organisation with no content model and no taxonomy will keep paying the same costs after every individual fix, because nothing it learns is retained anywhere. Below a certain maturity the honest first move is modelling, not measurement, and the tool says that instead of handing over a number that would not survive scrutiny.
Systems-level content, and why it is not new
Much of this structural work sits with people whose output is not a screen at all—content models, taxonomy, markup and semantics, schema, the shape an assistant retrieves answers from. It is often called backend or structured content design. The distinction is useful for hiring and misleading for measurement, because the value it produces shows up in other people's numbers.
In 2018 I interviewed Lauren Lucchese, then Head of AI Content at Capital One, for the Content Conversations series. Describing the AI Writer, Narrative Designer and Language Scientist roles on her team, she said they were no longer operating at purely the interface or touchpoint level: We're now working at the systems level, because the AI is going to be making decisions that inform the customer experience.
Her team mapped conversations as Language Trees—branches for every direction a conversation might take, given customer input and context. A content model, owned by content people, consumed by engineers.
The argument was never missing—the structure for making it was.
What maturity changes
At the lower levels, the measurement path opens with structure work—naming things once, writing a model, agreeing a taxonomy. At the higher levels it opens with instrumentation, because the structure is already there to hold what you learn.
Second question: what is this content costing you?
You name the screens in scope, then weight what worries you across them—task failure, support load, drop-off before value, rework and churn, no shared definition of quality, and content that cannot be reused or retrieved. Weights total a hundred, and each concern is pinned to the screens where you actually see it, because support load on a billing page and task failure at checkout are not the same problem.
Steps to follow, for the best use of Loupe
Seven steps, eight once you name a concern. Answer them in order—each one narrows what the next can honestly ask you. Nothing is mandatory except a screen name, and the review at the end lets you jump back to any step you rushed.
The URL or screenshots, and the screen names the scorecard will use.
Which content practices your organisation actually runs.
What worries you, weighted, and on which screens.
Your own figures where you have them, observed symptoms where you do not. This step appears once you name a concern.
What evidence you can actually get hold of, which sets each row's confidence.
Who writes the words, who can say no, and who has to be convinced.
The shape of the value, and a short ordered set of moves.
The same evidence phrased for each room you have to walk into.
Numbers or symptoms, and why both are allowed
Most teams do not have clean figures for content-caused failure, and waiting until they do is how the argument never gets made. Every concern can be answered with figures, with observed symptoms, or with both. A row backed by both is labelled corroborated. A row backed by neither is labelled unread, and stays visible rather than quietly disappearing.
Rows that can be priced carry a range modelled from your own inputs and stated assumptions—never a benchmark. Rows that cannot be priced honestly—comprehension, consistency across teams, decision ownership—carry no number at all. Pricing the unpriceable is how content ROI loses its credibility in the room, so the tool refuses to do it.
- 3,200 support contacts a month
- £14 fully loaded cost per contact
- Your own estimate: a fifth are content-caused
A range, with the arithmetic shown and the assumption stated.
- Agents paste the same explanation repeatedly
- People ask what a charge means after they have paid
- The help article contradicts the screen
No figure, but a named pattern anyone in support recognises.
Why the case is phrased per audience
Different functions have wanted to own their own content work for thirty years—marketing owns marketing content, design owns UX content, support owns the help centre. That siloing is an organisational design problem, not a writing problem, and it means one version of a content argument rarely convinces more than one room.
So the final step takes the same evidence and phrases it separately for marketing, design, engineering, support, research, media and the business, in the units each of them counts in—plus a holistic version for the room where they all sit together.
What Loupe deliberately does not do
- It does not crawl or save anything that you share. It just reads your answers. A URL is a label; a screenshot is a reference for your own export. No crawler can tell whether your customers understood the sentence—you can.
- It does not benchmark you. Every range comes from your inputs, with the arithmetic shown.
- It does not price judgment. Comprehension, consistency and ownership are argued with evidence, not currency.
- It does not read your operational estate. Loupe reads one product surface at a time. It does not measure a multilingual content estate, a localisation pipeline, a help centre across channels, or the cost of a CMS migration. Those are content operations questions, and they need instruments built for that scale.
- It does not store anything. No database, no backend, no account. Reloading clears the session, which is why the PDF export exists.