Run your CRM from a Google Sheet - until you can't

Every CRM vendor has a blog post explaining why a spreadsheet is not a CRM. The argument is always the same: sheets do not scale, sheets get messy, real businesses need real software. What the post never says is when any of that becomes true for you, because the honest answer - often not for years - does not sell subscriptions.

We sell form infrastructure, not a CRM, so we can afford to be honest here. A Google Sheet is a perfectly good CRM for a surprisingly long stretch of a company's life. It is also genuinely the wrong tool past a certain point. The interesting question is not whether to use a sheet. It is how to recognize the actual breaking points, and how to structure things so that graduating later costs you an afternoon instead of a quarter.

Strip the acronym down and a CRM at small scale is three things: a list of people, a status for each one, and a next action. That is it. Pipeline stages are a status column. Deal value is a number column. Follow-up dates are a date column plus conditional formatting that turns overdue rows red.

A sheet does all of this natively, and it does something most CRMs make hard: it shows you everything at once. Twenty leads fit on one screen. You can sort by any column, filter by any condition, and answer an ad hoc question in seconds without learning a report builder. When your entire pipeline fits in a few hundred rows, the sheet is not a compromise. It is arguably the better interface.

Three properties keep the sheet viable well past the point vendors predict collapse.

1. Total visibility. There is no schema hidden behind an API. The data model is the thing on your screen, so errors are obvious and fixable by anyone.
2. Zero onboarding. Everyone you will ever hire already knows how to use a spreadsheet. The training cost of a sheet-based process rounds to zero.
3. Formulas are automation. A COUNTIF is a dashboard. A conditional format is an alert. You get 80 percent of the reporting a CRM sells, from primitives you already understand.

We wrote more about the storage half of this in our guide to using Google Sheets as a form database. The short version: for structured, append-heavy, human-reviewed data, the sheet is a legitimate system of record.

One clarification before the breaking points, because it changes the whole graduation story. A sheet CRM has two layers that people conflate: the capture layer (how a lead gets into a row) and the working layer (what you do with the row afterward).

Manual capture - retyping emails into rows - is the version of the sheet CRM that deserves its bad reputation. The workable version wires your forms straight in: a contact form on your site posts to an endpoint, and the row lands with a timestamp and its attribution intact. That is exactly what we built - see how it works and the contact form use case. Keep this distinction in mind: the breaking points below are all failures of the working layer. The capture layer does not break at scale, which is why it should outlive the sheet.

Google Sheets technically supports up to 100 simultaneous editors. In practice, a shared working sheet starts hurting at three or four. Two people sort the sheet at the same time and one of them is now editing the wrong row. Someone filters, someone else pastes, and a status lands on the wrong lead. Version history can reconstruct what happened, but archaeology is not a workflow.

The failure mode is subtle because nothing crashes. The sheet just becomes slightly untrustworthy, and people respond by keeping private side lists, which is worse. If your team has started saying "do not touch the sheet while I am in it," you have hit this wall.

Sheet sharing is all or nothing per file. Anyone who can edit a row can edit every row, delete columns, or break the formulas that everything depends on. There is no "this person sees only their own leads," no "sales sees the pipeline but not the revenue column," no field-level rules at all. Protected ranges help at the margins, but they are a fence, not a permission model.

This matters the day you add a contractor, a client, or a second team. The moment you find yourself maintaining a second, sanitized copy of the sheet for a different audience, the permission model has failed and you are paying the cost in sync errors. (Capture is different: a form endpoint writes rows without granting any human access to the file, which is part of why we recommend it - see our security page for how the write path is scoped.)

The third wall is the least discussed and the most decisive. A sheet represents state beautifully and represents process badly. When a lead must move through five stages, trigger an email at stage two, get reassigned if idle for three days, and log every touch along the way, you are asking a grid of cells to be a workflow engine.

You can fake it with formulas and scripts for a while, and clever people always do. But every faked feature is unowned infrastructure: the reminder script one person wrote and nobody else can debug. When the number of hacks exceeds the number of people who understand them, the sheet has become software - just software with no tests, no permissions, and no vendor.

Notice what is absent from that list. Nothing about getting leads into the system breaks at scale. A form endpoint that appends a row works identically at ten submissions a month and ten thousand. Spam filtering, retries, and delivery logging are the same problem at every size - our spam protection guide covers that layer in depth.

This is the argument for keeping capture separate from the CRM from day one. Your forms post to a stable endpoint; the endpoint delivers to wherever your working system currently lives. The endpoint URL in your site's markup never changes. Today it fills a sheet. Later it can fill a sheet that your CRM imports from, while the sheet quietly becomes an archive.

When two of the three breaking points are costing you real hours weekly, graduate. Do it in this order:

1. Move the process, not the history. Import active leads only. Your two years of closed rows stay in the sheet, which remains searchable forever. Do not spend a week massaging dead data into a new schema.
2. Keep the sheet as the append-only capture log. Forms keep posting rows. The sheet becomes the raw intake ledger; the CRM becomes the working surface. Most CRMs can import or sync from a sheet on a schedule.
3. Dual-run for two weeks. The sheet is your fallback while the team learns the new tool. The day nobody has opened the working tab in a week, the migration is done - and it never had a cutover moment.

Rules of thumb, offered with the usual caveats. One or two people touching leads, under a few hundred active rows, a linear follow-up process: the sheet is fine, and probably optimal. Three to five people, or your first permission-boundary moment, or the first automation hack that only one person understands: start evaluating, without urgency. Beyond that, or the first time a lost update costs you a deal: graduate now.

Whatever stage you are at, wire the capture layer properly first - it is the one investment that survives every future migration. You can watch a live form feed a public sheet on our demo page, and the free tier is open - start free, no card needed.

Is a Google Sheet actually a viable CRM?

How many leads can a Google Sheet handle?

What breaks first: size or people?

How do form submissions get into the sheet automatically?

Can I restrict what teammates see in a sheet CRM?

Should I stop using the sheet once I buy a CRM?

Which CRM should I graduate to?

Does spam become a problem for a sheet-based CRM?