> ## Documentation Index
> Fetch the complete documentation index at: https://developers.autoplay.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Step 3: Add the proactive framework
> Configure when Autoplay may offer help, how frequently it can intervene, and what happens after the user accepts.
The onboarding objective tells Autoplay what the user should learn. The proactive framework controls when Autoplay may step in and how the user moves from an offer of help to useful guidance.
Your team configures this behavior for the product. Autoplay applies it continuously as it compares live activity with workflow progress.
## Give users space before offering help
The **exploration gate** defines how much opportunity a user gets to explore before proactive assistance becomes eligible. It can consider signals such as:
* Time spent in the product
* The number of distinct features explored
* Whether the user is making normal progress
* Whether they have completed the relevant workflow
Teams can tune these values in the onboarding configuration. A complex product may allow more exploration, while a short activation journey may offer help sooner.
## Control how often Autoplay intervenes
Cooldowns and limits prevent relevant help from becoming repetitive.
| Configuration | What it controls |
| ------------------------- | ------------------------------------------------------------- |
| Exploration gate | How much room the user gets before help becomes eligible |
| Welcome cooldown | How long Autoplay waits before another onboarding prompt |
| Maximum proactive support | How many proactive offers may appear in the configured period |
| Active conversation gate | Prevents a new offer while support is already helping |
| Workflow completion | Stops prompts for tasks the user has completed |
These settings are part of the proactive framework, not fixed behavior. Your team can adjust them as you learn how users respond.
## Choose the moments that deserve help
Proactive triggers connect a recognized user state to a relevant offer:
| What Autoplay recognizes | Possible proactive offer |
| ------------------------------------------------ | ---------------------------------------------------------------------- |
| Progress has stopped during a required workflow | “Want help completing this step?” |
| The same failure happens repeatedly | “It looks like this setup is not completing. Want to troubleshoot it?” |
| The user returns to unfinished work | “Want to continue where you left off?” |
| A completed workflow makes the next one relevant | “Ready to create your first report?” |
A trigger should reflect a meaningful workflow and clear user need. It should not fire only because someone visited a page or clicked a particular button.
## Keep the user in control
Autoplay is constantly reasoning in the background about what help the user needs next and when it is a good moment to offer it. It considers both timing and the next useful suggestion, then sends a nudge when proactive help could move the user forward.
When Autoplay decides to offer help, the user journey is:
1. Autoplay reasons that help may be useful and sends a relevant nudge.
2. The user chooses whether to click it.
3. If accepted, the existing support agent opens with the help message.
4. The support agent uses Autoplay MCP to understand recent activity, workflow progress, and available guidance.
5. If visual help would be useful, the support agent asks the user first.
6. After the user confirms, the support agent calls the Autoplay MCP tour tool.
7. Autoplay sends the trigger to the user's application, which launches the configured tour.
Autoplay does not launch a tour without the user. Both the conversation and visual guidance begin with an explicit user choice.
Extend the same model beyond onboarding into continual product adoption.