Details last reviewed on 5 October 2026. Rules and products change often. This is general information, not legal or tax advice, so confirm specifics with a qualified professional.
In most growing Indian businesses the same customer lives in three places. Sales has a contact sheet or a CRM, support has a shared inbox or a ticket tool, and finance has the accounting software. Each is right for its own team and slightly different from the others.
This guide is for the sales lead, the support lead and the finance controller who each hold part of the same customer. It covers what goes wrong, what to put on one record, how to scope access, how to protect phone numbers, and a routine to keep the data clean.
It is a design target for any business, whatever tools you use. For the wider picture of moving off scattered tools, see moving from spreadsheets to one platform.
What goes wrong when each team keeps its own customer
Three failures show up again and again.
The same contact, keyed three times. Sales types "Mehta Traders, Rakesh Mehta" into a sheet. Support creates "Mehta Trading Co" from an email. Finance books invoices to "M/s Mehta Traders". No one can say what Mehta Traders has bought, complained about or still owes.
An invoice dispute nobody in support can see. A customer writes in about a wrong amount. Support cannot see the invoice and asks finance on chat. Finance sends a payment reminder the next morning.
A renewal pitch to someone with an open complaint. Sales sees a contract ending and sends an upbeat renewal note. The customer has a ticket open for nine days. The note lands badly.
The founders' view at OpsGrids is that work stalls at handoffs, and that the same data keyed into several tools is a main cause. One record is the fix for this handoff.
What belongs on a single customer record
| Section | What it holds | Who writes it | Who reads it |
|---|---|---|---|
| Company | Legal name, trade name, GSTIN, billing and shipping addresses | Sales at first, finance corrects billing details | Everyone |
| Contacts | Named people, role, preferred channel, consent status | Sales and support | Sales, support; finance sees the billing contact |
| Owner | One accountable person | Sales lead assigns | Everyone |
| Deals | Open and closed deals, value, stage | Sales | Sales, finance for forecasting |
| Tickets | Open and past issues, severity, status | Support | Support, sales (status only) |
| Invoices and payments | Invoices, receipts, allocations, outstanding amount | Finance | Finance, sales and support (status only) |
| Activity | Calls, emails, messages, notes, with time and author | Whoever acts | Anyone with access to the record |
Notice the last column. Each team writes its own section and reads a summary of the others. Support needs to know an invoice is disputed, not see the ledger.
One owner per record
Every customer record needs exactly one named owner. Not a team, not "sales or support". The owner is the person who answers the question "who is looking after this customer?"
Owners approve merges, keep contact details current and take the first call when another team has a question. Ownership can move, for example when an account manager leaves. Log each change, so the history shows who held the account when. Pick the owner by who the customer actually talks to.
Merge and dedupe rules
Duplicates turn one record back into three. Write the rules before you need them.
- Match on stable identifiers first. GSTIN for a company, a verified phone number or email for a contact. Names are the weakest match, because "Pvt Ltd", "Private Limited" and "M/s" vary.
- Never auto-merge on name alone. Flag likely duplicates and let the owner confirm.
- Keep the oldest record as the survivor and move tickets, invoices and activity across.
- Record every merge. Who merged, when, and which record was folded in.
- One company, several branches. Use location fields or child records rather than separate companies, or a head office and its three plants will look like four customers.
Do not edit a posted invoice to change its customer; correct it with a credit note or new document, as in our guide to accounting workflows.
Scoped access: own, team, location, organisation
A shared record does not mean shared visibility. Finance should not see every sales negotiation, and sales should not see supplier payments or payroll-adjacent data. The practical tool is a permission that carries a scope, so the same permission can be granted narrowly or widely.
A few examples of how this plays out:
| Role | Customer data | Suggested scope |
|---|---|---|
| Sales executive | Own accounts and deals | Own |
| Sales lead | All deals of the team | Team |
| Support agent | Tickets in the queue | Team |
| Finance controller | Invoices and payments for all customers | Organisation |
Finance can be organisation-wide on invoices and payments while having no access to deal notes. Sales can be team-wide on deals while seeing only invoice status. Review grants when people change roles. Our platform page describes how scoped permissions work in OpsGrids.
Protecting phone numbers and reaching customers on WhatsApp
Phone numbers get pasted into chats and exported to sheets. A single record is a chance to stop that.
- Mask by default. Show the last few digits or a label such as "mobile on file".
- Reveal on permission. Only roles that need the full number can see it, and only on request.
- Log every reveal. Who, when, which record.
- Send without showing. When a rule sends a WhatsApp or email message, the system can look up the target for the send and deliver it without the person who triggered it ever seeing the number.
Most staff never need the digits; they need the customer to get the message. If you automate those messages, see our guide to WhatsApp automation for business and the companion on email automation for business events. Store consent on the contact.
India's Digital Personal Data Protection Rules were notified on 13 November 2025, with the main obligations reported for around mid-May 2027; confirm the dates with counsel. They are not in force today, but building notice and consent into the record now avoids a rebuild. See our privacy approach.
A data-quality routine
A record stays trustworthy only if someone checks it. A light routine is enough.
| Frequency | Check | Who |
|---|---|---|
| Weekly | New duplicates flagged and resolved | Record owners |
| Monthly | Customers with no owner, or an owner who has left | Sales lead |
| Monthly | Contacts missing a billing contact or consent status | Finance and support |
| Quarterly | Access grants reviewed against current roles | Department heads |
Checklist before you build
- One owner named on every active customer
- GSTIN, billing address and billing contact captured for each company
- Duplicate and merge rules written down and logged
- Each team writes its own section and reads summaries of the others
- Scopes set per role, with the smallest scope that works
- Phone numbers masked, reveals permissioned and logged
- Consent and preferred channel stored on each contact
Common mistakes
- Copying instead of linking. A second copy of a contact in the finance tool will drift.
- Giving everyone organisation scope. It is easy at set-up and costly at the first audit.
- Auto-merging on names. Two real customers become one, and invoices land on the wrong account.
- Treating the owner as optional. A record with no owner is where duplicates start.
What OpsGrids has today
This article describes a design target. OpsGrids does not ship a single combined customer screen across CRM, support and finance, and it has no cross-product customer timeline today.
What is live: the products share one organisation, one directory and one permissions model. CRM holds leads that convert into a company, contact and deal, companies and contacts with owners, an audited phone reveal, messaging-target resolution (a customer can be reached on WhatsApp or email without anyone decrypting the number), a deal board and an activity log.
Support & IT has tickets, SLA policies and an agent roster. Finance has invoices, payments and allocations. Not yet: CRM has no quotes, its pipeline stages are fixed, and the CRM has no combined customer screen.
Sharing one organisation is what makes a join across products possible, but the only cross-product joins live today are HRMS plus Approvals and CRM plus Notification. See the products page for the full list, and how permissions and privacy are handled.
FAQ
What is a single customer record? One shared record per customer that sales, support and finance all read, with each team writing its own section. It replaces three separately keyed versions.
Do we need a CRM to do this? No. Identifiers, one owner per customer and agreed merge rules matter more than the tool.
Should finance see everything sales sees? No. Give each role the narrowest scope that lets it work. Finance needs invoices and payments across customers, not every deal note.
How do we avoid exposing customers' phone numbers? Mask them by default, make reveal a permission, log every reveal, and send messages through a path that resolves the number without showing it.
Talk to us about your customer data
If you want to map where your customers live today and what one record could look like, Talk to our team.
Sources (checked 5 October 2026)
- Digital Personal Data Protection Rules, 2025: dates are from secondary reports; confirm on meity.gov.in before relying on them