Product Thinking

The price that only changed in the email

The price changed in the call; the proposal still quotes the old number.

ASR

Apollo Space Research

Apollo Space

· 10 min read

On a call, you agree to a lower price. The customer is happy, you’re happy, the deal is back on, and you move on to the next thing before the call even ends. The new number is real. It happened. And then it sits there, true in exactly one place, that conversation, while the proposal, the invoice, the onboarding email, and the renewal forecast all keep quietly quoting the number you already walked away from.

Nobody lied. Nobody was careless. The new price just never propagated.

That is the most expensive failure in a company, and almost no one names it, because it doesn’t look like a failure. It looks like a normal Tuesday. This post is about the one mechanism that fixes it, and why the thing most companies bolted on can’t.

The fact that’s only true in one place

The shape repeats everywhere, so it’s worth saying plainly first. A fact about your business changes. It gets recorded in the one place the change happened, the call, the email, somebody’s head, and every other copy of that fact keeps showing the old value until a human notices the drift and patches it by hand.

That’s the bug. Here’s the refrain I want you to leave with: the price changed in the call; the proposal still quotes the old number.

It sounds small. It isn’t. The same shape is the meeting that moved in a thread but never moved on the invite. The customer who said “we’re probably done” on a call but still reads “active” in the CRM, the dashboard, and the renewal forecast. The deadline that slipped in the standup but still says “Friday” on the plan the whole team works against. Each is a fact that’s true in one place and false everywhere else, and the gap between those two states is where deals die, margins leak, and a customer opens an invoice for a number you both already agreed wasn’t right.

The reason this is so hard to stamp out is that the moment of change and the moment of consequence are far apart. The new price feels finished the second you both nod to it. The pain arrives weeks later, from a completely different direction, a billing dispute, a renewal modeled on revenue you discounted away, and by then nobody connects it back to one sentence on one call.

The naive fix: tell everyone to be more careful

The instinct, every time, is discipline. We write the checklist. “When a price changes, update the proposal, the billing record, and the deal notes.” We add a step to the runbook. We remind people in the retro. For a week, it works, because everyone is freshly annoyed about the last miss.

Then it decays. Not because the team is lazy, because the discipline scales with the number of places a fact lives, and that number only goes up. Five tools become twelve. The quote, the proposal, the CRM, the billing system, the dashboard, the onboarding email, the partner-facing rate card. Updating one number correctly now means remembering, by hand, every downstream copy of it, every time, forever, across a dozen surfaces that don’t talk to each other.

This happens to every team that grows past a handful of tools, and it’s worth being precise about the mechanism: you didn’t get sloppier. You got more surfaces. The discipline that worked at five tools is the same discipline, applied to twelve, and it fails not at the step but at the count.

Asking people to manually keep a fact in sync across a dozen tools is asking them to do, by hand, the one job computers were invented for.

So discipline is the wrong layer. The checklist treats a propagation problem as an attention problem. It puts the burden of consistency on the most forgetful, most interrupted, most depleted part of the system, a human juggling twelve tabs, when the whole point of software is to never make a person remember something a machine could carry.

Two ways a changed price plays out: in the manual lane the new number lives only in the call while the proposal, invoice, and renewal forecast keep quoting the old price; in the system lane one update fans out to every copy automatically.

The real fix: one source of truth, and a system that propagates from it

The key idea is simple. Stop storing the same fact in twelve places that drift. Store it once, in one place that’s authoritative, and make every other surface a view of that one place, so when the fact changes, every view changes with it, because there’s nothing else to change.

Engineers will recognize this immediately. It’s the difference between copying a value into ten spreadsheets and putting it in one cell that ten spreadsheets reference. The first guarantees drift. The second makes drift impossible, because there’s only ever one number. The bug was never that people forgot to update. The bug was that there were ten numbers when there should have been one.

A company runs on the first model almost everywhere. The agreed price lives in the call notes and the proposal and the billing system and the salesperson’s memory, four copies, four chances to drift. The customer’s status lives in the CRM and the deal channel and the head of whoever last spoke to them. Every duplicate is a future contradiction waiting for a slow Tuesday to surface.

This is the version where the refrain finally breaks. The price changed in the call; the proposal still quotes the old number, but only because the proposal was a separate copy. Make it a view instead, and there’s no second copy left to drift.

Move to the second model and the proposal stops being a separate copy of the price. It becomes a window onto the single fact “this customer’s price is the new number.” Change that fact once, and the proposal, the invoice, the onboarding email, the renewal forecast all show the new number, not because someone updated four things, but because there was only ever one thing, and four windows looking at it.

Bolt a chatbot onto a company with twelve drifting copies of every fact and it doesn’t fix the drift, it adds a thirteenth surface that can be confidently wrong, because it’s reading whichever stale copy it happened to be pointed at. A smarter answer drawn from the wrong source is still the wrong answer, delivered faster.

The hard part: knowing the fact changed at all

Here’s where one source of truth stops being a database lecture and becomes the actual product. Pointing every surface at one fact is the easy half. The hard half is noticing that the fact changed, because in real companies, facts don’t change through a form with a “save” button. They change in a sentence, in a thread, in a call nobody transcribed.

Nobody opened the billing system and edited the rate. Someone said “okay, let’s do it at the lower number, send the updated paperwork.” That sentence is the moment the fact changed. If your system only listens to the billing record’s edit field, it will never hear it, and the source of truth, however elegant, stays frozen on the old price while the real decision sails past in plain language.

So the system that actually fixes this needs two properties at once. It has to hold one authoritative copy of each fact, and it has to be always listening, across the messy human surfaces where facts actually change, so it can recognize “let’s do it at the lower number” as an update event and not just chatter. One without the other is half a fix. A source of truth nobody updates is just a prettier place to be wrong.

A single authoritative fact at the center, this customer's agreed price, with the proposal, invoice, onboarding email, and renewal forecast as windows onto it; when a sentence on a call changes the price, the change radiates outward to every window at once.

That’s the loop that closes the gap: listen across the surfaces where decisions are actually spoken, recognize the change, update the one authoritative fact, and let every view follow. The price changes in the call, and this time the proposal changes with it, because the call and the proposal were never two facts. They were one fact and two windows, and the system was watching the window where humans actually live.

Why this can’t be a feature you bolt on

It’s tempting to treat sync as a plumbing problem, wire the CRM to the billing system, the billing system to the proposal, done. Teams try this, integration by integration, and it works until the second tool, then collapses under its own arithmetic. Connect a dozen tools pairwise and you don’t have twelve connections to maintain. You have closer to seventy, each one a place where the fact can leak, each one breaking the day a tool ships a new API.

That’s why the fix has to be a layer, not a wire. One place that holds the facts, that everything else reads from and writes to, so adding the thirteenth tool means pointing it at the center, not stitching it to the other twelve. The drift problem doesn’t get solved by more connections. It gets solved by removing the duplicates the connections were trying to reconcile.

Which is the same realization, one level up: this isn’t a feature. It’s an operating system for the company’s facts. The features, the briefing, the reminder, the alert when two surfaces disagree on what a customer pays, are what you get for free once the facts live in one place and something is always listening for when they change. Build the layer and the features fall out. Build the features first and you’ve just added more places to drift.

The turn

You already know who pays for the drift. It’s the person on your team who has become the human source of truth, the one everyone messages to ask “wait, did we land on the new price or the old one?” because they’re the only copy that’s reliably current. They hold the real state of the company in their head, and they’re exhausted, because being a load-bearing memory is a full-time job nobody put in the job description.

That person isn’t valuable because they remember which discount went through. They’re valuable for everything they can’t do while they’re busy being a database, the judgment, the relationship, the call only they can make about where the company should go next. Every minute they spend reconciling stale copies is a minute stolen from the one thing no system can do for them. We didn’t hire them to be a sync engine. We let them become one because nothing else would.

The point of one source of truth was never tidiness. It’s to give that person back the part of themselves that a machine should never have been allowed to consume.


We’re building this at Apollo Space, not a smarter chatbot reading whichever stale copy it landed on, but a layer that holds your company’s facts once and keeps every surface honest to them. If your most trusted teammate has quietly become the place everyone checks because nothing else can be trusted, that’s not loyalty you should be proud of. It’s a sync problem wearing a person’s face, and it finally has somewhere better to live.

Apollo runs your company's repetitive ops so your team doesn't.

Join the waitlist for early access, founding-user pricing, and a front-row seat as we ship.

Join the waitlist