Micro-lending back office for Zhenghe Wealth — four customer tracks, three repayment cases

The situation

Zhenghe Wealth runs a lending business with two sides and two stages. On the lending side there are people who have expressed interest and people who have signed; on the borrowing side, the same split. Around each person sit conversations, follow-up calls and documents — much of it on paper — plus the products themselves and the repayment that follows.

The company’s records were a mix of paper files and spreadsheets: archives that were hard to search, and interest calculations done by hand. The brief was to bring the business into one system.

The call we made

Model four customer tracks explicitly, and treat conversion as a move that carries history forward.

A generic customer database would put every person in one table with a “type” field. That looks efficient and loses the thing that matters: a prospective lender and a signed lender are not the same record with a different value. They have different next actions, different documents and different follow-up rhythms. So the four tracks are modelled as four working queues, and when someone converts, the record moves with its communication history intact rather than being copied into a second table. Conversion is precisely the moment where a single-table design quietly loses the earlier conversations — the ones that explain why the person signed.

Digitise the archive so that it can be searched, not merely stored. Scanning paper into folders is not digitisation; it is a different filing cabinet. The archive was built with indexing and retrieval, because the value is producing a document during a query, not knowing that it exists somewhere.

Model the three repayment cases separately. Normal repayment, overdue repayment and early repayment are not one calculation with a flag on it. Early repayment changes the interest period; overdue repayment changes the fee basis. These are exactly the cases where manual arithmetic goes wrong, and exactly the cases a customer disputes. Each is its own scenario in the system, with the amount computed from the loan’s terms and the actual dates rather than from an assumption about the term.

Interest and fees are computed from configured product terms. Wealth products and loan products are configured with their rates and rules, and the system derives the amounts from those terms. A clerk does not type a figure the system could compute, which also means a rate change is applied in one place rather than in every spreadsheet that referred to it.

What we built

Four customer tracks — prospective and confirmed, on the lending and borrowing sides — each with its own working queue.
Communication and follow-up records attached to the person and carried across conversion.
Paper archive digitisation with indexed retrieval.
Wealth and loan product configuration, so terms are maintained rather than hard-coded.
Automatic interest and fee calculation from the configured terms.
Three repayment scenarios — normal, overdue and early — each with its own computation and recorded basis.
Staff records with profiles and uploaded documents for the front-office users.

Result

The four tracks give the business a queue per segment instead of a mailing list, and the history survives conversion, so the reason a customer signed is still visible after they have signed. The archive is searchable, so a document that used to require finding a physical folder can be produced in the middle of a conversation. Repayment arithmetic moved from a person to the system, which removed the two cases that generated the most queries: early settlement and overdue.

For a lending business the interesting risk is not the volume of records. It is the small number of cases where a date or a rate changes the amount owed, and those are the cases worth modelling explicitly rather than handling in a spreadsheet when they occur.

Screens from this system are not published. It runs on client infrastructure with client data, so we show it live instead: a short screen-share walkthrough under NDA, on a system we demonstrate rather than a screenshot we sanitised. Ask for it in the first call.

Technology

Stack	Vue 3 · Spring Boot · MySQL
Delivery model	Custom web platform
Client	Zhenghe Wealth
Status	Delivered

What we cannot show

Borrower and lender identities, loan amounts, repayment schedules and scanned documents are not published. Interface screens from the delivered system are not shown.