Start with the job, not the bot
Lead qualification is a decision-support workflow. The assistant should help a visitor explain what they need, collect only the information required for the next step, and hand useful context to a person or approved system. It should not imitate a human, promise acceptance, or make sensitive decisions that require accountable review.
Write one sentence that defines success before drafting prompts: for example, “Identify the requested service, timing, and preferred next step, then route the conversation with a clear summary.” This keeps the flow focused. NIST’s AI Risk Management Framework treats risk management as a continuing process across design, development, use, and evaluation rather than a one-time launch check.[1]
Define the boundary
- What the assistant can explain from approved material.
- Which questions it may ask and why each answer is needed.
- What it must refuse, defer, or route to a person.
- Where summaries go and who is allowed to access them.
- How a visitor can reach a human without completing the flow.
- What happens when an integration is unavailable.
Plan a short, useful qualification flow
1. Set expectations immediately
Identify the experience as automated, describe what it can help with, and offer a visible alternative such as a contact page or direct email. Do not hide the human path behind repeated questions. Clear expectations reduce the chance that a visitor mistakes generated text for professional judgment.
2. Ask for intent before identity
Begin with the visitor’s goal or topic. Then ask only the details that change the next step: service fit, current situation, constraints, timeframe, and preferred contact method. Ask for name and contact details when there is a clear reason to follow up—not simply because the interface can collect them.
3. Explain data use in plain language
Tell people what information is collected, why it is needed, where it goes, and what choice they have. The FTC advises businesses to be transparent about data practices, collect only what is needed, secure it, and honor privacy promises.[3] Do not request passwords, payment details, medical details, government identifiers, or other sensitive information in a general lead-qualification chat.
4. Separate qualification from rejection
A structured flow can organize requests and flag missing information. It should not silently discard someone because an answer is ambiguous or does not match a preferred profile. Route uncertain, accessibility-related, high-stakes, or potentially sensitive conversations to a person with the original context preserved.
5. Design the handoff packet
A useful handoff includes the visitor’s stated goal, the questions asked, their answers, unresolved points, consent or contact preference, timestamp, and source page. Keep generated interpretation visibly separate from the visitor’s own words. The implementation can connect a website, inbox or CRM, scheduling, notifications, and reporting, but the business outcome and failure behavior should be specified before selecting a provider. This matches the practical scope described on the AI integrations service page.[5]
6. Make the conversation accessible
Use real buttons and form controls, accessible names, keyboard operation, logical focus movement, readable status messages, and a transcript that does not disappear before it can be reviewed. WCAG’s quick reference provides testable techniques for input purpose, link purpose, focus, labels, and status messages.[4]
Test more than the happy path
Create a written test matrix with expected outcomes. NIST’s Generative AI Profile highlights risks tied to human-AI configuration and recommends evaluation appropriate to the context of use.[2] A polished demo is not evidence that routing, privacy, and fallback behavior work.
Pre-launch test matrix
- A straightforward, in-scope inquiry reaches the correct destination with an accurate summary.
- A poor-fit or unclear inquiry gets a respectful human option rather than a fabricated answer.
- Empty, extremely long, multilingual, and misspelled answers do not break the flow.
- Attempts to override instructions or extract configuration do not expose internal prompts, credentials, or private data.
- Unsupported factual questions produce a bounded response and a human path.
- Duplicate messages, refreshes, closed tabs, and network failures do not create silent data loss or repeated handoffs.
- Keyboard-only and screen-reader flows can open, use, close, and leave the assistant.
- The assistant never submits a form, schedules, or sends a message without a clear user action and confirmation.
Use synthetic test details, not real customer information. Verify the exact destination record after each controlled test. If the interface says a handoff occurred but the destination has no record, the test failed.
Measure usefulness without over-collecting
Track operational signals tied to the defined job: flow completion, human-handoff requests, unanswered topics, routing errors, integration failures, and the amount of manual correction needed in summaries. Do not turn every conversation into a performance claim. Review examples regularly, remove unnecessary questions, update approved knowledge, and retest after prompt, model, content, or integration changes.
Assign an owner for incident review and a way to pause the assistant without taking down the website. Keep the contact route usable when automation is unavailable. A chatbot can reduce friction when it is narrow, transparent, tested, and accountable; technical deployment alone does not guarantee more or better leads.
Keep planning
Sources
These primary and first-party references informed this guide. They are provided so you can verify the underlying guidance.
Planning a website assistant?
Share the job it needs to do, the systems it should connect, and where a person should take over. I’ll help turn that into a clear implementation scope.
Start the conversation