A ticket sales team for a pro sports franchise came to us part way through their search for a new CRM, and the thing that kept eliminating platforms was not a feature anyone puts on a comparison chart. It was how each one handled a customer changing their mind.
Here is the pattern: a group commits to 100 tickets for a September game and puts down a deposit. Two weeks later they call and say they only need 80. The team needs that decrease of 20 to appear as its own line, dated the day the call came in, sitting next to the original commitment of 100. What they do not want is the number 100 quietly becoming 80.
That sounds like a small distinction, but it decides whether their weekly sales report can be trusted.
Why overwriting the number breaks the report
Every Monday this team sends leadership a report covering the previous week. If the original commitment is edited from 100 down to 80, the week the group first committed no longer says 100. It says 80, retroactively. Run the same report a month later and it gives a different answer than it gave at the time.
The decrease itself also disappears. There is no week in which anything happened, because nothing was recorded as happening. You can see where the season landed, but not when it moved, or by how much, or why.
A bank balance tells you one number: what you have right now. A bank statement tells you every movement, with the date each one happened, and the balance falls out of adding them up. Sales commitments need to behave like the statement. The current number should be something the system works out from a list of dated events, never a figure someone types over the top of the last one.
How this gets built in Dynamics 365 Sales
Four pieces, and none of them require custom software written from scratch. This is configuration of things the platform already does.
1.The commitment holds a list, not a number.
In Microsoft Dynamics 365 Sales, a deal does not have to carry a single quantity that gets edited over time. It carries a list of lines underneath it. The first line is the original commitment: 100 tickets, dated the day the group agreed to it. Every later change is a new line under the same deal, with its own quantity and its own date.
2. A change is always a new line, never an edit.
When the group drops to 80, nobody opens the original line and types over the number. A second line is added: minus 20, dated the day of the call, with a reason chosen from a short list of the reasons this happens in practice. The original line is left exactly as it was, permanently.
The current committed figure is then not typed by anyone at all. Dynamics 365 Sales adds the lines together and keeps the running total on the deal, so it updates the moment a change is entered, and it can never disagree with the lines behind it. There is no version of this where the summary and the detail drift apart, because the summary is only ever the sum of the detail.
3. Why this belongs on the sales record and not in the accounting system.
This distinction matters more than it first appears. The group paid a deposit of 25%, then reduced their count before paying the rest. No money went back to them. Their deposit still stands, and what changed is the balance they still owe.
That is a sales event, so it lives in the sales platform. If the full amount had already been collected and some of it was going back, that would be a money event, and it belongs in the accounting system as a credit. Building the first case as though it were the second is a common way these setups go wrong, because it pulls a routine sales conversation into the books and makes the month harder to close rather than easier.
Accounting stays the place money is recorded. The sales platform stays the place commitments are recorded, and when they changed.
4. The deposit and the remaining balance sit on the deal.
Because the committed total is worked out rather than typed, the balance owed can be worked out too. A rep taking the phone call sees the original commitment, every change since, and what is still owed, without opening the accounting system or asking anyone to check.
What the reporting looks like afterward
This is where the design earns its keep. Each line carries the date the thing happened, so a report can group by that date rather than by the deal it belongs to.
The week the group committed shows 100. The week of the call shows minus 20. Neither week ever changes again, because neither line ever changes. Add up every line to any point in the season and you have the position as it stood that day. Add up only the lines inside one week and you have that week's movement, which is what the Monday report is reporting.
Monthly and season-to-date views come off the same lines. There is no second set of numbers to keep in step, and nothing to reconcile, because there was only ever one list.
The same holds when this team's reporting pulls in figures from their ticketing platform and their accounting system alongside the sales platform. Each source keeps its own dated records, they meet on the calendar rather than on a spreadsheet, and a variance between them becomes something you can see on a report instead of something three people find in a meeting.
The two decisions worth settling first
Neither is difficult. Both are much cheaper to settle before the build than after it.
Where the lines live. There are two reasonable ways to hold them. One uses the quoting and ordering lines Dynamics 365 Sales already provides, configured to accept a reduction. The other adds a purpose-built list of commitment changes attached to the deal, carrying its own date, quantity, and reason on every entry. The second gives more control over what is captured and reported; the first is less to set up. Which one fits depends on how tightly the reasons for a change need to be tracked, and it has a bearing on which Dynamics 365 Sales licensing tier is the right one, which is why it is worth answering in the first week rather than the fifth.
Which stage the change happens at. A reduction before full payment, a reduction after it, and an outright cancellation are three different events with three different consequences. Writing down which of them the business sees, and roughly how often, is the fastest way to size this properly.
If this is the requirement that keeps breaking demos
A quirk like this rarely comes up in a standard platform tour, because a demo tends to follow the path where nothing goes wrong. The edge cases specific to how a business runs are where platforms differ from each other, and they are worth putting in front of a partner before a platform is chosen rather than after.
If you have one or two of these, bring us the report that keeps breaking and we will walk through how it would be built.