Recommendations — How to Turn an AI Visibility Finding Into an Actionable Recommendation

Key Takeaways

• A finding names a gap with a number attached; it doesn't yet explain why the gap exists or what to build.
• "Why" isn't one paragraph — it's four separate answers: the problem, why it matters, what's missing, and what else has to be true for a fix to actually land.
• A "how" only works if two different writers would build recognizably similar pages from it; vague direction produces on-topic content that's shaped wrong.
• Every claim should trace to an actual number from a specific slice, not a vibe; recommendations without evidence are the first thing cut when priorities tighten.
• Expected impact is the most skipped part of a recommendation, and the only one that turns the next test cycle into a real check instead of a fresh guess.

---

"Build an explainer hub for the weakest persona" looks like a recommendation. It is barely an observation. It names a direction without saying what the page has to argue, what it's currently losing to, or what number should move if it works.

This is where most manual audits stop. A finding gets written down as a sentence, the sentence gets handed to a writer, and the writer fills in everything the sentence left out — usually with whatever the brand would have written anyway. The page ships. The number that flagged the gap doesn't move, because nothing in the brief ever told anyone which number it was supposed to move.

A finding that actually survives the handoff to a content team is a different object than one that doesn't. It picks up a why, a how, evidence, and an expected impact along the way — and skipping any one of them produces a page that looks like it answers the finding without actually being checkable against it. This post is about what each of those four needs to contain, using one real finding worked all the way through. It continues the previous posts on brand discovery, persona design, intent mapping, question development, testing, and analysis.

---

The Finding Names the Gap. It Doesn't Explain It.

A finding is a single sentence anchored to a number: which persona, which intent or context level, which bucket, what the rate actually is. "Weak visibility for analytics-focused buyers" is a feeling. "30% organic appearance for this persona in diagnostic and educational questions, against 60% for the strongest persona" is a finding — specific enough that someone could go check it again later and get a comparable answer.

That specificity is necessary, but it's also where most build lists stop. A finding tells you where the gap is. It doesn't tell you why the gap exists, what's currently filling it, or what a fix would actually need to do. Those are different questions, and a one-line finding answers none of them.

A finding becomes a recommendation once four more things are attached to it: a why that explains why the finding is worth addressing in the first place, a how that spells out the implementation clearly enough that it isn't left to interpretation, evidence that ties the recommendation back to what was actually measured in testing and analysis rather than asserted out of thin air, and an expected impact — the outcome the recommendation should produce, without which it's just an instruction with no way to check whether it worked.

Why it matters: A finding that isn't anchored to a number is unfalsifiable — there's no way to check later whether it improved. A finding that's anchored to a number but missing any of the four parts above is falsifiable and still not actionable, because nobody downstream knows what to build, why it's worth building, or what to check it against once it ships.

---

"Why" Should Have Four Parts, Not One

Explaining why a finding is worth addressing sounds like a one-paragraph job. Done well, it isn't — it actually breaks into four distinct questions, each pointing a writer toward a different decision.

The problem. What's actually happening in the tested conversations — described concretely enough that someone could recognize it in a transcript. Not "buyers don't see us," but "buyers asking how to diagnose a performance bottleneck get a generic framework, or get a competitor's name, and don't get ours."

Why it matters. The downstream consequence of leaving this alone. Not every gap matters equally — a gap in a low-stakes, low-volume scenario is a different priority than a gap in a scenario that shapes what buyers carry into their next, more consequential conversation.

What's missing. The actual content or positioning gap that's letting the pattern happen — stated as a gap, not yet as a deliverable. "No content that translates this capability into the operational language this buyer uses" is what's missing. "Build a page" is the how, and belongs in the next section, not this one.

The dependency. What else has to be true for this fix to land. Most visibility gaps aren't pure content gaps — a content fix sitting next to a citation environment still dominated by competitor and third-party sources needs that environment addressed too, or the new page will say the right thing and still not get pulled into the answer.

Why it matters: A why with one part collapses into a justification for whatever's already been decided. A why with four parts forces the actual reasoning into the open — including the part that says "this fix alone probably isn't enough," which a one-paragraph why tends to quietly skip.

---

"How" Has to Be Specific Enough That Two Writers Converge

"Build an explainer hub" gives two different writers two different pages, because nothing in it specifies which questions the hub has to answer, in what order, with what proof attached. A how that actually transfers intent does four things a generic content brief doesn't.

It names the actual themes or sub-questions to cover — pulled from the scenarios in the test set, not invented fresh. It specifies the structural requirements that make a page retrievable in the first place: a direct answer up top, headings that mirror how buyers actually phrase the question, frameworks or checklists instead of prose where the tested conversations show models quoting structure rather than marketing language. It names which existing proof — product capabilities, documentation, real workflows — the new content has to connect to, so the page is grounded rather than aspirational. And where the dependency in the why points at a citation environment outside the brand's own domains, the how says so explicitly, rather than leaving owned-content work to quietly stand in for an answer to a problem it can't fully solve alone.

Why it matters: A how that's specific only about topic and vague about structure produces content that's about the right thing and shaped wrong — readable, on-brand, and still not the kind of page a model finds easy to extract a clean answer from.

---

Evidence Has to Trace to a Number, Not a Vibe

Every claim inside the why and the how should be checkable against something that was actually measured. Not "buyers seem to prefer the competitor here" — a displacement rate, a citation share, an appearance rate broken out by the exact slice the finding is about. Strong recommendations usually triangulate across more than one bucket: an appearance number showing the persona is weak, a displacement number showing who's filling the gap instead, sometimes a citation number showing that even partial appearances aren't backed by the brand's own proof.

This isn't pedantry. It's what separates a recommendation a stakeholder can interrogate from one they have to take on faith. "We think this persona is underserved" survives one skeptical question. "This persona sits at 30% organic appearance against 60% for the strongest persona, and a single competitor fills more than 70% of the conversations where we're absent" survives several.

Why it matters: Evidence-free recommendations get cut first when priorities tighten, because there's nothing to point to when someone asks why this made the list. Evidence-backed ones survive that conversation, and they're also the only ones a future test cycle can actually confirm or contradict.

---

Expected Impact Is the Part Almost Everyone Skips

A recommendation should end with a prediction: which number, in which slice, should move, and roughly in which direction, once the work ships. Not "improve visibility" — "organic appearance for this persona in this intent type should move off its current baseline toward where the stronger personas already sit."

This connects directly to the cadence principle from the testing step: the next test cycle is worth running once enough of this work has shipped to check against. A recommendation with no stated expected impact gives that next cycle nothing to check — you'll have new conversations and no baseline-to-outcome pair to compare them to, just a fresh read with no memory of what it was supposed to prove.

Why it matters: Without a stated expected impact, success gets defined after the fact, fitted to whatever happened to move. With one, the next cycle is a real test of whether the work did what it was supposed to — which is the entire reason a build list is worth writing in the first place.

---

What This Looks Like in Practice

The Freshdesk analysis step flagged the Support Leader / Analyst persona as the weakest organic performer in the set. Here's that finding carried all the way through the five parts, rather than left as a single build list line.

RECOMMENDATION: Build an Analytics and Bottleneck Content Cluster
Priority: Medium  |  Type: Content gap

FINDING
Support Leader or Analyst Investigating Service Metrics and Bottlenecks
is the weakest persona for organic appearance — 30%, against 60% for
the strongest persona in the set. The gap concentrates in diagnostic
and educational questions, the two weakest intent types overall.

WHY
The problem: Leaders and analysts asking how to find bottlenecks, read
channel performance, or use analytics proactively often get an answer
with no Freshdesk in it at all — a generic framework, or a competitor's
name, in its place.

Why it matters: This persona shapes the reporting and visibility
requirements that carry into later, higher-stakes leadership
comparisons. Losing this conversation now makes that later comparison
harder to win.

What's missing: Content that translates Freshdesk's existing reporting
and AI insight capabilities into this persona's actual operational
language — bottleneck diagnosis, queue health, proactive visibility —
rather than a capability list aimed at a buyer who isn't there yet.

Dependency: Analytics-focused third-party commentary already shapes
some of these answers. The fix lands harder if it also earns pickup
from that layer, not just from the brand's own pages.

HOW
— Separate pages for finding response-time bottlenecks, diagnosing
  routing and handoff failures, and catching channel issues before
  satisfaction scores drop — not one general analytics page.
— Tie each page to an actual product workflow — dashboards, queue
  views, SLA tracking — so the operational question gets a grounded
  answer, not a capability list.
— Lead each page with a checklist or diagnostic framework: the
  responses that did mention the brand tended to quote structure and
  steps, not marketing language.
— Link the cluster to existing analytics and reporting pages, and
  cross-link the cluster's pages to each other.
— Add a short stats or glossary section built to be quotable by the
  third-party commentary sites already shaping this conversation.

EVIDENCE
— Organic appearance for this persona: 30%, the lowest of five
  personas tested (strongest: 60%).
— Diagnostic and educational intent are the two weakest intent types
  brand-wide (30% and 17% appearance), and this persona's questions
  sit almost entirely inside those two types.
— When the brand is absent, one competitor fills the gap in over 70%
  of this persona's conversations, a second in more than a third — the
  same two names that dominate displacement across the rest of the
  test set.

EXPECTED IMPACT
Organic appearance for this persona in diagnostic and educational
questions should move off the 30% baseline toward where the stronger
personas already sit. Secondary check: whether the leadership persona's
comparison-stage conversations start citing reporting depth and
proactive visibility as a strength rather than leaving it unaddressed.

Nothing here exposes how the underlying numbers were computed — it doesn't need to. What carries forward is the part that actually matters to whoever has to act on it: what's broken, why it's worth fixing, what to build, what to check it against, and what it should look like working.

---

What This Gives You

A recommendation built this way produces two things a one-line build item never does.

A brief a content team can execute without guessing. The finding, the why, and the how travel together, so the page that gets built is answerable to the gap that prompted it — not a plausible-sounding page about the same general topic.

A prediction the next cycle can actually check. A stated expected impact turns the next test run into a real comparison — did this number move the way the recommendation said it would — instead of a fresh read with no memory of what it was supposed to prove.

This is also what should set the date for that next cycle. Not a fixed interval — the point at which enough recommendations like this one have shipped that there's a real prediction on the table worth testing against.

If you'd rather see what a recommendation like this looks like generated from your own brand's data before building this process yourself, fill out the form below.