What belongs in a HubSpot AEO project scope?
Name the pages, approved changes, client inputs, exclusions and live acceptance checks. The completed fictional brief below defines one implementation that an agency can estimate and a client can accept. Adapt it to the real site before quoting.
A completed project scope
Fictional example: Northbridge Operations wants buyers to understand its remote HubSpot onboarding offer for Canadian B2B teams. These are illustrative project terms, not a SuperSchema package or customer engagement.
| Scope field | Agreed example |
|---|---|
| Objective | Make delivery area, migration exclusion and enquiry route consistent across the public website |
| Website | https://example.com, one domain, English |
| Included pages | /, /about, /services/onboarding, /pricing, /contact |
| Approved service facts | Remote delivery for Canadian B2B teams; migration and custom integrations quoted separately |
| Content changes | Correct conflicting scope statements on the homepage, service and pricing pages; align contact labels with the enquiry destination |
| Technical changes | Correct existing provider and service descriptions on the named pages; verify shared-template impact before editing |
| External review | Review the company LinkedIn profile and one agency directory listing; edit the controlled profile and submit a directory correction if needed |
| Client inputs | Current offer, existing markup locations, CMS access, named service approver and publishing owner |
| Revision allowance | One consolidated client revision of the agreed changes |
| Completion | Five live pages match approved scope and contact route; affected markup passes syntax and vocabulary checks; unresolved external correction is recorded separately |
| Handover | Changed URLs, before/after excerpts, check results, unresolved issues and next owner |
| Exclusions | New integrations, CRM configuration, redesign, additional languages, new pages and ongoing monitoring |
A correction request is not proof that a directory changed. In this example, an unresolved directory request does not prevent acceptance of the website work, provided its status and owner appear in the handover.
The HubSpot AEO guide explains the website foundations. Use the agency delivery workflow for the broader process; use this brief to define one bounded release. Here, agent readiness concerns public information used to evaluate a business, not building an agent that transacts for the client.
What should the client provide?
Ask for the current service description, inclusions, exclusions, delivery area, quote conditions, contact route and evidence supporting important claims. Assign one person to approve those facts.
The agency also needs appropriate access for the agreed HubSpot changes, a publishing owner and an agreed way to test the enquiry route. Identify any developer or template dependency before promising a delivery date. Access to the public website work does not automatically require a copy of the client's CRM data.
Use the audit checklist to record gaps. If a fact remains unresolved, retain it as an open decision and state what work it blocks.
Define the deliverables and acceptance checks
| Deliverable | What the client receives | Acceptance check |
|---|---|---|
| Approved fact record | Current identity, service scope, eligibility and commercial conditions, with sources and approver | Client owner confirms the facts used in the release |
| Page findings | A short issue list tied to URLs and buyer questions | Each issue has evidence, priority and proposed action |
| Content changes | Agreed edits to the named pages, including a clearer service description | Published copy matches the approved facts and makes scope and next steps clear |
| Technical corrections | Agreed fixes to page delivery, metadata, links and existing markup | The named checks pass on the affected live URLs |
| External consistency record | Conflicts found in the named profiles, with corrections or requests documented | Each conflict has an owner and a recorded status |
| Handover | Changed URLs, before/after evidence, open issues and maintenance instructions | The client can see what shipped and who owns the next review |
Tie technical work to identified issues. An implementation task should name the page, defect and acceptance check. “Optimize everything for AI” leaves both sides guessing about completion.
For the service-page deliverable, use the annotated writing example. For markup changes, retain the existing implementation where it is accurate and use the validation workflow to check the live result.
How do you control changes to the scope?
Compare each new request with the named pages, deliverables and acceptance checks. Correcting a mistake in agreed work stays within that work; adding another service, language or integration requires a separate decision.
For the fictional brief, a request to add a sixth service page is outside scope. Record the request, estimate its effect on effort and delivery, and ask the client to approve the change before adding it. If an unknown shared-template defect affects all five pages, identify which agreed checks it blocks and resolve the implementation responsibility before continuing.
Before quoting, copy the table into the project tracker and replace every example value. Set delivery dates only after access, source material and approval availability are confirmed.
What should stay outside the first scope?
List exclusions clearly. A sensible starting boundary could exclude a site redesign, additional languages, new integrations, full directory cleanup, paid promotion and ongoing content production.
Also separate private CRM configuration, MCP or connector development, and automated booking or transaction capabilities. Those are distinct projects with their own access and testing requirements.
Do not promise rankings, citations, recommendation frequency or a sales result as acceptance criteria. The agency can commit to delivered changes and defined checks. Visibility and revenue require observation after the work ships.
Where do HubSpot recommendations fit?
Use relevant recommendations as findings to investigate, not as approved scope. HubSpot's AEO recommendations documentation describes audits, recommended actions and content generation, subject to account access. The recommendation-to-action guide shows how to turn a finding into a named implementation task.
How should you price and extend the work?
Estimate the work behind the named deliverables using the implementation budget worksheet: fact review, writing, CMS edits, technical changes, client revisions and verification. Account for template complexity and dependencies before setting a fixed fee. Separate software costs and third-party work where they are additional.
An initial project can lead to maintenance when there is recurring work to do. Examples include reviewing changed services, checking affected pages after a redesign, correcting new inconsistencies and maintaining a dated evidence record. Specify the cadence, page coverage and included corrections before proposing a retainer.
This is a pricing method, not a market-rate claim. A monthly fee should correspond to identifiable work and ownership.
What should the first handover show?
Show the original issue, approved change, live URL and dated verification result. Add any known limitations and the next owner. For example: “Service scope now states that migration is separately quoted; the homepage and service page agree; the external directory correction is still pending.”
If visibility observation is included, agree a small set of buyer questions before the edits. Repeat them by engine and retain the responses and sources. Keep crawler visits, mentions, citations and enquiries separate, following the measurement guide.
That gives the client an inspectable first outcome: a clearer public offer, fewer unresolved contradictions and a record of the work completed. It also gives the agency a concrete basis for deciding what should happen next.