Loading
Because in most systems the deal is a row with a number on it. When the quarter is reviewed nobody can say when the close date slipped, who moved it, or what the value was before somebody rounded it up.
The deal is the record of one opportunity: value, currency, owner, stage, close date, the company and contacts attached to it, and the full history of how each of those changed.
Every field change is written to the deal's own history with the actor and the timestamp. The deal shows its current state and, on the same page, the path it took to get there.
A £41,900 expansion at Kanaka Foods closed a month late. The history shows the close date moved twice, both times the day after a rescheduled review — which is a procurement problem, not a sales one.
It holds what the deal is worth to you, not what it costs to deliver. Margin lives in Loop and Books, because that is where the time and the invoices are.
Quotes price against it, Loop opens delivery phases from its sold lines, Books drafts the billing schedule from its terms, and every pipeline report is an aggregate of these rows.
Yes, on any object, with types and validation. They appear in the API and in reporting like the built-in ones.
Whoever you permit. Every change is recorded with the previous value regardless of role.
It stays as the record of the sale. Loop and Books open delivery and billing from it rather than copying it.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.