Jack Crabtree, Founder · 4 August 2026 · Case study

Overview

The client is a US sales consultancy. Part of its own service to its clients is keeping systems like Outreach and Salesforce in sync inside those clients’ revenue stacks, which means the consultancy’s reputation rests partly on infrastructure it doesn’t fully control. In one enterprise client’s environment, the Outreach-Salesforce sync had been failing intermittently for long enough that nobody trusted the numbers coming out of it anymore. We were brought in for two separate pieces of work: fix the sync, and build a scoring model the client’s own team could run without us. Both pieces mattered, but they were solved differently, and we’re describing them separately because conflating a remediation project with a build project usually hides the actual work either one involved, and makes it harder for anyone reading this to judge which parts of it are relevant to their own situation.

The Problem

Sync failures between Outreach and Salesforce are common enough that most revenue teams have learned to live with some baseline level of them, which is itself part of the problem: a team that’s used to a noisy sync stops noticing new noise until it’s bad enough to affect forecasting. In this enterprise client’s environment, fixable errors had piled up over time, and every report and forecast built on the underlying data had inherited the doubt. Nobody could say with confidence whether a given number reflected reality or reflected a sync gap. That’s a worse position than having no sync at all, because at least the absence of automation is an honest state; a sync that’s silently wrong some unknown percentage of the time erodes trust in every number downstream of it, and by the time it gets escalated, the team has usually stopped trusting the CRM generally, not just the sync.

Our Solution

We didn’t start by guessing at fixes. We audited the sync pipeline end to end first, because a sync that’s been failing for a while usually has more than one thing wrong with it, and fixing the first bug you find is a good way to spend a week solving 10% of the actual problem. The audit mapped every point where records failed to reconcile between the two systems, and the dominant root-cause class turned out to be picklist label versus API-name divergence: a field value that displayed correctly to a human in one system but didn’t match the underlying API identifier the other system expected, so the sync would silently fail to reconcile that record even though nothing looked wrong on screen. That’s a specific, mechanical class of bug, and once we’d identified it as the dominant cause, we could triage and classify every failing record against it rather than treating each failure as a one-off.

With the failures classified, we isolated what was genuinely fixable, because not every sync gap has a clean fix; some reflect a structural mismatch between how the two systems model the same concept, and forcing a fix onto that kind of gap usually creates a new, subtler bug. For the fixable set, we worked through a concentrated remediation pass rather than a slow trickle of individual fixes over months, on the basis that a sync problem affecting live forecasting deserves a fast, decisive fix more than a cautious, incremental one. For the errors that weren’t cleanly fixable within the scope of this engagement, we documented the residual error classes for the client’s own admins rather than quietly leaving them unaddressed, so the team would know exactly what was still there and why, instead of assuming everything had been resolved.

The picklist divergence pattern is worth explaining in a bit more detail, because it’s a class of bug that’s easy to miss precisely because it doesn’t look like a bug to a human reviewer. A sales rep looking at a deal in Outreach sees a clean, readable label, something like “Closed Won.” Salesforce, underneath its own picklist for the equivalent field, stores and expects a specific API name, which is often similar but not always identical, especially in an org that’s been customised over time by different admins with different naming conventions. When the two don’t match exactly, the sync doesn’t throw a loud error a rep would notice; it fails quietly for that specific record, and the record simply stops reconciling. Multiply that across a large org with picklists that have drifted for years, and you get exactly the pattern we found: not one big broken thing, but a long tail of small, quiet mismatches that individually look like edge cases and collectively account for most of the sync’s unreliability.

Separately, for one of the consultancy’s clients, we built a deterministic Clay scoring model with seven components. Deterministic here means exactly what it sounds like: the same inputs produce the same score, every time, with no hidden randomness or model drift between runs. That mattered more than raw scoring sophistication for this client, because a scoring model a sales team can’t reason about is a scoring model they’ll eventually stop trusting, the same way the sync had been trusted less over time. We shipped it with full operator documentation, specifically so the client’s own team could run and adjust it without us in the room. A scoring model that only its original builder can maintain isn’t a deliverable; it’s a support contract in disguise, and that’s not the kind of dependency we build client relationships around.

How We Deployed It

The remediation work was verified against a fixed before/after baseline rather than judged by feel. That distinction matters more than it might sound like it should: “the sync feels more reliable now” is not a claim we’re willing to put in front of a client or in front of anyone reading this case study, because it’s not falsifiable. We measured the error rate before the remediation pass, applied the fixes, and measured again against the same method, which is how we can say roughly an 86% reduction rather than “a lot better.” We rounded down in how we describe it publicly on purpose: the honest figure is close to but not precisely 86%, and rather than present a more impressive-looking exact number, we’ve chosen to describe it as roughly 86% throughout, which is a more accurate reflection of the underlying measurement’s precision.

The scoring model build had a different kind of deployment risk: not “did it break” but “will the client’s team actually be able to run it once we’re gone.” We treated the documentation as part of the deliverable, not an afterthought written up at the end. That meant writing it as we built each of the seven components, not retrospectively summarising a finished system, because documentation written alongside a build tends to explain the actual reasoning behind a decision, where documentation written after the fact tends to describe what the system does without explaining why it does it that way, which is the part a team actually needs when they come to adjust it six months later.

The Outcome

Roughly an 86% reduction in fixable sync errors, measured and not rounded up. Sync data became something the team could rely on again, and everything downstream of that, forecasting, reporting, and account prioritisation, depends on the underlying sync being trustworthy in a way that’s easy to take for granted until it isn’t there. On the scoring model side, the outcome is qualitative and we’re stating it honestly as such: the client’s team runs the model independently, using the documentation we shipped alongside it, without an ongoing dependency on us to keep it working. That was the actual goal of that piece of work, and it’s the kind of outcome that doesn’t show up as a percentage but matters just as much as one that does.

We’re also stating plainly what this engagement didn’t cover. We didn’t rebuild the client’s broader Outreach or Salesforce configuration beyond the sync-relevant fields, and we didn’t extend the scoring model beyond the seven components it was scoped for. Both of those were deliberate boundaries, not oversights: a remediation engagement that quietly grows into a full platform rebuild stops being a fast, targeted fix and starts being a much larger, much riskier project that the client didn’t ask for and hadn’t budgeted the time to properly evaluate against alternatives.

Related: RevOps Consultancy and AI Deployment. More on the team behind this build: About Equanax.