> ## Documentation Index > Fetch the complete documentation index at: https://docs.beaconrevenue.io/llms.txt > Use this file to discover all available pages before exploring further. # Signals — what changed for this customer, and does it matter? > How Beacon notices what changed for each customer across your tools, what you see and do on its page, what it needs, which modules depend on it, and what it does not calculate yet. **Signals** answers one question: *What changed for this customer, and does it matter?* A payment slipping, a plan being cut, usage dropping, a deal going quiet, a customer growing — each is a signal. Beacon looks for the same signals in the same way across all your tools, so every other module works from one shared reading of what is happening to each customer. It belongs to the Shared foundation — see [Modules](/modules/overview). ## What it does Beacon keeps a **signal list**. Each signal on it has a rule for what counts, a cut-off where it needs one, a direction — a **warning sign** or a **good sign** — and a fade setting of 14, 30 or 90 days, which says how quickly it stops mattering. When something in your tools matches a signal, Beacon records it against the right customer, with the date it happened. The signals are sorted into kinds — churn risk, customer health, expansion, buying intent, engagement, deal speed and others — and the modules that need them read them from here: Churn risk reads the churn-risk signals, Deal likelihood reads deal speed and buying intent, and so on. A signal switches on when two things are true: the tool it comes from is connected, and Beacon reads it. Beacon never changes anything in your tools, and it publishes no overall risk rating from signals. ## What it produces Its headline is two figures: | KPI | What it measures | Today | | - | - | - | | [**Signal coverage**](/definitions/signal-coverage-rate) | The share of your active customers whose signal coverage is high — how much of your customer base Beacon can actually see and trust. The aim is 85% or more | Not calculated yet | | [**Signals noticed**](/definitions/signals-noticed) | How many signals Beacon noticed for your customers, warning signs and good signs together | Shown for the last 30 days | Each name links to its definition, which also says how the [Data API](/api-reference) and [MCP](/mcp-tools) will carry it — neither serves these two figures yet. The signals themselves can already be read one by one. Behind them, the page shows today: | What | What it tells you | Today | | - | - | - | | **Signals switched on** | How many signals on the list Beacon is reading for you, and why each other one is off | Shown | | **Signals noticed over time** | Signals noticed week by week, warning signs against good signs, and how many customers they were on | Shown | | **The signal list** | Every signal, grouped by the tool it comes from, with its direction, fade setting and cut-off | Shown | | **Latest signals** | Every signal noticed, newest first, with the customer and the date, and a link to the customer's page | Shown | | **When each signal stops counting** | The date each signal fades out, and its fade curve | Not calculated yet | | **The signal coverage score for each customer** | A score from 0 to 100 for how much of each customer Beacon can see | Not calculated yet | | **Scores for each kind of signal** | How strong each kind of signal is for each customer — churn risk, expansion and so on | Not calculated yet | ## How signal coverage is worked out For each customer, every signal Beacon expects counts as **covered** when its tool is connected and up to date, the customer is matched in that tool, and the data behind it is reliable enough. The nine kinds of signal are then combined at fixed weights into a score from 0 to 100. Churn risk weighs most, at 18%; customer financial health least, at 2%. A customer is **High** at 80 or more, with reliable data behind it. How old a signal is does not affect coverage: a quiet customer on connected, up-to-date tools is fully covered. Age matters only when Beacon weighs what a signal means. [Signal coverage](/definitions/signal-coverage-rate) sets out the full rule. ## What you see on its page In Beacon, open **The Brain** and choose **Signals**. The page has six tabs: * **Overview** — how many signals are switched on, how many were noticed in the last 30 days, what switches on next, and the tools it reads. * **Dashboard** — signals noticed over 13 weeks, warning signs against good signs, and how many kinds of signal are covered today. * **Signals & alerts** — the signal list in groups by tool, with which are on, and the alert rules. * **Scorecard** — the fade settings and cut-offs. When each signal stops counting reads **Being settled** today. * **Latest signals** — every signal noticed, with search, a filter for warning signs or good signs, and a panel that opens the customer's page. * **Setup** — the questions the module uses, and the answers in use. ## What it needs Signals start as soon as your **billing system or your CRM** is connected. Every other tool adds more of the list. | Tool | What it adds | Read today | | - | - | - | | **Billing** (Stripe) | Revenue going up or down, payments, cancellations, discounts and refunds | A first set | | **CRM** (HubSpot) | Deals moving or stalling, activity and meetings | A first set | | **Accounting** | Overdue invoices and payment patterns | Not yet | | **Product usage** | Usage rising or dropping, and features adopted | Not yet | | **Website analytics** | Visits that show buying interest, such as the pricing page | Not yet | A signal whose tool is connected but which Beacon does not read yet says so on the page: it starts in a later update, and there is nothing for you to do. See [Connect your tools](/connect-your-tools) for how each connection is made. ## Reads from | Module | What Signals uses it for | | - | - | | [**Customer matching**](/modules/customer-matching) | Attaches every signal to the right customer, and says whether a customer is matched in each tool | | [**Data model**](/modules/data-model) | The joined-up records each signal is read from | | [**Data integrity**](/modules/data-integrity) | How reliable the data behind each signal is. A signal on data scoring under 60 is held back and counts as missing | | [**Segments**](/modules/segments) | Later: adjusts some signals by segment and shows signals by segment | | [**Customer fit**](/modules/customer-fit) | Later: sends back which customers turned out to fit, so the fit signals improve | ## Which modules read it | Module | What it uses Signals for | | - | - | | **Churn risk** | The churn-risk signals are its main input | | **Expansion readiness** | The expansion signals tell it when a customer is ready | | [**Customer fit**](/modules/customer-fit) | Fit, engagement, churn-risk and financial-health signals feed all five parts of fit | | **Customer value** | Health and margin signals set where each customer's value is heading | | **Deal likelihood** | Deal speed and buying intent for each deal | | **Sales forecast** | Deal speed, buying intent and engagement adjust when deals are expected to close | | **Buying intent** | The intent and engagement signals | | **Revenue forecast** | Every kind of signal, as an adjustment to the forecast | | **Forecast confidence** | How noisy, held back and complete the signals are | The scores these modules take from Signals are not calculated yet, so none of them is weighting signals today. The **Modules** page in The Brain shows which modules are running for you. ## Alerts Most of what Signals finds goes to other modules rather than to people. | Alert | When it fires | | - | - | | **Churn risk is rising** | A customer's churn-risk signals reach 55 out of 100. Passed to Churn risk | | **Ready to expand** | A customer's expansion signals reach 60. Passed to Expansion readiness | | **Buying interest in an open deal** | A customer in an active sales cycle reaches 65 on buying intent. Passed to Deal likelihood and Buying intent | | **Signals held back** | A customer's signals are held back because the data behind them scores under 60. Goes to your RevOps lead | | **Two tools disagree** | Two tools report the same event differently more than three times for one customer in 30 days. Goes to your RevOps lead | **No alert is sent yet.** The three score alerts wait for the scores, and the other two wait for the parts they read. ## Setup questions * **Which signals do your tools actually provide?** Beacon proposes the list from what you have connected. * **Do you have signals of your own** — a tool or a spreadsheet you rely on — that should be added to the list? * **Who owns the signal list?** They approve any change beyond the small adjustments Beacon may make on its own. * **When should signals be weighted by segment?** Recommended: once 90 days of outcomes have built up. Which tools you use and who looks after your data are asked once and used here too. ## What is not calculated yet * **Signal coverage**, and the signal coverage score for each customer. * **When each signal stops counting**, and its fade curve. * **Scores for each kind of signal**, for each customer and by segment. * **Company growth**, the one kind measured for the whole company. * **How reliable the signals are** — how many fire with no predictive weight, how many are held back, and how often tools disagree. * **Most of the signal list** — a first set of billing and CRM signals is read today; the rest start in later updates. * **Alerts** — none is sent yet. ## Related The ten module families and which modules are available today. How each signal finds the right customer. How reliable the data behind each signal is. What each connection unlocks, and which signals switch on with it. When each figure was last worked out. What Beacon reads, what it never changes, and what it does not decide. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.