A note from Lauren McCullough, CEO of Tromml : Brian has been a key engineer behind the architecture of Minecart. The matching system, the NER layer, the agent architecture underneath it all. I asked him to write up his thoughts because I think the work deserves to be explained by the person who actually did it. So this is his post. I will have a few words at the end.
There is a note sitting in a sales rep's head right now about an account you are about to lose. It will never make it into your CRM.
Not because the rep does not care. Not because they forgot. Because by the time they got back to their truck and pulled up their phone, the next stop was already pulling them forward. The note died in the parking lot.
If you manage a sales team, you know this pattern. If you are a sales rep, you have lived it. And if you have been around long enough to watch two or three CRM tools come and go, you already know how it ends: everyone buys in at the kickoff, the notes get shorter, the logins drop off, and eventually the system becomes the thing your manager asks about on Fridays.
That is not a discipline problem. It is a design problem. And understanding it is the first step to understanding what a next-generation CRM actually has to be.
The first generation of CRM software was, at its core, a database. Its job was to store structured records: contacts, accounts, dates, deal stages, call logs. It did that well. The tradeoff was that everything the system could work with had to fit into predefined fields. A dropdown. A date picker. A text box with a character limit.
That architecture has a name in data engineering: the relational database. It is fast, reliable, and excellent at organizing information that arrives in a predictable shape. The problem is that sales intelligence almost never arrives in a predictable shape.
The most valuable thing a rep learns in a meeting does not fit a dropdown. It sounds like this: Mike mentioned they have been sampling from a competitor on the brake pad line and they are worried about inventory heading into Q3. That sentence contains a competitive threat, a seasonal flag, a product category signal, and a relationship data point.
A traditional CRM can store it as a text note. It cannot do anything with it.
This is the schema wall. It is the point where rich, unstructured field intelligence gets forced into a format the system can hold. In that conversion, most of the signal disappears. The rep knows they are supposed to log something. They look at the form. They close the app. The note dies.
This is why CRM adoption has always been a behavior problem as much as a technology problem. The system asked reps to translate human observations into database language. Most reps, reasonably, decided it was not worth the time.
A next-generation CRM does not ask reps to translate. It reads the language they already speak.
This shift is made possible by technologies that have matured significantly in the last few years. The most important is natural language processing, and specifically a technique called named entity recognition, or NER.
NER is what allows a system to read a voice note or a typed sentence and extract the meaningful pieces automatically: which company was mentioned, which product came up, whether a competitor was referenced, what follow-up was implied, and when it needs to happen. The system does not need a form to be filled out. It reads the note and structures the data itself.
The result is a different relationship between the rep and the tool. Instead of the rep serving the CRM, the CRM serves the rep.
For sales leaders, this changes what the data looks like at the account level. Instead of sparse structured records with occasional notes attached, you get rich intelligence the system can surface, summarize, and act on: account health signals, competitive flags, follow-up gaps, rep activity patterns. All of it built from the natural language your team was already generating and never capturing.
For reps, it means the system finally gets out of your way.
When we started building Minecart, the first thing we did was get honest about where the friction actually lived.
Typing is slow. I have clocked the difference: dictation runs at 130 to 150 words per minute for the average person, while iPhone typing lands around 25 to 30. That is a four-to-five-times speedup. But the more important thing is not the speed. It is what that difference makes possible.
A rep leaving a shop has about ninety seconds before they are mentally at the next stop. Typing in that window means distilling: shorter sentences, less context, the texture gets lost. Dictating changes things. You can do it walking to your truck. You can do it driving out of the parking lot. The time was already there. It was just unavailable.
The note you get back is completely different. Not three fields and a status update. A real account of what happened: what was said, what the vibe was, what to remember before going back in thirty days. And that note has a downstream effect most reps do not fully appreciate until they have been using it for a few months.
Once the note exists, NER is the layer that makes it actionable. I think about this as the difference between pulling signal from noise versus doing a full cleanup round. The system reads the note and extracts the meaningful pieces automatically: account name, contacts mentioned, products that came up, competitors referenced, sentiment signals, time-sensitive flags, implied next steps. All of it structured without the rep filling out a single field.
The framing I keep coming back to: the goal is confirmation, not population. Population is the part that kills CRM adoption. Nobody wants to do it. That is why reps stop logging, why data goes stale, why you end up paying a subscription for a tool your team has quietly quit on. If the system has already done the extraction and the rep is just saying yes, that is right, the behavior change becomes something people can actually sustain.
Here is the engineering challenge that does not come up in most CRM sales conversations, because it is hard and most tools have decided not to solve it: account matching.
When a rep dictates a note, the system needs to figure out which account it belongs to. Sounds obvious. But transcription accuracy is not perfect. GPS has margin of error. Names get mispronounced or compressed in speech. In a dense industrial corridor where four distributors sit within half a mile of each other, automatic matching is not a solved problem.
At Tromml we built a multi-signal approach: GPS proximity, phonetic name matching, contact checks cross-referenced against existing records. When the system is not confident, it flags the note for quick review by the rep, a manager, or an admin. Even that fallback is faster than the old way. The note is already rich from dictation. The review is thirty seconds of confirmation, not starting from scratch.
The first-generation approach to matching was a scoring pipeline: assign point values to each signal, add them up, pick the top result. GPS within a tenth of a mile gets one point. Phonetic name match gets half a point. Clean, explainable, works fine in simple cases.
The problem is context. GPS is high-value signal for a rep in the field. GPS is useless for a rep making calls from their home office. A static model does not know which context it is in, and if you try to build rules to cover every case, you end up maintaining a list that grows and still never covers every edge.
The shift we made at Minecart was to an agent-based approach. Not possible a few years ago. Possible now.
Instead of fixed scoring weights, each signal type becomes a tool the agent can choose to use: GPS, phonetic matching, contact records, account history. The agent reads the note, infers the context, and determines which signals to weight. Field visit with GPS twenty minutes from the office: GPS gets weighted high. Phone call: GPS gets deprioritized automatically. No rules update needed.
Here is the illustration I keep coming back to. Say a note mentions someone named Ramiro, and GPS is ambiguous between two nearby accounts. A static scoring model assigns that name a value near zero. There is no deterministic path. An AI agent reasons the way a human would: check whether Ramiro appears in reviews or public records associated with either business. If there is a match, that is high-signal confirmation. It is the kind of lookup a sharp human does naturally, and a static pipeline cannot touch it. This kind of knowledge is implicit rather than explicit. LLMs can approximate it in a way that no scoring model ever will.
Voice capture, NER extraction, agent-based matching. All of it is infrastructure. The payoff is the briefing.
A rep has not visited an account in thirty days. They are pulling into the parking lot. Before they walk in, they get a summary: what was discussed last time, what the customer flagged, what follow-ups were committed to, what has changed since. Not a dashboard to dig through. A briefing. The kind a good assistant would put together before a big meeting. You go into the conversation with that knowledge rather than scrambling in the moment.
For the rep: the note you took in ninety seconds on the way out thirty days ago becomes the thing that makes you look prepared today.
For the sales leader: account knowledge stops living in individual reps' heads. When someone turns over or goes on vacation, the account history no longer walks out the door with them.
That is not a productivity feature. That is a structural change in how intelligence moves through a sales organization.
What Minecart does today would not have been possible two years ago. The advances in AI agents, tool calling, and NER accuracy are recent. The agent-based matching described above required LLM capabilities that were not accessible at production-ready cost until recently.
That is worth saying because there is real baggage here. Most sales reps have already watched one or two revolutionary CRM tools come and go. That skepticism is earned.
What we built is the automation of the parts that made old systems fail. Not a better interface. Not more integrations. The actual removal of the tedious, friction-heavy steps that killed adoption every other time. The knowledge that drives this system is implicit rather than explicit, and that is exactly what makes it different.
A final note from Lauren
What Brian described above is the reason I can walk into any room in this industry and say Minecart is different without flinching. This is the work underneath that claim. I am proud of it, and I am proud of him. If you want to see the voice capture and matching in action, we will show you exactly how it works.
Lauren McCullough, CEO, Tromml
Read FREE Tromml's eBook on how AI is changing work in aftermarket parts distribution.
%401x.svg){kind=icon}
