A SaaS website Agent should answer questions covered by approved public documentation, guide visitors through general onboarding, and route account-specific problems for human review. Public help is not proof that an Agent can see a visitor’s workspace, verify their identity, or diagnose a particular account. Use the worksheet and handover template below to keep those tasks separate and to give a person useful bug details without inviting visitors to share secrets.
Sort requests by what the answer depends on
Start by asking one question: could you give the same answer to any visitor who reads your public documentation, or does the answer depend on a particular workspace, user, or event?
Put requests into one of these groups:
- Public documentation: A question about a published feature, setup step, supported workflow, or policy. Answer from the approved source that explains it.
- General onboarding: A question about where to start or what a documented step does. Answer from public instructions if they cover the question.
- Workspace-specific support: A question about a particular user’s permissions, settings, data, billing, or the result of an action. Public instructions alone cannot establish what happened in that account.
- Possible bug: A report that an action failed, behaved differently than expected, or cannot be repeated as the documentation describes. Capture the symptom and route it for review rather than guessing at a cause.
A request can move between groups during the conversation. “How do I invite a teammate?” is general onboarding. “Why did the invitation I sent this morning fail?” depends on a specific event. If the public instructions do not resolve the second question, do not simply repeat them as if they confirm the visitor’s workspace is set up correctly.
An embedded website Agent does not itself connect order data, a CRM, or other business systems. Apply the same careful distinction to SaaS account information: do not suggest the Agent checked a workspace unless you have separately confirmed what information is actually available and how the visitor is verified.
Build a triage worksheet
Before writing responses, fill in one row for each common request type. Use this worksheet as a planning tool; adjust the examples to your own product and approved support process.
| Request | What the Agent can do from public help | When to route for review | Details to avoid requesting in chat |
|---|---|---|---|
| “How do I invite a teammate?” | Explain the documented steps and link to the relevant guide. | The visitor says a particular invitation failed or the expected setting is missing. | Passwords, sign-in codes, or private invitation links. |
| “Where can I change this setting?” | Point to the documented location and explain the general steps. | The visitor cannot find the setting in their workspace or reports that saving did not work. | Credentials or screenshots showing private account details. |
| “The feature is not working.” | Ask what the visitor expected and point to relevant public troubleshooting guidance, if available. | The problem appears reproducible, blocks work, or is not explained by public documentation. | API keys, session cookies, passwords, recovery codes, or unredacted logs. |
| “Can you change this for me?” | Explain the documented process, if one exists. | The request requires an account-specific change or verification. | Payment details or any information not needed to understand the request. |
Add a source for each automated answer. Knowledge sources must finish processing before their content can be used in answers. Check that the relevant source has finished processing, then compare the proposed answer with the source before relying on it. See the knowledge base feature for information about knowledge sources.
Set a boundary for onboarding
Write the boundary in plain language so the Agent can distinguish general instructions from a report that needs a person. For example:
- Answer “How do I create a project?” using the public setup guide.
- If the visitor says the documented option is missing, acknowledge that the guide does not establish what is happening in their workspace.
- Ask for a short description of what they expected and what happened instead. Do not ask for credentials or secret values.
- Offer a route to human support for review of the account-specific problem.
Keep follow-up questions focused. Ask only for details that help distinguish the symptom, such as which documented step the visitor reached and whether the problem happens consistently. Avoid asking them to perform risky actions or change account settings just to make the conversation easier to classify.
You can organize the conversation path around those decisions in your support process. For further background on support setup and escalation, see AI Agents for Customer Support: A Deployment Guide. Do not imply that a workflow authenticates someone or provides access to their private workspace data.
Use a concise bug handover
A useful handover records the reported behavior without claiming to know its cause. The example below is illustrative, not a report of an observed incident.
Visitor’s report: “I select Save on the project settings page, but the change does not appear afterward.”
Handover summary: “Possible settings-save problem. The visitor expected the project setting to remain saved. They report that after selecting Save, the change does not appear. Please review with the visitor.”
Safe follow-up questions:
- Which setting were you trying to change? Please describe it without sharing private values.
- What did you expect to happen, and what happened instead?
- Can you repeat the problem? If so, what general steps lead to it?
- Does the issue affect one action, or have you noticed it with another documented step too?
This gives a support person the symptom, expected result, reported result, and a basic reproduction description. It does not label the cause as a software defect or promise a fix. If the visitor’s answer includes sensitive material, do not repeat it in the handover. Ask for a sanitized description instead.
Do not ask visitors to paste source code, access tokens, passwords, session cookies, recovery codes, or complete unredacted logs into the chat. If a screenshot might help, ask them to remove account identifiers, private content, and secret values first. Avoid collecting details just because they might be useful later; request only what is needed to understand the report and route it appropriately.
Do not tell the visitor that a ticket was created or an issue tracker updated unless you have verified that this actually happened. This example does not assume an automatic issue-tracker connection.
Make the human route clear
Tell the visitor when their request needs a person, and state what the next step is without promising a response time your team has not committed to. Authorized Workspace members can take over a conversation and reply as a human. Waiting or human-takeover conversations do not receive an AI response from the widget. Human handover is a route for help, not a response-time guarantee. Review your own support process so the handover wording matches the path you actually provide. See the human handover feature for related information.
Pass along a concise, sanitized summary and the visitor’s stated impact, not credentials or unnecessary personal information. A human can decide whether more information is needed and how to request it through an appropriate process.
Check the triage path with example prompts
Before using the worksheet as your support guide, write one example prompt for each category and decide in advance what a suitable response should do.
- Public help: Ask a question the documentation answers. Check that the answer matches the source and does not add unsupported steps.
- General onboarding: Ask how to complete a documented first step. Check that the response explains the step without claiming to inspect a workspace.
- Account-specific issue: Say that the documented option is missing in your account. Check that the response acknowledges the limit of public help and offers human review.
- Possible bug: Report a setting that does not appear to save. Check that the handover captures expected behavior, reported behavior, and safe follow-up details without requesting secrets.
Use the results to revise unclear wording and identify missing public documentation. The practical outcome is a repeatable triage rule: answer from public help when it covers the question, ask only for safe details needed to understand a problem, and route requests that depend on a particular account to a person for review.
An invitation error example
Give a test Agent a fictional guide: owners invite teammates from Workspace settings; expired invitations need a new invitation. Ask where to invite a teammate, then report “The invite button fails with an error.” The first needs the public guide. The second needs a bug report with the attempted step and error text, without passwords or authentication tokens.
Use the onboarding worked example to distinguish expected answers from account actions. If you are comparing support stacks, the Freshchat session comparison explains repeat-visit billing and the Intercom migration guide separates the Agent from the retained helpdesk.