> 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
**Jump ahead:**
* [Setting up a playbook](#setting-up-a-playbook)
* [Qualifying leads](#qualifying-leads)
* [Meeting bookings](#meeting-bookings)
* [Form submissions](#form-submissions)
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.
***
### 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.
***
### Meeting bookings
A qualified conversation is worth far more if it ends on your team's calendar. From the playbook, you can give RepX a scheduling link and tell it when to offer it - so the visitor books in the chat instead of being sent off to find a contact form.
**Adding a calendar**
Add your scheduling link at the playbook level, under **Meeting bookings**. RepX works with any hosted scheduling URL - Calendly, Chili Piper, HubSpot Meetings, or your own booking page.
Because the calendar sits on the playbook rather than the account, different pages can route to different teams. Your enterprise pricing page can point at an AE's calendar while your self-serve pages point at a shared onboarding link, with no extra logic to maintain.
When RepX offers the meeting, the calendar opens inside the conversation - the visitor picks a slot without leaving the page. The booking is recorded against the conversation, so it shows up in your playbook's performance numbers and flows through to your CRM.
**Telling RepX when to offer it**
Adding the link makes booking possible. The instruction is what makes it well-timed. Describe the conditions in plain English, the same way you'd brief a rep on when to push for a call and when to hold back.
The pattern that works: state what has to be true first, then what to do, then what not to do.
> Offer to book a meeting once the visitor has confirmed they're evaluating for a team of 50 or more, or has asked about enterprise or custom pricing. Ask for their work email before sharing the calendar. Do not offer a meeting to visitors asking only about the free plan.
> Answer at least one substantive product question before mentioning a meeting. If the visitor asks something we can't answer from the documentation - custom contracts, security reviews, procurement - offer the calendar straight away and say a specialist can cover it properly.
> This is a post-demo page. If the visitor has watched a demo and asks a follow-up question about implementation or migration, offer to book time with a solutions engineer. Never offer a meeting more than once in a conversation - if they decline, keep helping and don't ask again.
{% hint style="info" %}
The most common mistake is pushing too early. A visitor asked for a meeting in their second message reads the whole conversation as a sales trap. Let RepX earn the ask - answer the question first, then convert. {% endhint %}
{% endhint %}
***
### Form submissions
Not every visitor is ready to talk to someone, and a meeting is a big ask for someone still reading. Form submissions are the lighter conversion: RepX captures the visitor's details inside the conversation, so the lead reaches your team even when a booking doesn't happen.
**Setting up a form**
Under **Form submissions** in the playbook, choose which details RepX should collect - work email, name, phone number, company - and mark which ones are required. Keep it short. Every extra field is another reason to abandon.
RepX presents the form inline in the conversation rather than as a page interstitial, and it only appears when the conditions you've set are met. Submitted details are attached to the lead and to that conversation, land in your conversation signals, and sync to your CRM through the integrations you've connected.
**Telling RepX when to ask**
As with meetings, the instruction is what separates a form that converts from one that annoys. Give RepX a reason the visitor would want to hand over their email, not just a point at which to demand it.
> Ask for the visitor's work email once they've shown interest in a specific product and you've answered at least one question about it. Frame it as sending them a summary of what you covered plus the relevant demo links. Don't ask again if they decline.
> If the visitor asks for pricing details beyond what's published, or asks for a quote, ask for their work email and company name so the team can send figures for their setup.
> This is a comparison page. If the visitor asks how we stack up against a competitor, answer honestly first, then offer to email them a detailed comparison in exchange for their work email.
**Choosing between a form and a meeting**
Both are on the same playbook, and the two work best in sequence rather than in competition. Capture the email early enough that you keep the lead, and offer the calendar once intent is high enough to justify it - so a visitor who isn't ready to book still doesn't leave anonymous.
***
**Playbook performance**
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.