I find things businesses (and people)
don’t see.

Everyone talks about “customer health.” Ask a hundred people what that means and you’ll probably get a hundred different answers. So I defined it mathematically—and in the process realized we were actually talking about two different things: Customer Health and, separately, Customer Strength.

To separate the two, I treated Customer Health as a measure of what was happening now—contacts, activity, opportunities and current engagement—while Customer Strength captured the deeper relationship: tenure, momentum and historical success.

Then I made the models work through complex institutional hierarchies, so individual departments and sub-accounts could roll into a meaningful overall score without throwing away the detail underneath.

The platform team wanted a flashy dashboard—color, movement, visual effects, all the things that showed off what the software could do. But the customer was a major defense contractor, and I knew that wasn’t what they needed. They had been asking for Customer Health. I gave them Customer Health and, separately, Customer Strength—a more granular way to understand the relationship. Then I built the smallest dashboard I could: three gauges, a few KPIs, and a compact table. Black and white. No spectacle. The customer loved it.

The simplicity was deliberate. I already knew the audience cared far more about precision and usefulness than whether the platform could animate a chart. Giving them both Health and Strength also answered the question at a finer level than they had originally requested.

Internally, the stark presentation was not what people had expected. The customer reaction was the opposite: the major defense contractor immediately understood it and loved the additional granularity. The complexity stayed behind the screen; the answer stayed in front of them.

Many vehicle owners are enthusiasts. They don’t just want the vehicle fixed—they care about what happens to it, who touches it, and how the work is done. Our technicians already used detailed internal service checklists, but those forms stayed buried in the customer file. I started handing the actual completed checklist to the customer instead—grease marks, fingerprints and all. Suddenly the customer could touch the process. They loved it.

The shop foreman initially objected: those checklists were internal records and belonged in the file. So I changed the process. We made cleaner, branded forms for the technicians—but I specifically did not want the technicians worrying about keeping them pristine.

The fingerprints and grime were the point. They were physical evidence that an expert had actually touched the vehicle, inspected it and worked through the list. A polished brochure could claim expertise; the dirty checklist let the customer hold the proof in their hands.

The dealership was holding a major rollout party. The service department had been cleaned up, customers were everywhere, and the entire point was to present a polished version of the business. Then a tow truck arrived with a customer’s disabled car. The customer was stuck outside in the pouring rain. I brought him inside, got him a drink, handled his problem even though service was closed, and had the tow truck come through the front service door—with the party still going on. The customers watched our service team handle a real problem in real time. They loved it.

That decision fit what I had already done with the rest of the event. Instead of hiding the service department, I had technicians stay in uniform, mingle with customers and answer questions. There was even an engine sitting on the shop floor because a car could not come off its lift in time. I treated all of it as part of what customers had come to see.

Management would have preferred the tow truck and disabled car stay outside until the party was over. Bringing them straight through the front turned an inconvenient real-world problem into something better than a staged demonstration: customers watched the service team take care of somebody when he actually needed help.

Around 2014, a large retailer wanted richer customer intelligence—demographics, income, household characteristics and likely buying preferences—but for many customers the reliable inputs were little more than a name and an address.

This was well before modern plug-and-play enrichment services made that sort of thing routine. I had about two weeks, so I built it myself.

I combined large name datasets with Census, geographic and demographic data, then wrote entirely custom logic—including JavaScript—to turn those raw sources into a usable enrichment system. The underlying data was large enough that I had to build and chunk the enrichment tables carefully just to make the whole thing practical inside the analytics platform.

The system did not pretend its inferences were certainties. It returned probabilities: the likelihood that a name belonged to a particular demographic group, the probable economic and household characteristics associated with an address, likely housing characteristics, possible children in the household, geography, and buying tendencies associated with those patterns.

In other words, I wasn’t merely joining a ZIP code to a Census table. I had built a probabilistic inference engine from raw data and custom programming, using the tools available more than a decade ago.

The prototype worked in roughly two weeks. The reaction from the retailer’s executives was essentially “holy shit.” They wanted the capability, although the platform’s required front end ultimately kept them from adopting it. Later, when I demonstrated the same approach at a trade show, the reaction was much the same.