Zoho CRM for MFDs: What Modules Should Be Built

How should the Zoho CRM data model for an MFD be structured?

Zoho CRM ships with modules designed for B2B sales: Leads, Contacts, Accounts, Deals. An MFD practice can use several of them, but only after deciding what each one represents in your business. Getting this wrong early means painful restructuring later.

A common approach is to treat Contacts as individual investors and Accounts as family or household groups, with every investor linked to one family. Leads stay as prospects until they are onboarded, and custom modules handle MFD-specific records such as SIPs, reviews and service requests. Custom module availability depends on your Zoho CRM edition, so check that before finalizing the design.

Draw this model on paper first. For each module, write what one record means, what makes it unique and which other modules it links to.

• Leads: prospects who are not yet clients
• Investors (Contacts): one record per individual investor, keyed on PAN where available
• Families (Accounts): one record per household, with a head of family and relationship owner
• SIPs or holdings summaries: custom records linked to investors
• Reviews: one record per review meeting, linked to a family or investor
• Service Requests: one record per client request, linked to an investor

Leads and opportunities: fields and stages that work for MFDs

Keep the lead module lean. The purpose is to make sure every enquiry has an owner, a next action and an honest status. Extra fields that nobody fills in make reports less reliable, not more.

Stages should describe what has happened, not what the RM hopes will happen. Something like New, Contacted, Meeting scheduled, Documents pending, Onboarded and Not proceeding covers most practices. Use Zoho Blueprint or validation rules to require a next action date before a lead can move forward.

• Source and referrer, including campaign or website form
• Owner and date of first contact
• Interest area, captured in plain terms
• Next action and next action date, both mandatory
• Loss or not-proceeding reason, from a fixed list

Investor and family modules: the core of an MFD CRM

These two modules carry most of the practice's value. The investor record should hold identity and contact details, relationship owner and key status fields. The family record should show the household view: members, combined relationship notes, review frequency and the next scheduled review.

Use PAN as the main unique identifier for adult investors and plan a separate rule for minors and PAN-exempt cases. Add a relationship-role field, such as head of family, spouse, child or parent, so the family view is readable at a glance.

• PAN, date of birth and investor type such as resident, NRI or minor
• Mobile and email, with a note where contact details are shared across family members
• KYC status and nominee status as reference fields updated from source data
• Relationship owner and backup owner
• Communication consent and preferred channel

SIP, holdings and transaction data: what to bring into Zoho

Your back office, RTA files from CAMS and KFintech, and transaction platforms remain the source of truth for holdings and transactions. The CRM should hold only what the team needs to act on, not a full copy of every transaction.

Typically that means active SIP summaries, a holdings or AUM summary at investor and family level, and exception events such as rejections or mandate failures. Each imported record should keep a source reference, such as PAN plus folio, and an import date so it can be reconciled.

Decide the import schedule based on how the data will be used. Review preparation may only need monthly summaries, while SIP rejection follow-up needs a more frequent feed.

Review meeting and service request modules

A Reviews module turns review meetings into scheduled, trackable work. Each record holds the due month, type of review, preparation checklist, meeting date, notes, client concerns and agreed actions. Agreed actions become tasks linked back to the review.

A Service Requests module gives every client request a single record, regardless of whether it came by phone, email or WhatsApp. Use a fixed category list and a target turnaround for each, and let a Blueprint guide the request through its stages.

• Address, mobile or email update
• Bank mandate registration or change
• Nominee addition or update
• SIP start, pause, modification or cancellation request
• Redemption or switch request handling
• Statement or capital gains report request
• KYC update support

Supporting setup: roles, permissions, automation and dashboards

Zoho's roles and profiles control who sees what. A typical MFD setup gives RMs access to their own clients, operations access to service queues, and owners access to everything. Field-level security can hide sensitive details from roles that do not need them.

Add automation after the modules are in use, not before. Start with a handful of workflow rules: task creation when a review is due, reminders for overdue service requests, and alerts for leads without a next action. Dashboards come last, once everyone agrees on what each field means.

What to build first: a phased Zoho CRM rollout for MFDs

Trying to launch every module at once is one of the most common reasons MFD CRM projects stall. A phased rollout gives the team time to adopt each piece and lets you fix design issues while data volumes are small.

• Phase 1: leads, investors, families, tasks and basic permissions
• Phase 2: service requests and review meetings with standard templates
• Phase 3: SIP and holdings imports, exception workflows and dashboards
• Phase 4: messaging integrations, further automation and refinement

Core checklist

A practical action plan

1. 1

   Design the client and family data model before creating fields.

2. 2

   Define stage-entry and stage-exit rules for every major workflow.

3. 3

   Build dashboards only after teams agree on field definitions.

4. 4

   Pilot with a small team and refine before migrating all records.

Frequently asked questions