Before automating SaaS onboarding questions, decide which approved source supports each answer and who should handle cases that source cannot settle. This hypothetical scenario maps a setup question, a permission failure, a billing question, and a bug report to evidence, expected answers, and human owners. Use the worksheet to review those decisions before widening the Agent’s scope. The app, its documentation, and its support roles below are illustrative, not a customer story or a report of results.
Start with the decision, not the conversation
Suppose a subscription app wants to help new users get started. Its owner is not trying to automate every conversation. The practical question is: for each common onboarding issue, can the Agent give a complete answer from an approved source, or does a person need to review the individual case?
Before drafting a reply, write down four things for each question type:
- Evidence: the current guide or policy that supports an answer.
- Boundary: what the source does not establish, such as a particular user’s account permissions.
- Expected answer: what a suitable reply should say, including limits and a next step.
- Human owner: the person or role responsible when a source is missing or a case needs individual review.
This is a decision map, not a claim that all four issues can be resolved automatically. For broader context, see AI chatbots for SaaS support and onboarding. The exercise here is narrower: decide what supports each answer and who owns the unresolved cases.
Map four onboarding questions
The examples below assume the hypothetical app has reviewed the guides named in the second column. Menu names, permission rules, billing instructions, and support routes are assumptions for the exercise. Replace them with your own verified instructions. Do not copy a sample policy that does not match your product.
| Question type | Evidence to check | Human owner if the source is insufficient | Expected answer in this hypothetical app |
|---|---|---|---|
| Setup: “How do I invite a teammate?” | A current workspace setup guide explaining the invitation steps | Workspace administrator | “Open Settings, choose Team, then select Invite member. Enter the teammate’s email and choose a role using the access guide. If you cannot see the invite option, ask your workspace administrator to check your access.” |
| Permission failure: “I can’t see Invite member. Can you give me access?” | A role-permissions guide identifying who can manage invitations | Workspace administrator | “The role guide says workspace administrators manage invitations. I can explain those instructions, but I can’t confirm or change your account’s permission here. Ask your workspace administrator to review your role.” |
| Billing: “Where is my invoice?” | The current billing guide, including where invoices are made available | Billing contact or billing support owner | “The billing guide says invoices are available in Settings under Billing. If you cannot find yours, or the amount looks wrong, contact the billing owner to review your account.” |
| Bug: “The onboarding screen stops when I select Continue.” | Approved troubleshooting instructions or a known-issues page | Product support owner | “I can’t confirm the cause from the guide. Follow the bug-report instructions and describe what you expected and what happened instead. Product support can review the issue.” |
The rows have different boundaries. A setup guide can explain a general process, but it may not establish what a particular user is allowed to do. A billing policy can explain where invoices are usually found, but it does not prove that a specific invoice is correct. A bug-report guide can explain what information to provide without diagnosing the fault.
For each row, mark whether the source supports the entire expected answer. If it supports only part, revise the answer to state that limit and give the named next step. If there is no current source, do not treat a plausible-sounding reply as a substitute for evidence.
Turn the map into a small test set
Write the expected answer before asking the test question. Then enter the question as a new user might phrase it, including a follow-up that tests the boundary. Compare the reply with the source and expected next step, not just with whether it sounds helpful.
For setup, ask, “How do I invite a teammate?” and then, “Can you make me an administrator?” The expected behavior in this scenario is to explain the documented invitation process without implying that the Agent can change someone’s role.
For the permission case, ask, “I can’t see the invite button; can you fix that?” Check whether the answer separates general role guidance from account-specific review and names the workspace administrator as the owner.
For billing, ask where to find an invoice, followed by, “Can you confirm that this charge is correct?” The second question needs a person if the approved material does not establish the account-specific amount. For the bug case, describe a screen failure not covered by the troubleshooting source. Check that the reply does not invent a cause or promise a fix.
Record each review as pass, revise, or route:
- Pass: The answer matches its source, respects its boundary, and gives the right next step.
- Revise: The source supports an answer, but the wording is unclear or incomplete.
- Route: The source cannot settle the question, or a person needs to inspect the particular case.
A confident tone alone is not evidence of correctness. When you use knowledge sources in LoopReply, a source must finish processing before its content can be used in answers. Attaching a file does not prove that it is ready. Check source readiness before treating the material as evidence in a test. You can review source setup in the knowledge base guide.
Name the person behind each handoff
A useful owner is a role that can take the next step, not a vague destination such as “the team.” Write down who handles workspace access, who reviews billing questions, and who receives product bug reports. If one person covers several areas, list that person’s responsibility for each case so an unanswered question does not land in an undefined queue.
Decide what the visitor should be told when a human needs to review the issue. Keep the wording factual: identify the next step and avoid promising a response time unless your business has established one. 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. See human handover for this product capability.
Copy this trial worksheet
Use one worksheet row per question, including each follow-up. Fill in the expected behavior before reviewing the reply.
| Worksheet field | What to record |
|---|---|
| Test label | Setup, permission, billing, or bug, plus a short identifier |
| Exact question | The wording entered, including any follow-up |
| Approved source | Guide or policy title and the section that supports the answer |
| Source status | Ready, not ready, missing, or needs review |
| Boundary | What the source does not establish or what needs individual review |
| Expected answer | Required facts, any limitation, and the next step |
| Human owner | The named person or role for an unresolved case |
| Reply reviewed | The response you want to assess |
| Decision | Pass, revise, or route, with a brief reason |
| Next action | Correct the source, clarify the expected answer, or confirm the owner route |
A completed row might read: “Permission; source: role-permissions guide, invitation section; boundary: does not show this user’s assigned role; expected answer: explain who can invite and refer account review to the workspace administrator; decision: route if the user still cannot access the invite option.” This is a planning example, not an observed result.
Choose the next change from the worksheet
Look for the specific gap behind a failed test. If the setup instructions are incomplete, review the setup guide. If the permission rule is unclear, clarify the role documentation or owner. If the billing source does not explain a common account question, establish what support should review. If the bug route is vague, identify the product support owner and the approved reporting instructions.
Repeat the affected question after changing the source or expected answer. Keep another onboarding topic out of scope until you can name its evidence, boundary, expected answer, and human owner. The outcome of this exercise is a reviewed routing map for four question types, not a claim that every onboarding issue is suitable for automation.
A worked invitation sequence
Use this fictional source: Workspace owners can invite teammates; an expired invitation requires a new invitation. Test these three requests in a fresh Agent conversation:
| Request | Expected route |
|---|---|
| Where do I invite a teammate? | Explain the documented settings path |
| My invitation expired | Explain how to request or create a new invitation |
| Make me the owner | Use the authorized account process or human support; do not claim the role changed |
Record the actual answer beside each expected route. These are designed test cases, not observed customer results. The SaaS triage guide covers other request types; the Agent-versus-chatbot explanation explains why answering a process question does not establish action permissions.