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.

founder story

Why we built Signals