A weekly AI competitor analysis brief should tell you what changed, show where the evidence came from and explain why the change might matter to your work. Start with a small approved source list and a successful manual run before putting the task on a schedule.
The recurring task is not “tell me everything about competitors.” It is a bounded research job: inspect chosen public sources, compare dated observations with an available baseline and identify findings worth a human review.
This guide supplies a template and an illustrative two-run example. The example is not the result of live monitoring. You can download the weekly brief instructions and use them with your own source list.
Decide which changes matter
Choose the decisions the brief should inform. A product marketer might care about changes to an offer, pricing terms, a new use case or published customer evidence. A founder might care about a newly served segment or an announced integration.
Make the scope small enough to check. Three competitors with a few relevant pages each can be more useful than a large directory that produces shallow summaries.
| Source type | What to inspect | What it cannot establish alone |
|---|---|---|
| Pricing page | Published plans, conditions and changes | A private negotiated quote or actual customer bill |
| Product release notes | Announced availability and intended behavior | Real-world quality or adoption |
| Product page | Positioning, claims and use cases | Independently verified outcomes |
| Official company post | An announcement and its date | Market-wide impact |
| Customer evidence | A particular described experience | A typical result for every buyer |
Keep the direct URLs in the instructions. An assistant should not have to guess which company with a similar name you mean.
Define the baseline and comparison window
The first run establishes what is visible at that time. It cannot reliably say what changed since last week unless it has a trustworthy earlier record.
Save the first approved report with its date, source URLs and relevant observations. For later runs, supply that report or an explicitly available comparison source. Do not assume every new scheduled run remembers prior material automatically.
State the reporting window and time zone. For example:
Review the specified sources for the period ending Monday at 08:45 in Europe/Istanbul. Compare with the attached prior report. Distinguish newly observed information from changes whose actual publication date is known.
“Newly observed” and “newly launched” are different findings. A page that the assistant sees for the first time may have existed for months.
Copy the weekly brief instructions
TASK
Prepare a weekly competitor brief for [decision owner].
DECISION
Use the brief to inform [specific decision].
SCOPE
Competitors and exact public source URLs:
[list]
Reporting window and time zone:
[window]
Prior approved report or baseline:
[reference, or say none exists]
OUTPUT
1. Up to five relevant findings.
2. For each: observation, source URL, source date if known,
access date, baseline comparison and business implication.
3. A source-coverage table: checked, unavailable or not reviewed.
4. Uncertainties and one suggested follow-up.
RULES
Use public accessible sources and respect access restrictions.
Do not treat an unavailable page as evidence that a feature ended.
Do not label a change confirmed without comparison evidence.
Separate vendor claims from independently checked facts.
Do not contact competitors, create accounts, buy anything,
publish findings or update external records.
If a required step needs approval or exceeds the allowed budget,
pause and explain what is needed.
The output limit keeps the brief focused. If there are no relevant findings, “no confirmed relevant changes in the checked sources” is useful. It is more honest than adding weak news to fill five rows.
Run the task manually first
Use the exact instructions and source list you intend to schedule. Review the resulting report for wrong companies, unsupported dates and conclusions that go beyond the linked evidence.
Open the source for each consequential finding. Check the full condition around a price or feature statement. A short excerpt can omit the plan, billing interval or eligibility that changes its meaning.
Improve the instructions based on specific failures. If the report repeatedly includes unrelated announcements, narrow the decision and exclusions. If it calls old information new, strengthen the baseline rule.
Only save the routine after a manual result is useful. Automation repeats the method you give it, including an unclear scope.
For a longer decision document, the market research report template provides a broader structure.
Save a skill and create the schedule
In AI Magicx, a saved skill holds repeatable instructions, and Schedules can run a task on a timetable. Check current plan eligibility before setting up a recurring workflow.
Save the reviewed instructions as a skill with a clear name and purpose. Then open Schedules and create a new schedule for the routine or task you intend to run. Check the prompt, recurrence, time zone, permitted tools and funding before enabling it.
For a weekly research brief, confirm:
- The correct day and local time.
- The source list and reporting window.
- Where the result should be available for review.
- How the prior report will be supplied or found.
- The per-run mana budget.
- Any approval needed for tools or connected accounts.
Do not assume a daily schedule is harmless because the individual budget is small. Consider the number of runs in the period and any provider-account spending that sits outside the platform-funded portion.
A scheduled task is also not permission to change external data. In AI Magicx, a run that needs approval pauses rather than approving itself. Keep the research output and any later action as separate decisions.
What two runs should reveal
Here is an illustrative comparison using fictional competitors. It shows the reporting format, not a record of real changes.
| Source | Baseline observation | Later observation | Appropriate finding |
|---|---|---|---|
| Northline Tools pricing | An annual plan is displayed | The annual plan remains displayed | No observed change in the checked terms |
| Clearpath release notes | Latest visible entry is an export update | A newer dated entry describes a reporting feature | A newly published announcement, subject to checking its scope |
| Hearth CRM product page | Page was accessible | Page could not be read during the run | Coverage gap; no conclusion about availability |
The third row is important. A failed read is a problem with the observation, not proof that the competitor removed a feature or left the market.
When you run your own process twice, retain both reports and the source references. If the assistant proposes a change, check whether the baseline actually contains comparable material. If not, label the observation and establish the missing baseline for next time.
Make the brief actionable without exaggerating it
Separate three parts of each finding:
Observation: A source says something specific, with a date and URL.
Interpretation: The change may affect a positioning, product or sales question.
Follow-up: A person should inspect the relevant claim, ask a customer question or update an internal note.
For example, a competitor adding a new use-case page may suggest increased emphasis on a segment. It does not establish that the segment is profitable, that customers adopted the feature or that you should immediately copy it.
Use the brief to choose what deserves attention. Do not turn every competitor movement into work for your team.
Handle incomplete or paused runs
| Problem | Useful recovery |
|---|---|
| A source is unavailable | Mark the gap, retain other findings and retry only if it matters |
| The previous report is missing | Produce a dated baseline instead of inventing changes |
| A paid step exceeds the budget | Review the estimate, narrow the source list or approve an appropriate limit |
| A connection expires | Reconnect through the supported account flow, then rerun the affected part |
| A tool requests a write | Review the proposed destination and action; reject it if the task is read-only |
| The run stops before completion | Label the output partial and check source coverage before sharing it |
Keep the original instructions and accepted findings while resolving the error. Re-running the entire task without understanding the failure can add cost and duplicate material.
Review the routine after a few cycles
Ask whether the brief has influenced a useful decision. If it produces repetitive low-value updates, reduce the frequency or source list. If a category matters only near a launch, run it for that period instead of making it permanent by default.
Assign one owner to review scope and source changes. When a competitor changes its site, update the source register and retain the reason for the change.
If your approved context lives in Notion, the Notion connection guide explains how to use an assistant with workspace material while keeping proposed writes reviewable.
Start with the weekly brief template, approve one manual report and verify how the next run will access its baseline. Then review skills and schedules for the recurring stage.