A CRM for a microfinance organisation (MFO) should follow a client from their first enquiry to their last payment: where the application came from, what stage it's at, which contract was signed and when the next payment is due. In an insurance company, payments give way to policy expiry dates and renewals; in a pawnshop, to redemption deadlines. If even one of these steps lives in a notebook or in a manager's personal chats, that's exactly where clients get lost.
People searching for "microfinance software" or "software for MFOs" often mix up two different jobs: loan accounting and working with clients. This article is about the second: what a CRM should keep track of, when an off-the-shelf system is enough and when you need your own. We don't cover regulatory requirements; that's a question for a lawyer.
Applications from every channel in one database
A financial company gets applications from everywhere: the form and calculator on the website, Telegram, Instagram, phone calls, agents and partners, the office. As long as each channel lives separately, a client who wrote on Telegram and then called turns into two different people. And some enquiries simply go unseen.
-
One record per client. A repeat enquiry from the same phone number goes into the existing record instead of creating a duplicate.
-
A source for every application. You can see which channel brings in contracts and which only brings in calls.
-
The whole history in one place. Past loans, policies, declined applications and correspondence: the manager knows who they're dealing with before making the call.
An application from the calculator should arrive with the amount and term already filled in; we explained how to set that up in the article on loan and leasing calculators for websites. And if your applications are still kept in a spreadsheet, check whether it's time to move to a CRM.
Application and contract statuses: the basis for reporting
An application and a contract have different lives, and it's worth tracking them separately. An application goes from "new" to "under review" to "approved" or "declined", and once approved it becomes a contract. The contract carries on from there, and its stages depend on the type of business:
-
MFO. Disbursement, scheduled repayment, arrears, closure.
-
Insurance company. Policy issued, active, expiring soon, renewed, or client lost.
-
Pawnshop. In a CRM for a pawnshop, the stages are valuation, pledge, extension, redemption or end of term.
Every status should have an owner and a deadline. Then the CRM itself will show what's stuck: for example, an application was approved, but nobody ever called the client.
If statuses are kept accurately, management reports put themselves together, with no late night in Excel before a meeting. Management usually needs three things:
-
Funnel by channel. How many applications came from each source and how many of them turned into a contract.
-
Manager performance. How quickly new applications get a response, how many deals were closed, what's stuck.
-
Portfolio. Disbursements, repayments and arrears for an MFO or pawnshop; renewals and lost clients for an insurance company.
Payment and renewal reminders
Reminders are a simple CRM feature with a direct effect on revenue. An MFO client gets a message a few days before a payment is due, an insurance client before the policy expires, a pawnshop client before the pledge period ends. The messages go out automatically, by SMS or through a Telegram bot, with the amount and the date.
It helps when clients can reply to a reminder, for example by tapping "I've paid" or "I need advice" in the Telegram bot. The reply goes straight into the client record, and the manager can see who to call and who to leave alone.
In a CRM for an insurance company, renewals are a job in their own right. A client who wasn't reminded in time often renews with whoever makes an offer first. So as well as messaging the client, the CRM gives the manager a task: call in advance, offer the renewal, record the outcome.
Agree the wording and frequency of reminders about overdue payments with your lawyer. And staff should be able to change the templates and the schedule themselves, without a programmer.
Client documents and staff access
Passport, contract, policy, photos of the pledged item: all of this should be kept in the client record, not in managers' chats or in a shared folder that anyone can open.
-
Roles. An operator sees contact details and status, a manager sees their own deals, a branch head sees their own branch. Documents can only be opened by the people who need them for their work.
-
Activity log. Who opened a record, downloaded a document or changed an amount: everything is logged.
-
Export restrictions. Not every employee can export the whole database to Excel.
-
Document checks. The CRM shows which documents are still missing for the contract and won't let the application move on until they're in.
When a manager leaves the company, their access is closed, but the clients, documents and correspondence stay in the CRM. That can't be done with personal chats.
Check with a lawyer which requirements for storing client data apply to your company. The CRM's job is to give you the tools to meet them.
An off-the-shelf CRM for an MFO or your own
Off-the-shelf systems such as Bitrix24 or amoCRM handle applications and deals well. If your process is mostly about sales, start with one of them: setting up a ready-made system is easier than building your own.
The limitations begin where a financial company has needs of its own: a payment schedule for every contract, collateral, policies with expiry dates, a connection to the accounting system. In an off-the-shelf CRM, all of this has to be imitated with extra fields and manual reminders, and over time the workarounds take more effort than the work itself.
Your own system makes sense when you have many contracts, several products and branches, and need a connection to accounting. Which route suits you depends on your processes, and analysing them is where CRM development should begin.
An example from our own work involves a leasing company rather than an MFO, but the task is the same: bringing clients from different channels together in one place. For Eskhata Leasing TJ in Tajikistan, we built a single client database that combines data from different channels. And the Eskhata Leasing website in Uzbekistan is integrated with Bitrix24, with additional modules built for the managers.
Checklist
-
All channels feed into one database. An application from the website, a Telegram message and a phone call can all be seen in one place.
-
Every application has a source and an owner. And it's clear what should happen to it next.
-
Stuck applications are visible without searching by hand. An approved application that nobody has called about stands out straight away.
-
Payment and renewal reminders go out automatically. Managers don't have to keep them in their own calendars.
-
Client documents are stored in the CRM. And staff permissions differ by role.
-
The management report builds itself. No merging spreadsheets by hand before a meeting.
-
You know what has to be done by hand in an off-the-shelf CRM. That list is the brief for your own system.
If you want to work out which CRM your company needs, a ready-made one configured for you or your own, take a look at what we do for leasing and financial companies and get in touch. We'll look at where your applications come from and where they get lost, and suggest where to start.
