How PDP Keeps Deleted Deals for Loss Analysis
PDP now uses soft delete for deals: a manager picks one of 13 loss reasons, and the sales team gets data for analyzing the funnel.

For PDP, we implemented soft delete for deals: the manager selects one of 13 loss reasons, and the deal leaves the active funnel while remaining available for analytics.
From the user’s perspective, this looks like a normal CRM action. The deal is no longer relevant: the client changed their mind, the deadline expired, the property doesn’t fit, or the mortgage no longer meets the conditions. The manager clicks delete, but the system does not let them close the dialog with a blank click. A reason is required.
The reasons are predefined in a reference list of 13 options: “expired,” “bought from a competitor,” “delivery date doesn’t work,” “we don’t work with military mortgages,” and other loss scenarios. This is an important detail. If we allowed a free-form field, a month later the database would contain “changed mind,” “they changed their mind,” “dropped off,” “didn’t respond,” and another dozen variations for the same case.
Remove from work, not from history
Physically deleting a deal here would break two things at once: sales history and loss analytics. So we implemented soft delete.
The deal no longer appears in the working list of active sales, but the record remains. Along with it, the lifecycle data is preserved: creation, invoice issued, waiting, confirmation, or expiration. On top of that, we store the reason the deal was closed.
For the manager, this feels less like “archiving for the sake of archiving” and more like normal funnel hygiene. Deals that no longer have a next action do not keep cluttering the active list. At the same time, the sales lead can later look not only at final payments, but also at where deals were lost.
For example, if “delivery date doesn’t work” is selected often, that points to one kind of issue. If rejections due to military mortgages start piling up, that points to another. If many deals simply expire, then the waiting process and reminders need to be reviewed.
Why the reason is required
The main decision was not the delete button itself. Adding a button is easier than agreeing on data that won’t need to be cleaned up by hand later.
We made the reason mandatory for soft delete. Without a selected option, the deal cannot be closed. Yes, this adds one extra step for the manager. But it keeps the analytics from turning into a pile of empty values.
A real project detail: the biggest questions were not about the list of 13 reasons, but about the boundary between “expired” and a client rejection. On screen, it is one minute of work for the user, but in reports these are different loss reasons: one process-related, one commercial. That is why the options were kept predefined, without a “write it however you want” field.
The trade-off is simple: the reference list covers the main reasons needed for funnel slicing. If the business process changes, the list can be expanded intentionally, rather than extracting meaning from arbitrary comments.
How this relates to the deal lifecycle
In PDP, a deal follows a clear route: creation → invoice issued → waiting → confirmation → expiration. Soft delete had to fit into this cycle without hiding the state.
There is a difference between a deal that expired on its own and a deal that a manager closed with the reason “bought from a competitor.” In the interface, both may disappear from the active list. In the data, these are different events.
That is why soft delete does not replace lifecycle statuses. It adds a closed flag and a loss reason. This makes it possible to separate the technical state of the deal from the business reason why it stopped moving forward.
In practice, this gives us a base for questions that were previously usually answered by gut feeling:
- at which stage deals are lost most often;
- which loss reasons repeat;
- which reasons are tied to product terms and which to the sales process;
- where the flow needs work: invoice, waiting, confirmation, or expiration handling.
A deleted deal no longer disappears from the system. It stops creating noise in day-to-day operations and remains usable for funnel analysis.