When we started building NaS_OS, buyer tracking was not on the roadmap. The plan was documents: take a data room, produce a teaser and an information memorandum, do it fast and do it accurately. Tracking buyers felt like someone else’s problem, and there are a hundred CRMs already.
I changed my mind after watching how boutiques actually run a process, and the reason is worth writing down because I think most of this category has the same blind spot.
A CRM models a pipeline. Opportunities move through stages, each one a separate thing you are trying to close. That shape is correct for selling software, and it is wrong for selling a company. A sell-side process is not a pipeline of independent deals. It is one asset, one story, and a list of buyers all moving through the same fixed sequence at different speeds. Teaser. NDA. CIM. Management call. IOI.
You can force that into a generic CRM. Plenty of firms do. Every buyer becomes a record, every stage becomes a custom field, and it works, roughly. But something breaks that nobody notices for weeks.
The documents and the process drift apart.
Here is how it happens. The IM goes out in week two. In week four an assumption changes, the model gets updated, and the memo gets a revision. Some buyers have the old version, some have the new one, and the only record of who got what lives in an inbox. Then a buyer asks a question on a management call about a figure that moved, and the associate answering does not know which version that buyer is holding. The deal does not die from this. It just gets slower, and a little less credible each time it happens.
The root cause is that the document system and the process system have no shared idea of what is true. Two tools, two sets of numbers, and a human in the middle reconciling them from memory.
So we built Racetrack inside NaS_OS rather than integrating with something external. Every buyer sits on the real sell-side sequence, not a generic pipeline, and it runs on the same verified fact base that produced the teaser, the IM and the model. When a number changes upstream, every output moves with it, and the process knows which version went to whom.
The honest counterargument is that this is not our job. A specialist CRM will always have more features than something we build alongside a document engine, and integration is what APIs are for. I take that seriously, and for a large bank it is probably right.
But at a ten-person boutique running three mandates, every integration is a seam, and every seam is a place where a number drifts and nobody is accountable for catching it. The firms I have watched are not short of tools. They are short of a single place where the story and the evidence and the buyer list agree with each other. Adding a sixth login does not solve that. Removing the seam does.
The broader point, and the thing I would argue with anyone building in this space: the unit of work in M&A is not the document. It is the mandate. A tool that produces beautiful documents and then hands you off to three other systems to actually run the deal has automated the part that was never really the problem.
The IM is not the deliverable. Closing is.
NaS_OS runs the mandate end to end: the teaser, the IM and the model come from one verified fact base, and Racetrack tracks every buyer through the sell-side sequence on that same base. If you want to see it on your own process, apply for access.