CRM City — User Manual

What this is, in one page

If someone asks "what does your CRM do?" and the answer is "manages clients", the conversation is already over. Every CRM manages clients. Here is the actual answer.

Every CRM on the market assumes you are a salesperson chasing deals. Most people who genuinely need a CRM are not. They are pastors with eight hundred members, community leaders, consultants with a large network, charity organisers, course providers. Their problem is not a pipeline. Their problem is that past a certain number of people, memory fails.

And when memory fails, it fails in two opposite directions at the same time.

Some people you abandon. Four months of silence you never noticed, because nothing in your day pointed at them. Others you crowd. They are in a drip sequence, and they also got the campaign, and then a "how are you", and now they have gone quiet — not because they lost interest, but because you became noise.

Neither of those is "too little CRM" or "too much CRM". It is attention allocated badly. One cause — memory failing at scale — producing two opposite errors.

Every other CRM sees only the first half. Not because the second is hard to build, but because they are all sold to sales departments, where more contact is by definition better. Telling a customer they are bothering people contradicts the business their buyers are in.

CRM City measures both directions. A contact is blue when you are neglecting them, green when the rhythm is healthy, red when you are crowding them. That is the spine of the product, and everything else exists either to serve it or to stop you needing a second tool for the rest of your work.

The rest is real, and there is a lot of it — email that closes the loop, automations on a shared event bus, invoicing, bookings, courses, a full API. Fourteen modules you switch on and off per organisation, so the same engine is a simple address book for one customer and a full commercial system for another. But if you remember one thing from this manual, remember the paragraph above. The rest is machinery.

How to read this manual

You do not need to read it in order, and you should not try to read it all. The first three chapters are the product; everything after them is a module you may never switch on.

Start here, in order:

Then whatever your work needs:

Three things that are true everywhere

Read these once and a lot of the product stops being surprising.

Your data is isolated at the database, not by our code. Every table carries a tenant_id and the database itself refuses to return rows that do not belong to your organisation. Even a bug in the application cannot leak another organisation's data, because the rule is enforced one layer below the application.

Everything remarkable lands on one event bus. A new contact, a won deal, a submitted rating, a paid invoice — each of these emits an event. That single event feeds external webhooks, automations and lead scoring simultaneously. This is why "when X happens, do Y" works consistently across modules that were built at different times: they all speak through the same channel.

Nothing is deleted when you switch a module off. Modules control what you see, not what exists. Switch off Invoicing and the invoices stay in the database, untouched; switch it back on six months later and everything is exactly where you left it. The same is true of downgrading a plan — you stop being able to create new things past the limit, but nothing you already made stops working.