I have worked in software support for nearly 30 years, the last 14 leading an organization through a growth journey from $4.5 million to $600 million in annual revenue.

The focus never changed — keep customers satisfied and drive margin. What changed was the scale — and with scale comes complexity that makes both of those goals harder to maintain and easier to lose sight of. The bigger an organization gets, the more layers exist between leadership decisions and customer outcomes. The more those layers multiply, the more critical it becomes to have a clear view of where the operation is actually serving the business and where it has quietly drifted from it. Blind spots that are manageable at $50 million become structural problems at $200 million.

---

When I took on the leadership of the support organization the business was early stage — small enough that you could know every customer, every issue, every rep. At that scale the relationship between the support team and the customer is direct and personal. We owned it completely.

Maintaining that ownership as the business scaled was one of the defining challenges of the fourteen years. Growth creates pressure to industrialize support — to route, to tier, to deflect. Some of that is necessary. But every efficiency decision carries a relationship cost that doesn't show up in the metrics that justified it.

The shift that changed how we thought about everything came when we moved from supporting an on-premise product to a SaaS platform. On the surface it looked like a technology transition. What it actually was was a customer transition. We had been supporting IT departments — technical people whose job was to run the application. In the SaaS world we were supporting practitioners. People whose job was not to run the application but to use it to do their job. When they contacted support, their day was disrupted. They weren't filing a ticket. They were stopped.

That distinction reshaped how we thought about everything — response time, resolution time, the relationship between the support team and the end user, what a good outcome actually looked like. Traditional support approaches built for IT departments didn't serve practitioners the same way. Recognizing that early, and rebuilding around it, was one of the most consequential things we did.

---

What thirty years in this work teaches you is that the fundamentals never change. Keep customers satisfied. Drive margin. Every organization is trying to do those two things. The ones that do it well over time are not the ones with the best tools or the most sophisticated metrics. They are the ones with the clearest view of where their operation is actually serving those goals — and the discipline to find where it isn't.

That clarity doesn't come from measuring more. It comes from measuring the right things and being honest about what the gaps are telling you. Most support organizations are better at the first than the second. The metrics they track confirm what they set out to achieve. The blind spots live in what they didn't think to measure — and in the unintended consequences of decisions that looked right at the time.

That is what I spent thirty years learning to see. And it is what I built Support Signal Advisory to help others find.

---

Support Signal Advisory exists to do one thing — help organizations find what their current operational framework isn't showing them, and turn that clarity into results.

Every engagement starts from the same place. An objective look at the data before any subjective conversation happens. What the metrics are saying, what they aren't saying, and where the gaps between them are pointing. That analytical foundation is what protects the integrity of the diagnostic — and what makes the findings credible to the people who need to act on them.

I work with organizations in two ways. For those who need an outside perspective, I run the diagnostic and deliver a clear set of findings and directional initiatives. For leaders who want to build the capability themselves, I work alongside them through the same process — using their own data and their own team — until they can see what I see and do something about it on their own.

In both cases the goal is the same. Not a report that sits on a shelf. Not a set of recommendations that require me to implement them. A clear view of where the operation stands, why it stands there, and what it will take to move it.