Running several businesses on one CRM without the mess

Groups running several businesses almost always arrive at the same place: three CRMs, four spreadsheets, and no way to answer the question "how did the group do last month" without a person spending a day in Excel.

The two failure modes

The first is one shared database with a "business" field on every record. It is cheap to set up and it collapses the moment someone needs to see only their own entity, or two businesses want different sales stages. The second is completely separate systems, which solves isolation and destroys consolidated reporting.

What works is a workspace model: separate data, separate configuration, separate branding, shared administration, and a reporting layer that reads across all of them.

Three decisions that determine the outcome

Decide what is shared before you build anything. Usually the customer list is not shared, the product catalogue partly is, and the user directory entirely is. Write this down first, because retrofitting it later means a migration.

Decide who reports to whom. A group dashboard is only useful if the entities beneath it measure things the same way. If one business counts a lead at enquiry and another at qualification, your consolidated conversion rate is fiction.

Decide the exception policy. Someone will want a custom field that only their entity uses. Allowing it freely produces six divergent systems within a year; forbidding it entirely means people go back to spreadsheets. A reasonable rule: custom fields are free, custom stages need group approval.

What to do in week one

Pick the messiest business, not the cleanest. If the model survives your hardest entity, the rest will follow. Migrate its data, run it in parallel for two weeks, and only then roll out to the others.