Ryan Ginsberg

The break was upstream of every report — fixed at the source rather than in the reporting, and the backfill ran clean across 230 closed-won deals.

Roughly 95% of contacts carried attribution that could not be true, which meant every downstream report was confidently wrong rather than obviously broken. The cause was at the form, not in the reporting layer, and fixing reports on top of it would have produced a number that looked better and meant the same thing.

We fixed it at the form and backfilled 230 closed-won deals with zero failures. The signal that it landed was not ours: the team renamed their own Slack channel to match the new system.

A HubSpot-to-Salesforce sync that had lost the team's confidence, deliberately reset rather than patched — and still holding three months later, in their own words.

The sync had drifted far enough that people had stopped believing what it produced, and the honest read was that incremental repair would restore the mechanism without restoring the trust. So we reset it deliberately, which costs more up front and is the only version that ends with anyone believing the output.

Three months on, the RevOps lead's own verdict was that the flow is generally working. That is a deliberately unglamorous sentence and it is the one worth reporting, because it came from them rather than from us.

An unmeasured channel finally quantified — and it landed close enough to the owner's own instinct that the number was believed the day it appeared.

A meaningful part of how this business sold had never been measured, so it existed as an impression rather than a figure, and every decision that touched it was being made on feel. The work was making it countable rather than estimating it.

When the figure arrived it was within a rounding distance of what the owner had believed all along, which is the outcome you want and the one people underrate — a number that confirms an experienced operator's instinct gets adopted immediately, where a surprising one starts an argument about the method.

Capability transfer the client called a clear win — and their CEO's own standard for the engagement was that doing it for them would have been the failure case.

The build mattered less here than who could operate it afterward, and that was the client's framing before it was ours. Their CEO's verdict was that done-for-them without transfer "would have been a failure" — his words, and the cleanest external statement of the thing this practice is built around.

It is also the hardest outcome to evidence, because success looks like an absence: no standing dependency, no retainer that exists to keep the lights on, no call that has to come back to us.

An undocumented integration reverse-engineered from behavior alone, then a 60-workflow re-point verified to zero stale IDs — with the real risk found by enumerating all 696 workflows rather than sampling.

An acquisition left two portals and an integration nobody could read: its author had gone and the repository was lost, so the only available source of truth was what it did when it ran. We reverse-engineered it from behavior, which is slower than reading code and is the only method available once the code is not there.

The instinct at that point is to sample the workflows and extrapolate. We scanned all 696 instead, which is what surfaced the actual risk — enabled status rather than logic — and the 60-workflow re-point that followed was verified to zero stale IDs rather than assumed clean.

424,000 contacts, 1,623 properties and four duplicate pipelines audited — which is how a broken service worker firing a phantom 404 turned out to be the single most common first touch on record.

At 424K contacts and 1,623 properties, nobody can hold the portal in their head, and four duplicate pipelines meant the same commercial motion was being counted in several places at once. The audit was the deliverable before any rebuild could be scoped honestly.

The finding that mattered was not in the pipelines. A broken service worker was firing a fake 404, and that 404 had quietly become the number-one first-touch interaction in the portal — which means every first-touch attribution report was ranking a bug at the top and nobody could see it, because at that volume a wrong number and a right one look identical.

Contact deletion locked down after in-flight transactions started breaking, plus custom-code training and a shared repository stood up ahead of a key developer's departure.

Contacts were being hard-deleted while transactions referencing them were still running, so the failure showed up somewhere else entirely and looked like an unrelated bug. We locked deletion down, which is a governance change rather than a technical one and is the reason it held.

The second half was timing rather than craft: a developer who held knowledge nobody else did was leaving. Custom-code training and a shared repository went in before the departure rather than after it, which is the only point at which that work is cheap.

Custom UI extensions the sales operation runs on daily — and the rebuild was scoped by the client's own sales ops rather than by us.

Their sellers needed proposals built from what was actually available, and the gap between the inventory and the document was being closed by hand every time. We built the UI extensions that close it inside the CRM, so the proposal comes from the live record rather than from a copy of it.

The part worth reporting is who scoped it. Their own sales ops led the rebuild scope, which is slower at the start and is the difference between a system a team uses and one they work around.

The CRM and the ERP made to describe the same business — and the first engagement where letting AI carry the low-signal work measurably moved the team.

The commercial system and the operational system each held a partial account of the business, so any question that crossed them was answered by a person reconciling two screens. We made them one operating picture rather than two feeds pointed at a dashboard.

It was also the first engagement where handing the low-signal work to AI produced a visible speed difference for the team rather than a demo. That is reported as a first proof rather than a general claim, because one engagement is what it rests on.

Partner tiers, commissions, and custom-coded rate resolution — reported here as a design story, because the production outcome is genuinely in doubt and I will not claim one.

Standing up a partner channel means the commercial model gets harder in a specific way: the rate that applies to a given deal depends on the partner, the tier, the product and the timing, and that resolution has to happen somewhere reliable rather than in a spreadsheet someone maintains. We designed the model and custom-coded the rate resolution.

What I cannot tell you is whether it is running well in production today. My own record marks the outcome as affirmatively in doubt, so this sits here as a design story and nothing more. It is on the page because leaving it off would make the rest of this list look better than the work actually was.

An architecture realignment — the objects that carry their real operation put into production, reconciled against the live portal rather than the design docs.

The original build fit a prior, generic business model — not a multi-location vehicle retailer with a buyer side, an acquisition side, financing, and a post-sale operation. We put the objects that carry the real operation into production behind a unified contact view, ran the architecture audit against live reads, and found and reconciled the drift between the design docs and the portal.

The buyer-pipeline reshape that follows is in progress and gated on a sandbox test — named as in flight rather than finished, because it is.

A referral-first population scored fairly — Fit and Engagement kept legible on separate axes, built with their own architect so they run it without us.

Their buyer makes a 12-to-24-month decision and arrives through referrals, brokers, and on-property events — a population a standard engagement score systematically buries, because referral contacts rarely carry a tracking history. Ranking who was worth a call was being done by hand, from memory.

We built a Combined model and wrote down why: a nine-tier grade where the letter reflects Fit and the number reflects Engagement, so a referral-led contact stays legible on the axis that actually describes them. Their architect owns the pieces his team is closest to — the point is that they can run it without us.

Audited down to 65, renewals rebuilt into one pipeline — and support beat its own response target for the first time, 35 minutes against a 60-minute goal.

Growth had outrun the systems: four-hundred-plus active workflows with dependencies nobody could trace, renewals scattered across three divisional pipelines, roughly 450 hours a year spent fixing associations by hand. We audited the workflows down to about 65, built a contact health score their team actually uses, and rebuilt renewals — 409 quarterly contracts extracted from production data into clean records, with the end-to-end renewal quote flow demonstrated working.

A renewal used to be reconstructed by hand across three systems. It is becoming one record with a date on it that a named person owns — and "becoming" is deliberate, because the rollout is still in progress and saying otherwise would be a lie.