JSONCRM vs a spreadsheet
The short version: the spreadsheet is the real incumbent — rows are records, tabs are stages, and an Excel CRM or Google Sheets CRM works surprisingly far. It breaks in four places: no schema, no enforcement, no history, and no safe way for an AI agent to touch it. JSONCRM is the smallest possible spreadsheet-CRM upgrade that fixes all four while keeping the "it's just files" simplicity.
Let's be fair first: if you're tracking twenty leads and you already know pivot tables, a spreadsheet is a fine CRM. Most CRM software is over-engineered for that job. The question is what stops working as the pipeline grows — and especially the moment an AI agent enters the picture.
1. Schema: vibes vs validation
A sheet will happily accept "⭐⭐⭐⭐", "4 stars", "4★", and "four" in the same column. Every consumer
of that data — including the agent you'll ask to "promote everyone above three stars" — now has to
guess. JSONCRM defines score values, identity fields, and stage files in .crm.json, and
jsoncrm validate checks structural integrity on demand.
2. Process: drag-and-hope vs enforced transitions
In a sheet, "stages" are tabs and the process is whatever people remember. Records get lost between
tabs, duplicated across them, or promoted backwards by accident. JSONCRM's transitions are explicit:
leads → prospects → customers is config, promote/demote move
records along legal paths, and an invalid move isn't a formula error — it just doesn't exist.
3. History: "final_v7_REAL.xlsx" vs git
Who changed this deal's score, when, and why? In a sheet: email attachments and hope. (Google Sheets
has version history — for one file, one owner, in one cloud.) In JSONCRM every change is a diff and
every state is a commit: git log -p prospects.json is your audit log,
git revert is your undo, and "Open PR" makes review a workflow instead of a trust
exercise.
4. Agents: CSV roulette vs native tooling
This is the 2026 problem. Asking an LLM to edit a spreadsheet means asking it to rewrite a whole
serialization format around one cell — and CSV/Excel are exactly the formats models mangle
(quoting, encoding, formulas-as-data). JSON is what models read and write natively. On top of that,
JSONCRM gives agents a CLI and a first-party MCP server, with --dry-run so every
proposed write is inspectable before it lands. The agent works on your CRM the way it works on a
codebase: read state, propose a diff, apply on approval.
Side by side
| JSONCRM | Spreadsheet | |
|---|---|---|
| Format | JSON — structured, machine-native | Cells — flexible, human-casual |
| Schema | Config-defined stages, scores, identity + validate |
Whatever was typed that day |
| Process enforcement | Legal transitions only (promote/demote) |
Tabs and discipline |
| History | git log / revert / PR review | Attachments and version history (per-file, per-cloud) |
| AI agent editing | Native: files + CLI + MCP with dry-run | CSV/Excel rewriting — corruption roulette |
| Merge two people's changes | git merge (line-level JSON diffs) | Copy-paste reconciliation call |
| Duplicates & blocklist | deduplicate, filter-competitors |
Conditional formatting you wrote once and forgot |
| Ad-hoc analysis | Export to JSON/CSV (dump_emails) — or just open the files |
Pivot tables, charts — unbeatable |
| Price | Free, AGPL-3.0 | Roughly free |
📊 Keep the spreadsheet if…
- Your pipeline is small and stable (a couple dozen live records)
- Ad-hoc pivots and charts are how you actually think
- Everyone who touches it already shares the one sheet happily
- No agent will ever be asked to edit it
⚡ Move to JSONCRM if…
- Records number in the hundreds+, or intake is automated
- "Which tab is Alice in?" has no reliable answer anymore
- You want an audit trail and review instead of trust
- You want to tell an agent "score and promote the ready ones" and get a diff back
- You want it to still just be files you can open
Switching is boring, on purpose
Your sheet is already a table of flat records — which is exactly JSONCRM's data model. Paste a
column-mapped export into leads.json, write a fifteen-line .crm.json, run
jsoncrm validate, and you've upgraded the substrate without changing what the data
means. And the door stays open: dump_emails and plain JSON exports mean the
spreadsheet can stay your analysis layer while the files become the system of record.
Spreadsheet CRM — common questions
Is a spreadsheet good enough as a CRM?
For a small, stable pipeline — a couple dozen live leads, one owner, no automation — yes, and a spreadsheet CRM is often the right amount of tool. It stops being enough when intake scales, records multiply across tabs, or you want an AI agent to edit the data: no schema, no enforced process, no audit trail, and CSV/Excel is exactly the format LLMs mangle.
How do I move my CRM out of Excel or Google Sheets?
Your sheet is already a table of flat records, which is JSONCRM's data model. Export it, map columns to fields, save the rows as a JSON array in leads.json, write a small .crm.json defining stages and scores, then run jsoncrm validate to catch anything malformed. From then on, git tracks every change.
Why is JSON better than CSV for AI agents?
JSON is the format LLMs read and write natively, and it carries structure: fields are named, types are unambiguous, and a validator can check them. CSV leans on quoting conventions and column position — one stray comma or encoding surprise and an agent silently corrupts the file. JSONCRM adds a CLI and MCP server with dry-run previews on top, so agent edits are proposed as diffs you approve.
Keep the simplicity. Lose the chaos.
It's still just files — now with schema, history, and agents that can't wreck it.