Scope an AI visibility engagement around deliverables you can control

To scope an AI visibility engagement without over-promising, write the statement of work around things you can control: which prompts are monitored, how often results are reviewed, which content work you will deliver, what is excluded, and what you will report. Leave out outcomes you cannot control, such as a mention rate, a citation count or a position in any AI answer. The reasons an engine gives a particular answer are not visible from outside, so a promise about the answer is a promise about someone else's system. The checklist below turns that principle into clauses you can adapt. It is a scoping aid, not legal or contract advice.

In short

• Commit to inputs and activities: the monitored prompt population, the review cadence, the content deliverables, the reporting pack.
• Report outcomes as observations with their definitions, never as guarantees. Nobody can promise what an AI engine will say.
• Fix the prompt set and the reporting week in writing, so a change in scope is a visible decision and not a quiet drift.
• List exclusions explicitly: engines, countries, languages, publishing work, and anything that depends on the client's own team.
• Decide who owns the project account before you start, because plan limits, exports and report access follow the project owner.
• Have a lawyer review the contract wording. The checklist covers scope, not legal terms.

Why should scope stop at things you control?

Scope should stop at the edge of your influence, because a deliverable you cannot control turns every quiet week into a dispute. You control which prompts you monitor, whether the review happened, and whether the brief was delivered. You do not control what an engine writes.

AI answers are observations, not verdicts. A mention is your brand named in an answer; a citation is an answer naming your domain or a specific URL as a source. A saved answer tells you what was said on one day for one prompt. It does not tell you why the engine said it: DiscoveredBy's brand reasons are a model's reading of the answer, and the documentation says the quotes do not show what caused an engine to rank a brand. If your statement of work says "increase citations by a set amount", you have promised the cause.

What you can promise instead is process quality. "We monitor these prompts daily, review results weekly, deliver two page updates a month, and report the same four measurements every week" is a promise you can keep in a bad month and a good one.

Enlarge image

What should the statement of work commit to?

Commit to five things: the monitoring population, the review cadence, the content work, the exclusions and the reporting obligations. Each one is an input you can verify, and each maps onto something concrete in a monitoring tool.

1. The monitoring population. This is the fixed list of prompts (full questions asked to AI engines on the client's behalf) plus the locations, audiences and languages they run in. In DiscoveredBy, every prompt tracks at least one location, at least one audience and one or more languages, and each combination is its own prompt target, which is what actually gets run and what uses a plan slot. Twenty prompts in two countries with the General audience plus one persona, all as written, is 20 x 2 x 2 x 1 = 80 targets, not 20 (Prompts). Scope the target count, not just the prompt count, or the population will surprise you.

2. The review cadence. Prompts run on a daily schedule, so decide what a human does with the results and how often. A weekly review of a weekly report is a natural rhythm; see how to run a weekly AI search review in 30 minutes.

3. The content work. Name the deliverables in units: page updates, briefs, drafts. Describe them as hypotheses to test, never as fixes with a known effect.

4. The exclusions. Say what is not in scope. This section prevents most scope arguments, so it gets its own heading below.

5. The reporting obligations. Say which measurements you report, for which week, in which form, to whom, and for how long each link stays open.

How do you fix the monitoring population in writing?

Write the prompt set into an appendix and treat any change to it as a change request. The prompts are the denominator behind every rate you will report, so changing them changes what the numbers mean.

The onboarding intake is where the prompt list is agreed. For the statement of work you need four facts about it:

• The number of prompts at signing, and the number of prompt targets after locations, audiences and languages are counted.
• Which engines are included. DiscoveredBy measures eight engines (Engines and measurement). Which of them run for a target depends on the plan, on the engine choice for each prompt, and on the target itself: persona variants, for example, do not run on the Google engines, ChatGPT (app) or Gemini (app). Name the engines you will report on instead of saying "all AI engines", and do not state that a client's setup covers something the plan or prompt settings do not.
• Whether cities are in scope. A city target is a separate location from its country, so it is its own target and its own slot.
• How the set may change, and who approves it.

Also decide the change rule. If the client wants to add ten prompts in month three, is it a swap, an addition at an agreed fee, or a new phase? If the set drifts, a month-over-month change may reflect the list and not the engines; using a fixed prompt cohort for month-to-month comparisons explains why.

What review cadence can you promise?

Promise the meetings and the reading, not the movement. A cadence clause says when results are reviewed, by whom, and what happens with anything unusual.

Useful facts to build it on:

• Prompts run once a day, and, on plans that include it, a weekly report is built once a week for a project, covering the most recent complete Monday to Sunday week in UTC (Weekly report). A weekly cadence therefore fits the product's own rhythm.
• Alerts come from a daily comparison of adjacent seven-day windows, with a threshold for each kind of change (Alerts). Decide whether alert triage is part of the engagement, and how quickly you will look at one. Do not promise a response time you cannot staff.
• Some weeks have missing data. A project with no AI-search data recorded in a week gets no weekly report for it, and the Client reports overview says so instead of substituting another week (Client reports). Write into the contract that you will state a gap as a gap and explain it, not fill it in.

A clear cadence clause reads like this: "We review the weekly report every Monday afternoon UTC, flag changes that cross the alert thresholds within two working days, and hold a monthly review call." The specific days are yours to choose.

What content work belongs in scope?

Content work belongs in scope as a count of finished deliverables, each described as an experiment. Listing "improve AI visibility" as a deliverable is an outcome; listing "update two existing pages per month against briefs agreed with the client" is an activity.

Good units are:

• Page updates against a written brief.
• New pages or articles, with a review step.
• A source outreach list drawn from cited pages, with outreach handled by the client or by you as separately agreed.
• Technical tickets handed to the client's developers.

Be explicit about who publishes. If the client's team controls the CMS, your deliverable is a reviewed draft, and publication timing is theirs. A delay on their side should extend the timeline and not breach your commitment.

Also say that suggested changes are hypotheses. You can promise to record what was changed and when, and to look at the affected prompts afterwards. You cannot promise an effect.

What should you exclude, and how do you say it?

Exclude anything that depends on a third party, on the client's own team, or on a capability you have not confirmed. State exclusions as plainly as commitments; the aim is that neither side can be surprised.

Typical exclusions to write down:

• Any specific mention rate, citation count, position or share of voice.
• Any engine, country or language not listed in the monitoring appendix.
• Consumer-interface equivalence. Results reflect how each engine was collected: some engines are queried through their company's API, while others are collected as the answer a person would see. Your reports should not claim to reproduce what every individual person sees. See Engines and measurement for what each collects.
• Publishing, design, development and PR work not itemised in the content section.
• Changes made by the client's team, other agencies or platforms that affect results during the engagement.
• Anything about the client's private data, unless access is separately agreed.
• Legal, regulatory or claims review of the content.

What do you report, and who can see it?

Report the same few measurements in the same form every time, and say who can read them. A reporting clause lists the measurements, the report week, the delivery method and the access rules.

The client digest and the Client reports cards show four readings from the saved weekly report: brand visibility, citation rate, citation share and average citation position. Brand visibility and citation rate are defined on Metrics defined; for the other two, check the definition in the weekly report before you write it down. Name the readings in the contract by definition, so "visibility" cannot drift into "whatever looked good this month".

Facts that shape the reporting clause:

• Client report links are fixed snapshots of a generated week. They last 1, 7 or 30 days, can be revoked, and anyone holding a link can open it without an account (Client report links). Your clause should say how links are shared, and that a link is treated as a credential.
• A client digest is client-branded but keeps a "Prepared with DiscoveredBy" footer. Do not promise white-labelled reporting.
• A combined agency report can include 2 to 10 client projects, but each client's metrics stay separate. If you run several clients, promise separate reports; the post on comparing client projects without league tables explains why.
• Data exports are available as CSV or JSON, and are gated by the project owner's plan (Exports). If the client wants the raw data at the end, put the format and the date in the contract.
• Team roles are per project: owner, editor and viewer. Decide who gets which role, and when contractor access ends (Team access).

Also agree in advance how weekly reporting rolls into monthly and quarterly summaries, so the reporting clause covers every review the client expects.

Enlarge image

The statement-of-work checklist

Copy this into your proposal template and delete what does not apply. Fill each bracket. It is a scoping aid; have your own counsel review contract language.

# AI visibility engagement: scope checklist

## 1. Purpose and definitions
- [ ] Client / project name: [ ]
- [ ] Business goal in one sentence: [ ]
- [ ] Definitions agreed: mention, citation, prompt, prompt target, brand visibility, citation rate,
      citation share, average citation position
- [ ] Statement: results are observations of AI answers; no outcome is guaranteed

## 2. Monitoring population (appendix A)
- [ ] Prompts at start: [ ]   Prompt targets (locations x audiences x languages): [ ]
- [ ] Engines reported on: [ ]
- [ ] Countries / cities: [ ]   Languages: [ ]   Personas: [ ]
- [ ] Competitors tracked: [ ]   Brand aliases and sub-brands agreed: [ ]
- [ ] Who owns the project account and pays for the plan: [ ]
- [ ] Change rule: additions / swaps / removals need [approval by] and [effect on fee]

## 3. Review cadence
- [ ] Weekly report review: [day, owner]
- [ ] Alert triage: [who, response window in working days]
- [ ] Monthly call: [day, attendees]
- [ ] Quarterly review: [month, attendees]
- [ ] Gap rule: a week with missing collection or no report is stated as a gap, not filled in

## 4. Content and technical work
- [ ] Page updates per month: [ ]   New pages per month: [ ]
- [ ] Briefs delivered: [ ]   Developer tickets: [ ]   Outreach lists: [ ]
- [ ] Who reviews: [ ]   Who publishes: [ ]   Turnaround for client feedback: [ ]
- [ ] Statement: changes are hypotheses; effects are observed, not promised

## 5. Exclusions
- [ ] No promised mention rate, citation count, position or share of voice
- [ ] Engines / countries / languages not in appendix A
- [ ] Publishing, design, development, PR not itemised above
- [ ] Third-party or client-side changes during the term
- [ ] Legal, regulatory and claims review
- [ ] Anything the client's team must supply: [ ]

## 6. Reporting
- [ ] Measurements reported: [four readings, by definition]
- [ ] Report week: [Monday to Sunday, UTC]
- [ ] Delivery: [client link / call / export]   Link lifetime: [1 / 7 / 30 days]
- [ ] Recipients and roles (owner / editor / viewer): [ ]
- [ ] Raw data at end: [CSV / JSON, date]
- [ ] Branding: client-branded digest, product attribution retained

## 7. Assumptions and dependencies
- [ ] Client provides: [CMS access, approved facts, approvals within N days]
- [ ] Engines may change behaviour; changes are logged, not billed as failure
- [ ] Term, renewal and offboarding (access removed, links revoked): [ ]

## 8. Sign-off
- [ ] Legal review of contract wording completed by: [ ]

Worked example

Northfold Digital scopes a six-month engagement for Quillstone, a document-review software company for legal and compliance teams. Quillstone's rivals in the example are Brieflane and Clausewise.

The first draft of the proposal said: "Increase Quillstone's AI citations by 40% in six months." Northfold rewrote it as follows.

Appendix A lists 20 prompts, run in two countries, for the General audience plus one persona, as written. That is 20 x 2 x 2 x 1 = 80 targets. The proposal counts targets, not runs, because how many runs each target gets depends on which engines it runs on (the persona targets skip some engines). The Quillstone account owns the project, so Quillstone's plan sets the slot limit; the proposal notes that adding ten prompts would add 10 x 2 x 2 = 40 targets and needs Quillstone's plan to allow it.

In month three, Quillstone asks to add a third country. Because the change rule is in the contract, the request becomes a costed change (20 x 1 x 2 x 1 = 40 more targets), not a silent expansion. A drop in citation rate in month four is reported with its definition, and Northfold notes that one week had missed collection. It does not trigger a dispute because no outcome was promised.

Common mistakes and limits

The checklist reduces disputes but cannot remove uncertainty. These are the mistakes to avoid:

• Guaranteeing an outcome. A target of "X% visibility" is a promise about an engine. Set reporting targets, not results.
• Counting prompts instead of targets. Locations, audiences and languages multiply the population and the load on plan slots.
• Letting the prompt set drift. A changed set is a changed measurement, and month-to-month comparisons stop being like for like.
• Promising equivalence with what every person sees. Reports describe how each engine was collected; they do not reproduce every individual's experience.
• Sharing a link and forgetting it. Anyone with a link can read the digest until it expires or is revoked.
• Treating the checklist as a contract. It scopes the work. The legal terms need a lawyer.

What this approach cannot tell you: whether the work will move results, how long that takes, or what an engine will do next month. It only makes sure the commitments you sign are the ones you can keep.

Frequently asked questions

Can I include a visibility target in the scope?

You can include a reporting target, such as reviewing a named measurement weekly. Avoid a results target. If a client insists on a benchmark, label it an aspiration in the appendix, define the measurement precisely, and state that it is not a guaranteed deliverable.

How many prompts should an engagement cover?

There is no universal number. Start from the client's real buying questions and remember that each location, audience and language multiplies the prompt targets that run. Size the set to what the plan allows and to what your team can review, then expand by agreement.

Who should own the project account?

Whoever will pay for the plan and be responsible for the limits should own it, because plan limits, exports and weekly-report access follow the project owner. Decide this before the first prompt is added, and record it in the statement of work.

What if an engine changes and results shift mid-contract?

Say in the contract that engine changes are logged and reported, not treated as your failure. Keep a note of the date, and compare like with like where you can.

Should the client get a login or only reports?

That is a scoping decision. Roles are per project (owner, editor, viewer), and report links are a lighter option that needs no account. Choose based on how much the client wants to explore and how carefully they will handle links.

Can I promise white-labelled reports?

Not on the basis of the documentation. A client digest carries the client's project name and accent colour and keeps a "Prepared with DiscoveredBy" attribution. Describe it as client-branded, and do not promise more.

Next step

Write your scope from the checklist, then set up the monitoring population it describes: the prompts, locations, personas and competitors in appendix A. Sign in or start a project and check that the prompt targets and engines match what you are about to commit to, before the proposal goes out. For the mechanics of the weekly reporting pack, see the client reports documentation, and to find prompts you could pause without losing what they regularly see, see Prompt coverage.