How We Advise an In-House Team That Executes Its Own AI Visibility Work

1. Baseline Review

Before recommending anything, we establish where the brand actually stands - in AI answers and in the technical signals behind them.

• •Sample a fixed panel of 20-30 category prompts across ChatGPT, Perplexity, and Google AI Overviews, logging which brands get named and which sources get cited
• •Review the technical posture: site architecture, service pages, metadata, structured data, robots, sitemap, and how clearly the site explains what the company does and who it is for
• •Check entity consistency: whether the name, descriptions, and category framing match across the site, directories, and the third-party sources AI systems reconcile
• •Map competitor presence in the sampled answers and in the sources those answers retrieve from

The deliverable is a written baseline: what assistants currently say about the brand, where they source it from, and which gaps are technical versus reputational. Everything after this is prioritized against it.

2. Strategy and Prioritization Workshop

We work through the baseline with the team in a live session and decide, together, which layers to fix first.

• •Weigh the four layers against the findings: SEO foundation (crawlability, site structure, page quality), AEO structure (answer-shaped pages, FAQs, schema), GEO signals (entity consistency, third-party corroboration), and community presence (Reddit and category forums)
• •Sequence by dependency: structural and technical fixes usually come before promotion, because promoting a site assistants cannot parse wastes the effort
• •Mark every recommendation as urgent, next, or later - matched to the hours and skills the team actually has, not an idealized headcount
• •Flag risks in plain language: where claims, automation, or channel choices could create problems later

The output is a prioritized roadmap the team agreed to in the room - not a generic audit deck they file away.

3. Execution Playbook

Because the team implements everything themselves, the handover has to be runnable, not theoretical.

• •A brief per workstream: what to change, why it matters, what done looks like, and an example of good execution
• •An owner and effort estimate for each item, so the roadmap maps onto the sprint planning the team already uses
• •Templates where they help: page structure for answer-shaped content, an entity consistency checklist, and disclosure guidelines for community participation
• •An explicit do-not list - tactics that look tempting but create trust or policy risk, so nobody improvises into trouble

4. Review Cadence

Advisory only works if someone checks whether the plan survives contact with reality, so we stay on a recurring schedule.

• •Recurring sessions reviewing the sampled prompt panel: what moved, what did not, and whether variance or a real trend explains it
• •Unblocking decisions the team cannot settle alone: trade-offs between workstreams, whether to drop an item that is not paying off, when to escalate a technical fix
• •Re-prioritizing the roadmap as findings come in, so the plan reflects what the panel and analytics actually show

5. Skills Transfer

The end state is a team that measures for itself instead of renting the capability indefinitely.

• •Teach prompt panel design: fixed wording, a fixed set, sampled repeatedly, logged with dates and model versions
• •Teach honest reading: single runs prove nothing - repeated sampling with variance notes is the minimum bar for calling something a trend
• •Hand over the measurement log and sampling checklist so the cadence continues without us in the loop
• •Help set expectations internally: leadership reporting framed as directional movement, never as promised placements