When Two CRMs Make Sense: Full-Service Firms With an IP Group

The default advice for a full-service firm is one CRM. Single source of truth, single licence stack, single onboarding burden. For most firms that advice is right. For a specific subset — full-service firms with a substantial IP group — it is sometimes wrong.

The case for two systems is narrow but real. It is worth understanding when it applies and when it does not.

The shape of the problem

A full-service firm with corporate, litigation, employment, real estate, and IP practices has a partnership-wide BD function whose CRM needs are well served by an enterprise-class system. Intapp and its peers exist for exactly this reason and they do this job well. Conflicts, matter intake, pitches across practice groups, firm-wide contact governance — these are real problems that an enterprise CRM was built for.

The IP group inside that firm has different needs. Register-driven signal data. Foreign associate networks. Inventor relationships. Prosecution-versus-litigation pipeline distinctions. Conference ecosystems (INTA, AIPPI, AIPLA) that do not map onto the firm's general events calendar. An enterprise CRM can be made to hold this with custom fields, but the IP group ends up using a fraction of the system at 100% effort and losing the inference that an IP-native platform provides natively.

When two systems is the right call

The two-CRM architecture starts to make sense when three conditions hold:

• The IP group is large enough to justify its own toolchain — typically 20+ fee earners
• The firm-wide CRM serves practices whose BD motion is fundamentally different from IP (transactional corporate, contentious litigation)
• The IP group is already operating semi-independently on BD planning, conference budget, and origination tracking

If the IP group is six lawyers in a fifty-lawyer firm, two systems is overhead. If the IP group is sixty lawyers in a four-hundred-lawyer firm, it is probably correct.

How the two systems coexist

The architecture is not "two unrelated systems." It is one enterprise system holding firm-wide governance data and one IP-native system holding the relationship and signal layer for the IP group, with defined integration patterns between them.

The patterns that work:

Contact and organisation sync, one direction. The enterprise CRM is the system of record for client and contact existence. The IP-native system reads from it and enriches. Names, organisations, and matter shells flow from enterprise to IP. The IP system never tells the enterprise system that a contact exists; it tells it what is happening with that contact.

Matter linkage. Every IP matter exists in both systems, with a shared identifier. The enterprise system holds the matter for firm-wide purposes (billing, conflicts, governance). The IP system holds the BD activity, relationship history, and signal data associated with it.

Conflicts always run through enterprise. No exceptions. The IP system surfaces relationship history to inform the conflicts process, but the clearance happens centrally.

Reporting flows up. The IP group reports its BD performance to the partnership in the format the partnership uses. The IP-native system produces the IP group's internal view; the rolled-up numbers feed the firm-wide dashboard.

Avoiding double-entry

Double-entry is the failure mode that gives the two-system architecture a bad name. The defence is automation, not policy. Anything a partner has to enter twice will eventually be entered once and then drift. The integration has to push contacts, organisations, and matters automatically; the BD team has to monitor the sync; and exceptions have to be visible.

We covered the broader point on automated capture in the case for single source of truth over every-field-filled. The principle applies twice as hard when there are two systems involved.

The political handling

The political question is sharper than the technical one. The firm-wide BD director will reasonably ask why the IP group needs its own system. The honest answer is that the IP group's BD motion is different enough that a shared tool serves it badly, and that the IP group will report into the firm-wide view in exactly the same way it does today. The two-system architecture is not a secession. It is a specialisation.

Frame it that way, with the integration patterns committed to in writing, and the conversation gets easier. Frame it as the IP group going independent, and the project dies in committee.

Related: The Best CRM for IP Law Firms in 2026. Legal CRM for IP Firms vs Generic Tools. The CRM as the Operating System of a Modern Law Firm.