AI Discovery Baseline Playbook

Write the business question first. You may need to decide whether to improve a service page, commission original research, repair an inquiry path, or investigate inconsistent business facts. “We want more AI visibility” is too broad to determine which evidence matters. A more useful question names the service, the audience, and the decision the buyer needs to make.

For a hypothetical commercial maintenance company, the question might be whether property managers can understand the assessment service and submit enough information for a useful follow up. That question makes the service page, preparation guidance, contact form, and inquiry qualification process relevant. A large sample of unrelated consumer prompts would contribute little to the decision.

Use the AI Overviews business guide for the strategic context. The baseline should connect to a real service journey and remain useful even when search interfaces change.

Name a business owner who can confirm service facts, a marketing owner who can interpret audience questions, and a technical owner who can inspect the public site and available accounts. One person may fill several roles in a small company. The important point is to identify the responsibility rather than assuming everyone understands who decides.

Give the baseline a date, version, and storage location. Record who collected each source and who can grant access later. Preserve original exports and observations separately from charts or summaries. A presentation is easier to update when the evidence behind it has not been overwritten.

Limit collection to what the decision needs. Anonymize customer questions, avoid copying confidential project material into shared research tools, and keep private account details in the appropriate business systems. A useful baseline does not require gathering every available data point.

List the main service page, relevant comparison or educational pages, contact path, and public profiles that matter to the chosen journey. Record the exact URL and its intended role. Note whether the destination is controlled by the business, an agency account, or a third party.

Open each owned destination as a public visitor. Confirm that it loads, displays the expected information, and provides a relevant next step. Record material errors, redirects, hidden content, and mobile difficulties. Do not confuse a CMS draft with the public page customers can reach.

If the site is large, state the sample boundary. A review of one service journey can produce valuable findings, but it does not establish the condition of every template, market, or integration. Name the unreviewed areas so later work can expand deliberately.

Record the approved business name, service scope, geographic coverage, contact routes, eligibility, commitments, and important exclusions. Ask the relevant owner to confirm each fact and identify its evidence. A public page may contain an outdated promise; copying it into the baseline does not make it approved.

Compare the important destinations for contradictions. Prioritize differences that affect a customer's decision, such as whether the company offers a service, serves a location, or accepts a project type. Minor stylistic variations can wait. The business entity consistency playbook provides a deeper process for resolving those conflicts.

Use the AI Answer Kit to organize a reusable facts pack if that helps the team maintain the record. Treat it as an input to editorial review with an accountable owner, not as a ranking prediction or an approval from a search platform.

Google's current AI optimization guidance describes foundational Search requirements and relevant inclusion considerations. For the baseline, record the checks actually performed and the results. Distinguish public page observations from findings made through an account or configuration review.

If access to Search Console or server settings is unavailable, mark those areas unverified. Do not infer a setting from a screenshot of an unrelated property. Do not change crawler policy simply to make a checklist green. The business should understand the purpose and effect of a proposed configuration change before implementation.

The crawler access review playbook can be used when access is a confirmed concern. It keeps technical controls separate from content quality and protects against treating robots rules as a security system for private information.

Choose questions that correspond to the buyer decisions in scope. Include discovery, comparison, qualification, and preparation where those stages matter. Label each question as observed in customer or account evidence, found in provider language, or inferred by the team. The label should survive into the report.

Keep the exact wording and any collection settings used for manual or tool assisted observations. Record whether an AI response appeared, whether the business was mentioned, whether an owned page was linked, and whether the answer contained a material factual error. Mark collection failures as unavailable rather than absent.

Read the citation review article for interpreting an individual observation. A stable sample can reveal useful patterns, but it does not measure every buyer's experience or prove market wide share.

Inventory the reports available in the actual accounts. Record the platform, property, date range, filters, extraction date, metric definitions, and material availability limits. Google's Search generative AI report help is the appropriate reference for that report's documented scope.

Keep a Web filtered export labeled as Web. Keep a dedicated AI report labeled with its platform and metric. Do not add overlapping periods or treat page level and property level aggregation as interchangeable. If a report is absent or has insufficient activity, preserve that fact rather than filling the gap with a different source.

A baseline can still be useful with incomplete platform data. The team can verify public facts, repair a broken inquiry path, and establish consistent definitions while waiting for more evidence. Missing data should narrow the claim, not stop every useful action.

Document the analytics configuration relevant to the journey: landing pages, recorded acquisition dimensions, contact actions, and known collection limitations. Record recent changes to forms, consent behavior, tracking, or phone routing. These changes can affect measured activity independently of search exposure.

Agree on the business definition of a qualified inquiry. Identify who assigns the status and what information is required. Separate spam, duplicates, and existing customer requests where the workflow supports it. If the CRM process is inconsistent, record the limitation and a practical improvement task before publishing a polished conversion chart.

The article on AI Overviews traffic and conversions explains why exposure, visits, and outcomes belong in separate layers. The baseline should make those layers visible even when attribution between them is incomplete.

Keep the summary short enough for an owner to review, with links to the underlying evidence. A useful packet lets a new team member understand what was examined without asking the original researcher to reconstruct the process from memory.

Prioritize confirmed problems with meaningful consequences. A broken contact route, an inaccurate service commitment, or a conflict about geographic eligibility may deserve attention before a speculative content opportunity. After that, choose a bounded improvement that addresses a known buyer question.

Write the intended change and acceptance condition before implementation. Preserve the baseline rather than updating it in place to match the new site. Create a dated change record and a later review record. This makes it possible to distinguish what the team knew before the intervention from what it learned afterward.

If several changes must happen together, document the bundle and avoid claiming that a later outcome proves the effect of one component. The goal is practical learning, not a falsely precise experiment.

Work through a hypothetical baseline decision

Imagine a service business whose owner has seen the company named in an AI answer and wants to increase investment immediately. The marketing lead first records the observation and inspects the linked page. The page accurately describes the service, but its inquiry form routes to an inbox that staff check inconsistently. The available search export is filtered to Web, and no separate AI report has been provided. The CRM does not consistently distinguish new opportunities from existing customer requests.

The baseline should preserve each finding separately. It can document the citation without treating it as a traffic estimate. It can identify a concrete handoff problem without claiming that the problem explains all lost opportunities. It can label the Web export correctly and make the CRM definition gap visible. The first intervention might therefore improve inquiry routing and qualification while the team gathers more search evidence.

After the handoff is repaired, the next review can examine whether submitted information reaches the right person and whether qualification is being recorded consistently. That is a narrower, more observable question than whether the company has become an AI leader. The business can still pursue useful content improvements, but it now has a clearer basis for deciding which work matters.

This example is hypothetical. Its purpose is to show how a baseline changes the order of work. It does not predict a conversion improvement or describe a Trojan client result. Your first intervention should follow the conditions actually found in your own evidence packet.

The baseline is complete when the business decision is defined, the reviewed scope is explicit, important facts have owners, available sources retain their definitions, and the next action can be justified from the evidence. It is not complete merely because a dashboard contains numbers.

Set review triggers around meaningful events: an important service change, a site release, a reporting definition change, or enough new inquiry evidence to assess the chosen question. A fixed meeting can help coordination, but it should not force conclusions from an inadequate sample.

Ask Trojan Digital Marketing to establish an AI discovery baseline for one service. Bring the pages, available account exports, and the questions your team hears. The deliverable should help you approve a concrete next step and understand the limits of what is known.