A new customer opens your app, follows the getting-started guide and gets stuck at “Connect your data”. The guide explains the steps. It cannot tell them whether their connection succeeded, whether the import is still running or whether they are working in the wrong workspace.
That is a useful job for a SaaS onboarding chatbot. It can combine a maintained explanation with a small, approved view of the customer's actual setup state and help them choose the next step.
I would start with one setup journey where progress is observable, such as connecting a source and completing a first import. It is easier to improve a specific blocked step than to build a general-purpose assistant for the whole application.
Pick a milestone your application can verify
“The user has finished onboarding” is often too vague to implement. “The workspace has a connected source and one successfully processed import” is a much clearer milestone.
Write down the states that lead to it. No source connected. Connection awaiting verification. Import queued. Import running. Import completed. Import failed with a customer-safe reason. Then define what the customer can do in each state.
The application owns these states. The assistant reads them and explains the relevant next step. A friendly conversation, a viewed help article or a customer's “I think it worked” should not mark an import as completed.
What an onboarding case study actually demonstrates
In Intercom's published trumpet customer story, onboarding combines product tours, sequenced messages, help articles and application data. The case illustrates using progress information to make guidance relevant. It describes Fin as a future exploration, so its onboarding results should not be attributed to an already deployed AI chatbot. It is an external example, not a project using my plugin.
For an AI assistant, the transferable idea is the same starting point: understand the customer's current step before recommending the next one. You can use that principle without copying the entire onboarding stack.
Use a small view of setup state
The assistant usually needs much less information than your support team can see in the admin panel. For a first-import journey, a useful view might contain the following:
| Information | Reason to expose it | Boundary |
|---|---|---|
| Current workspace label | Help the customer recognize the setup being discussed | Only a workspace they can access |
| Connection state | Explain whether the source is ready | No API keys or authentication tokens |
| Import state and update time | Distinguish waiting, processing and completion | Only permitted imports in the current workspace |
| Customer-safe failure code | Select the correct troubleshooting guidance | No raw stack traces or secret-bearing logs |
| Available next actions | Offer a valid next step | Computed by application permissions and business rules |
Resolve the signed-in actor and workspace through trusted application context. The customer's message can describe what they are seeing; it cannot grant access to a different tenant. If the required context is absent, the lookup should stop.
Keep explanatory material in maintained setup documentation. If the import parser changes, update the related help content and review the affected conversations. The assistant should not improvise unsupported field mappings.
Help with a blocked CSV import
Here is an illustrative setup conversation, not a measured customer result:
Customer: I connected the source, but there are still no contacts.
Assistant: The connection is ready. The latest import stopped because it is missing an email column. Does your file use a different column name for email addresses?
This response combines two different sources: the application reports the import failure; your documentation explains the accepted column names and mapping process.
If the application supports mapping “Email Address” to its email field, the assistant can explain that supported option. If it does not, the advice should be to adjust the file using the documented format. The next instruction depends on real product behavior.
Suppose the import is actually running. The answer should describe that state and point to progress information. Telling the customer to upload the file again may create an unnecessary second job.
Once the import completes, read the result before recommending the next milestone. The assistant should know whether the customer has something useful to work with, rather than automatically advancing after a reassuring exchange.
Keep guidance and execution visibly separate
Explaining how to retry an import and triggering a retry have different consequences. For an action-enabled assistant, show what will be retried and let the customer confirm it before dispatch.
Your application should verify that the customer can perform the action, the job belongs to their workspace and the current state permits it. Reading an earlier failure does not authorize a retry after the job has already succeeded.
Completion is another separate event. If a system accepts a background job, say that it has been queued. Wait for its actual result before saying the import succeeded. A timeout or uncertain submission needs reconciliation rather than an automatic second attempt.
For the first version, guidance and read-only status checks may be enough. Add actions when the normal application path and its failure behavior are clear.
Make human help arrive with the setup context
Some problems need a person. An unsupported source, repeated parser failures or an access issue may require support or an implementation specialist.
A prepared handoff should include the milestone the customer is trying to reach, the permitted workspace reference, the observed state, the safe error category and the steps already attempted. Ask for contact details only where needed.
Keep credentials out of the conversation. If the customer needs to replace a key, direct them to the normal secure connection settings. Do not ask them to paste it into chat.
For a customer, the benefit is straightforward: they do not have to repeat the entire setup story when support takes over.
How I would wire this into a Laravel SaaS
I would configure Filament Agentic Chatbot with an onboarding Agent, approved setup guides as Knowledge Sources and a narrowly scoped Data Resource for the relevant connection and import records. If setup state lives in another service, an approved API Connector can provide the read.
The application supplies trusted customer and tenant context and keeps ownership of permissions and onboarding state. The plugin provides the assistant surface and approved tools; your product still defines what “ready” means.
An optional Playbook is useful for a bounded sequence with confirmation, waiting or a structured handoff. Simple status explanations can use the Agent's approved reads directly. The UI and account-specific integration need to be configured for your host app.
This setup does not automatically recognize arbitrary screens, highlight buttons or build product tours. Those are separate interface features. A focused assistant can already be useful when it accurately explains the step that has blocked someone.
Test the states people really get stuck in
Start with no connection, a pending connection, an import still in progress and a failure with a documented remedy. Then add failures your help content cannot explain. The assistant should hand over uncertainty rather than invent a fix.
Test a user who switches workspaces between messages. Test a job that completes while the customer is reading the retry suggestion. Add a status-service outage and a repeated confirmation for an action. These cases reveal whether guidance stays attached to current, authorized state.
Ask a customer success colleague to review the proposed next step. Technical correctness is one part of usefulness; the instruction also needs to be understandable to someone seeing your product for the first time.
Measure the first successful outcome
Track time from starting the chosen journey to the verified milestone, the share of users who reach it, repeated setup questions and handoffs that arrive with enough context. Segment by source type and error category.
Use conversation review to identify missing documentation and confusing product behavior. If every customer asks where a mapping setting lives, improving that screen may be the best next change.
Do not attribute all activation changes to the assistant. Product changes, new customer cohorts and different acquisition channels can affect the numbers. Compare equivalent groups or use a controlled rollout where practical.
The ongoing review process is covered in my guide to operating a Laravel AI support bot. For onboarding, the most useful first scope is one observable milestone and the handful of situations that prevent customers from reaching it.
Planning questions
Is an onboarding chatbot the same as a product tour?
No. A tour introduces a planned sequence of interface steps. A chatbot responds to the customer's question and, when connected, explains their actual setup state. They can complement each other.
Can the assistant mark onboarding as complete?
Let the application decide from a verified milestone. The assistant can report that result. Completing a conversation alone is not evidence of successful setup.
Should onboarding start with write actions?
Read-only status and accurate guidance make a useful pilot. Add approved actions only when authorization, confirmation and recovery behavior have been defined and tested.