Start with the enquiry problem
A promising enquiry reaches your website with an unclear brief. The form asks for a name, email address, and message. Your team replies with the same questions it asks every new prospect, then copies the answers into a CRM. Another enquiry sits untouched because nobody can tell who owns it.
AI lead qualification is a journey design problem. Collect enough context, apply transparent rules, pass a usable record to the right person, and recover when the system can't proceed.
Define the operational problem first. It may be incomplete enquiries, repeated discovery questions, slow assignment, poor CRM context, or inconsistent treatment of similar requests. Record what happens now, including completion, response time, rework, routing errors, and enquiries incorrectly rejected. That baseline keeps the project tied to an observable problem without assuming AI will improve it.
If enquiry handling is only one of several candidates, first use the broader framework for deciding which workflow to automate. This guide begins once website intake is the chosen route.
Decide whether the journey needs AI
A static form is often the right interface when the questions and outcomes are predictable. Rules can adapt later questions, score supplied answers, and route a submission without asking a model to interpret anything. AI becomes useful when people describe varied situations in their own words and a bounded summary or category would reduce genuine work.
| Approach | Best fit | Data risk | Accessibility work | Maintenance |
|---|---|---|---|---|
| Static form | stable questions and one destination | lower | familiar controls and errors | low |
| Adaptive form | known branches and eligibility rules | lower to moderate | focus, progress, and hidden-field behaviour | moderate |
| AI-assisted chat | varied language and useful follow-up questions | higher | conversation state, keyboard use, timeouts, and fallback | high |
| AI behind the form | structured intake with a summary or category | moderate | form remains primary | moderate |
Current form products show that these layers can remain separate. Typeform's lead qualification workflow documentation describes AI-generated questions alongside editable scoring rules, score-based endings, redirects, and follow-up workflows. The documentation establishes that the pattern exists, while offering no independent evidence of higher conversions or revenue.
Choose the least complex approach that handles the variation you actually see. If postcode, service type, and timeframe determine the next step, rules are easier to test and explain. If a paragraph needs to be condensed into a factual brief for a consultant, a model may have a narrow supporting job.
Map the route before choosing a tool
Draw the whole journey from the visitor's first choice to the team's next action. Include the website, validation, rules, any model task, the CRM, the receiving person, and the fallback. A tool demo rarely shows all those joins.
For each connector, define the payload, success signal, timeout response, and alert owner. A completed chat isn't a completed handoff if its CRM write failed.
Collect only the context qualification requires
Start with the decision your team needs to make. Work backwards to the minimum facts that support it.
For an expert-led service business, useful facts may include the requested outcome, service or project scope, location, timing, readiness, constraints, and preferred contact method. Budget, authority, need, and timing can contribute, but BANT isn't a complete model for every service. Location, risk, required expertise, and whether the client can supply essential inputs may matter more. This is Off Piste's strategic synthesis, not a universal scoring standard.
Separate three kinds of data.
- Required facts are necessary to provide or route the requested service.
- Optional context helps the team prepare but doesn't block submission.
- Sensitive or high-risk information should be excluded unless there is a defined need, lawful handling, and an appropriate protected channel.
The OAIC guidance on commercially available AI says privacy obligations apply to personal information entered into and generated by AI where the Privacy Act applies. It also treats inferred information about an identifiable person as personal information, calls for necessity, due diligence, accuracy controls, and human oversight, and recommends that organisations don't enter personal or sensitive information into publicly available generative AI tools as a matter of best practice.
Privacy Act coverage and other sector duties vary. Confirm your organisation's position and obtain specialist advice for sensitive data, regulated services, or decisions with a significant effect.
The W3C WAI Forms Tutorial recommends asking only for information required to complete the process. It also covers explicit labels, instructions, validation, notifications, logical multi-step forms, and manageable time limits. Apply those requirements to both the form and conversational route. Let people review and correct captured facts before submission.
Separate rules, model assistance and human decisions
Qualification becomes hard to govern when a single AI score hides several different decisions. Assign each task to the simplest responsible layer and record the reason for the route.
| Information or decision | Owner | Evidence kept | Failure response |
|---|---|---|---|
| Visitor's scope, suburb, timing, and contact choice | visitor, with validation | original answers and corrections | ask again or save for manual follow-up |
| Service area, minimum scope, required field, and duplicate checks | deterministic rules | rule version and matched condition | show the applicable next step or queue for review |
| Summary, intent category, or missing-context suggestion | bounded model | source answers, output, model version, and uncertainty | discard output and pass original answers |
| Ambiguous fit, exception, sensitive case, or consequential rejection | named person | review decision and reason | contact the visitor or use the manual route |
Rules should own conditions you can state in advance. A model can summarise the visitor's own words, suggest a category from an approved list, or flag that a required fact appears to be missing. It shouldn't invent facts, silently change answers, or issue an irreversible acceptance or rejection.
Keep any service facts and eligibility rules in an owned source. The guide to building an AI-ready knowledge base explains how to prepare approved, current material for reliable retrieval and answers.
A score can order human review, but the contributing fields and weights should be visible. Give a person authority to overturn the route. Give the visitor a way to correct the information behind it. The Australian Government's October 2025 Guidance for AI Adoption implementation practices organises responsible adoption around accountability, impact assessment, risk management, transparency, testing and monitoring, and meaningful human control. Translate those practices into named owners and approval gates for this route. Use the broader AI governance checklist for organisation-wide controls.
Design the CRM handoff as a usable record
The CRM record should let a person understand what the visitor wants, what the system did, and what must happen next without reading a polished summary as if it were the source.
At minimum, capture the original answers, validated fields, deterministic rule outcomes and rule version, any model summary with its source and uncertainty, the visitor's consent state, the route taken, timestamps, failure or exception flags, and the next action with an owner.
Store the model summary beside the original input. Mark inferred categories as inferences. If the CRM can't accept the full payload, retain a secure linked record or reduce the automation's role. Keep uncertainty visible and auditable.
The receiving queue must confirm that it accepted the record. If it doesn't, preserve the enquiry and alert an owner. The detailed design for escalation, context transfer, and customer expectations sits in the guide to a safe human handoff.
Build privacy, disclosure and accessibility into the route
Tell visitors when they're interacting with AI, what it can do, why you need their information, how it will be used, and how they can choose another route. The OAIC guidance specifically calls for public-facing AI such as chatbots to be clearly identified and for privacy notices to explain AI use.
Make that disclosure useful at the point of choice. A short message might explain that the assistant can collect service details and prepare an enquiry for the team, can't approve work or provide a final quote, and will save chosen details for follow-up. The wording must match the actual system and privacy notice.
Keep a comparable non-AI form or human route visible at the point of choice and throughout the conversation. Preserve keyboard operation, visible focus, programmatic labels, clear errors, announced status changes, progress information, and a way to extend or avoid timeouts. When a conversation fails, retain permitted answers with the visitor's agreement or let them restart without losing access to the service.
Review the supplier before sending live enquiry data. Check where data travels, who can access it, whether prompts and outputs train another model, how deletion and retention work, what security controls apply, and how a model or service change is communicated. Record the decision and review it when the supplier, purpose, or data changes.
Test the journey before live enquiries depend on it
Test the route against written acceptance cases that include normal use, edge cases, and failure. The NIST Generative AI Profile supports documented evaluation, monitoring, incident processes, human intervention, and management of systems that depart from intended behaviour.
Your pre-launch set should include:
- A clear service fit with complete information.
- A clear non-fit that receives an accurate, respectful next step and can request review.
- An ambiguous request that reaches a person without a fabricated conclusion.
- Missing, contradictory, or corrected information.
- Sensitive information the system isn't approved to process.
- Prompt injection, abusive text, and instructions to ignore the qualification boundary.
- Model refusal, timeout, unavailable knowledge, and malformed output.
- CRM failure, duplicate records, and an unaccepted team transfer.
- Keyboard-only, screen-reader, zoom, mobile, slow-connection, and timeout tasks.
- The complete non-AI route, including confirmation and recovery.
For each case, record the expected result, actual result, evidence, owner, and release decision. Define stop conditions before launch. Examples include a consequential false rejection, personal information crossing an unapproved boundary, a broken fallback, or a CRM failure that loses the original enquiry.
Measure qualified outcomes and operating effort
A successful submission is only one signal. Measure whether the route produces correct, usable outcomes and how much work it creates.
| Measure | Check | Owner or intervention trigger |
|---|---|---|
| Completion | visitor reaches a confirmed next step | journey owner reviews unusual abandonment |
| Routing accuracy | sampled records reached the correct queue | process owner investigates misroutes |
| False rejection | suitable enquiries were incorrectly screened out | human review pauses the rejecting rule |
| Handoff success | CRM and receiving queue accepted usable context | integration owner handles failed transfers |
| Correction rate | visitor or staff changed captured facts or summaries | content or model owner inspects the cause |
| Response time | elapsed time to the promised human action | queue owner addresses missed expectations |
| Review effort | staff time to verify, repair, or re-enter records | workflow owner checks whether automation adds work |
| Privacy incident | data crossed an unapproved purpose or system boundary | incident owner pauses and investigates |
| Accessibility failure | a person couldn't complete, correct, or exit | website owner fixes the route before expansion |
Set your baseline and review cadence before release. Don't choose benchmark values from vendor claims. Compare your route with its own previous process and verify a sample of outcomes. The full framework for total cost, exceptions, verified outcomes, and scale, fix, or stop decisions is in the guide to measuring AI workflow ROI and reliability.
Choose the smallest reliable version
The first version may be an accessible form with better fields, deterministic routing, and a CRM payload. That can solve the enquiry problem without a conversational interface. A later version might add a bounded summary after you have enough real submissions to test it safely.
Write down the visitor choice, required facts, rules, optional model task, human-reserved decisions, CRM payload, fallback, owners, and acceptance cases. If any part has no owner or recovery path, reduce the scope before launch.
Choose the smallest route your team can observe, correct, and maintain. When that route spans form design, service content, accessibility, analytics, and CRM integration, design the website and its supporting systems as one journey.