When we talk about what we are building, we often use the familiar term βCRMβ β a system for managing customer relationships. But that word is only an external view. Underneath it, we believe, lies a more general pattern that reaches beyond the customer relationship. CRM is, in fact, a special case of something larger.
The general pattern
This pattern comprises several components that form a shared cognitive system. First, a semantic network that holds entities and information about them. Second, an action layer that moves work forward. Third, distinct cognitive roles that gather information, organise it, and decide when a matter advances to the next stage. Fourth, a human review loop that approves proposals. Fifth, recorded reasoning: the trail of what each decision was based on.
These five components form a pattern applicable to any shared cognitive problem β wherever information must be gathered, organised, and turned into action.
Why CRM is one instance
In a CRM, the βmatterβ the system tracks is a relationship: one with rights and responsibilities that develops over time. The networkβs edges encode the structure of this relationship. But the pattern applies elsewhere if you change the matter. Whether the matter is a case file, a project, or anything else that evolves and requires information gathering and decisions, the structure holds. CRM is simply the instance where the matter is a relationship.
Why this view matters
This view is not just a theoretical nicety; it shapes how we build. When you see a system not as a CRM, but as one instance of a general pattern, you build it so its components are reusable. The semantic network, the cognitive roles, and the review loop are not tied to a single domain. When you reach the next cognitive problem, you do not start from scratch; you apply the same foundation to a new matter.
Where this view is not the right answer
To be honest: this abstraction is not always worth it. For many teams, a conventional, off-the-shelf CRM β with its forms, sales pipelines, and standard reports β is simpler, cheaper, and entirely sufficient. If you have exactly one problem and it is managing customer relationships, building a general cognitive foundation adds complexity that does not pay for itself. Premature abstraction is a cost in its own right. This pattern only earns its keep when you genuinely have several growing cognitive problems that can share the same foundation. Otherwise, the direct solution is the better choice.
Putting it together
We do not see CRM as an endpoint, but as the first application of a more general idea: a shared cognitive foundation for matters that grow over time. This is a direction we are building toward, not a finished product. Whether or not you ever reach for this abstraction, the view itself is a reminder: behind a familiar term like CRM, a larger pattern is sometimes hidden β one worth seeing.