The Lumen Index helps teams monitor external company change across a customer or account portfolio. These are the questions we hear most often from buyers evaluating onboarding, signal coverage, and workflow fit.
A customer health score is usually built from internal product usage, support, renewal, and relationship data. The Lumen Index adds an external signal layer that tracks public company change around your accounts. It is designed to complement internal health models, not replace them.
The core signal families today are WARN filings, layoffs, data breaches, and company-change or company-news signals. Within company news, the platform also classifies categories such as leadership changes, legal and regulatory activity, M&A, outages, partnerships, product changes, funding, and growth-related events.
Signals come from public external sources that can indicate meaningful company change. That includes items such as WARN filings, layoff reporting, breach reporting, and other public company-event sources that can be tied back to monitored accounts.
No. The Lumen Index is not presented as a churn prediction model. It highlights external company signals that may add context to account risk, change, or timing. Teams can use it alongside internal account knowledge, but it should not be treated as a stand-alone churn prediction score.
We do not fabricate a signal when none is observed. A quiet account can mean either no meaningful external change or no qualifying source activity in the sources we track. Coverage visibility matters here, so the goal is to show not just where signals exist, but also where the portfolio has been reviewed without a qualifying signal appearing.
As soon as your companies are loaded and the next monitoring sweep runs, you can start seeing signals. If a relevant public-source item already exists for one of your accounts, value can appear quickly. If there is no qualifying source coverage yet, the account will remain quiet until an external signal is observed.
We can support meaningful history, but the exact lookback depends on the signal source and the ingestion policy used for your deployment. The platform is designed to show both recent change and accumulated signal history, rather than only forward-looking monitoring.
Matching is centered on normalized company name, domain, and aliases. For example, a Salesforce ID can also be used as part of the mapping workflow. The goal is to tie your account records to a clean canonical company record so the signal history stays consistent over time.
We typically start with a customer account list and load those companies into the monitoring workflow. The cleanest onboarding file includes company name, primary domain, and any known aliases, because that improves matching quality from the start.
Yes. The product includes API access for downstream workflows, including company-level risk timelines and portfolio-level views, so the signal layer can be consumed in reports, internal workflows, or connected systems.
The onboarding workflow is centered on company and account metadata such as company name, domain, aliases, and related account-level reference fields. It is not designed around ingesting contact-level customer data.
Contact us with questions, or request access to speak with the founder about your specific needs.
