The Spreadsheet Is a Receipt for a Decision

The Spreadsheet You Maintain Is a Receipt for a Decision You Didn't Make

Somewhere on your machine there is a spreadsheet you rebuild every week. It reconciles two systems that should agree and don't. You didn't choose to maintain it. It accreted, quietly, until it became part of your job. That spreadsheet is not a process. It's a receipt - for a decision made above you, before your time, in a function you may never deal with directly. Most of the manual work that fills an ops team's week traces back to exactly two of them: Data Engineering and Product/Platform.

Your workload has an origin story

The instinct, when work piles up, is to blame the work. Too many requests, not enough headcount, a busy quarter. Sometimes that's true. But a large share of recurring ops toil isn't volume - it's compensation. You are manually holding together something that was supposed to hold together on its own.

The useful question isn't "how do I get through this faster?" It's "what decision, made where, turned this into my problem?" Trace almost any standing manual task back far enough and it lands in one of two places.

Data Engineering: the duplicate that becomes your morning

Start with partner data. Somewhere upstream there's meant to be one record per partner - one ID, one tier, one consistent classification that every other system reads from. When that's clean, you never think about it. When it isn't, you think about it constantly, without knowing that's what you're doing.

A duplicate partner record doesn't announce itself. It shows up as the partner who got the wrong MDF and emailed you, annoyed. As the tier-gated content that opened for someone who shouldn't have access. As the co-sell credit that didn't land. As the report two stakeholders refuse to trust because the totals don't match. Each one arrives as a separate fire. You fight them separately. None of them feels like the same problem.

They are the same problem. They're a partner data model that was never properly resolved, surfacing downstream as a dozen unrelated-looking tickets. You are the resolution layer that the data model isn't. That's the morning: hand-correcting records to compensate for IDs that were never reconciled at the source.

Product/Platform: built to a spec that had already changed

The second source is subtler. A tool gets built - a portal, a workflow, an intake form. The team builds exactly what the requirements describe. The problem is when the requirements were locked.

If scope was frozen before the data model, the consent rules, or the co-sell logic were actually settled, the tool got built to a spec the business hadn't finished deciding. Builders deliver what the doc says. If the doc described a state that then changed, the gap doesn't disappear. It gets handed to you, in production, as a workaround. The form that doesn't capture the field you now need. The status that has to be updated by hand because the integration assumed a flow that no longer exists. The export-reformat-reimport dance between two tools that were specced before anyone agreed how they'd talk.

This isn't a build-quality problem. The tool does what it was told. It's a sequencing problem - scope locked ahead of the decisions that should have driven it - and the cost of that early lock gets paid in your manual steps, every cycle, indefinitely.

What fixing it actually looks like

Here's the part worth being honest about: most of this is not yours to fix alone, and pretending otherwise is how it stays broken.

The duplicate records won't be solved by you cleaning them faster. They get solved at the data layer - one canonical record, resolved at the source, so the downstream tickets stop being generated in the first place. The tool workarounds won't be solved by a better workaround. They get solved upstream, by resolving the data and policy decisions before scope is locked, so the build matches reality.

What is yours is the evidence. You are sitting on the clearest record anyone has of where these decisions went wrong - the recurring tickets, the standing reconciliation, the workarounds with no expiry date. Named precisely, that's not a list of complaints. It's a diagnosis, traced to a specific upstream cause, which is exactly what it takes to get the decision revisited where it was actually made.

The closing observation

The trap is treating manual work as the cost of doing the job. Some of it is. But the work that repeats in the same shape every week, that exists only to make two systems agree, that you could describe in your sleep - that work has an address. It was created by a decision in Data Engineering or Product/Platform, and it lives with you because no one traced it back. Those two are just part of a wider set of functions that shape a partner program this way, which is exactly what our The Organizational Interdependencies That Make or Break a Partner Program maps out.

The spreadsheet isn't your process. It's the receipt. The fix starts with reading what's printed on it - and sending it back to where the charge was made.