In the previous article, I wrote about the delivery chain behind the Zhurun projects: from a WordPress website to product display and consultation handling. That chain was more about the external entry point: where customers saw information, how they submitted inquiries, and how the business received them.

This article moves inward. It is about how I understood and decomposed the CRM.

When I worked on CRM systems, the easiest starting point to imagine was usually simple: create a customer table, build a list page, add a few filters, and let business staff write follow-up records. That kind of system solves the problem of "having somewhere to record things", but it does not necessarily solve the problem of making the business manageable. Over time, I became more inclined to think about relationships first and pages second.

Who the customer is, where they came from, who owns the relationship, which department they belong to, how many times they have been contacted, which products they hold, which consignment partners they relate to, and whether there are later WeCom touchpoints: if I do not give these questions structure early, more pages only become more complicated spreadsheets.

A Customer Is Not One Row of Data

I did not want to put customer information into a single flat table. For me, the profile was only the entry point. What really needed to be preserved was how the customer changed throughout the business process. So I treated customer type, status, source, level, institution, title, contact information, notes, owner, and department as the basic profile, then separated contacts, follow-up records, and holding records around the customer.

The underlying judgment was simple: a customer is not one row of data. A customer is an object that keeps producing context.

When a customer first enters the system, there may only be a name, institution, and contact method. After business staff have interacted with them several times, follow-up records, additional contacts, demand judgments, product interests, holding changes, and processing status start to appear. If the system writes all of that into notes, it is fast in the short term, but difficult to search, summarize, and hand over later.

So when I design this kind of CRM, I first separate "customer profile" from "customer process". The profile describes who the customer is right now. The process describes how I want the system to understand that customer: who maintained the relationship, what happened, and what should happen next.

Holdings Are Business State, Not Notes

In financial-service CRM systems, I pay close attention to product holdings. They should not exist only as follow-up notes.

At the time, I separated customer holdings, holding records, products, product sales, and product data into clearer modules. This was more work than writing "holds this product" inside a customer note, but it solved later management problems.

Once holdings are structured, I can let the system find customers through products, show product status through customers, and add follow-up records around holding changes. When business staff open a customer detail page, they see more than contact information. They see the real relationship between the customer and the products.

After these relationships enter structured data, I can continue to build statistics, filters, imports, reviews, and permission controls. Otherwise, they remain scattered across chat histories and personal spreadsheets.

Consignment Partners Need Their Own Object

I also separated consignment cooperation into its own module, with consignment objects and consignment follow-up records.

For me, this was a small but important boundary. A consignment partner is not an ordinary customer, and it is not exactly a product either. It has its own type, status, similar information, notes, owner, and follow-up process. If I forced it into the customer table just to save a few pages early, the field meanings and business actions would become awkward later.

When I look at systems like this now, I pay more attention to whether object boundaries are clear. Not everything should become an independent module. But once I see an object with its own lifecycle, owner, and follow-up method, I seriously consider giving it its own structure.

Otherwise, the system looks simple on the surface while pushing complexity onto the people using it.

Import, Permissions, and Organization Are Not Minor Details

In my experience, after a CRM goes live, the first problems that appear are often not page problems. They are about how data enters the system and where people sit inside the system.

I kept Excel import entry points for both customers and consignment partners. This feature looks ordinary, but it matters in real business. Internal data usually does not flow in from a perfect system at the beginning. It comes from historical spreadsheets, manual cleanup, and staged migration. Import is not an advanced feature. It is the entry point that lets the system receive real-world data.

Permissions and organization structure work the same way. I treated departments, users, roles, and permissions as basic parts of the internal system, and connected authentication with WeCom. For an internal CRM, customer ownership, department boundaries, who can see which data, and who can maintain which records all directly affect the business team's sense of safety and willingness to use the system.

If these boundaries are ignored early, two problems appear quickly. Either everyone can see all data, and the business team hesitates to put real information into the system; or permission patches grow everywhere, and the maintenance cost soon becomes larger than the feature itself.

A Dashboard Is Feedback, Not Decoration

I also built dashboard components around customers, direct sales, consignment, and target progress. For internal systems, I do not like dashboards that are only decorative. A dashboard should answer a practical question: can the data accumulated inside the system help managers and operators understand the current state more clearly?

How many customers are there? Where did they come from? What is the follow-up status? How are product sales moving? Where is consignment cooperation stuck? If this information only exists inside list pages, managers have to filter repeatedly. What I care about in a dashboard is making the frequently checked business state visible and stable.

I also do not think an early dashboard needs to be complex. It is more like a feedback loop between the system and the business: put the key indicators on the surface first, then adjust the definitions based on actual use. As long as the data structure is clear, this feedback loop can improve over time.

The Core of a CRM Is Not Recording, but Continued Management

This kind of project made me realize earlier that the first goal of a CRM is not simply to record information. It is to make that information manageable later.

If customer profiles, contacts, follow-ups, holdings, products, consignment partners, departments, and permissions do not have clear relationships, the system only becomes a more formal spreadsheet. It looks like a backend system, but the real work still depends on human memory and manual cross-checking.

So when I judge whether a CRM has a solid foundation, I do not only look at how many features it has at the beginning. I look at whether several key questions have answers:

• Are customer profiles separated from business process records?
• Can products and holdings be viewed as structured relationships?
• Does consignment cooperation have its own lifecycle?
• Can historical data enter the system through imports?
• Can organization, roles, and permissions support real use?
• Can external touchpoints such as WeCom connect back to customer records?

These questions decide whether the system can move from "recordable" to "manageable". Looking back, this CRM did not leave me with the memory of a particular backend page. It left me with a more stable judgment: in real projects, the lifespan of a system is often decided less by the number of pages and more by whether customer, product, organization, and touchpoint relationships were taken seriously from the beginning.