> 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-chat/playbooks.md).
# Playbooks
Learn how you can customize how RepX qualifies leads within different webpages.
* [Setting up a playbook](#setting-up-a-playbook)
* [Qualifying leads](#qualifying-leads)
* [Meeting bookings](#meeting-bookings)
Someone comparing plans on your pricing page probably arrives with a very different intent and has very different questions compared to someone who just landed from an ad.\
\
A single, generic conversation flow may not serve both well. A playbook lets you define RepX's qualification behaviour for different webpages, allowing you to push the right leads towards your pipeline goals.
Playbooks can be associated with specific pages. For example, you can have a playbook associated with the pricing page and another playbook associated with all /solutions pages 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 %}
***
**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 following URL with the `ask` and `goal` query parameters:
```
GET https://docs.storylane.io/repx-chat/playbooks.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
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.
