The Simple Fix

Not every ticket is a green-field build. Sometimes it’s one wrong field on a live system that’s been running fine for years — and the real work is knowing how much not to build.

The Problem

A client’s project managers were manually correcting a survey org code by hand, every single survey, because the connector was pulling the org description instead of the org code — a structured identifier their reporting depended on. At their volume, hundreds of surveys a quarter, that was a small, constant tax nobody had scoped a fix for until the ticket landed.

Scoping Before Building

Before writing anything, I clarified scope with the client rather than assuming the more complex answer was the right one. The system already defaulted to pulling the org of the current project, but there was also an existing option to attach survey groups that fell outside the project’s actual org structure entirely.

I laid out both paths:

• A simple fix that only ever uses the project’s own org code
• A more involved build that would support arbitrary extra groups

They confirmed they only needed the simple version — which meant I didn’t build more than the problem required.

Catching What Wasn’t Asked For

While gathering requirements, I also caught a data-integrity issue the client hadn’t flagged: one project, copied from an earlier promotional project, was producing a malformed value — three fragments joined together instead of the intended format. That wasn’t the original ask, but it was clearly going to cause the same downstream reporting problem, so I flagged it and folded the fix into the same change.

The Build

The fix stayed entirely inside the SQL layer — no API changes — which kept the blast radius small for a live production system already in use elsewhere. I had the client test the script in their own sandbox before rollout.

What started as a fix scoped to one project type grew mid-engagement: after checking with a stakeholder, the client asked to extend it to a second category, for future-proofing. Their own test run gave me real runtime data — roughly two hours across all affected records — which let their ops team size an accurate maintenance window for the live cutover instead of guessing.

I also worked through a live edge case with the connector vendor’s client-success team: how the fix interacts with a survey opt-out flag, specifically for projects duplicated from an opted-out template and later re-enabled. That distinction mattered enough that it got flagged internally on the client’s side as something their team needed to know before sending.

Once the plan was set, I stayed available for the live rollout — the client scheduled a standby call with me the morning after their production deployment, specifically in case anything broke.

The Result

The fix was intentionally minimal in final form. But the engagement behind it wasn’t small: full ticket-to-resolution ownership across several weeks, a scoping decision that kept the build simple, an unprompted data-integrity catch, and a coordinated live rollout across two organizations.

It removed a manual correction step from every survey the client sends, while improving the accuracy of their downstream reporting — since the org code is what their reporting structure actually keys off of.

It’s a fix that’s easy to underrate on the surface, and easy to get wrong if you don’t scope it, test it, and plan the rollout carefully.