A construction WhatsApp Agent should answer only questions supported by approved information and send project-specific or uncertain requests to a person for confirmation. Plan the WhatsApp provider and channel configuration separately from the Agent’s permissions and conversation rules. Start with three examples: a general project inquiry, a site access question, and a progress question. Exclude drawing interpretation, pricing, safety advice, and scheduling from the Agent’s authority.
This guide is a planning worksheet, not confirmation that any particular platform or provider supports your intended WhatsApp setup. Check the provider’s current requirements and permission controls before designing the visitor conversation around them.
1. Set a narrow purpose and clear exclusions
Write a one-sentence purpose before configuring anything. For example: “Answer general project questions from approved company information, identify the visitor’s topic, and route site-specific questions to a person for confirmation.” Keep that purpose narrower than your construction business as a whole.
Use this scope table to decide what the Agent may say and where it must stop. The examples are illustrative, not information about an actual project.
| Example question | Possible Agent role | Human confirmation needed |
|---|---|---|
| “What kinds of projects do you handle?” | Give a general description using approved company information. | Whether a particular job fits the business’s current capacity or requirements. |
| “Can I enter through the north gate tomorrow?” | Refer only to current, approved access information when it is suitable for the visitor. | Whether that person is authorized, whether access has changed, or whether an exception applies. |
| “Will my project be finished next week?” | Explain that a team member must confirm the project-specific status. | Any statement about current progress or a completion date. |
Write the exclusions in plain language: the Agent does not interpret drawings, quote prices, give safety advice, confirm project progress without authoritative confirmation, or schedule work. If someone asks about a hazard or urgent situation, do not have the Agent offer safety guidance. Direct the person to your established human or emergency process.
2. Keep provider setup and Agent permissions separate
Treat channel setup as one workstream and Agent behavior as another. The provider or messaging service determines its own account setup and channel controls. The Agent’s instructions determine what it should say, what information it may use, and when a person should take over. Do not assume that completing one workstream completes the other.
Use two checklists, with a named role responsible for each item. Keep credentials, account identifiers, and private project details out of the planning worksheet.
| Provider and channel checks | Agent and conversation checks |
|---|---|
| Confirm with the provider that the intended WhatsApp use is supported. | Define the Agent’s permitted topics and explicit exclusions. |
| Identify who is authorized to manage the provider account and channel settings. | Identify which sources are approved for each answer. |
| Decide who approves use of the business number and who checks the channel before it is presented to visitors. | Decide who can review Agent changes and who handles requests needing a person. |
| Record how your team will respond if the channel is unavailable or its configuration changes. | Decide what the Agent says when information is missing, uncertain, or project-specific. |
Provider administration and Agent content approval are different responsibilities. A person who can manage the channel does not necessarily need to approve project information. A person who reviews the information does not necessarily need provider-account access. Document who owns each decision and how to reach that person internally.
For ideas on structuring the conversation itself, review the workflow builder. Use a workflow plan to make the visitor’s path understandable; do not treat it as proof that a provider connection or permission has been configured.
3. Match each answer to an approved source
For every answer in scope, name the material that supports it and the person responsible for keeping it current. A general project inquiry might use an approved company overview. A site access answer needs an approved instruction that is current and appropriate for the visitor. A progress question needs a reliable, project-specific confirmation process; general company information is not evidence of current project status.
Avoid turning informal notes into authoritative guidance. Mark superseded instructions clearly, set a review owner, and decide what the Agent should do if two approved sources disagree. Do not include sensitive project material in information intended for general inquiries.
Attaching a file does not prove its contents have been indexed. A source must finish processing before its content can be used in answers. Check the source’s processing status, then test the exact information you expect the Agent to use. The knowledge base overview describes that product area. For a useful review pattern, see how to test questions your Agent cannot answer.
A source list can be as simple as this:
| Topic | Approved reference | Owner | Review trigger |
|---|---|---|---|
| General project inquiry | Current company overview | Business owner or delegate | Services or scope description changes |
| Site access | Approved access instruction for the relevant context | Site or operations contact | Access arrangements change |
| Project progress | Human confirmation, not a general reference answer | Person responsible for that project update | Visitor asks for a current status or date |
4. Write the handoff rule before the reply
Decide what the Agent should do before writing sample answers. For a progress question, a useful boundary is: “Do not estimate or infer a project’s progress. Say that a team member needs to confirm the current status and offer the approved route for follow-up.” For access questions, the boundary can say not to decide whether someone is authorized or invent an alternate route.
Make the handoff understandable. State what the Agent cannot confirm, what the person should do next, and whether the business will follow up. Do not imply a response time unless your business has established and can maintain one. The human handover overview is a resource for planning human support; confirm separately how your chosen channel and provider handle the conversations you intend to route.
5. Review the conversation with a worksheet
Before inviting visitors to use the Agent, prepare questions and write down the acceptable boundary before reviewing replies. Ask a reviewer to compare each response with its approved source and rule, rather than judging only whether it sounds confident.
| Test prompt | Source or boundary | Acceptable response | Review |
|---|---|---|---|
| “What kind of projects do you take on?” | Approved company overview | Give only the supported general description; route a specific job assessment to a person. | Pass / revise |
| “Can I use the north gate tomorrow?” | Current approved access information; authorization may need confirmation | Do not make an unverified access decision. Ask for human confirmation when needed. | Pass / revise |
| “Will my project be complete next week?” | No approved current progress confirmation | Do not guess or promise a date. Explain that a person must confirm. | Pass / revise |
| “Can you review this drawing and tell me what to change?” | Outside the Agent’s scope | Do not interpret the drawing; direct the request to an appropriate person. | Pass / revise |
| “What will it cost, and when can you start?” | No authority to quote or schedule | Do not give a price or promise a start date. Offer the approved human follow-up route. | Pass / revise |
Try natural variations, including brief messages and follow-up questions. If a reply crosses a boundary, revise the instruction or remove the unsupported answer from scope, then review the changed conversation again. This is a planning check, not evidence that every future message will be handled correctly.
6. Check the exact field when changing behavior
If you use LoopReply, owners can ask the Architect to change Agent instructions, appearance and workflow in conversation. Those changes remain drafts until the owner publishes them. Identify which field changed before deciding whether a review and Publish step applies.
For LoopReply, tone or personality wording inside the Agent’s draft instructions waits for Publish, while model-context personality traits, response style and language take effect immediately. Do not treat every tone or personality adjustment as a draft. Check the saved field before assuming a change is not yet visible to visitors.
7. Finish with an owner check
Before presenting the channel to visitors, have the responsible people confirm that provider setup and permissions were reviewed, the Agent’s sources are approved and processed, each out-of-scope request has a clear route, and the worksheet has been reviewed. Revisit the plan when access information, source material, provider configuration, or responsibilities change. Keep the provider checklist separate from the Agent scope and test worksheet so each owner can review the decisions they are responsible for.
A synthetic project enquiry
A fictional renovation firm serves two named districts and asks for project type, district, and preferred follow-up. A visitor writes, “I need a kitchen renovation in the north district next spring.” The useful intake is the requested work, location, and timeframe, followed by the agreed contact route.
A request to confirm whether a wall is load-bearing should leave this intake scope. Do not let public marketing information become a structural assessment. Configure that boundary and have a qualified person handle the appropriate next step.
Use the lead-intake guide for the questions and WhatsApp builder comparison for connection and provider checks. A received message and a successful team reply are both required before the channel is ready.