> For the complete documentation index, see [llms.txt](https://docs.storylane.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.storylane.io/repx/playbooks.md). # Playbooks Someone comparing plans on your pricing page probably arrives with a very different intent than someone who just landed from an ad. A single, generic conversation flow may not serve both well. A playbook lets you define RepX's conversational pre-qualification flow for different webpages, allowing you to push the right leads towards meeting your pipeline goals (by capturing their emails or pushing them towards booking meetings) When you create a playbook, you associate it with one or more pages on your website. Then, at the playbook level, you can define **popup nudges** (questions and demos). Popup nudges encourage visitors to begin a conversation by showcasing questions they can start asking or demos they can start watching. \ \ Once the user begins a conversation, RepX looks at the **prompt** you've setup on the playbook to orchestrate a pre-qualification conversation flow. RepX can ask the right questions, and based on answers from your visitors, ask further questions or ask for their email. In the right situations, you can also steer RepX to suggest booking a meeting with your team. \ \ Setting up the right playbooks with well-written prompts would lead RepX to have more targeted conversations, deliver higher engagement on your website, and help you meet your sales pipeline goals. All from the traffic you already get on your website. {% hint style="info" %} Think of a playbook as RepX's game plan for a section of your site. You can run as many as you need - a focused one for high-intent pages like pricing, and a broad default for everywhere else. {% endhint %} ### Setting up a playbook Every account comes with a default playbook - the default one associated with the URL `*` influences RepX's qualification conversations and popup nudges on all URLs. Besides having the default playbook, you can create additional playbooks to define RepX's behaviour on specific pages on your website. #### Associating playbooks with webpages When you create a playbook, you define which pages a playbook covers - for example, you can have a playbook that runs only on the page `yourwebsite.com/pricing`. You would do this by associating the playbook with "exact match" of the URL `yourwebsite.com/pricing` when you setup the playbook. You can also associate a playbook with URLs based on "starts with" or "contains" - in such a situation, the playbook runs seamlessly when you add new webpages that have the same pattern as the URL you define in the playbook. This is useful when a group of pages shares the same intent - say, all your migration pages - because you configure the behavior once and manage those pages together instead of duplicating prompts and popup nudges. **The `*` playbook.** A playbook set to the URL `*` acts as your default, running on any page that doesn't have a more specific playbook of its own. Its purpose is to guarantee RepX always has sensible behavior everywhere, so no visitor ever lands on a page where the agent has nothing to go on. #### Pop-up nudges Pop-up nudges are the questions and demos RepX surfaces in the launcher to pull a visitor into a conversation before they start typing, when they hover over the embedded RepX widget. The purpose of popup nudges is to turn passive browsing into an active conversation, instead of waiting for the visitor to make the first move. A relevant question or a demo on a webpage is far more likely to earn a click than something that's more generic, which is what makes nudges one of the most direct levers for lifting engagement. Because nudges live inside a playbook, they can be specific to your webpages. On a playbook associated with the pricing page, a nudge might show the question "Want a quick walkthrough of which plan fits you?". On a feature page, you can showcase a Storylane demo from your account about that feature. #### Prompts for qualifying leads The prompt defines how RepX should drive conversations on the pages this playbook covers - the questions it should ask, when it should consider a lead as qualified and when it should ask for a visitor's email and when it should drive them towards booking a meeting. The prompt's purpose is to make RepX's qualification flow fit the page's intent rather than staying generic. This is where page-level context pays off. For a playbook associated with the pricing page on your website, you might prompt RepX to lead with value, address common objections, and offer to book a call. But on a landing page built for a specific ad, you might have RepX deliver a customized qualification flow based on that campaign, so the conversation feels like a continuation of what brought the visitor there. The result is a visitor who feels understood, which is what moves them forward. {% hint style="info" %} A clean way to think about it: give each set of high-intent pages its own playbook, and let the \* playbook handle everything else as your baseline. {% endhint %} #### Prompts for qualifying leads Each playbook shows how many conversations it has steered and how many meetings it has booked and the number of emails that were captured on conversations where the playbook was activated. This exists so you can see which pages and setups are actually driving engagement and pipeline - and use that information to double down on what's working, adjust what isn't, and decide where a more tailored playbook is worth creating. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.storylane.io/repx/playbooks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.