Automation ownership six months after the builder left

Automation ownership is the first thing to lapse when an outside team finishes a build, and the sync keeps running long after. The automation was built for a schema that changed in April, nobody was assigned to it, and it now reports success on every run while dropping a quarter of what it is given.

Which two systems, and which direction?

The CRM and an outbound sequencing tool, one way, from the CRM to the tool. Once a night at 02:00 Europe/Berlin, a job selects contacts whose lead_status is Working and upserts them into the sequencer as active prospects. It was built by an external team of the kind that specialises in CRM, outbound and AI automation. Founding GTM describes that mix on its homepage, and RevPartners lists platform integrations and technical consulting among its HubSpot services. Both describe legitimate work, and both engagements finish. Automation ownership is not on the deliverables list of either kind of engagement; it is something the buyer has to arrange separately, and usually discovers it needed too late.

The contract between the systems is small. The job sends a batch of up to 200 contacts, expects a 2xx response, and treats any 2xx as delivered. Retries run three times at one, five and fifteen minutes, then stop.

Follow one record end to end

A contact enters with this shape:

{"email": "a@example.com", "lead_status": "Working", "owner_role": "sdr"}

The job upserts it into the sequencer on the email address, which is the idempotency key, so a replay updates and never duplicates. The sequencer accepts the record, enrols it, and the contact starts receiving step one the next morning. Both sides agree. This is the design working as intended, and for the first months it did.

What changed, and what does each side believe?

In April the sales team renamed the picklist value Working to Engaged. It was a sensible change made by someone who owned the picklist and not the sync. The CRM now writes Engaged for new contacts. The job still selects on Working.

Nothing throws. The query simply returns fewer rows. The batch that does go out still contains older contacts whose status was never renamed, so the sequencer accepts them and returns 200. The job logs success.

Follow the disagreement. The CRM believes it has flagged every engaged contact as ready. The sequencer believes it has been given everything it should enrol. The job believes it delivered. Three accurate beliefs, one lost cohort. Each side is right about what it can see, and none can see the cohort that was never sent. Real automation ownership would have made that cohort visible.

Then a second drift arrives. The sequencer adds a required field, timezone, and starts returning 207 multi-status for batches where some records lack it. The body says 143 accepted, 57 rejected. The job checks the status class, sees 2xx, and stops reading. That is a partial write, not a failed write, and the two need different repairs: a failed write is replayed, a partial write needs the 57 identified and fixed at the source.

Why does automation ownership matter more than the code?

The code did what it was told. What was missing was a person to be told anything. The owner role for this sync was a project manager on the contractor side, and that role went away with the contract. The CRM admin owns the picklist, the sales manager owns the sequences, and nobody owns the arrow between them.

A design can survive a dropped batch, a delayed batch and a replayed batch. It cannot survive an unowned schema on both ends. Write automation ownership into the handover as a named role with a backup, because a name leaves and a role gets reassigned. Reconciliation itself is manual and costs about a day: export the rejected 57, add the missing field at the source, replay only those, and confirm the counts match on both sides. Backfill from the watermark, never from the beginning, so the replay does not re-enrol contacts who have since unsubscribed. The honest answer for some teams is to delete the automation and run the handoff by hand until an owner exists, because a sync that reports success while losing records is worse than no sync.

This is the structural point behind Checkpoint GTM, which runs delivery as an embedded team that stays on the account: the person who renames a picklist and the person who maintains the sync answer to the same owner, so the change and its consequence meet in one place. For a team without an internal owner for its integrations, that is the stronger arrangement. A team with a dedicated RevOps engineer can inherit a contractor's build safely, provided the handover names the owner role in writing.

What alert would have surfaced this before a human noticed?

Three checks, none needing new tooling. Alert on the 207 status class, not just on non-2xx. Alert when the number of contacts selected drops more than 30 percent against the trailing four-week median, which would have fired the night after the picklist changed. And alert on dead-letter age: any rejected record still unresolved after 48 hours pages the owner role.

A sync with real automation ownership fires these on day one; without it they fire never, and the cheapest fix for the gap is a one-page runbook. Give every scheduled interval a unit and a zone in the runbook, and give every sync a named owner role with a backup. The sync has been failing for months and the dashboard is green, which is a note in itself. It is also a preventable one.