AI Chatbot Discovery Questions: Build a Pre-Proposal Qualification Record

TL;DR

• Use AI chatbot discovery questions to qualify one specific workflow before discussing features, timelines, or a proposal.
• Examine the use case, approved knowledge sources, security and data expectations, success measures, and conditions that should pause the sale.
• End with one decision: proceed to scoping, narrow the pilot, fix content or verify requirements, or defer the opportunity.
• Record the reason for that decision, the next action, and the person responsible for it.

A broad request for an AI chatbot is not yet a project. Before proposing a solution, an agency needs to know who requires help, which recurring interaction matters, what information can be trusted, where human judgment remains necessary, and what evidence would justify continuing. Discovery turns those unknowns into a qualification record without prematurely promising scope, timing, or results.

Key Takeaways

• Discovery should end in a decision, not a feature wish list.
• One audience, one repeated problem, and one next action are easier to qualify than a general-purpose assistant.
• Current, approved, maintainable content is a qualification gate.
• Sensitive or high-stakes requests need named owners and clear escalation paths.
• Success measures must match the selected workflow and the records the client can access.

Decide What the Discovery Call Must Produce

A discovery call is complete when its answers support one of four outcomes:

1. Proceed to scoping. The workflow, audience, sources, owners, boundaries, and prospective success signals are clear enough to define a delivery boundary.
2. Narrow the pilot. The general idea may be useful, but only a bounded, lower-risk part is ready to test.
3. Fix or verify first. Content conflicts, approval gaps, capability questions, or security requirements must be resolved before responsible scoping can begin.
4. Defer the opportunity. The proposed workflow lacks a specific problem, reliable source truth, accountable ownership, acceptable controls, or an observable result.

Record the reason for the decision. “Narrow the pilot because refund exceptions require staff judgment” creates a usable next step. “Client interested in AI” does not.

Discovery and scoping are separate. Discovery determines viability and identifies the problem worth addressing. Scoping converts a qualified problem into a written delivery boundary, including what will and will not be delivered. Do not allow assumptions from discovery to become proposal commitments without verification.

Ask Use-Case Qualification Questions First

Begin with the operating problem rather than the desired technology. Ask:

• Who will use the assistant?
• Where will the interaction begin: a public website, portal, product, phone channel, or somewhere else?
• What repeated question or task creates the current pain?
• How is that interaction handled now, and who owns it?
• Which requests involve retrieving information, and which require judgment, approval, negotiation, or empathy?
• What should happen after a useful answer: show a resource, capture agreed details, request a booking, create a ticket, or hand off to a person?
• Which topics, users, pages, or actions must be excluded?
• What should happen when an answer is unavailable or uncertain?

Ask for concrete examples when the initial answer is vague. If a prospect says support demand is high, ask which questions recur and where the approved answers live. If the goal is lead qualification, ask which information makes a lead usable and who is responsible for follow-up.

Consider a service company receiving questions about service areas, availability, and estimates. Service-area questions may be suitable if the rules are documented. Availability may depend on a current scheduling system. Estimates may require human review because site conditions affect the answer. A defensible first workflow might answer approved service-area questions and route estimate requests to staff rather than attempt to automate the entire sales process.

Each answer should change or confirm the proposed boundary. If the agency cannot name the user, repeated problem, source of truth, permitted job, and next action, the workflow is not ready for a proposal.

Test Knowledge and Content Readiness

Once the workflow is clear, determine whether the client has current, approved information to support it. The volume of available material does not establish readiness; a large archive may contain stale, duplicated, contradictory, sensitive, or unapproved content.

Ask:

• Which website pages, documents, FAQs, policies, catalogs, videos, or structured records contain the answers?
• Who approved those sources for the intended audience?
• Which source is authoritative when materials disagree?
• What information changes frequently, such as prices, availability, eligibility, products, events, or policies?
• Who owns each changing source and its updates?
• Which common questions have no approved answer?
• Which material is outdated, duplicated, sensitive, unsupported, or intended only for internal use?
• Which topics require a refusal, fallback, or human handoff?

Do not accept “it is on the website” as sufficient evidence. Identify the specific source and the person responsible for its accuracy. Accessible content may still be unsuitable for customer-facing answers.

If current service pages and FAQs exist but pricing changes frequently and two policy documents conflict, exclude pricing from the initial workflow and send the policy conflict to the client’s decision owner. Content cleanup or fact verification is a legitimate pre-build outcome.

The qualification record should identify approved sources, exclusions, gaps, freshness concerns, contradictions, source owners, update responsibilities, and do-not-answer topics. Detailed preparation can follow after the opportunity qualifies.

Clarify Security, Data, and Review Expectations

Security discovery should map the proposed data path and identify the people authorized to review it. It should not produce an unconditional security, privacy, legal, or compliance conclusion.

Walk through the proposed workflow:

• What source files will be connected?
• What might users enter in prompts or uploads?
• What context could be used to form an answer?
• Could conversations contain contact details, account information, order data, or other sensitive fields?
• Where should leads or captured information be sent?
• Which integrations or external systems would read or write data?
• What conversation, activity, feedback, source-use, or access logs does the client expect?

Then establish the boundaries:

• Which data is allowed, prohibited, or unnecessary for the first version?
• Who may access sources, conversations, leads, settings, and integrations?
• Must clients, departments, or use cases remain in separate workspaces?
• Does the client have requirements involving retention, deletion, export, residency, subprocessors, or model providers?
• Which vendor documents or verified answers does procurement require?
• Who owns approval: security, privacy, legal, IT, procurement, or a business leader?
• Which sensitive or high-stakes requests must always reach a qualified person?

Separate workflow facts from verification items and approval decisions. The agency can document choices it controls, such as the proposed form fields. The platform vendor should verify platform-dependent behavior, controls, and documentation. The client’s authorized reviewers decide whether the deployment meets its policies and obligations.

If the prospect cannot approve collecting a phone number, remove that field or narrow the pilot to non-sensitive questions. If a particular retention rule, region, agreement, or provider arrangement is required, record it for verification rather than translating a general statement into a deployment-specific promise.

Ask What Success Would Look Like

Ask the client to complete this sentence: “This workflow will be worth continuing if we can observe…”

Build the answer from evidence connected to the selected workflow:

• Usage signal: Are the intended users engaging with the assistant for the defined job?
• Answer-quality signal: Do reviewed answers use approved information, remain current, and respect the agreed boundaries?
• Workflow outcome: Are users reaching the intended next step, such as a completed intake, resource, booking request, ticket, or handoff?
• Handoff quality: Does the receiving person obtain enough context to continue effectively?
• Content-gap signal: Do recurring unanswered questions reveal missing or unclear source material?

Ask whether a baseline exists, where it is recorded, and who owns it. Potential records may include support categories, site-search queries, form submissions, booking records, CRM fields, or reviewed conversations. If there is no baseline, decide whether the pilot can establish one or whether the initial decision must rely on narrower evidence.

For a lead-qualification workflow, an observable result could be completion of the agreed fields followed by a handoff that the designated sales owner considers usable. That result does not by itself establish incremental revenue. Claims about ROI, conversion, support deflection, or revenue attribution require suitable baseline and attribution data.

Finish by asking what decision the evidence should enable. The answer might be to continue, revise the sources, change the handoff, narrow the audience, or stop the workflow.

Recognize Red Flags That Should Pause the Sale

Pause or narrow the opportunity when:

• The prospect cannot name a specific user problem or repeated interaction.
• No current, approved, maintainable source of truth exists.
• Sources conflict and nobody has authority to resolve them.
• The buyer expects broad autonomy, guaranteed accuracy, or staff replacement.
• A sensitive or regulated workflow lacks qualified review and escalation.
• The sale depends on an unverified security, compliance, integration, or platform claim.
• Nobody owns unanswered questions, handoffs, content updates, or conversation review.
• The client cannot identify an observable result or relevant records.
• A required capability is assumed rather than verified for the proposed deployment.
• The agency is pressured to promise scope, timing, or outcomes before dependencies are known.

A red flag does not always require ending the conversation. It means the dependency must not be treated as settled. The agency can narrow the workflow, seek a decision from the appropriate owner, request current documentation, or defer the opportunity.

For example, a request for an assistant to make regulated decisions from unapproved internal notes—with no qualified reviewer and an expectation of guaranteed results—is not ready for a quote. Removing the decision-making task and limiting the workflow to approved public information may create a different opportunity, but that revised workflow must be qualified separately.

Turn the Answers Into One Next Decision

Close the call by reading back a short qualification record containing:

• the selected workflow;
• its audience and entry point;
• the repeated problem and intended next action;
• approved sources, gaps, conflicts, and excluded topics;
• the workflow owner and required approval owners;
• data, security, integration, or capability questions awaiting verification;
• the prospective success signal and available baseline;
• explicit exclusions;
• the decision to proceed, narrow, fix or verify, or defer;
• the named owner and next action.

This record is not a proposal. It is the evidence used to decide whether proposal work should begin.

A useful closing statement could be: “We will narrow the pilot to product-policy questions on the help page. The client’s content owner will resolve the returns-policy conflict, and the security owner will confirm the proposed lead-data path. The agency will reconsider scoping after those decisions are recorded.”

Evaluate Platform Fit After the Client Opportunity Is Qualified

Only after qualification should the agency evaluate a platform against the documented workflow. If InsertChat is being considered, treat it as a candidate for a bounded, source-grounded, human-controlled use case—not as proof that the client opportunity is viable.

Ask the vendor to verify whether the proposed deployment can:

• limit answers to the client’s approved sources and present source citations;
• test representative questions before launch;
• respect excluded topics and defined fallback rules;
• preserve the context required for human handoff;
• provide the conversation, source-use, handoff, and content-gap visibility needed for the chosen success signal; and
• satisfy the deployment-specific security, data, integration, and procurement requirements recorded during discovery.

Obtain current evidence for each required capability before making commitments. Do not infer deployment suitability from a general feature description.

For a bounded, non-sensitive workflow, the next step may be a controlled test using approved content and representative questions. For a workflow involving complex security, data, integration, or procurement requirements, contact the vendor and request the relevant current documentation before scoping.

The qualification rule remains the same regardless of platform: use discovery to decide whether one client workflow is ready for a responsible next step.