“One system that runs the whole deal” is the most seductive pitch in deal-team software right now, and for good reason. We have made the case ourselves in What Deal Teams Can Learn from Software Teams. Software teams got tooling where status is a byproduct of work; deal teams still assemble status by hand. Close the gap and you eliminate an entire category of unpaid labor. The promise is right. What most people underestimate is what it actually takes to build.
The hard part is not the board, the stages, or the keyboard shortcuts. The hard part is that in software, truth is cheap: the compiler and the test suite arbitrate it for free. In deals, truth is contested. “Buyer 12 is at IOI stage” is not a fact the system can verify by running the tests; it is a claim someone made, based on a call someone half-remembers, possibly contradicted by an email someone else has. A process tool that renders contested claims in confident columns is not one system that runs the deal. It is the CRM problem with better typography. An AI native process tool has to be built on receipts, not vibes, and that decomposes into five concrete requirements.
1. Every stage claim carries its evidence
In a working process record, no stage is a bare assertion. “NDA executed” points at the executed document. “Management meeting held” points at the calendar event and the transcript. “Sponsor passed on valuation” points at the sentence in the email where they said so, with a date. When two people disagree about where a buyer stands (and on a fifty-buyer process they will), the dispute resolves by clicking through to the source instead of by whoever speaks last in the Monday meeting. Evidence is not a nice-to-have on top of the process view. It is the thing that makes the view worth reading, because a senior banker will trust a board exactly once; the first unsupported claim they catch, they go back to asking humans.
2. Agents propose, humans approve
AI is what makes the byproduct property possible. Agents reading the email flow, the transcripts, and the documents can detect stage changes no human would pause to log. But detection is not the same as truth, and an agent that writes its own inferences into the record will eventually write a wrong one into a document that goes to a client. So the write path has one shape: agents propose, humans approve, and only approval writes. The process record is an append-only ledger: every entry carries what changed, the evidence for it, who approved it, and when. Nothing is silently overwritten; corrections are new entries. That discipline is what lets a firm put an AI in the loop on its most sensitive workflow and still answer, months later, exactly why the record says what it says.
3. The CRM and the tracker become projections
A process tool that ignores the CRM and the personal Excel tracker just adds a third place for state to diverge, the exact disease it claims to cure. The correct architecture makes both of them projections of the process record: the same approved fact flows to DealCloud or Salesforce and to the banker's own tracker format, written with approval and verified with read-back receipts. After each write, the system reads the record back and confirms the value actually landed. The CRM stays authoritative for compliance, the tracker stays shaped the way its owner thinks, and neither is maintained by hand, because both are downstream of one ledger.
4. Exceptions sorted by consequence
Human review only scales if the system is honest about which decisions deserve a human. Treat every proposed update as equally important and you have rebuilt data entry with an approve button. The sorting principle is consequence:
- Money and terminal outcomes always get a human. A valuation signal, a bid level, a pass, a dead buyer: anything that moves economics or ends a path gets individual attention, every time, no matter how confident the extraction.
- Routine progression is batchable. Teaser sent, NDA countersigned, data room access granted: high-volume, low-ambiguity, evidence-attached. A banker reviews these as a batch in minutes, keyboard-first, each still individually approved.
- Ambiguity escalates itself. When the evidence is thin or sources conflict, the proposal says so and routes up rather than guessing. An honest “unclear, here are both sources” preserves trust; a confident guess destroys it.
5. Status renders itself
The payoff of the first four requirements is the fifth. If every stage claim is evidenced, approved, and ledgered, then the Monday morning pack is not a document anyone writes. It is a deterministic render of the record: buyers by stage, movement since last week, days quiet, open items by owner, each line traceable to its receipt. Not an intern reconciling three trackers at 11pm on Sunday, and not a generative model freestyling a summary that might embellish: the same record, rendered the same way, every week. If a number in the pack is wrong, the record is wrong, and fixing the record fixes every downstream view at once. That property (one source, many renders) is the actual lesson of software tooling, more than any particular board or view.
Build order: the ledger before the board
Status, honestly labeled. The full process product (stages and owners as first-class objects, the consequence-sorted queue, the self-rendering Monday pack) is in development, not shipped; its design is on the process page. The layer underneath it is live today and in daily use: evidence attached to every proposed update, approval gating every write, read-back receipts on every CRM write, buyer trackers and weekly updates rendered from the approved record. The full architecture is on the platform page.
That sequencing is the whole thesis. A beautiful process board on top of contested claims is a faster way to read fiction, and several generations of deal software have proven it. Receipts first, then process: get the ledger true, and the board on top of it is straightforward. Skip the ledger, and the board is just the CRM problem wearing better clothes. If you want to see the evidence-and-approval layer running on a live mandate, book a demo.
