Simulation intent is an extremely sensitive lever that guides what types of users get simulated and what their intentions are. It’s one of the most powerful tools for controlling the focus and quality of your simulations.

What is Simulation Intent?

Simulation intent defines who your simulated users are and what they’re trying to accomplish. It directly impacts:
  • The types of personas generated
  • The scenarios and questions users will ask
  • The behaviors and interaction patterns exhibited
  • The edge cases and testing scenarios explored
Keep simulation intent concise - typically 1-2 sentences maximum. For specific conversation examples, use historical data upload instead.

Three Categories of Simulation Intent

Broad-Based Intent

Defines general topics or use case categories that users should explore. Use this when testing overall chatbot performance, discovering unexpected usage patterns, needing comprehensive feature coverage, or when you’re not sure what specific issues to focus on. Examples:
  • “Users seeking help with account management and billing issues”
  • “Customers exploring product features and asking setup questions”
  • “Students asking for help with math and science homework”

Narrow-Based Intent

Focuses on specific features, workflows, or problem areas to test in depth. Use this when testing specific features or workflows, reproducing reported bugs or issues, validating recent changes or updates, or when time and resources are limited. Examples:
  • “Users specifically testing the new payment integration workflow”
  • “Customers having trouble with the mobile app login process”
  • “Advanced users exploring API integration capabilities”

Behavioral Intent

Describes how users should behave or interaction patterns to exhibit during testing. Use this when testing edge cases and error handling, stress testing conversation flows, evaluating chatbot robustness, or simulating difficult user scenarios. Examples:
  • “Users who are impatient and easily frustrated with complex processes”
  • “Curious users who ask follow-up questions and explore edge cases”
  • “Skeptical users who challenge recommendations and ask for evidence”

Writing Guidelines

  • If you don’t know what to write, use a broad-based intent or simply go with “General users”. Snowglobe will figure out the rest.
  • If you don’t like the quality of conversations generated, you can update the intent to give instructions on how to keep or avoid certain behaviors and re-run the simulation.
  • Keep simulation intent concise (1-2 sentences maximum) and focus on clear, actionable direction for user generation.
  • Be specific if you’re using a narrow-based intent. Avoid vague descriptions like “Users doing e-commerce things”.
  • Focus on user intent rather than implementation details. Describe what users want to accomplish and not the technical steps they’ll take.
  • Don’t include specific examples in the intent. Use historical data upload instead.
  • If you want, you can include tags on what category of intent you’re using. E.g. <behavioral> Users who are new to the platform..

Examples

Good Simulation Intent Examples

Intent: “Existing customers experiencing various technical issues and needing troubleshooting help.”Why it works: Defines user type (existing customers) and general intent (troubleshooting) without being overly specific.
Intent: “New users specifically trying to set up their first automated workflow using the drag-and-drop interface.”Why it works: Focuses on a specific feature (automated workflows) and user state (new users, first time).
Intent: “Impatient users who interrupt conversations, change topics frequently, and expect immediate solutions.”Why it works: Defines specific behavioral patterns that will stress-test conversation handling.
Intent: “Skeptical users who question recommendations, ask for sources, and try to find limitations.”Why it works: Tests robustness by simulating challenging user behaviors.

Poor Simulation Intent Examples

Bad: “Users asking questions.”Why it’s bad: Provides no direction about user type, intent, or focus areas.Better: “Customer support users seeking help with account and billing issues.”
Bad: “Users who are new to the platform and haven’t used similar tools before will be trying to complete their first project setup. They might be confused about the initial configuration steps, especially around API key setup and webhook configuration. They’ll probably ask about documentation and may need step-by-step guidance. Some might also ask about pricing and feature limitations.”Why it’s bad: Too much detail constrains persona generation. Save specifics for historical data.Better: “New users setting up their first project and needing configuration guidance.”
Bad: “Users who will ask ‘How do I reset my password?’ and ‘Why isn’t my login working?’ and similar account access questions.”Why it’s bad: Specific examples belong in historical data upload, not simulation intent.Better: “Users experiencing account access and authentication issues.”
Bad: “Users who will send JSON payloads to the API endpoint and expect specific HTTP response codes.”Why it’s bad: Focuses on technical implementation rather than user intent.Better: “Developers integrating with the API and troubleshooting connection issues.”
Bad: “Both beginner users who need simple help and advanced power users testing complex enterprise features.”Why it’s bad: Mixed intents create unfocused simulations. Run separate simulations instead.Better: Run two separate simulations with focused intents for each user type.

Resources


Questions? Join our developer community or contact support for help crafting your simulation intent.