A system of record stores the current state of customers, contacts, opportunities and related activity. A system of action uses that information to detect what needs attention, assign work, escalate exceptions and verify that the required action actually happened. Many CRM implementations stop at the first layer.
A clean database is necessary—but it is not the outcome
Most CRM projects begin with structure: contacts, accounts, deals, fields, pipelines and dashboards. That work matters. Without consistent records, every workflow built on top of the CRM becomes fragile.
But a database can be perfectly organized and still fail operationally. A referral can remain open. A client review can become overdue. A customs change can affect an account without anyone translating the change into commercial action. A dental group can have accurate treatment values but no group-wide way to see which locations are failing to work those opportunities.
The gap is not usually "we have no data." It is "the data does not reliably become action."
The operating pattern is surprisingly consistent
Across industries, two patterns recur.
The first is external change → affected records → action. A regulation changes, a tariff changes, a policy changes, or a new operating constraint appears. The organization then has to identify which clients, quotes, patients, products or workflows are affected.
The second is internal state → exception → action. A status becomes stale, a threshold is crossed, a deadline approaches, a KPI deteriorates, a document remains incomplete or a customer interaction goes unresolved.
A CRM becomes much more valuable when it can model both patterns and connect them to ownership, deadlines, evidence and escalation.
Dashboards are not the same thing as control
Dashboards answer "what is happening?" Operational control answers "what needs to happen next, who owns it, and when do we escalate?"
That distinction matters. A red KPI on a screen is only useful if a manager can drill into the exact records creating the problem, route them to the right owner, and see whether the exceptions are being closed. Otherwise the dashboard becomes another report people review before returning to spreadsheets, inboxes and ad hoc follow-up.
Why managed CRM changes the model
A self-managed CRM can support sophisticated workflows. The technical platform is not the hard part. The operating burden comes later: data models drift, integrations fail, staff create inconsistent records, business rules change, new exceptions appear, and AI or automation starts acting on stale assumptions.
A managed CRM service should therefore be judged less like a software implementation and more like an operating function. The provider should maintain data integrity, rules, integrations, exception definitions, dashboards, approvals and human handoffs over time.
Where Twenty fits
Twenty is useful as a base because it is flexible enough to model custom objects, relations, workflows, APIs and extensions without forcing every client into a rigid vertical template. That flexibility does not itself create value. It creates room to build the operating layer.
The strategic question is always the same: what should remain in the system of record, and what should the managed CRM own? In healthcare the EMR should remain the clinical record. In legal, Clio or another legal platform may remain the matter system. In manufacturing, ERP should remain the operational and financial system. The CRM earns its place by orchestrating the work that crosses those systems.
- Twenty: Key features
- Twenty: Partners
See the managed CRM comparison hub and choose the operating model that fits your industry. See the full comparison →