Run a weekly AI search review meeting in 30 minutes (agenda and template)

A weekly AI search review works in 30 minutes when it has five fixed segments and one rule: every item ends as a decision, a follow-up with a named owner, or an explicit "watch". Spend five minutes reading the week's report, five on alerts, seven on checking the evidence behind anything you plan to act on, eight on decisions from your open-work list, and five on assignments. Nothing in the meeting should be a tour of the dashboard. If a number does not change what someone will do this week, it does not need airtime.

In short

• Fix the cadence to the data. The weekly report covers a Monday to Sunday week in UTC, so meet after it exists and always review the same week.
• Use five timed segments: read the week, alerts, evidence check, decisions, assignments.
• Check the evidence before you commit work. A change in a number is a reason to look, not a reason to act.
• Close every item as decide, assign, or watch. Keep owners and due dates in your own task tracker.
• Write findings at the strength the evidence supports. Observations of AI answers are not proof of why an engine said what it said.

Why does a weekly AI search review need a fixed agenda?

Without one, the meeting drifts toward whichever chart is on screen. AI answers can vary from one day to the next, so a week often contains some movement, and an unstructured review turns that movement into debate. A fixed agenda gives every metric the same treatment: read it, check it, decide something or park it.

The agenda below is built around what the product already produces on a weekly rhythm, so nobody has to prepare a separate deck. The weekly report is assembled automatically for a Monday to Sunday UTC week, alerts are written by a daily comparison, and an open-work list collects the records that need a decision. Which of these your project has access to depends on your plan; see plans and limits.

Enlarge image

What should you prepare before the meeting?

Preparation is ten minutes for one person, not for the room. The preparer opens the latest weekly report, notes the alerts raised since the last meeting, and skims the open-work list for its top items. Everyone else arrives cold, which is the point: the meeting should work from the same pages the team will use afterwards.

The weekly report is a dated summary with one headline number, the prompts that moved, where you stand against competitors, and a short list of what to do next. According to the weekly report docs, it is built on Mondays for eligible projects, uses the last complete Monday to Sunday week in UTC, and makes no language-model call: it reads numbers the product already computes. Two consequences matter for a meeting. First, hold the meeting after the report exists. Second, always review that completed week, not a partial current one.

Enlarge image

If you run several client projects, the client reports overview lists them for one chosen completed week, so the preparer can see which projects have a report ready. It treats each project's readings as separate: prompts, countries and engine mixes can differ, so do not rank clients against each other from that page.

The 30-minute agenda

Each segment has a purpose, a time box and a required output. If a segment produces no output, say so and move on.

Segment 1: read the week (5 minutes)

Start with the report's headline reading and its change from the prior week, then the prompts that gained or lost ground. Say the summary out loud in one sentence, for example "brand visibility flat, two prompts down, one competitor up".

Read the caveats before the numbers. The weekly report compares only the engines measured in both weeks, and where a reading has no data behind it, the report shows it as unavailable instead of as zero. A blank change means there was no comparable prior week, not that nothing changed. Definitions for each reading are in the metrics reference.

Segment 2: alerts (5 minutes)

Alerts are the shortlist of changes that crossed a fixed threshold, so they are a better meeting input than eyeballing every line. The alerts docs describe a daily comparison of adjacent seven-day windows across four visibility kinds (visibility drop, competitor surge, prompt drop, rank slide), four brand-signal kinds, source watchlist changes and fact contradictions.

For each open alert, decide one of three things. Act means it goes to the decisions segment. Watch means you note it and see whether next week confirms it. Dismiss means it is not a real change for you. Owners and editors can acknowledge, dismiss or snooze an alert (7, 14 or 30 days) and attach a shared team note of up to 500 characters, so record the meeting's conclusion there while it is fresh.

Segment 3: evidence check (7 minutes)

This is the segment most teams skip, and the one that stops wasted work. Before you commit effort to anything, open one or two of the collected answers behind the change and read them. The overview's recent answers open in full in a side panel, which is enough to see who was named and which sources were cited. An aggregate number tells you where to look; the answer tells you what happened.

For each finding, assign a claim strength using the ladder in the template below. The main discipline is to separate what the evidence shows from why it happened. Citations, mentions and stated reasons are observations of an answer. They do not prove why a model produced it, and a metric that moved next to a change you made does not show the change caused it. If the drop is on a single prompt, read that prompt's recent answers before you call it a trend.

Segment 4: decisions (8 minutes)

Work from the open-work list, not from memory. The Actions → To do list gathers open records from seven sources (fact check findings, alerts, optimizations, citation gaps, Search Console opportunities, earned sources and prompt suggestions) in priority bands, High first. Take the High band first and stop when time runs out; the page loads at most the first 200 items.

The list has no status of its own: each item is a record that lives on its own page, and its buttons (such as Accept, Dismiss or Mark applied, depending on the kind) change that same record. That makes it convenient to settle an item during the meeting. Only owners and editors see the buttons; viewers see Open links. Decide each item as do, defer or drop, and be honest that a suggested change is a hypothesis to test, not a promised gain. Note that accepting a citation gap also adds a candidate topic to Articles (nothing is written until someone picks it there), so accept only the gaps you mean to pursue. (The product also has an "Approve selected for handoff" action on Optimizations; that is a separate review record, not the meeting decision described here.)

Enlarge image

Segment 5: assignments (5 minutes)

Every item marked "do" leaves the room with an owner and a date. The product docs do not describe assigning owners inside the To do list, so keep ownership in your team's tracker and paste the link into the meeting notes. For a page-level change, hand the editor a self-contained task rather than scheduling another meeting; see give an editor a page-fix task. For an optimization, the Optimizations page can export a task packet file for your implementer, depending on your plan, which you can attach to the tracker item.

The meeting template

Copy this into your notes tool. One page per week, filled in live.

WEEKLY AI SEARCH REVIEW
Project: ______________   Report week (Mon-Sun, UTC): ________ to ________
Attendees: ______________   Facilitator: ________   Note-taker: ________

1. READ THE WEEK (5 min)
   Headline reading and change vs prior week: ______________________
   One-sentence summary: __________________________________________
   Caveats (unavailable readings, engines compared, new prompts/countries): ____________
   Anything we could not measure this week: ________________________

2. ALERTS (5 min)
   Alert / kind / prompt or brand   | Act | Watch | Dismiss | Team note written?
   _________________________________|_____|_______|_________|___________________
   _________________________________|_____|_______|_________|___________________

3. EVIDENCE CHECK (7 min)
   Finding | Answers opened (count) | Claim strength (1-4) | Still unknown
   ________|________________________|______________________|_______________
   Claim strength:
     1 = a number moved (no answer read yet)
     2 = we read the answers and the change is visible in them
     3 = a plausible reason is visible in the answer or cited sources
     4 = a change we made was followed by a measured change (still not proof of cause)

4. DECISIONS (8 min)   Source: Actions > To do, High band first
   Item | Kind | Do / Defer / Drop | Hypothesis to test | How we will check it
   _____|______|________________________|____________________|_____________________

5. ASSIGNMENTS (5 min)   Owners live in our task tracker
   Task | Owner | Due | Tracker link | Check-back week
   _____|_______|_____|______________|________________

WATCH LIST (carry to next week): ______________________________________
LAST WEEK'S ACTIONS: done / not done / dropped, one line each: ____________

How do you handle last week's actions?

Put them at the top of the next meeting's page, one line each, and mark them done, not done or dropped. Do not spend time on the ones that are done.

The weekly report helps here. Its "Do this next" checklist holds the five highest-impact citation gap opportunities, owners and editors can tick items off as done, and next week's report shows how many of the list were completed. Treat that as a progress signal for that list only; work that lives in your own tracker has to be reviewed from there.

Worked example

Illustrative example: Quillstone and its competitors are fictional, and the numbers are made up to show the method.

Quillstone sells document-review software to legal and compliance teams. Its three-person AI search team (a content lead, an SEO lead and an editor) meets on Tuesday at 10:00 for the previous Monday to Sunday week. Competitors are Brieflane and Clausewise.

Read the week (5 min). The report shows brand visibility flat, two tracked prompts down and one competitor up. The content lead notes the report's engine comparison covers only engines measured in both weeks and says so in the notes.

Alerts (5 min). Two open alerts. A prompt drop on "best contract review software for in-house teams" and a competitor surge for Brieflane. The team marks the prompt drop "act" and the surge "watch", because Brieflane's rise is one week old. The SEO lead writes a team note on each: "Checked in weekly review, see notes."

Evidence check (7 min). They open three collected answers for the dropped prompt. In all three Quillstone is still named. In two of the three, a Clausewise comparison page is cited where Quillstone's own comparison page was cited in earlier answers; the third is unchanged. That is claim strength 2 (visible in the answers), with the cause unknown: the answers do not show why the citation moved. The editor notes the "still unknown" column: "Did our comparison page change, or did theirs get more linkable?"

Decisions (8 min). From the High band of the To do list, the team sees one citation gap for that comparison topic and one optimization draft for the Quillstone comparison page. They decide to do the draft as a hypothesis ("refreshing the comparison table may restore the citation") and defer a Search Console item to next week.

Assignments (5 min). The editor takes the page refresh, due Friday, with a tracker link. The SEO lead owns the check-back: re-read the same prompt's answers in the review two weeks out. The Brieflane surge goes on the watch list.

Arithmetic check: 5 + 5 + 7 + 8 + 5 = 30 minutes; three answers opened, two of which show the changed citation and one that does not.

Common mistakes and what this meeting cannot tell you

• Reviewing a partial week. The report covers a completed Monday to Sunday week. Reading a live, partial week invites false alarms.
• Ranking clients against each other. If you run several projects, each has its own prompts, countries and engine mix. Use the overview to find which reports are ready, not to build a league table.
• Treating an alert as a diagnosis. An alert says a threshold was crossed. It does not say why.
• Skipping the evidence segment when time is short. Cut decisions first; never cut the evidence check.
• Reading a movement next to your change as proof. A saved outcome is an observation. It does not show your edit caused it, and the answers you sampled are a snapshot, not a stable ranking.
• Sharing more than you meant to. If notes leave the room as a client report, check what the link exposes first; see share an AI visibility report safely.

This meeting also cannot fix thin data. If a project has few tracked prompts or few answers in the week, the honest outcome is "not enough to conclude", and that is a legitimate result to record.

Frequently asked questions

How often should we review AI search visibility?

Weekly is a sensible default because the weekly report and the alert comparison both work in seven-day windows. Reviewing daily risks reacting to ordinary answer variation. Move deeper analysis to a monthly or quarterly rhythm; see turn a weekly analyst report into a monthly leadership update.

Who should attend?

Whoever can decide and whoever will do the work: typically a content lead, an SEO lead and an editor, plus an account lead for agencies. Owners and editors can act on alerts and To do items in the product; viewers can read them, so make sure at least one attendee can click the buttons.

What if the weekly report is missing or locked?

Report access depends on your plan, and a project with no AI-search data recorded in the week is skipped instead of shown a partial one. Run the meeting from the alerts and the To do list, and record "no report this week" in the caveats line. See plans and limits.

Should we act on every alert?

No. Use act, watch or dismiss. Watch items that are one week old, and dismiss alerts that reflect a change you caused yourself, such as adding a country or a persona audience to a tracked prompt.

Where do we keep the action owners?

In your team's task tracker. The product records the state of each item (accepted, applied, dismissed) but the docs do not describe assigning people to items, so the tracker is the source of truth for who and when.

How do we know if last week's fix worked?

Put a check-back week on every "do" item, then re-read the same prompts' answers. Treat any change as an observation and label it with the claim-strength ladder rather than declaring success.

Next step

Set the meeting for the same time each week, after the report exists, and run the first one from the template above. The alerts and the weekly report are described in alerts and reports, and you can sign in and open them at app.discoveredby.ai.