An AI website assistant is ready for contractor enquiries only when its job is narrow, its answers come from approved business information, its actions are constrained, and a person can take over before an uncertain conversation becomes a false promise. A polished chat window is not acceptance evidence. Neither is a handful of friendly demo questions.

The launch decision is whether the assistant can collect and route the intended enquiries without misrepresenting services, service areas, availability, qualifications, prices, warranties, or emergency response. That requires business, privacy, security, accessibility, and operational checks together.

This guide owns acceptance for a conversational AI intake assistant. The contractor quote-form checklist owns deterministic form submission and CRM delivery. The online booking guide owns calendar rules and confirmed appointments. The missed-call text-back guide owns SMS consent, delivery, and reply handling. Treat those as connected systems, not as proof that the AI layer is safe or accurate.

Write the decision before choosing the assistant

Start with one sentence that an owner can approve:

The assistant may answer approved pre-sale questions, collect the minimum details required for follow-up, and offer an authorized next step; it must defer uncertain, sensitive, safety-critical, price-binding, or out-of-scope decisions to a person.

Then name the intended outcome. Examples include routing a residential service request, preparing a non-binding estimate intake, or helping a visitor find the correct booking path. “Answer everything” is not a testable outcome.

Use four acceptance states:

  • Pass: required evidence exists and every launch-blocking scenario behaves as approved.
  • Pass with a recorded limitation: a bounded limitation has an owner, compensating control, expiry date, and retest plan.
  • Fail: a required answer, handoff, privacy notice, control, or test is missing.
  • Not applicable: the capability is absent, and the released configuration proves it is absent.

Do not turn “not applicable” into a shortcut. If the assistant can invoke a calendar, send a message, update a CRM record, or retrieve external content, those capabilities belong in the review even if the happy-path demo did not use them.

Define allowed, restricted, and prohibited work

Create a capability register before writing prompts. The boundary should be understandable without reading model or vendor documentation.

| Capability | Example | Default launch rule | | --- | --- | --- | | Informational answer | Explain an approved service in plain language | Allow only from an approved source | | Intake question | Ask for service type, location, timing, and contact preference | Allow only when each field has a stated purpose | | Routing | Direct the enquiry to a service page, form, calendar, or person | Allow using documented rules | | Record creation | Create a lead or conversation in the CRM | Allow only with validated fields, idempotency, and an audit trail | | Appointment action | Show openings, request a time, or confirm a booking | Separate these states; confirmation requires the calendar system's authoritative response | | Estimate or price | Give a range, calculate a quote, or bind a price | Prohibit unless an approved deterministic rule and disclaimer exist | | Safety or emergency advice | Diagnose hazards or claim emergency response | Refuse and provide the approved urgent path | | Eligibility or compliance decision | Decide permits, financing, insurance, code, warranty, or regulated eligibility | Route to an authorized person or authoritative body |

Separate conversation from authority. An assistant may gather a preferred appointment time without having authority to confirm it. It may explain the factors that affect an estimate without producing a binding amount. It may identify that an enquiry sounds urgent without promising dispatch time.

The Competition Bureau says materially false or misleading representations used to promote a service are prohibited, and performance claims require adequate and proper testing. The assistant's words are part of the business's public representation. Do not treat generated text as an informal side channel outside marketing review.

Build an approved knowledge register

The assistant needs a controlled source of business truth. A general model's prior knowledge is not evidence for the contractor's current services.

For each answerable subject, record:

  • the approved statement;
  • source document or system;
  • business owner;
  • jurisdiction or service area;
  • effective date and review date;
  • allowed wording and required qualification;
  • prohibited inference; and
  • what the assistant must do when the source is silent or contradictory.

At minimum, cover business name, contact channels, service categories, exclusions, service areas, ordinary hours, urgent-contact policy, qualifications that may be stated, estimate process, deposit policy, warranties, promotions, financing language, booking rules, and privacy contact. If a claim changes by province, municipality, product, technician, property type, or contract, encode that condition rather than presenting a universal answer.

Do not upload a pile of old brochures, web pages, proposals, and emails and call it a knowledge base. Remove superseded material. Identify conflicts. Keep internal instructions separate from public content. Record which version produced the released assistant's answers.

Test the absence path explicitly. When an answer is not approved, the desired response is a concise limitation and useful handoff, not a plausible completion. A safe “I do not have an approved answer for that” is better than an invented service promise.

A public-facing assistant should identify itself as automated before asking for personal information. The Office of the Privacy Commissioner of Canada's generative AI principles say people interacting with a public-facing generative AI tool should be aware that it is AI and be informed about privacy risks and mitigations. They also call for clear information about what, how, when, and why personal information is collected, used, or disclosed.

The opening and collection notices should answer, in plain language:

  • that the visitor is interacting with an AI assistant;
  • what the assistant can and cannot do;
  • which details are optional or required;
  • why each collected detail is needed;
  • where the information goes;
  • whether conversations are stored, reviewed, or used to improve a system;
  • how long relevant records are retained;
  • how to reach a person or use a non-AI path; and
  • where to read the applicable privacy information.

Do not hide the important points behind a generic “By continuing, you agree” line. Canadian privacy guidance emphasizes key collection, use, and disclosure information and expects organizations to be able to demonstrate that consent was understandable for the intended audience. The correct legal authority and form of consent depend on the information, purpose, jurisdiction, sensitivity, reasonable expectations, and risk. Obtain qualified privacy advice where the answer is not clear.

Collect the minimum needed for the current step. A visitor may be able to ask a general service question without giving a name, phone number, full address, property history, or photos. Ask for contact details only when moving to follow-up. Avoid soliciting health, financial, identity, security, or other sensitive information through a general intake assistant unless a documented, protected process genuinely requires it.

Separate dialogue from tools and business actions

Tool access changes the risk. An assistant that only drafts a response is different from one that can send an email, create a CRM contact, book a time, issue a payment link, modify a record, or fetch arbitrary web content.

Create an action matrix:

| Action | Authority | Required validation | Confirmation shown to visitor | Recovery path | | --- | --- | --- | --- | --- | | Create lead | Approved intake purpose | Required fields, format, duplicate key, consent state | Enquiry received, not job accepted | Queue, retry, or manual entry | | Request appointment | Visitor request plus booking rules | Service, area, duration, availability | Requested versus confirmed state | Alternate times or human review | | Send follow-up | Approved channel and message | Destination, template, consent, quiet-hour rules where applicable | Channel and expected next step | Delivery monitoring and reply owner | | Escalate to person | Handoff rule | Queue, hours, urgency, context package | Realistic response expectation | Backup queue and stale-item alert |

OWASP describes excessive agency as excessive functionality, permissions, or autonomy. Give the assistant the fewest actions and narrowest data access needed for the approved outcome. Prefer structured parameters, allowlists, server-side validation, and deterministic policy checks. Do not let generated text directly become an API instruction, database query, destination address, price, or booking confirmation.

Require human approval for high-impact or irreversible actions. A model's confidence score is not authority. If a connected system fails, show an accurate fallback state. Never tell the visitor that a booking or message succeeded until the authoritative system confirms it.

Design handoff before the assistant needs it

“Talk to a human” must be a real operating path. Define what triggers handoff, who receives it, what context is included, and what happens outside staffed hours.

Handoff triggers should include:

  • the visitor asks for a person;
  • the assistant lacks an approved answer;
  • sources conflict or are stale;
  • the conversation concerns safety, emergencies, complaints, damage, legal threats, permits, insurance, warranties, payments, or sensitive information;
  • repeated clarification does not resolve the request;
  • tool validation or delivery fails;
  • abuse, prompt injection, or unusual automation is detected; and
  • the visitor disputes an AI-generated statement or recorded detail.

The handoff package should contain only the context needed by the receiving person: contact preference, stated request, collected fields, material disclosures, consent state, transcript or concise summary where authorized, detected risk, failed actions, and source references used. Label generated summaries as generated and provide access to the underlying record where appropriate.

Set honest expectations. If nobody monitors the queue overnight, do not promise 24/7 service merely because the assistant is available. State when a person is expected to review the enquiry, who owns overdue items, and which urgent channel the business has actually approved.

Defend instructions, data, and connected actions

Visitors and retrieved content are untrusted inputs. OWASP defines prompt injection as input that manipulates an LLM's behaviour and notes possible effects such as control bypass, data exposure, prompt leakage, and unauthorized tool actions.

Security acceptance should verify that:

  • system instructions, approved knowledge, user input, and tool output are separated by role and structure;
  • the assistant cannot reveal hidden instructions, secrets, other visitors' data, private documents, or internal identifiers;
  • external pages, files, reviews, emails, and CRM notes are treated as data, not instructions;
  • tool names, parameters, destinations, permissions, and rate limits are constrained outside the model;
  • rendered output is sanitized and cannot introduce unsafe HTML, scripts, redirects, or deceptive links;
  • logs avoid secrets and unnecessary personal information;
  • administrative access uses strong authentication and least privilege;
  • suspicious patterns, repeated failures, and unusual tool use generate reviewable signals; and
  • an owner can disable the assistant or individual tools without taking down the website.

Keyword filters alone are not acceptance evidence. Test direct requests to ignore instructions, encoded or misspelled variants, multi-turn manipulation, requests for system text, attempts to obtain another lead's details, malicious content in uploaded or retrieved material, and attempts to make tools operate outside the visitor's request.

Assume some attacks will evolve past the test set. Layer controls so a model error cannot by itself authorize a sensitive action.

Make the conversation usable and accessible

The assistant should not become the only route to contact the business. Keep a visible phone, form, email, or other approved alternative appropriate to the service.

Verify keyboard operation, visible focus, meaningful labels, logical reading order, adequate contrast, zoom and reflow, error identification, and screen-reader announcements. Conversation updates, waiting states, delivery results, and errors need programmatic semantics. W3C's guidance for WCAG 2.2 status messages explains that users of assistive technology should be notified of important changes without forcing focus to move, while warning that overly chatty live regions can also harm usability.

Test with the actual widget and integrations, not only a static design. Include:

  • keyboard-only navigation through opening, messages, links, controls, consent, and exit;
  • screen-reader reading order and announcements for new messages and status changes;
  • behaviour at 200% and 400% zoom and on narrow screens;
  • timeout, reconnect, duplicate-send, slow-response, and tool-error states;
  • plain-language explanations of required fields and validation errors;
  • a persistent way to stop, close, or switch channels; and
  • reduced-motion and animation behaviour where applicable.

Do not auto-open repeatedly, cover essential page content, trap focus, or make the close control difficult to find. Measure the widget's effect on page performance and conversion separately; visual prominence is not proof of usefulness.

Test decisions, not just sample answers

Build a versioned acceptance set from real business rules without using customer data. Include expected answer elements, prohibited claims, allowed actions, handoff state, source, severity, and reviewer.

Cover at least these scenario families:

  1. Approved routine questions: service description, area, hours, process, and next step.
  2. Unknowns: services, brands, locations, promotions, qualifications, and policies absent from the approved source.
  3. Boundary questions: exact price, guaranteed arrival, diagnosis, permits, insurance, warranty coverage, financing, and contract terms.
  4. Contradictions: an old page conflicts with the current register or two approved sources disagree.
  5. Privacy: anonymous questions, optional fields, withdrawal, correction, deletion request, sensitive disclosures, and minors.
  6. Actions: duplicate submissions, invalid destinations, stale availability, partial outages, timeouts, retries, and false-success prevention.
  7. Handoff: explicit request, uncertainty, frustration, complaint, safety issue, closed hours, and queue failure.
  8. Abuse and security: instruction override, data extraction, system-prompt request, malicious links, unsafe markup, rate abuse, and tool manipulation.
  9. Accessibility: keyboard, screen reader, zoom, status messages, errors, alternate channel, and motion.

Run each critical scenario more than once because generated output can vary. Evaluate meaning and action, not exact phrasing. A response fails if it reaches the wrong business conclusion even when it sounds courteous.

Record both false acceptance and unnecessary refusal. An assistant that invents a service is unsafe; one that refuses every ordinary question is not useful. NIST's Generative AI Profile frames risk work across design, development, use, and evaluation. Acceptance should therefore combine risk limits with evidence that the intended task works.

Create an AI intake acceptance register

Use one register as the launch record:

| Field | What to record | | --- | --- | | Release | Assistant, model/provider, prompt/configuration, knowledge version, tools, widget, and environment | | Intended purpose | Audience, problem, allowed outcomes, and excluded decisions | | Business truth | Approved sources, owners, effective dates, conflicts, and refresh process | | Privacy | Data map, purposes, legal review, notices, consent states, retention, access, correction, and deletion paths | | Actions | Tool permissions, validation, confirmation, idempotency, audit trail, recovery, and human approval | | Handoff | Triggers, destination, staffed hours, context, expected response, fallback, and overdue owner | | Test evidence | Scenario version, runs, expected result, actual result, reviewer, date, and linked evidence | | Exceptions | Impact, compensating control, authorized owner, due date, and retest result | | Operations | Logs, alerts, complaint path, kill switch, incident owner, vendor contacts, and review cadence | | Decision | Pass, limited pass, fail, or not applicable, with approver and timestamp |

Keep the released configuration tied to the evidence. A provider model update, new knowledge source, prompt change, tool permission, routing rule, vendor setting, privacy use, or business policy can invalidate part of the approval. Classify changes by risk and rerun the affected tests before release.

Set post-launch monitoring and review ownership

Launch approval is not permanent. Monitor the business outcomes and failure modes the assistant can influence:

  • conversations started and completed;
  • successful and failed handoffs;
  • tool requests, authoritative confirmations, failures, and retries;
  • unanswered and disputed questions;
  • prohibited-claim and security alerts;
  • unnecessary personal-information collection;
  • complaints, corrections, deletions, and opt-outs;
  • accessibility issues;
  • stale knowledge and overdue reviews; and
  • incidents, disablements, and recovery time.

Use samples and aggregates that respect the approved privacy design. Do not retain every conversation forever simply because storage is available. Restrict who can review transcripts, document the purpose, protect exported data, and delete it according to the approved schedule.

Name the people who own business content, privacy, security, accessibility, lead operations, vendor administration, and incident response. A contractor or agency can implement and monitor parts of the system, but the business still needs durable ownership of what may be promised and how enquiries are handled.

Know when not to launch AI intake

Delay or narrow the release when:

  • the business cannot provide current service and policy information;
  • the desired task is fully handled by a simpler form, FAQ, or calendar;
  • nobody owns handoff and complaint review;
  • the assistant needs sensitive information without an approved necessity, protection, and retention design;
  • a model answer would decide safety, legal, regulatory, eligibility, insurance, warranty, financial, or binding price matters;
  • connected actions cannot be constrained and confirmed by deterministic systems;
  • the business cannot test, monitor, disable, and recover the service; or
  • the intended claims have not been adequately tested and approved.

The Office of the Privacy Commissioner of Canada's AI principles recommend considering whether generative AI is necessary and proportionate and whether a more privacy-protective technology could achieve the purpose. Sometimes the better launch is a structured quote form plus a staffed follow-up queue. AI should earn its place by improving a defined part of intake under controls the business can operate.

Turn the checklist into a scoped build

A useful implementation scope states the intended conversations, prohibited decisions, approved knowledge, data flow, notices, consent, tools, handoff, accessibility behaviour, security controls, scenario set, monitoring, ownership, and change process. That scope lets a contractor compare proposals on evidence rather than on a vendor demo.

Nexxen's Canadian web development service covers website integrations and AI-assisted intake as part of a broader build when the business rules and escalation path can be defined. Before choosing an implementation, prepare the capability register, knowledge owners, collection purposes, authoritative booking or CRM systems, and named handoff queue. Those inputs determine whether the project should use conversational AI, a deterministic workflow, or a simpler combination of both.

This checklist is operational guidance, not legal, privacy, accessibility, cybersecurity, or professional-safety advice. Requirements vary by jurisdiction, sector, information, channel, and intended use. Obtain qualified advice for the specific deployment and keep the final approval tied to tested evidence.