Case studies

Below are three examples of prior work in distributed retail analytics. They give a reasonable sense of the kinds of problems I take on and how I tend to approach them. Client identifying details are described in general terms where appropriate.

Network-wide A/B price testing: $20M+ incremental annual revenue

Strategy & analytics work at a national automated retail company operating 40,000+ locations across the US.

The question: Is the current price point ideal? Will a price increase result in a revenue increase? Leadership had an instinct that demand was inelastic enough to support a price increase, but wanted rigorous evidence before committing. A wrong decision at network scale is expensive to reverse.
The approach: My work started with a customer survey designed specifically to produce price elasticity curves rather than a simpler "would you pay X" sentiment read. The elasticity data was used to narrow the range of plausible price points to the three most likely to maximize long-term revenue, each representing a different tradeoff between customer retention and per-transaction revenue gain. From there, I selected matched test and control markets comparable in demand profile, seasonality, growth, and other factors, and ran a difference-in-differences design with year-over-year adjustments to isolate the price effect from underlying market trends. The experiment ran with sample sizing based on the minimum detectable effect we'd need to act on, with enough test sites at each of the three price points for conclusive results. Results were monitored throughout against pre-agreed thresholds for rental volume and customer behavior.
The result: The live test confirmed the elasticity estimates within tolerance across all three price points. The full set of results were presented to leadership with a recommended price point showing the best balance of customer retention and long-term revenue gain. After the change was rolled out network-wide, the reporting infrastructure built for the test was reused to confirm the expected revenue lift in newly selected holdout markets, validating an estimated $20M+ in incremental annual revenue.
Why it worked: The elasticity work narrowed the range of plausible price points before any live testing started, which kept the experiment small and focused while still testing enough alternatives to give leadership a real choice rather than a single recommendation to accept or reject. In the test/control selection process I matched markets carefully to avoid bias and noise from differing seasonality or growth rates, ensuring reliable, readable results.

Cluster-based cannibalization & accretion modeling for a distributed kiosk network

Network optimization work at a national distributed retail operator with thousands of physical locations.

The question: When a kiosk is added to a market, how much of its revenue is genuinely new versus pulled from neighboring kiosks? And the inverse: when a kiosk is removed, how much of its revenue migrates to nearby kiosks as accretion, versus disappearing entirely?
Getting this wrong at scale means either over-pruning the network and destroying revenue, or operating underperforming locations longer than needed. Both result in lost revenue, and without a clear methodology, decision paralysis is surprisingly easy to land in.
The approach: I created a model to cluster locations based on observed transaction overlap, specifically customers who had transacted at multiple kiosks within a trade area. This was deliberately different from the geographic clustering that prior attempts had relied on, which tended to group locations that looked close on a map but didn't actually compete for the same customers. Each resulting cluster represented a real unit of competitive interaction, so removal decisions could be evaluated cluster by cluster rather than location by location. This avoided what would otherwise be the most likely failure mode: pruning multiple kiosks within the same cluster and accidentally collapsing the trade area as a whole.
The result: Network planning conversations shifted from arguments about individual locations to structured decisions at the cluster level. Importantly, the model identified which clusters were candidates for removal but deliberately left the which location within the cluster question open, so that the appropriate sales and regional leaders could apply qualitative judgment about specific sites (revenue share agreements, landlord relationships, operational ease, etc.) that no model would reasonably be able to incorporate.
Why it worked: The model was designed around how the decision was actually being made, rather than around technical elegance. Leaving genuine room for input from sales and regional leaders meant the analysis was used as a tool rather than overridden as a constraint, which is the more common failure mode for network optimization work.

Predictive failure model for automated kiosks

Operational analytics work in partnership with hardware engineering teams.

The question: When is the next failure coming? Which failures should we tackle first? Automated kiosks fail in ways that tend to compound. A partial mechanical fault generates revenue loss, then a service visit, then often a second visit when the original diagnosis turns out to have been wrong. Can the patterns sitting in error codes and sensor data logs predict failures early enough to dispatch the right technician with the right parts, before customers are affected?
The approach: The work started by spending real time with engineers to understand which error codes and sensor value ranges actually corresponded to which underlying failure modes. From there, I built reporting to flag kiosks showing pre-failure patterns and surface them to dispatch for review. One common failure type I was able to identify in advance was cooling cycles (the rhythm of the compressor running and resting) that stayed within acceptable limits but trended in the wrong direction over time. By predicting when those readings would likely move out of range, I could flag and prioritize the kiosks for review and indicate the level of urgency. That gave dispatch the missing data point needed to optimize maintenance labor, with focus directed toward uptime at high-revenue locations.
The result: A material reduction in customer-facing downtime, along with meaningful improvement in technician labor utilization since dispatched visits were more likely to fix the problem in a single trip.
Why it worked: The model was built in genuine partnership with the engineers who understood what the sensor patterns actually meant. Most predictive maintenance projects fail because the data team builds in isolation from the people who understand the underlying physical system.

See services → · Start a conversation →