Academy

CRM is a special case of a larger pattern

What we're building to manage customer relationships looks, at first glance, like a CRM. But underneath it lies a more general pattern that reaches beyond relationships.

The Felesh team 4 min

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.

Five parts around one networkOne matter: Nasim Textile renews contract C-208. The semantic network holds Nasim Textile, party to contract C-208, which ends on 30 Nov and is owned by Parisa. The cognitive roles read it and see 30 days left, so renewal is due. The action layer proposes a renewal quote. The human review step has Parisa approve the quote. The recorded reasoning stores why: C-208 ends 30 Nov. All four parts are wired to the one network.one matter: Nasim Textile renews contract C-208semantic networkNasim Textileparty tocontract C-208ends 30 Novowned byParisacognitive rolesaction layerhuman reviewrecorded reasoning30 days left: renewal dueproposes a renewal quoteParisa approves the quotewhy: C-208 ends 30 Nov
Every part reads and writes the same semantic network, so a renewal moves from a 30-day warning to an approved quote with its reason on record.

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.

Three matters, the same five partsA table of three matters. A relationship, which is the CRM case: Nasim Textile is linked to contract C-208, and it advances when 30 days remain to expiry. A case file: claim 77 is linked to policy P-3, and it advances when the evidence is complete. A project: task T-12 blocks task T-15, and it advances when T-12 is done. Under every row sit the same five parts: network, roles, actions, review and reasoning.matteran edge in its networkadvances whenrelationship(the CRM case)case file(a claim)project(a launch)Nasim Textile : C-208claim 77 : policy P-3task T-12 blocks T-1530 days to expiryevidence completeT-12 is doneunder every row, the same five partsnetworkrolesactionsreviewreasoning
Change the matter and the five parts stay; only the edges in the network and the moment a matter advances change.

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.

Where the foundation starts to payA schematic of total effort against the number of cognitive problems, from customers, to customers and claims, to customers, claims and projects, and one more. The off-the-shelf CRM line starts low and climbs steeply, because every new problem is solved again. The shared foundation line starts higher but climbs slowly. The lines cross at break-even, between two and three problems. Left of it, with one problem, buying the CRM is cheaper; right of it, building the foundation once is cheaper. No figures are measured; it shows the shape only.total effortoff-the-shelf CRMshared foundationbreak-evenone problem: buy the CRMseveral: build once1234customers+ claims+ projects+ the nextcognitive problems on one foundation
With one problem the off-the-shelf CRM is cheaper; the shared foundation pays back only once several growing problems use it.

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.