A Single Customer View (SCV) is one trusted, deduplicated record of each customer that marketing, sales and service all work from. Most South African B2B businesses do not have one, and the reason is rarely the platform. If your sales team does not trust the CRM, marketing works from different numbers and leadership regularly asks where a report came from, the problem is the data inside it, and more specifically the configuration that keeps producing records you cannot consolidate into one view.
Where data sits in RevOps
Data quality is not a standalone discipline. It is function two of the six functions of RevOps, and everything in this article is what happens when function two has no owner.
| # | Function | What it owns |
|---|---|---|
| 1 | System architecture | The CRM object model, the lifecycle, and what connects to what |
| 2 | Data governance | Field definitions, data standards, record ownership, retention and lawful use |
| 3 | Process design | The workflow that actually happens on the floor, not the one in the documentation |
| 4 | Reporting and forecasting | One revenue number, produced by the system rather than assembled by hand |
| 5 | Enablement and adoption | Whether the people running the process have the means and the incentive to run it |
| 6 | Commercial operations | Quoting, approvals, contracting and the handoff into billing |
A single customer view is what function two produces when it works. The rest of this article is what it looks like when it does not.
Five causes account for most of it:
- A setting or integration is manufacturing the duplicates, so cleaning is temporary
- No agreed source of truth per field, so systems overwrite each other
- Free text where you needed controlled lists, so nothing segments reliably
- Property sprawl, so reports run against fields that hold nothing
- A database you cannot lawfully or reliably use, inflating every count
The common response is a scheduled clean-up. That addresses the data that already exists and not the reason it happened, which is why the database returns to the same state within a few quarters.
Five causes, and how to check for each
| Cause | What you see | How to check it |
|---|---|---|
| A mechanism creating duplicates | Duplicates return within months of a cleanup | Audit automatic record creation settings, integration write behaviour and form deduplication |
| No source of truth per field | The same field holds different values depending on which report you open | For each reporting field, name the one system allowed to write to it. If you cannot, that is the answer |
| Free text instead of controlled lists | Lead source, closed-lost reason or job title cannot be grouped | Export the field and count distinct values. Anything above a handful is a note, not a property |
| Property sprawl | Two people build the same report and get different numbers | Report on fill rate per property. Archive anything at zero |
| Unusable contact records | Large database, weak engagement rates | Segment hard bounces, personal email domains, contacts with no company and contacts with no email |
1. Find the mechanism before you clean anything
The most efficient data quality fix we have delivered involved no cleaning at all. A travel technology business was struggling with significant duplication on company records, created with minimal information, with nobody able to tell which record the team should use. The cause was a setting that automatically created a company record whenever a contact was created. Disabling it stopped the problem at source, and only then was the existing backlog worth addressing.
Duplicates are almost always being manufactured by something: an automatic creation setting, an integration writing without matching logic, a form that does not deduplicate, or an import run without a unique identifier. Clean first and you will be cleaning again.
One detail worth knowing: most CRMs, HubSpot included, warn about potential duplicates based on domain or contact details but do not block record creation. A warning that can be clicked past is not a control. Domain logic has limits too: two legitimate domains for one group read as separate companies, and one shared domain across different entities reads as duplicates.
What to check: whether anything in your stack can create a record without first checking whether it exists.
2. One source of truth per field, or the systems overwrite each other
This is the difficult version of the problem, and it is common in businesses that have added tools over several years. On one engagement, multiple integrations and workflows were each writing into the CRM independently, producing different values in the same key fields depending on which system wrote last, across thousands of fields and several hundred workflows. The consequence was not only wrong data but a loss of confidence in the platform, which is harder to recover than a broken report.
The fix was structural rather than cosmetic: nominate one object as the source of truth for each field, which in that case was the company record, and enforce it through property synchronisation workflows, which in turn depends on a reliable unique identifier to match on.
Sequencing mattered as much as the design. The scope was reordered so data integrity and deal-to-company-to-contact associations were resolved before anyone touched the workflow layer. Repairing workflows first would have felt productive and achieved nothing, because they were operating on data that could not be trusted. Automation does not fix a weak process, it runs it at scale.
What to check: for every field your reporting depends on, which single system is allowed to write to it.
3. Controlled lists where you currently have free text
Every free-text field is a future reporting problem. If three people can type "Managing Director", "MD" and "Man. Director", you do not have a segmentable property, you have a note. On a national training provider's implementation, a designation field stayed a dropdown rather than free text to preserve reporting and filtering, with a periodic review process for adding options. That review process is the part most teams skip, and it is what stops a dropdown becoming a bottleneck.
The same logic applies to the fields you report on most:
- Lead source must be a controlled list or attribution is guesswork.
- Closed-lost reason must be a controlled list or you can never analyse why you lose. Both were standardised on a procurement consultancy implementation for exactly this reason.
- Country and region need a controlled vocabulary. On one enterprise cleanup this was a named deliverable, because inconsistent values made regional reporting impossible.
- Calculation properties should default to zero rather than blank, which stops an input gap silently breaking the maths downstream.
Lifecycle stages belong in the same category and are the most consequential. The labels create no consistency on their own: the organisation has to agree what each stage means and what must be true before a record moves, because those definitions drive routing, automation, segmentation, scoring and the marketing-to-sales handover. Where marketing qualifies on engagement and sales qualifies on something else, every process built on those stages inherits the ambiguity.
What to check: export each reporting field and count distinct values.
4. Property sprawl makes reports look authoritative and return nothing
Portals accumulate fields. Someone needs one, creates it, uses it for a quarter, moves on. Two years later there are several ways to record the same thing and no way to know which is current. On one enterprise audit we found 11 duplicate properties spread across objects that had to be consolidated into single authoritative fields, alongside formatting inconsistencies across more than 98,000 records and a set of properties with a zero fill rate that were archived.
The zero-fill-rate properties are the dangerous category. They look official in a dropdown and contain nothing, so anyone building a report can select one in good faith and get an empty answer. Two principles apply:
Archive, do not delete. Archiving clears a property from view while keeping the data recoverable. Deletion is irreversible and someone will eventually need what was in there.
Migrate the data before retiring the field. Where a redundant property holds genuinely useful information, such as a free-text field being replaced by a dropdown, bulk update the records via workflow to move the information across first, then archive.
What to check: fill rate on every property, and how many properties describe the same thing.
5. Total contact count is the vanity metric of CRM
What matters is how many records are reachable, associated and lawful to email, and the real numbers are consistently larger than expected:
- One enterprise portal: over 5,000 duplicate contacts and close to 4,000 duplicate companies, formatting issues across more than 98,000 records, roughly 14,000 contacts with no email address and around 10,000 orphaned marketing contacts.
- A consulting business: roughly 800 contacts carrying over a thousand duplicate issues between them, 200 duplicate companies and 1,067 contacts with hard-bounced addresses.
- A B2B software platform: a database reduced from 54,000 contacts and 84,000 companies to 48,000 and 25,000, purely by exporting and removing empty company records.
That last one is the clearest illustration. Two-thirds of their company records contained nothing, so every report segmented by company had been running against mostly empty shells.
Four segments are worth building on day one, because each is an actionable list rather than a vague sense that the data is bad: hard bounces, contacts on personal rather than business domains, contacts with no associated company, and deals with no associated contact. Associations matter most, since a deal with no company and no contact still contributes to the pipeline total and cannot be attributed, chased or coached on.
What to check: contactable database size, meaning valid, non-bounced, business addresses, rather than total contacts.
How to deduplicate without breaking things
Deduplication is the highest-risk work in a CRM, because a wrong merge is difficult to undo and easy to do at volume. The method we use:
Export before you merge. Always. If a merge goes wrong, the original data is recoverable from that export and nowhere else.
Set the retained-record criteria in advance. Creation date, most recent engagement, or most complete record. Pick one, document it, apply it consistently. Deciding per record produces inconsistent data at the other end.
Split automated from manual. Automated rules handle the obvious cases at volume. Ambiguous records, where two similar records each hold different information, need a human deciding the source of truth. On one engagement the work was split by team: technical work on company records, manual contact review by the service team, with a defined review workflow for cases automated rules could not resolve.
Know when native tooling is not enough. On an enterprise cleanup running to thousands of records, even with custom deduplication rules available, the volume made native deduplication both painful and risky, so a specialist marketplace tool was recommended instead. That is usually the cheaper answer for the client.
Expect the reporting side effects. Merging changes record-creation attribution. That is normally the desired outcome, since it stops duplicate creation being counted twice, but know it before someone notices their numbers moved.
Grant narrow permissions. Data quality tooling access can go to the specific people doing the cleanup without handing out broad admin rights. On one engagement, giving the service team access to the data quality tools was managed entirely through permission settings.
Governance is what stops it happening again
Data governance sounds technical. Its practical purpose is that someone is responsible for deciding what information means, how it is structured and what happens when it changes. Without that, the problems fall between teams: marketing assumes sales maintains contact information, sales assumes marketing manages lifecycle stages, operations assumes an integration updates account information, and nobody owns the outcome.
On one enterprise engagement, governance was a named set of deliverables rather than a principle: super administrator count reduced against a documented RACI, role-based permission sets defined for sales, marketing, business development and service, export settings tightened, and connected private applications reviewed. That is also the answer you give when a client's security questionnaire asks who can export your CRM.
What to check: who is accountable for each reporting field, and how many people can export the database.
Where to start on Monday
- Find the mechanism. Check automatic record creation settings, integration write behaviour and form deduplication. Stop the source before cleaning.
- Baseline it. Duplicate counts, hard bounces, contacts with no company, deals with no contact, fill rate on the fields your dashboards use. You need the before-picture.
- Fix associations first. Deals without an associated company and contact break more reporting than duplicates do.
- Lock down the fields you report on. Free text to dropdowns, standardised country and region values, calculation properties defaulting to zero, lifecycle stages defined in writing.
- Then deduplicate, export-first, automated for the clear cases and manual for the rest.
Why MO Agency for Revenue Operations?
MO Agency designs Revenue Operations systems for enterprise and growth-led companies, covering CRM architecture and data governance, process and automation design, systems and data integration, and revenue reporting and forecasting.
That matters when CRM problems are symptoms of a larger operational issue. If duplicates are created because a setting allows it, cleaning the database addresses part of the problem. If lifecycle stages are inconsistent, changing a report does not resolve the definition. If information is lost between systems, adding another property does not fix the integration.
When teams trust the information, reporting becomes meaningful, automation becomes dependable, and revenue teams spend less time questioning the data and more time acting on it.
Build a CRM your revenue teams can trust
The measurable cost of bad data is wasted time and inaccurate reporting. The real cost is confidence: once a sales team stops believing the CRM they build parallel systems, and that fragmentation is difficult to reverse.
Which is why data quality is not a cleanup project. It is a set of configuration decisions, controlled fields, a documented source of truth per field, and someone accountable for the numbers. Get those in place and the cleanup only has to happen once.
If your teams are questioning the data in your CRM, it may be time to look at the revenue operation behind it. Explore MO Agency's Revenue Operations services.
A single customer view is not a cleanup you buy once. It is function two of a wider revenue operations programme, sequenced so the fixes hold, and its cost sits inside that programme rather than beside it. For the numbers, see how much RevOps costs in South Africa.
Frequently asked questions
What is a single customer view, and why does B2B in South Africa need one?
A single customer view is one trusted, deduplicated record of each customer that marketing, sales and service all work from, with one agreed source of truth per field. South African businesses need it because revenue is produced by three teams operating on one customer, and without it every team reports a different number. It is what function two of RevOps, data governance, produces when it has a named owner.
Why can our CRM data not be trusted enough to give us a single customer view?
Because the causes are configuration decisions, not user carelessness: a setting or integration manufacturing duplicates, no agreed source of truth per field, free text where controlled lists were needed, property sprawl, and records you cannot lawfully or reliably use. Until the mechanism producing bad data is fixed, any single view assembled on top of it drifts back out of sync within a few quarters.
How long does it take to build a single customer view in HubSpot?
A single-entity business on a reasonably clean CRM reaches a trusted, system-generated view in roughly six to ten weeks. A multi-entity, multi-currency business takes four to six months, with most of the extra time spent modelling entity and currency rather than reporting. The variable is dependency mapping, not record count.
How is a single customer view different from a one-off data cleanup?
A cleanup fixes the records that exist today and leaves the mechanism that produced them, so the database returns to the same state within a few quarters. A single customer view fixes the source first, names one owner per field, then cleans once and tracks duplicate rate and fill rate as monthly trends. One is a task, the other is governance.
Does POPIA affect how we build a single customer view?
Yes. Purpose limitation means data collected for one reason cannot be silently repurposed, so merging records across business units needs a lawful basis, not just a technical match. Data subject requests must be answerable from one place, which is itself the strongest operational argument for a single customer view rather than several partial ones.
