When critical project information is buried in email threads or lost in hours of meeting footage, staying proactive becomes a challenge. Signals solve this by transforming unstructured interaction data into clear, AI-powered insights.

This capability, known as Enterprise Listening, allows Rocketlane AI to monitor conversations across your team for specific, pre-configured statements. Rather than just scanning text, the AI applies your unique business context to evaluate interactions through your organization's specific lens.

By analyzing one or more transcripts from your interactions, Rocketlane AI identifies specific patterns or events that carry business significance. For example, if a customer mentions a budget freeze in an email or expresses frustration during a weekly sync, the AI "signals" this as a potential risk to the account.

TABLE OF CONTENTS

• Signal types
  • Risk
  • Opportunity
  • Operational
• What a signal card contains
• Signal occurrences
• Signal Lifecycle
  • Transcript Ingestion:
  • Eligibility & Filtering:
  • Signal Detection:
  • Signal Occurrence & Visibility: 
• Creating a Signal Definition
  • Inputs used to build the signal configuration
  • Clarifying questions
  • Reason codes and examples
• Create and Test a Signal
  • Create a new signal
  • Review the generated configuration
    • Instructions
    • Filter
    • Negative examples
    • Positive examples
    • Test the signal
• RBAC Signals
  • Permission Categories
    • 1. Viewing Signals
    • 2. Signal Settings
    • 3. Signal Analyst
  • Scope Options

Signal types

Signals are classified into three broad types:

• Risk: Negative impact potential (renewal risk, churn signals, escalations)
• Opportunity: Positive impact potential (expansion, upsell interest)
• Operational: Important signals that are not clearly risk or opportunity (bugs, process gaps)

Risk

Factors that may negatively impact renewal or adoption, for example:

• Churn threats
• Escalations
• Repeated dissatisfaction
  
  

Opportunity

Factors that may lead to more revenue, for example:

• Expansion interest
• Cross sell or upsell signals
• Interest in new modules or higher tiers
  
  

Operational

Signals that matter but are not defined as a risk or opportunity, for example:

• Bugs
• Gaps in process or documentation
• Repeated “how to” friction points
  
  

What a signal card contains

A signal card typically includes:

• Signal type: Risk / Opportunity / Operational
• Reasoncode: a finer category of the issue (for example “Data sync issue”)
• Title
• Description
• Citations (excerpts or references from the transcript)
• Date
• Person(s) who raised it
  

Signal occurrences

Internally, each time a signal is detected from a transcript, Rocketlane creates a signal occurrence, which is the specific instance of a signal triggered by a specific transcript. Signal occurrences are what get surfaced and grouped in the Signals UI as cards.

Signal Lifecycle

When a new transcript arrives (meeting or email), Rocketlane runs a detection pipeline. The pipeline follows a logical, step-by-step path to filter out noise and focus on high-value data:

Transcript Ingestion:

The process triggers immediately whenever a new transcript, whether from a recorded meeting or a synced email thread, arrives in the system.

To ensure that AI insights remain focused on customer-facing interactions, the system applies strict eligibility criteria before processing.

For a transcript to enter the downstream Signal detection workflow, it must be linked to a customer account. Rocketlane identifies these interactions through two primary methods:

• Project Membership: The system checks if the meeting or email includes a participant who is already a member of the project.
• Domain Matching: If the participant is not a project member, the system cross-references their email domain against the domain fields stored within your Account objects.

Purely internal communications are automatically excluded from Signal detection to avoid internal noise. If all participants belong to your organization's domain (for example, @rocketlane.com), the system classifies the transcript as internal and bypasses it. Similarly, interactions from domains not associated with a known customer account, such as a random email from @github.com when GitHub is not a client, will not trigger signal generation.

For more granular control, you can use the Blacklist feature to explicitly block specific domains or email addresses from generating Signals. This ensures your data remains clean and relevant.

Eligibility & Filtering:

Before the AI begins its deep analysis, the transcript passes through a set of defined filters. These are the conditions you establish when creating a signal to clarify exactly what counts and what doesn't. For example, if you set a signal for "Customer dissatisfaction and churn risk," the pipeline first ensures the interaction data is relevant to that specific context.

• If the transcript does not meet these initial eligibility requirements, the process stops here.

Example Use Case - To ensure high-signal relevance, you can restrict specific signals to certain account types, sizes, or regions. For example, a GDPR compliance signal can be configured to trigger only for customers located in the European Union, preventing unnecessary noise for teams managing accounts in other territories. 

Signal Detection:

Once a transcript is deemed eligible, the AI performs a comprehensive evaluation. It compares your specific conditions against the transcript of the meeting or email to find a match. 

• If the stated conditions are not detected within the text, the evaluation ends.

Signal Occurrence & Visibility: 

If the AI confirms a match, a Signal Occurrence is officially created. This event is then surfaced directly in your Signals UI.

Conditions act as a gate. If a transcript is not eligible, Rocketlane does not even run detection for that transcript.

Example:

• Condition: ARR > 100K
• Transcript arrives for an account with ARR = 20K
• Result: detection is skipped for that transcript

Note: Signal visibility is based on signal RBAC

Creating a Signal Definition

When you create a signal definition, Rocketlane builds a structured signal configuration through a guided flow.

Inputs used to build the signal configuration

Signal configuration is built using:

1. User input:
   The user defines exactly what they want the AI to look for using simple, natural language. Example: "Flag an escalation risk whenever a leadership-level stakeholder from the account is involved in the conversation and expresses dissatisfaction."
   
   
2. Business context:
   Signals depend on what “risk” or “opportunity” means for your business.
   Example: “billing issues” may be operational for one company but a major risk for a billing platform company. This context is sourced from a knowledge base that is created (treated as a black box for enablement purposes).
   
   
3. Conditions / filters parsing:
   The system extracts structured eligibility criteria from your request.
   Example: “Only run this for high-value accounts” becomes an account filter like ARR > $100K.
   
   

Clarifying questions

In order to narrow down the specifics, Rocketlane asks clarifiers before finalizing the configuration.

Examples:

• “Does leadership involvement apply only to high-value accounts or any account?”
• “Should this signal trigger on general dissatisfaction, or only when the customer mentions churn or switching vendors?”
  

Reason codes and examples

Signal definitions often need second-level classification, which are provided by the reason code, which defines what the signal is specifically for. Example:

• When you create a signal to detect a “Feature request” it is broad. This can result in creation of  reason codes specific to the request, eg:
  • Workflow
  • Mobile app
  • Reporting
  • Customization

To improve accuracy, signal configurations can include:

• Positive examples: when to trigger the signal, in this case “When customer explicitly requests for a new feature”
• Negative examples: when not to trigger the signal, and why, in this case “Customer asks how to do something”

Note: To make it more specific to your use case, you can also add documents, pieces of text or even refer to a URL and the agent will scrape the URL so that it gets better context. For example, if you think that the signal generator does not have enough context about your app features, you can give it a URL of the help documentation, it'll scrape it and it'll make the signal more contextual that way. 

Create and Test a Signal

Create a new signal

1. Navigate to Settings → Signals → Create signal.
   
   
2. Select the signal type:
   
   • Risk
   • Opportunity
   • Operational

3. Enter your prompt in the Nitro AI, for example: “Whenever any high value account or if the leadership of any account says that they are considering moving away from our product because we don't support integration of X”

Rocketlane uses:

• Your input prompt
• Business context from the knowledge base
• Parsed conditions from your request
  
  

Rocketlane may ask follow-up questions to refine conditions. For example, if you say “high value account,” Rocketlane may ask you to define it, and you might specify “accounts by ARR.”

Conditions can be generated from transcript content as well as Rocketlane account data.

Review the generated configuration

After you answer clarifying questions, Rocketlane presents a new window with the chat on the side and configuration tabs that describe what will be captured.

This window includes four tabs:

Instructions

The detailed description of what Nitro AI will look for and how it will evaluate transcripts based on your inputs.

Instructions typically includes:

• Signal identity and purpose: Defines the segment and objective (for example identifying high-value accounts at risk due to missing X integration).
  
• Detection logic (the “what”): Defines phrases, behaviors, or sentiments that trigger an alert (for example separating casual mentions from real renewal blockers).
  
• Eligibility criteria: Sets guardrails for which accounts or personas apply (for example only accounts > $50K ARR or leadership titles).
  
• Classification by reason and root cause: Categorizes the business driver and source of the interaction (for example executive mandate vs workflow disruption).
• Output format: Defines how findings are presented (for example paraphrased summary with context explaining qualification).

Filter

The structured conditions Rocketlane uses to gate eligibility and scope.

Filter typically includes:

• Signal metadata: Defines the core identification and categorization.
• Primary target filters: Defines quantitative and qualitative thresholds (for example ARR > $50K, leadership titles).
• Data exclusions: Excludes accounts like internal or test accounts.
• Channel scope: Defines which interaction channels are monitored (meetings, emails, and later chat or support).
• Plain language summary: A readable explanation of what the filter is doing.
  

Negative examples

Examples of scenarios that should NOT trigger a signal, with reasoning.

Examples:

• Neutral request: “It would be great to have X integration one day.” (No urgency or threat)
• Internal note: “CSM noted customer uses X.” (Not customer voice)

Positive examples

Examples of scenarios that SHOULD trigger a signal, with reasoning.

Examples:

• Explicit threat: “If we don't get X soon, we'll switch to a competitor.” (Clear intent to leave)
• Executive mandate: “CFO says we need this in X or we can't renew.” (Leadership-driven risk)
  
  

You can use the chat on the left to edit the skill, filters, or add more refinement.

Test the signal

1. Click Test (top right).
2. Select the transcript source:
   • Meetings
   • Emails
3. Select the meeting or email.
4. Click Run.
   
   

Rocketlane AI analyzes the selected transcript based on your signal definition. After testing, proceed to create the signal if it is satisfactory, or continue to tweak it in the chat window.

Note: Transcripts are currently associated only with accounts, not projects. As a result, signals primarily behave as account-level insights.

Note: There is currently no mechanism to automatically resolve or close a signal once it is raised.

RBAC Signals

The Signals module lets admins control who can view, hide, and configure signals, as well as who can access the Signal Analyst feature. Viewing permissions are scoped to limit the reach of signal data across the account.

Location: Settings → Permissions → Signals → Signals: Account level

Permission Categories

1. Viewing Signals

2. Signal Settings

3. Signal Analyst

Scope Options

Scopes control which signals a user can see when a viewing or Signal Analyst permission is granted.

Note: By default, signals are not associated to projects. You must manually associate signals to projects. If this association is absent, users with Project access scope will see no signals.