Why we built Signals
Signals did not start with a pitch deck or a market gap.
It started with a problem I could not ignore.
Twelve months before Signals existed, I was describing a situation to Jon that I had lived through repeatedly in senior customer and support roles. Accounts did not churn suddenly. They drifted. The warning signs were there, scattered across tools, teams, and conversations, but nobody could see them clearly or act on them early enough.
So I built a workaround.
The original problem
The issue was never a lack of data.
Support had tickets. Customer success had sentiment. Sales had pipeline context. Product had usage. Each team saw part of the picture, but no one saw the whole thing in a way that translated into action.
By the time churn showed up in reports, the relationship was already damaged.
What I needed was a way to spot risk early and turn it into something operational. Not a score for reporting. A system for decision-making.
The first solution
The initial solution was simple and manual.
I started tracking observable signals. Changes in engagement. Escalations. Stakeholder movement. Commercial pressure points. I grouped those signals into drivers and weighted them based on impact.
The output was not just a health score. It was clarity.
You could see why an account was at risk and what needed to happen to bring it back to green. More importantly, it was repeatable. The same approach worked across accounts, teams, and quarters.
Where Jon came in
Jon’s background is in software and process design. When I walked him through the model, he immediately saw the elegance in it.
Not because it was complex, but because it was structured.
The system reduced noise, explained itself, and created a natural operating rhythm. It turned gut feel into something teams could actually work from.
At that point, Signals was still just an idea. A pattern. A way of thinking.
Separate paths, same problem
Our paths went separate ways for a period.
During that time, I continued refining the model in different environments. I tightened the signal definitions. Improved the weighting. Clarified the operating rhythm. Each iteration made it more robust and easier to apply.
Eventually, it became clear this was not just a workaround. It was a product.
Building the MVP
When Jon and I reconnected, the problem had not changed. The solution had matured.
What followed was the first Signals MVP. A way to capture signals, translate them into drivers, and turn risk into structured back-to-green plans that teams could actually run.
No dashboards for the sake of dashboards. No abstract scoring. Just early visibility and clear action.
The point of Signals
Signals exists to solve one core problem.
Companies lose customers not because they do not care, but because they see risk too late and act too slowly.
We built Signals to make that risk visible earlier and to turn insight into disciplined action.
That is still the goal.
Related insights
Why customer risk is almost always spotted too late
Most teams rely on lagging indicators to identify churn risk. This article explains why that approach fails and what to do instead.
When churn needs a system, not a spreadsheet
Why manual churn tracking breaks down as teams scale and why shared systems are required to manage risk reliably.
How to run a weekly churn risk review
A practical, repeatable process for reviewing customer risk weekly without noise, panic, or performance theatre.
Stephen leads Signals with a focus on helping businesses understand their customers better through actionable data insights.
LinkedInWhat this is
This article explains the real operational problem that led to Signals, and how a manual churn workaround evolved into a repeatable system.
- The original problem
- The first solution
- Where Jon came in
What this is
This article explains the real operational problem that led to Signals, and how a manual churn workaround evolved into a repeatable system.
- The original problem
- The first solution
- Where Jon came in