Design it around capture, not data entry. Pull companies, contacts and meetings from email and calendar automatically, keep a short list of required fields and pipeline stages, and make the CRM answer the questions partners ask every week. If the system depends on people forwarding emails or typing notes, it will go stale within a quarter.
Almost every ops person I talk to has a CRM story, and most of them are sad. The firm picked a tool, someone spent a month configuring it, partners used it for a few weeks, and a year later half the pipeline lives in someone's inbox. Then the ops lead gets asked to "clean up the CRM" before the next fund's LP meetings, which means a weekend of reconstructing history by hand.
What I've come to believe is that the tool choice matters a lot less than people think. Affinity, Attio, HubSpot, Salesforce, even a well-built Airtable base can all work. CRMs are turning into commodities. The design decisions you make on top of the tool are what decide whether it survives.
Start from the questions, not the fields
Most CRM projects start with a field list. Someone opens the admin settings and adds every field that might be useful: round size, valuation, burn, team size, co-investors, thesis fit score, competitors. Each one is a small chore for the partner who has to fill it in, and the chores add up.
Work backwards instead. Write down the questions partners and the ops team actually ask, then keep only the fields that answer them. A typical list looks like this:
- What's new in the pipeline this week, and who owns each deal?
- Which deals have no next step, or a next step that's overdue?
- Where did our best deals come from over the last two years?
- Why did we pass on this company, and has anything changed?
- Who at the firm knows someone at this company or its investors?
- How many first meetings did we take this quarter, by source?
If no question needs a field, cut it. You can always add a field later when a real question shows up. Removing a field that people half-filled for a year is much harder, because now there's messy history to deal with.
Capture from email and calendar, not forwarding
This is the design choice that matters most. If the CRM depends on partners forwarding emails to a special address, logging calls or typing notes after meetings, it will fail. Not because partners are lazy. They're in back-to-back meetings, and anything that relies on remembering one more step gets dropped. People who forward by hand forget.
So make capture ambient:
- Connect every investor's email and calendar. With sensible privacy settings, so personal threads and internal-only conversations stay out.
- Create organizations and people from meetings. A first meeting with someone from a new domain should create a draft record on its own.
- Pull in meeting notes. If the team uses a note-taking tool, send each summary to the CRM against the right company, so the next person to meet the founder starts with context.
- Review, don't type. Have someone on the ops team spend 15 minutes a week on a review queue: merge duplicates, fix wrong matches, mark obvious noise.
The flow you want is meeting → record → review. Nobody types a contact or a meeting date by hand. Partners add only what a machine can't know: what they thought, and what happens next. For how this same idea helps outside dealflow, see maintaining a professional network, which leans on the same inbox-as-log approach.
Define the pipeline stages, and write the definitions down
Pipeline stages fall apart when different partners mean different things by them. One partner's "diligence" is a second meeting. Another's is a full data room review. Then the pipeline report means nothing.
Keep the stages few and define each one with an exit rule:
| Stage | What it means | Moves on when |
|---|---|---|
| Sourced | We know about the company and want to look | Someone takes a first meeting |
| First meeting | At least one investor has met the founder | The owner decides it's worth a second look |
| Active | We're doing real work: more meetings, references | It goes to the partner meeting |
| Partner meeting | The full partnership is discussing it | A decision: term sheet or pass |
| Term sheet | We've offered terms | Closed, or lost to another investor |
| Passed | We said no | Never, unless something changes and we reopen it |
Write these in a one-page data dictionary, next to a short list of pass reasons: team, market, traction, price, timing, conflict, lost to another investor. It's an old idea that still works. The pass reasons, in particular, become one of the most useful datasets the firm has a year or two later.
Pick the tool last, and own your data
Once you know your questions, fields, stages and capture method, choosing a tool gets easier. You're no longer comparing feature lists. You're checking whether a tool fits a design you already have.
Questions I'd ask any vendor:
- Can it capture from email and calendar automatically, and how do we keep personal threads out?
- Can we export all of our data, with history, at any time?
- Is there an API, so we can pipe data into our own warehouse or AI tools?
- What does it take for a non-technical person to change fields and stages?
- What happens to our data if we leave?
The second and third questions matter more every year. Your deal history is the firm's data, and you should be able to move it, query it and connect it to the AI tools your team already uses. Avoid any setup where the only way to get your data out is a support ticket.
Where the CRM stops
A dealflow CRM is built for the front office: sourcing, meetings and decisions. Once a deal closes, the work changes. Now it's metrics, board decks, updates, follow-ups and portfolio support, and a generic CRM handles that poorly. Portfolio workflows are much more specific to each firm. That's where Cura picks up: it pulls portfolio company signal from email, board decks, LinkedIn, X and news into one feed, and it has an API and an MCP server so the same AI tools your team uses for deals can work with portfolio data too.
What fields should a VC dealflow CRM track?
Track a few fields that drive decisions: company, stage, sector, source and referrer, owner, pipeline stage, next step with a date, and the reason for a pass. Let email and calendar fill in contacts and last touch. Every extra required field lowers the odds anyone keeps the record current.
The source and referrer fields deserve extra care, because they answer the question partners care about most over time: where do our best deals come from? Use a fixed list for source (inbound, founder referral, co-investor, accelerator, scout, outbound, event) and a link to the actual person for referrer. A free-text field here ruins the data within months. If partnerships are a big part of how you source, turning partnerships into dealflow channels covers how to track them. And if you're using AI to sort inbound, the same fields feed AI deal sourcing.
How do you get partners to keep the CRM up to date?
Ask them for as little as possible. Capture emails and meetings automatically, so partners only add judgment: stage changes, a pass reason, a next step. Then make the CRM the place the Monday pipeline meeting runs from. Partners update what gets discussed, and they stop updating what nobody looks at.
Running the meeting from the CRM is the habit that does the work. Put the pipeline view on the screen and go deal by deal. If a deal has no next step, it gets one before the meeting moves on. Within a few weeks, partners start updating records before Monday so they don't have to do it in front of everyone (a little social pressure goes a long way). And when someone asks the ops team for a pipeline report, send a link to the saved view instead of a spreadsheet. Every report built outside the CRM teaches people the CRM isn't the real source.