Centralizing Vendor Memory for Procurement
James McGillicuddy, CEO of BRM, on the problem with “little P” procurement
BRM is trying to win procurement by becoming the system that remembers every vendor conversation, not just the final contract or approval. That matters because software buying usually gets scattered across email, Slack, security reviews, renewal calendars, and finance tools. BRM’s pitch is to pull those fragments into one vendor record, so the next buyer, approver, or seller starts with history already attached instead of restarting the process from scratch.
-
This is the practical difference between vendor centric and document centric software. A CLM like Ironclad is built around contracts and approvals. BRM is built around the vendor itself, then attaches contracts, spend data, inbox threads, usage context, and renewal tasks to that vendor record.
-
It also explains why BRM can sit beside tools like Zip. Zip is an orchestration layer for getting a purchase request approved and routed. BRM is aiming to hold the living memory of the vendor relationship before, during, and after the purchase, including compliance questionnaires and renewal prep.
-
Creating a persistent seller org turns each request into a reusable profile instead of a one off questionnaire. If a seller has already answered security, compliance, or firmographic questions once, that data can be reused and refreshed, which lowers manual work for both buyer and seller over time.
The next step is software buying that looks less like email ping pong and more like a shared workspace with prefilled data, reusable vendor profiles, and agents handling the first pass of diligence. If BRM executes, procurement software shifts from tracking approvals to continuously structuring the market memory around every vendor relationship.