Connect and a CRM
A CRM is a system of record you fill in. Connect is a worker that answers the mail and leaves records behind as a consequence. They overlap on people, companies and opportunities, and they are strongest at opposite ends: a CRM at reporting, customisation and being the agreed truth for a whole company; Connect at reading a message, deciding what to do and doing it.
The overlap, stated precisely#
Connect holds a Person (the canonical human), an Identity (one address on one channel, and a person may hold many), a Company, an Opportunity on a pipeline with stage rules, a Support Case, and a lifecycle stage per person. It assembles a timeline across every channel and answers one relationship in a single view. Those are CRM nouns and there is no point pretending otherwise.
The difference is where the rows come from. In a CRM a row exists because somebody typed it or an integration pushed it. In Connect a row exists because a message arrived, was resolved to a person, and was worked. Nobody is asked to update a record after the fact, which is the single reason most CRM data goes stale.
What a CRM does better#
This is not a short list, and pretending it is would be dishonest.
- Reporting and forecasting
- Pipeline analytics, weighted forecasts, cohort and territory reporting, and the board pack that comes out of them. Connect shows a pipeline; it is not a reporting product.
- Custom objects and fields
- A mature CRM lets you model your own business — a fleet, a policy, a course enrolment — with your own fields and validation. Connect's record shapes are fixed.
- Being everyone's source of truth
- Finance, service, marketing and sales agreeing on one customer record is an organisational achievement a CRM is built to support, with the permission model to match.
- Ecosystem
- Quoting and CPQ, contract tooling, e-signature, marketing automation and dozens of vertical add-ons all assume a CRM underneath.
- Bulk data work at scale
- Mass import, deduplication tooling, data enrichment vendors and migration services are a CRM discipline with decades behind it.
If your problem is *we cannot see the numbers*, a CRM is the answer and Connect is not.
What Connect does that a CRM does not#
- It answers. A reply is drafted against the thread, the workspace's Knowledge and what Connect remembers, and it is sent through one send boundary that only reports sent when the provider has acknowledged it.
- It remembers at four tiers. Workspace, channel, endpoint and contact, resolved narrowest-first, so a direction set against one customer overrides the channel's without a rule engine.
- It decides under a stated rule. Autonomy is per channel and per scope, and every decision — including a refusal — lands in the decision log.
- It works while nobody is watching. Follow-ups are dated commitments with a reason, drained on their channel, including phone.
- It refuses to invent commercial terms. A price, SLA or warranty that Knowledge does not support is escalated rather than improvised.
Which system owns which record#
Run both and the only question that matters is ownership. The workable split, in practice, is by who writes the row most often.
| Record | Usually canonical in | Why |
|---|---|---|
| Company and account hierarchy | The CRM | Finance, contracts and reporting all key off it |
| Person and their channel identities | Connect | Identities are discovered from real traffic — a phone number and an email address resolving to one person is work Connect does anyway |
| Conversation and call history | Connect | The canonical threads, messages and calls are what the engine reads; copying them out is a reporting export, not a sync |
| Opportunity value and forecast | The CRM, if you have one | Forecast maths is what a CRM is for |
| Commitments and their reasons | Connect | A follow-up carries a reason and a channel and is drained automatically |
Connect publishes a public API and an MCP server, and integration keys are issued per workspace, so moving records either way is ordinary integration work. There is no packaged connector for any named CRM described in this documentation; if you need one, you build it against those interfaces.
How the choice usually goes wrong#
- Buying Connect to fix CRM hygiene
- Records improve because conversations are worked, not because a cleaning process runs. A CRM full of bad rows stays full of bad rows.
- Expecting Connect's pipeline to replace forecasting
- It tracks opportunities, stages and value in minor units. It does not weight, roll up or project.
- Syncing everything both ways
- The most common failure. Pick a direction per record type; bidirectional sync of the same field between two systems that both mutate it will diverge.
- Assuming the CRM's consent flags travel
- Suppression, unsubscribe and do-not-contact are checked inside Connect before any outreach. A flag sitting in another system is not a flag Connect can see.
Questions#
Can Connect be my only customer system?
For a small business whose customer relationships are mostly conversations, often yes — people, companies, identities, a timeline, opportunities, cases and onboarding are all there, plus the data grid over thirteen record sheets. Once you need custom objects, weighted forecasting or department-level permissions, you want a CRM as well.
Does Connect sync with my CRM automatically?
Not out of the box. What exists is a documented public API, an MCP server and per-workspace integration keys. A sync is something you or your integrator builds on those, and it should be one-directional per record type.
If the CRM owns the company record, what does Connect do with it?
It still resolves people to a company and shows the relationship; it simply stops being the place that decides the company's canonical name, hierarchy or account owner. Nothing in the engine depends on Connect being the authority for that field.