S01E12: Why I Stopped Using CRM

Finance doesn’t run on “mostly right.” It runs on math.

In The Architecture Behind AI-Native Revenue Automation, Tabs’s CTO breaks down why LLMs alone aren’t enough—and what it actually takes to build audit-ready, AI-driven contract-to-cash systems for modern B2B teams.

Get the whitepaper

Ten seconds later I have the weighted pipeline value, deal count by stage, MEDDPICC score distribution, deals with close dates in the next 30 days, and a flag on anything that has gone quiet.

No CRM opened. No spreadsheet. No manual calculation.

Ten seconds.

I built this after spending two years entering data into CRMs that gave me nothing useful in return. CRM is a data collection system. It is very good at collecting data. It is not designed to coach you, score your deals, or tell you what to do next.

Jarvis is.

This is the final issue in the Build Your Own Jarvis series. I am going to cover the sales layer specifically: what tools make the most difference, how the data layer works, and where all of this is heading by end of year.

CRM solves one problem: making sales data visible to managers.

It is designed for reporting. Pipeline reviews. Forecasting calls. Board decks. The features that got built first, that got the most investment, that work the most reliably, are the features that help managers see what their reps are doing.

What it does not do is help the rep do the work.

It does not score your deals. It does not tell you which one is at risk. It does not generate your follow-up. It does not surface the question you should ask on your next call. It does not notice that a deal has been in the same stage for 22 days and flag it before your manager does.

You enter data. It stores the data. You close the tab.

The coaching, the prioritization, the actual sales thinking: that happens in your head. CRM is there to log the conclusions after the fact.

Jarvis flips this. It coaches you during the work, not just after.

Not every sales tool in Jarvis is equally impactful. These four are where most of the leverage is.

Pipeline view.
/pipeline returns a full snapshot in 10 seconds. Weighted value by stage. MEDDPICC score distribution across all deals. Close-date alerts. Deal velocity (average days per stage and where things slow down). This is the morning review. It is also the pre-meeting brief. It replaces the 15 minutes of clicking through CRM to get a mental model of the pipeline.

MEDDPICC scoring.
/score [deal name] scores a deal across all eight MEDDPICC dimensions, identifies the weakest areas, and returns specific coaching questions for the gaps. This used to be something I did in my head, inconsistently, with no record of the analysis. Now it is a tool I run after every meaningful interaction. The score goes up when I take the right actions. The score stays low when I am in denial about a deal.

Follow-up sequence generation.
/followup [deal name] generates a 3-touch sequence (Day 1, Day 5, Day 14) using the full deal context: what was discussed, what the pain is, what stage the deal is in, who the champion is. The output is not a generic template. It is a sequence written for that specific deal. I edit it. I do not write it from scratch.

Gap coaching.
/meddpicc [deal name] does a full MEDDPICC gap analysis and returns the specific questions I should ask my champion to close each gap. Buying process unclear? Here is the question. No named economic buyer? Here is the question. Implementation risk not addressed? Here is the question. This is what a great sales manager does in a deal review. I can run it any time.

Where does all of this data live?

Right now: JSON files on the server.

Deals live in deals.json. Every deal has a record: name, stage, MEDDPICC scores by dimension, notes, activity log, close date, value, contact details.

Every time I add a note (/note), score a deal (/score), log a win or loss (/won, /lost), or advance a stage, the file updates. The next tool call reads the updated file.

This is simple and it works. The limitation is that JSON files do not scale past a few hundred records and do not support complex queries efficiently. For a founder or individual rep managing 20 to 50 deals, they are fine.

The next step is a lightweight database (SQLite or Postgres) that keeps the same simple interface but handles larger volumes and enables more complex queries: deal velocity calculations, historical trend analysis, predictive scoring.

That migration is on the roadmap for this year. The interface stays the same. The storage layer gets more robust.

I said in Part 1 that by end of year Jarvis operates without commands.

Here is what that means in the sales context specifically.

Today: I ask Jarvis about my deals. It tells me.

By end of year: Jarvis monitors my deals continuously and tells me when something needs attention without being asked.

Deal went quiet for 6 days. Jarvis flags it with a suggested re-engagement message already drafted.

Close date is 12 days away and the MEDDPICC score is below 15. Jarvis sends an alert with the three gaps I need to close and the specific questions to ask.

Win rate is down 8% over the last 30 days. Jarvis identifies which dimension in the deal score correlates with the losses and suggests what to fix.

That is the chief of staff mode I referenced in Part 1. It is not fully built yet. The infrastructure exists. The tool pattern, the knowledge base, the automation layer: those are all in place. The remaining work is building the monitoring logic and the alert conditions.

The harder part is not the code. It is deciding what matters enough to be worth alerting on. Every alert that fires when it should not matters trains you to ignore the system. Getting the signal-to-noise ratio right is the real work.

I want to close with this because it is the actual point of the series.

The rep who builds this system does not spend their morning checking 8 things manually.

They do not write follow-up emails from scratch.

They do not guess which deal is at risk.

They do not go into a pipeline review without knowing the numbers.

They do not copy-paste prospect research into a template.

All of that runs automatically or with one command. Their time goes to conversations and decisions. The work that actually moves deals.

This is not hypothetical. It is where I operate today, imperfect version of it.

The sales AI OS does not replace the rep. It removes the overhead that should never have been the rep's job in the first place.

The rep who builds this sells more. Not because the AI closes deals. Because the rep has more time and better information when they are in conversations that matter.

That is the series. Five parts. The OS, the tool pattern, the brain, the automation layer, and the sales layer.

The skeleton and blueprint are in Part 1 for paid subscribers. The implementation patterns are in Parts 2 through 4.

Build one thing. Use it for two weeks. Add the next one.

Talk next week.

A new report shows 44% of family offices are investing more in residential real estate. Now, you can access these assets with mogul. This platform lets you invest in properties producing +7% yields and 18% IRRs. Plus, they do all the property management for you.

Join 20,000 investors today.

Past performance isn't predictive; illustrative only. Investing risks principal; no securities offer. See important Disclaimers