> 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/conversation-signals.md). # Conversation Signals Your sales team rarely needs the whole conversation. They need the two or three things that change how they run the next call - what the visitor is trying to solve, which product they were looking at, how big their setup is, and whether they're worth reaching out to at all. Conversation signals are how RepX gives you key insights from conversations as structured data. A signal is a named piece of information you want RepX to pull out of every chat, defined by a prompt you write in plain language. When a conversation ends, RepX runs each of your signal prompts against the full conversation and stores the result against that conversation. Because signals are extracted from the whole conversation, they don't depend on RepX having asked a specific question. A visitor might describe their pain point, interests, current tooling in their opening message, or across three different answers halfway through - either way, the relevant signals capture it. {% hint style="info" %} Playbooks shape the conversation. Signals shape what you get out of it. The two are configured separately, so you can change how RepX qualifies without touching what your CRM receives. {% endhint %} There are two kinds of signals: **default signals** that every account gets, and **custom signals** you create for whatever else matters to your business. *** ### Anatomy of a signal Every signal - default or custom - is made up of four things. | Field | What it is | | ----------------- | ------------------------------------------------------------------------------------------- | | Label | The display name you'll see in the RepX dashboard. For example, `Primary product interest`. | | Type | The kind of value the signal holds - String, Email, Phone, Yes / No or Number. | | Extraction Prompt | Your plain-English instruction describing what RepX should pull out of the conversation. | *** ### Default signals | Signal | Data Type | What RepX extracts | | ------------ | ------------- | ---------------------------------------------------------------------- | | Visitor name | String | The visitor's name, if they shared it at any point in the conversation | | Email | String | The email address the visitor provided | | Phone number | String | The phone number the visitor provided | | Qualified | True or False | Whether the conversation meets your definition of a qualified lead | Because these are extracted from the conversation, they get picked up whenever the visitor happens to share them. If someone opens the chat, drops their email, and closes the window without answering a single question, RepX still ends the conversation, processes it, and attaches that email to the lead. #### **Customizing the 'Qualified' signal** **Qualified** is different. A qualified lead at a company selling to enterprise IT teams looks nothing like a qualified lead at a self-serve product. So `qualified` is the one default signal whose prompt you can edit, and it's worth editing - the default is deliberately generic. Write it as the criteria you'd give a rep reviewing the transcript. For example: > Mark this conversation as qualified if the visitor works at a company with more than 100 employees and described a current problem with their existing tooling, or asked about pricing for a paid plan. Answer no if the visitor is a student, a job applicant, or asking only about the free tier. Because Qualified is a **Yes / No** signal, it's the one most teams filter on downstream - routing only qualified conversations into a CRM, a Slack channel, or a rep's queue. *** #### Custom signals Custom signals are where you capture the things specific to how your team sells. You create one by giving it a name and writing the prompt that tells RepX what to look for. Some examples of custom signals customers run today: | Label | Captures | | ------------------------ | ----------------------------------------------------------------------- | | Pain points | The specific problems the visitor described with their current setup | | Primary product interest | Which of your products the visitor was really asking about | | Number of users or sites | The size of the visitor's environment, as a proxy for deal size | | Interests | What the visitor wants to accomplish - the goal behind the conversation | | Current tooling | The competitor or incumbent tool the visitor said they're moving off | | Timeline | When the visitor said they're looking to make a decision | #### **Writing a good signal prompt** A signal prompt is just an instruction, but a few things make the output far more useful downstream - particularly if you're pushing signals into CRM fields. **1. Set the scene, then name the target.** Open by telling RepX what it's reading and exactly what to pull out. > You are analyzing a completed sales-chat transcript to extract the visitor's interest: what they want to accomplish, evaluate, or see - the goal or use case behind the conversation. **2. Draw the line against your other signals.** If two signals could plausibly capture the same sentence, say so explicitly. Otherwise you'll get the same text in both. > ...as distinct from the problem itself, which is captured in a separate signal. **3. Spell out what counts.** This is where most of the accuracy comes from. List the concrete things you'd accept, in your own vocabulary. > Capture the visitor's stated objective and what they were looking for. This covers things like: the migration scenario they want to run; the governance outcome they want; what they asked to do next (see a demo, get pricing, start a trial, talk to sales); and their evaluation stage, if stated. **4. Say what to do when it isn't there.** Most conversations won't contain every signal. Tell RepX to leave it empty rather than infer. > Return null if the visitor did not share this. Two more things worth keeping in mind: match the instruction to the type you picked - a **Number** signal should ask for a figure, not a description - and if the value is headed for a CRM picklist, name the exact set of values RepX is allowed to return. {% hint style="info" %} **Warning**: Signals are extracted by AI from what the visitor actually said. They're a strong indicator of intent, not a verified data source - treat a signal the way you'd treat a rep's notes from a discovery call. {% endhint %} *** #### Setting up signals You can create and edit signals from **Settings > Conversation signals** in RepX. * To edit the **Qualified** prompt, open the signal and replace the prompt with your own qualification criteria. * To add a **custom signal**, create a new signal, give it a name, and write the prompt describing what RepX should extract. Signals apply at the account level - they run against every conversation your agent has, regardless of which playbook was active. Changes take effect on conversations that complete after you save them; conversations already processed keep the signals they were extracted with. *** #### Where signals show up Once extracted, every signal is available in three places: * **Against the conversation in RepX**, alongside the summary, topics and transcript, so anyone reviewing the conversation sees the extracted signals with it. * **In the `repx_conversation_completed` event**, inside the `extracted_variables` block. Both default and custom signals are included. This is what makes signals usable outside Storylane. * **In the tool of your choice, through Zapier or webhooks.** Because signals arrive in the event payload, you can map any signal to any field in your CRM or nurture tool. See Integrations for setup. The HubSpot integration writes a set of conversation attributes into HubSpot properties by default, and logs the conversation as a note on the record. If you want a specific custom signal in a specific HubSpot field - `pain points` into a custom Contact property, for example - send it through Zapier. A conversation with two custom signals configured would produce an `extracted_variables` block like this: ``` "extracted_variables": { "email": "john.doe@example.com", "visitor_name": "John Doe", "phone_number": "+1-555-0100", "qualified": true, "pain_points": "Manual migration process across 40 SharePoint sites, no way to validate what transferred", "migration_size": "2.4 TB" } ``` --- # 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/conversation-signals.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.