Three reps, three spreadsheets, one forecast
The forecast is where this problem surfaces. Each rep quotes from their own copy of the pricing sheet, each copy has drifted a little from the others, and the figure in the deal record is whatever the rep had in front of them. The forecast is the sum of those figures. By quarter end, finance has learned to discount it, sales has learned to defend it, and you sit between the two with no single number you can stand behind.
Nobody decided to run sales this way. The sheet was one person's tool, it worked, it was copied sideways, and every copy was then edited independently. The cost is not the spreadsheet. It is that the quote the customer received and the number in your system were never connected in the first place.
Where the number drifts
Follow one deal. A rep opens their copy of the sheet, picks a configuration, applies a discount they believe is allowed, and pastes the total into a document template. That is the first divergence: the sheet has one number, the document may have another after a manual edit.
The rep then types a value into the deal record. Second divergence: it is a summary, rounded, possibly from memory, possibly from before the last revision.
A discount above the usual level gets agreed in a chat thread or across a desk. Third divergence: the approval exists, but not anywhere the record can see it.
Finally, the sheet itself changes. Someone updates a rate, the copy on another laptop does not, and two reps now quote the same product at different prices. Four points of drift per deal make a matching number the exception.
Bring the calculator to the data
The fix is to put the pricing logic where the deal already lives, as a native extension of the CRM. The rep opens the deal, configures and prices the quote there, and the total is in the record because that is where it was calculated. No number is copied, because there is no second place.
We have built exactly this: the calculator and the document flows as native extensions inside a client's CRM, in the same engagement that produced the trust centre in stop emailing security PDFs.
That is not another tool for the rep to resist. It removes one, and with it the switching between spreadsheet, document template and CRM. Fewer steps is the promise; the governance arrives without anyone asking for it. Complex pricing is the strongest argument against a spreadsheet, not for one: rules buried in cell formulas break the moment the file is copied, while one versioned pricing logic can be read and tested.
Approvals inside the flow
The approval threshold is the rule that says which discounts a rep may give alone, which need a manager, and which need finance. Today it lives in people's heads and is enforced in corridors. Inside the flow it is part of the pricing logic: a quote that crosses the threshold waits for approval before the document can be generated, and the decision, the approver and the time are written back to the deal record.
This is not more bureaucracy. The conversation already happens; it just leaves no trace. Recording it gives finance a list of every exception and who agreed to it.
Enforcing the threshold inside the calculator is the pattern we recommend once it sits in the deal record: the rule then has a place to live, and the decision has a place to land.
What each side gains
Sales gains speed. The quote is built where the deal is, the document comes from the same record, and nobody reconciles two numbers at month end.
Finance gains evidence. One versioned pricing logic, owned by finance rather than by whoever opened the file last, so a rate change reaches every rep at once and every discount above the threshold has a name against it.
IT and procurement gain the absence of something: no new system to buy, no new login to manage, no new integration to keep alive. The logic runs in a platform you already administer, under access rules you already set. And what you would carry to a different CRM is one written set of rules, not a folder of spreadsheets.
If you are mid migration to a new CRM, that is the reason not to wait. Design the pricing logic now, on paper, and implement it once, in the destination.
Where a spreadsheet still wins
None of this makes the spreadsheet useless. Modelling a new pricing tier, testing what a volume discount does to margin across last year's deals, or building a scenario for a board paper: those are spreadsheet jobs and should stay that way. The spreadsheet is where finance decides what the rules should be. The CRM is where the rules are applied to a real customer. Trouble starts when one file tries to do both.
