CRM

A CRM in a prospecting operation is a write target before it is a reporting tool. Call summaries, replies, booked meetings and enrichment all arrive from somewhere else, and none of them are typed by a human who remembered. That single fact decides how to choose one: if the API is a premium feature, the CRM will quietly become a place where data goes to be re-entered by hand. Three things to check. Whether you can model the objects your business actually has, rather than bending your process into someone else's vocabulary of leads and opportunities. Whether every record can be read and written through a normal API, with webhooks that fire reliably. And what a seat costs for the person who only needs to read, because per-seat pricing is what stops a company from giving access to the people who should have it. For an agency there is a fourth question: one shared pipeline separated by a filter is separation by discipline, and discipline fails silently. A workspace per client is structural isolation, and it also makes the end of an engagement clean. Expect nine to twenty dollars a user per month, with open-source self-hosting a real option whose licence is free and whose operations are not.

Start from the write path, not the demo

When I evaluate a CRM for a prospecting operation, I ignore the demo pipeline entirely. The demo shows a human typing. My operation has no humans typing. Call summaries arrive from a dialer, replies arrive from an inbox tool, enrichment arrives from a data provider, and booked meetings arrive from a scheduler. If any one of those sources cannot write to the CRM through a normal API with webhooks that fire reliably, the integration becomes a person copy-pasting, and that person is me or someone I pay. So the first thing I test is the write path, with a real record, before I look at anything else. The introduction says this and I will only add: test it with the ugliest record you have, the one with missing fields and a weird company name, because that is the record your dialer will actually send.

Model your objects, or bend your process

The second thing I look at is whether the CRM lets me model the objects my business actually has. Most CRMs hand you a fixed vocabulary of leads and opportunities and expect you to translate. Translation works for a while, then someone on the team starts using the opportunity stage to mean something else, and your reporting quietly rots. A CRM that lets you define custom objects and relations is a CRM that lets your process stay honest. This is also where customisation earns its price: Twenty positions itself as the most customisable CRM on the market, and that claim matters more to me than any feature list, because customisation is what decides whether the tool survives contact with a real operation.

What a seat costs, and who needs one

Per-seat pricing is the third check, and it is the one that decides who gets access. If a read-only seat costs the same as a full seat, managers stop adding the people who should be able to look, and the CRM becomes a silo. On the Pro plan, Twenty lists a rate of 9 dollars per user, per month. The Organization plan is listed at 19 dollars per user, per month, and adds row-level permissions, SAML and OIDC SSO, a custom domain and priority support. The Enterprise tier starts from 50,000 dollars a year and covers single-tenant isolation, IP allow-listing, SCIM and an SLA. I break down how I read these numbers for agency economics in CRM for agencies: the number to read before you pick one.

One pipeline or one workspace per client

For an agency, the structural question is whether the tool supports a real workspace per client rather than a shared pipeline separated by filters. Filters are a theory about your market, and theories are often wrong; a filter that someone unchecks once is all it takes for one client's data to surface in another client's view. A workspace per client is structural isolation, and it also makes the end of an engagement clean: you hand over the workspace or you archive it, and nothing lingers. I explain what changes in practice in One workspace per client: what changes when the CRM stops being shared.

Where the CRM meets the meeting

The last thing I check is the path from qualification to booking. A CRM that stores a qualified prospect is worthless if booking the meeting happens in another tool with another copy of the data. The fewer clicks between qualified and booked, the fewer meetings you lose on the way, which is the whole argument of Qualify and book on one page: the second click that costs you meetings. Whatever CRM you pick, measure that click count on your own process before you commit, because it is the number your calendar will feel.