Skip to content

The Ops Operating System · Part 8

When the Tools Fight Back: How to Turn Martech Friction Into a Business Case

Quick answer (TL;DR): Every GTM stack has tools that don’t cooperate: the Salesforce sync that silently skips records, the form that stops passing UTMs after a site release, the enrichment tool that overwrites good data, the connector that errors every Monday. Most teams absorb these as noise and patch them one at a time. The better move is a friction log: every tool failure recorded as a system event, with the date, what was attempted, what happened, the impact and the time spent. An AI assistant that maintains the team’s records makes it nearly effortless. Over a quarter, “the tools are a bit flaky” becomes “this integration failed this many times, cost this many hours and delayed these leads”, which is a vendor escalation and a business case in one document.

This is the most commercially useful habit in The Ops Operating System, because tool friction is where much ops time goes, and very few teams can show it.

The quiet cost of tools that don’t work

Every ops team knows these moments:

  • The HubSpot–Salesforce sync reports success, but a batch of records never arrives because a required field was blank.
  • A form stops passing UTM parameters after a website release, and a week of attribution is gone.
  • A workflow re-enrols contacts it shouldn’t, and someone spends a day unpicking the sends.
  • A connector’s token expires, and leads queue silently until a sales manager asks where they went.

Individually each is small. Cumulatively they’re expensive, and because the ops team keeps fixing them, the cost is invisible to everyone else. Leadership sees an ops team that’s always busy and never quite finishes the roadmap. They don’t see the hours spent propping up a tool that doesn’t do what the contract promised.

Worse, without a record the friction gets attributed to the team: “ops keeps dropping leads” when the real story is “this connector drops leads, and ops keeps catching it.”

The friction log: friction recorded as evidence

The practice is simple: when a tool fails, log it as a tool failure, with specifics, in the team’s shared memory. Not as a ticket someone fumbled, but as a system event:

  • Date and system: which tool, integration or workflow.
  • What we were trying to do.
  • What happened instead, including any error message or case number.
  • Impact: records affected, leads delayed, reports wrong, sends misfired.
  • Time to detect and time to fix.
  • Workaround in place, if any.

The point isn’t a grievance file. It’s that patterns only show up in data. One sync failure is an anecdote. Several in a quarter, logged with dates, impact and hours, is a systems problem with a price tag. An AI assistant is well suited to keeping this: it can add entries during the closing ritual, tag them by system and summarise the pattern when you need it.

From isolated incidents to an actionable pattern

Without a log:

“The sync has been a bit unreliable lately. We’ve had a few issues with the enrichment tool too.” (Vague. Easy for a vendor or a budget holder to dismiss.)

With a log:

“This quarter: the HubSpot–Salesforce sync failed silently on several occasions, affecting a documented number of records, each detected by a stakeholder rather than by monitoring. The enrichment tool overwrote title data we had verified by hand on two imports. Together, these took a measurable number of ops hours to detect and fix.” (Specific, dated, costed. Now it can be acted on.)

The second version is both truer and more useful. The numbers are yours, from your log, which is exactly why they carry weight.

What to do with the pattern

A documented friction log gives you options you didn’t have before.

  • Route around it. Record the workaround (“this connector fails on records without a company name, so we now fill the field before sync”) so the next session, or the next teammate, doesn’t rediscover the wall.
  • Escalate to the vendor with evidence. “These failures, on these dates, with these case numbers and this impact” gets a very different response from a vendor’s support or account team than “your sync is flaky”. It’s also what you bring to the renewal conversation.
  • Build the business case to fix or replace. Hours lost multiplied by a loaded hourly cost, plus delayed or lost leads, set against the cost of a fix, a different tool or a rebuild. Finance can evaluate that. They can’t evaluate “the tools are annoying”.
  • Set expectations with stakeholders. If a tool is unreliable, say so in advance with the log behind you, rather than explaining each failure after the fact.
  • Feed tool rationalisation. At renewal time, the log shows which tools earn their place and which create more work than they save.

Make detection part of the log

One field in the log deserves special attention: who detected the failure. If most failures are spotted by a sales rep or a finance analyst rather than by ops monitoring, that’s a finding in itself. It tells you where to add alerts, sync-error reports or daily reconciliation checks, and it’s often the cheapest fix on the list.

Log the friction. A dated, costed pattern is the difference between “the tools are a bit flaky” and “this integration is costing us this much, and here’s the case to fix it”. One gets ignored. The other gets funded.


Frequently asked questions

How should a marketing-ops team handle tools that keep failing? Log every failure as a system event: date, system, what you tried, what happened, impact, time to detect and fix, and any workaround. The pattern becomes evidence for a vendor escalation, a fix, or a replacement.

How do we build a business case to replace a martech tool? Start from a friction log. Total the ops hours spent on the tool’s failures, add the downstream impact (delayed leads, wrong reports, misfired sends) and compare that with the cost of fixing or replacing it. Dated, specific evidence is what finance and procurement can act on.

How do we escalate effectively with a SaaS vendor? Bring specifics: the dates, error messages, support case numbers, records affected and business impact from your log. A documented pattern is far harder to dismiss than a general complaint, and it’s useful again at renewal.

Can an AI assistant help keep a friction log? Yes. An assistant that maintains the team’s records can add entries as failures happen, tag them by system, and summarise the pattern and its cost when you need it for an escalation or a budget request.


This is Part 8 of The Ops Operating System. The series closes with the idea that ties it together: your team’s operating method has to outlast any one person, tool or vendor.

If your friction log keeps pointing at the same integration, our GTM Systems Audit diagnoses the HubSpot, Marketo and Salesforce syncs behind it and tells you whether to fix, rebuild or replace.

Get new parts in your inbox.

One short email when a new part of The Ops Operating System is published.