Discovery & Scoping
The tier you recommend should come from what you learn in discovery, not from what's easiest to sell. Get this wrong and you'll either underwhelm a client who needed Run, or overwhelm one who just wanted Crawl.
Discovery Questions
Ask these before recommending a tier:
- What does your current site search or support experience look like today? (A simple site-search box, no search at all, an existing chatbot, a support portal?) — this shapes whether Crawl (layer onto what exists) or Walk/Run (replace it) is the right pitch.
- What CMS or content platform do you run on? Determines whether an event-driven connector exists or scheduled web scraping is the ingestion path — see Knowledge Foundation.
- Do you need this to take action, or just answer questions? If the honest answer is "just answer questions for now," that's a Crawl or Walk engagement — don't oversell Run.
- If action is needed, which systems? CRM, commerce platform, ticketing/support system, booking/scheduling — each maps to a specific integration path in Integrations & Actions.
- Is this a regulated or compliance-sensitive industry? (Healthcare, life sciences, financial services) — flags a likely need for the controlled/compliance-first answer mode in Trust & Governance.
- Who owns follow-through after this engagement? — technical contact for connector/integration credentials, content owner for ingestion, brand owner for styling.
- Is this one site, or multiple brands/properties? — determines whether Managing Multiple Clients's sub-organization model applies from day one.
Answers to 1–4 are what actually determine the engagement tier; 5–7 shape scope and delivery, not the tier itself.
Guardrails for Live Demos
If you're demoing a live deployment — the client's own or a reference example — a few rules keep this professional and safe:
- Never demo another client's real data, even anonymized, even as a "typical example." Use the fallback example below instead.
- Redact PII before the session, not live on screen — if a demo conversation includes a real name, email, or other personal detail, blur or replace it in advance rather than live.
- Confirm what's appropriate to show the room — a working session with a client's core team is different from a demo in front of their leadership or board.
Fallback Demo Pattern
When live client data isn't available yet, use a consistent example rather than improvising a new one per engagement — the deck examples referenced throughout this guide (a resort booking assistant, an HVAC parts locator, a ski-gear commerce assistant) work well because they're visual, easy to follow, and don't require explaining an unfamiliar industry before the AI capability itself lands.
Deliverable Template
Every scoping conversation should end with the same structure handed to the client, not a different format per engagement:
| Field | Description |
|---|---|
| Recommended tier | Crawl / Walk / Run, with the specific reasoning from discovery |
| Surface | Which deployment surface(s) from Deployment Surfaces |
| Content source | Connector, scraping, or manual ingestion — see Knowledge Foundation |
| Integrations needed | Named systems, if any |
| Timeline | Realistic estimate for the recommended tier |
| Owner | Client-side technical and content contacts |
Related Documentation
- Engagement Tiers — What discovery answers actually determine
- The Agenda — How this scoping conversation fits into the live session run of show