Beat one
What they were trying to do
A multistate dealership group wanted dual pricing — a card price and a cash price — rolled out across their entire operation. On every terminal, at every location, and on every invoice their dealer-management system produced.
The engagement ran from pre-sale through post-launch, inside a portfolio of roughly 25 merchants with clients processing $30M+ in annual volume.
Beat two
What we found
Dual pricing only works if the terminal and the paperwork agree. If a customer sees one number on a card reader and a different presentation on their invoice, you don't have a pricing program — you have a dispute generator and a compliance problem.
So the actual work wasn't procuring hardware. It was defining the invoice specifications and getting them correct inside the system the staff already used. We worked directly with the dealership's DMS vendor to update the language and presentation in their existing software — no parallel process, no second system to remember, no retraining anyone around a new tool.
That decision is the whole engagement in miniature: the cheapest, most reliable path was to change what an existing system produced, not to add a new one beside it.
Beat three
What we built, and what changed
We configured and loaded 100+ terminals, physical and virtual, then ran a multiphase rollout: equipment installation, on-site staff training, and standing communication channels with onsite personnel at every location.
Then the building fought back.
Mid-rollout, the client's IT policy blocked us from wiring into their LAN, and wifi couldn't reach parts of the service areas. First fix was cellular SIMs on one carrier — not reliable enough in those bays. So we established a direct relationship with a second carrier to deploy their SIMs, and re-specced a subset of terminals from Linux to Android hardware so they could run dual-SIM redundancy. Connectivity held from that point forward.
We also sat with the controllers until month-end reconciliation was something they could run without us. A rollout isn't finished when the hardware works; it's finished when the staff can operate it on a Tuesday without calling anyone.
The rollout plan is a hypothesis. Every multi-site deployment meets a building, a policy, or a person the plan didn't account for. What matters isn't a plan that survives contact — it's a relationship that lets you keep iterating until the thing actually works.
Why this generalizes
Any time you're rolling something out across multiple locations, the failure mode is the same: the pilot works, and then reality — a building, an IT policy, a staff habit — breaks it at site four.
The way through is to define the outcome precisely enough that you can tell when you've drifted from it, and to stay close enough to the people on the ground that you find out in week two instead of month three.