Fundraising CRM template: fields that matter and fields you can delete

The 40-column tracker nobody updates

A founder shows you their investor tracker and it is a thing of beauty. Firm name, partner name, fund size, AUM, stage focus, check size, sweet spot, geography, portfolio overlap, mutual connections, Twitter handle, podcast appearances, last fund vintage, dry powder estimate, thesis keywords, warm or cold, intro source, intro strength, first email date, first reply date, first call date, sentiment, second call date, partner meeting date, deck version sent, data room access, objections, internal champion, decision timeline, expected check, valuation comfort, term preferences, follow-on appetite, board seat appetite, notes, next step, owner, priority, and a color-coded status.

It is forty columns wide. It was built on a Sunday before outreach started. By the second week of the raise, three columns are current: last email, the call happened or it did not, and a panicked freeform note. The other thirty-seven are frozen at their Sunday values, which means the tracker is now lying to the founder about most of what it claims to know.

This is the central failure of fundraising trackers. They are designed for the calm before the round and used during the chaos of it. A column that takes ten seconds to fill when you have time and zero active conversations becomes dead weight when you have nine threads open and forty minutes between calls. The founder does not abandon the tracker because they are lazy. They abandon it because it asks for more than a raise leaves time to give.

The test every column has to pass

There is one question that sorts a useful field from a vanity field. If this cell were blank, would it change what I do next?

Run "fund AUM" through it. You have a number in that column: $400M. Now blank it. Does the blank change your next action with this firm? No. You still send the deck, still take the call, still follow up. The AUM was never going to alter a single move you make this week. It is context you collected once and will never act on. Delete the column.

Now run "next action" through it. Blank it. Suddenly you do not know what to do with this investor. The blank is intolerable, because the whole point of the tracker is to tell you the next move. That column is load-bearing.

Most fields in a typical tracker fail this test. Fund vintage, partner Twitter, podcast appearances, dry powder estimates, board seat appetite at the seed stage: none of these change a Tuesday-morning decision. They feel like diligence, so founders collect them, but a tracker is not a research database. It is a decision queue. Every field that does not drive a decision is a field you will stop updating, and a field you stop updating poisons trust in the ones you keep.

The good news is that the fields that survive the test fit on one screen. There are ten.

The ten-field template

Here is the entire schema. One row per active investor relationship. Every column drives a decision, which is why every column gets updated.

Ten columns. Every one of them, blanked, changes what you do next. That is not a coincidence. It is the design rule, applied until only the load-bearing fields remain.

A live row reads like a sentence you can act on: General Catalyst / Mike R. / partner meeting / warm intro via Dana / last touch June 24 / next action: send updated retention cohort / reason: they led two infra seeds in our space last year / signal: partner asked for a second call unprompted / owner: me / deadline: June 30. You know what to do and when, without reading a paragraph of notes.

The delete list

If you are migrating from a wide tracker, these are the columns to cut, grouped by why they fail.

Static facts you will never act on. Fund size, AUM, vintage, dry powder, geography, sweet-spot check size, full portfolio list. These are real, but they do not change a move during the raise. If you need one for a specific email, look it up once. Do not maintain a column for it.

Vanity research. Twitter handle, podcast appearances, blog posts, mutual-connection count, alma mater. This feels like preparation. It is procrastination with a spreadsheet interface. The one piece that matters, your actual angle on why they fit, lives in `reason`.

Premature deal terms. Expected check, valuation comfort, term preferences, follow-on appetite, board seat appetite. At seed, before a single term sheet, these are guesses. Tracking guesses as if they were data makes the tracker feel precise and be wrong. Add them back the day a real conversation about terms starts, on the two or three rows where it is live.

Redundant date columns. First email date, first reply date, first call date, second call date, partner meeting date. You do not need a column per event. `stage` tells you where you are and `last touch` tells you when you were last there. The event history, if you ever need it, is in your inbox and calendar already.

Duplicate status fields. "Status," "priority," "sentiment," and "temperature" almost always coexist in a wide tracker and almost always contradict each other by week two. Collapse them into `stage` (objective progress) and `signal` (subjective read). Two fields, no overlap.

The rule behind all five groups is the same. A fundraise is run from a decision queue, not a research file. If a column does not answer "what do I do next and when," it does not belong in the thing you check between calls.

Migration in four steps

You do not need to rebuild from scratch. Convert what you have.

First, copy your existing tracker to an archive tab. You are deleting columns, and the static facts you cut still exist if you ever want them. This removes the fear that makes founders hoard fields.

Second, add the ten template columns to a fresh tab. Map what you can from the old sheet: investor, person, and any path or last-touch data carry straight over.

Third, fill `next action`, `owner`, and `deadline` for every active row by hand. This is the only slow part, and it is slow because these are the fields your old tracker never forced you to think about. Doing it will surface three or four investors where you genuinely do not know whose ball it is. That confusion was always there. The template just made it visible.

Fourth, delete every column not in the ten. Cut, do not hide. A hidden column is a column you will reopen and start half-filling again. The archive tab is your safety net, so make the working tab ruthless.

When you finish, you will have a tracker that is narrower, more current, and more honest than the forty-column version, because you can keep all ten fields true.

Where the ten fields stop being a spreadsheet

The template works on day one. It also decays, for one boring reason: even ten fields have to be updated by hand, and you update them last, after the calls and the inbox and the standup. `last touch` drifts. `next action` goes stale the moment they reply and you have not re-read the thread. `owner` flips to "them" when they answer and you do not notice for four days. The schema stays correct and slowly stops being true.

The thing is, every one of these ten fields already exists in a source you are not looking at. `last touch` is the date of the most recent email in the thread. `signal` is the sentence in their last reply where the partner asked for more. `owner` flips the instant they hit send. `stage` moves when the calendar shows a partner meeting got booked. RoundOS reads those sources, your inbox, calendar, and meeting notes, and keeps the ten fields current from them, so `last touch` matches the real last email, `owner` flips when a reply lands, and `next action` updates when the conversation moves. Same ten-field template, maintained from the round instead of from your willpower, with the rows where you hold the ball surfaced as the moves to make today.

You can build the ten-field template in a spreadsheet this afternoon. The schema is the valuable part. Keeping it true is the part that breaks.