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.
Start With the Goal, Not the Tech
Before any of the tactical questions below, get two things straight. They shape the system prompt and conversation design more than any tier decision does:
- What is this agent actually for? Not "answer questions", a goal. A real goal names the calls to action it should drive toward and the journey it replaces: fewer clicks to a booking, a form, a comparison, or a purchase, not just fewer clicks to an answer. See CTA Buttons for how a goal turns into an actual button or action inside the conversation. If a client can't name what a "successful" conversation ends in, that's the real scoping gap, not which tier to pick.
- What tone should the bot have? Formal or casual, technical or plain-language, brand-voice-matched or generic. This goes directly into the system prompt and shapes every answer the agent gives, regardless of tier or surface.
Once those are answered, the tactical questions below scope how to build it.
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.
- 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.
- Does this need to support multiple languages? If so, which ones, and does the client's content actually exist in each one? A bot can detect and respond in a language it was never given content for, but it can't cite the right page in that language unless that page was ingested too. A Canadian client supporting French and English needs both ingested separately (see Knowledge Foundation), so a question asked in French cites the actual French page, not a machine-translated answer pointing at the English one. This also determines whether the bot's multi-panel welcome screens and any forms in scope need a per-language build.
- Should the bot navigate visitors to a page, not just answer inline? A Directive can send the AI's answer with an invisible tag that navigates to the most relevant URL, switches a panel, or opens a form, and it works from a Modal Dialog or Knowledge Box just as well as a full Bot, with no backend integration required. This is different from question 3: that's about whether the bot can do something on a system, this is about where the answer sends them on the page.
- Does the client have Figma design tokens, or do you want ai12z to generate the brand? Figma Design Tokens JSON produces the most consistent, complete result; without it, brand guidelines can still be generated from screenshots or a plain-language description via Vibe Coding, just with more iteration to get exact colors and fonts right. Either way, this drives the bot's theme, welcome screen styling, and any brand-matched content generated in integrations.
Answers to 1–4 are what actually determine the engagement tier; 5–10 shape scope and delivery, not the tier itself.
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
- AI Brand Creation: Full reference for Figma tokens, screenshots, and Vibe Coding brand generation
- Answer AI: Where an agent's goal, tone, and purpose actually live, in the system prompt
- CTA Buttons: Turning a defined goal into an actual call-to-action inside the conversation