Who builds this, and why it is built this way

Founder, MarkR Management Inc.

Termsroom was designed after asking senior negotiators what they actually needed, and being told something the market had not built. They did not need software to negotiate. They are good at that, and it is their profession. What they wanted was software to facilitate the negotiation: to make the process auditable, easier to follow, and the same for both parties.

The pattern that kept appearing is a simple one. The negotiation is well managed by the people in the room and badly recorded by the systems around them. Positions are worked out carefully, then documented in an inbox. The consequence turns up later, when somebody has to prove what was exchanged, or when the person who held the file has moved on, and the organisation discovers its own history was never really its own.

Every product available at the time served either the institution or the union. A tool owned by one side records that side of a shared event, and the other side is asked to take its word for it. Termsroom was built for the table instead, which is a harder product to build and the only one that answers the objection both parties actually raise.

The design rests on two pieces of work rather than on an opinion. A review of how rounds are actually conducted and recorded, drawn from what the parties themselves publish. And a scan of the current landscape from a governance and auditability standpoint, gathered from vendor documentation, deployment guides, published pricing and regulator publications, which is kept as a dated record with its sources and its gaps marked where nothing could be found.

Termsroom is the answer to that, built deliberately narrow. It does not try to be a contract management platform, a document store or an approval workflow, because each of those already exists and none of them addresses two parties with opposed interests and separate obligations.

Professional background and history are on LinkedIn.

Each party keeps its own documents. The simplest version of this product would store everything and be much easier to build. It would also be unsellable to a public body with a retention schedule, and it would ask two opposed parties to trust the same vendor with their private positions. So Termsroom holds the record and the parties hold the documents, and every design decision downstream follows from that.

Rules live in the database, not in the screen. A rule enforced by hiding a button is a rule until somebody finds another way in. The isolation between the two sides is enforced by row level security, and there is a query a customer can run that returns every violation of it. Nothing about that is for our convenience.

Say what is not finished. Every page that describes a control also says where the control stops. That is not modesty. A buyer who finds a gap you did not mention stops believing the parts you did.

Termsroom is software delivered over the web. There is nothing to install and nothing to keep updated, which also means the two sides of a negotiation are never on different versions of the same product.

It runs in a browser on a phone, a tablet and a computer. Not a reduced version on the small screen: the same rooms, the same record, the same controls, laid out for the device in front of you. A negotiator checking overnight what the other side tabled is usually holding a phone.

The application runs on Vercel and the record is held in a managed Postgres database with row level security as the authorisation boundary. Sub-processors are listed on the sub-processor page rather than left to be discovered in a questionnaire.

MarkR Management Inc., British Columbia. For a demonstration, a security questionnaire or a procurement conversation, write to sales@termsroom.com.