Every go-to-market team eventually discovers that it has been arguing about data, not about performance. The lead count went up because a webinar platform created a new contact for every registration. The win rate went down because someone started logging partner referrals as opportunities. The churn number in the board pack does not match the churn number in the CRM, because one counts cancelled subscriptions and the other counts accounts marked "lost".
Fixing that sounds like housekeeping. It is the foundation for everything else in this series. CloudNala's view is that revenue data is only trustworthy when three things are written down and enforced: what each lifecycle stage means, which system is the source of truth for each field, and how duplicates and gaps are detected continuously. Until those exist, a lead score ranks noise, a play targets the wrong people, and an AI writer personalises messages with facts that are wrong.
This part is the least glamorous in the series and the one most worth doing first.
Lowveld Ledger is fictional, and its systems and figures are illustrative. Lowveld Ledger, the Mbombela accounting and payroll software company from Parts 1 and 2, has about 2,300 paying customers, a CRM holding around 41,000 contact records, and a newly hired GTM engineer whose first ninety-day measure is written, agreed stage definitions.
The record nobody could agree on
The GTM engineer's first week at Lowveld Ledger began with a single account. A 60-person transport company in Mbombela appeared in the CRM five times: twice as a lead from two webinars, once as an opportunity created by an account executive, once as a referral entered by the partner manager, and once as a "customer" because a trial had been marked closed-won by mistake. In the billing system it did not exist at all. It had never paid.
Multiply that by tens of thousands of records and the monthly argument from Part 1 makes sense. A de-duplication pass later found that roughly one in four contact records was a duplicate or unusable. Marketing's lead count, sales' opportunity count and finance's customer count were each measuring something real, and none of them was measuring the same thing.
Write the lifecycle definitions first
The first fix was not technical. It was a document.
The GTM engineer drafted one entry rule per stage, then took the draft to a one-hour meeting with the head of sales, the marketing lead and the customer success lead. The rules had to pass a single test: two people looking at the same record must put it in the same stage.
Lead. A person with a contact record and no qualification yet. Nothing more is implied.
Marketing-qualified lead (MQL). The person's company fits the written target profile, and the lead score has reached the threshold. Part 5 describes the score. The point here is that MQL becomes a rule the CRM applies, not a label someone chooses.
Sales-accepted lead (SAL). An SDR or account executive has accepted the MQL within one working day, or rejected it with a reason from a short coded list. This single stage closes the loop that caused the monthly argument: marketing can now see exactly how many of its MQLs sales accepted, and why the rest were rejected.
Opportunity. A discovery conversation has happened, and a named decision-maker and a timeline exist. An opportunity without those is a hope.
Customer. An active paid subscription in the billing system. Not a closed-won flag in the CRM, which is a sales claim, but a payment, which is a fact.
Once agreed, the definitions were published in the CRM's help text next to each stage field, versioned, and dated. Any later change goes through the same three people.
Separate accounts from contacts
Most small-company CRMs grow around people, because the first lead is always a person who filled in a form. Lowveld Ledger sells to companies. A company buys, a company pays, and a company churns, even though several people inside it interact with the product.
The data model was rewritten around that distinction. An account is a company, identified where possible by its registration number and otherwise by a normalised name and domain. A contact is a person, always linked to one account. An opportunity belongs to an account, not to whichever contact happened to be talking to sales.
This change sounds small. It changed most of the reporting. Webinar attendance became "three people from this account attended", which is a much stronger signal than one contact attending three times. Payroll activation became an account-level event. The five records for the transport company collapsed into one account with four contacts and no customer status.
CloudNala has made a related argument about data products elsewhere: a data product is more than a governed table. The revenue dataset is a data product. It has consumers (sales, marketing, finance, the board), a definition, an owner and quality expectations. Treating it as a side effect of the CRM is how it decays.
One system of record per field
The second reason numbers disagree is that the same fact is stored in several places and edited in more than one of them. Company size typed by an SDR, company size from an enrichment service and company size from the trial sign-up form will not agree for long.
The GTM engineer wrote a short field register: for each field that matters to reporting, scoring or routing, one system of record and a rule for every other system.
The two rows that changed the most were paying status and consent status. Paying status moved to the billing system, read-only everywhere else, which ended the "customers" that had never paid. Consent status became a record that can be changed only through the consent flow, not by anyone editing a contact. Part 10 covers why that matters legally. Operationally, it means an automation can trust the field.
The partner manager's referral spreadsheet was the hardest row. It held the most valuable leads the company had, with notes nobody else could see. It was moved into the CRM as a referral source and a referral record, and the spreadsheet was retired. Part 8 returns to the partner handoff.
De-duplication is a process, not a project
Most companies de-duplicate their CRM once, during a migration or before a board meeting, and then let it decay. Duplicates are created continuously: every form, import, integration and manual entry is a new chance.
Lowveld Ledger made de-duplication a running process with three parts.
Matching rules, written down. Accounts match on registration number first, then on normalised domain, then on normalised name plus province. Contacts match on email, then on name plus account. Every rule was tested on a sample before it ran on everything.
Merge rules, written down. When two records match, which value wins for each field? The field register answers most of this: the system of record wins. For the rest, the most recently verified value wins, and the merge is logged.
Prevention at the point of entry. Forms and integrations check for an existing account before creating one. Imports go through the same matching before they reach the CRM.
The first full pass merged or removed about a quarter of contact records. More importantly, the monthly duplicate rate became a number on the GTM engineer's dashboard, and it stayed low.
Run data-quality checks like tests
The final piece was a set of checks that run every night and report failures, the way automated tests do in software delivery. Each check is a rule that should always be true:
- every contact belongs to exactly one account;
- every opportunity has an account, a stage that matches the written definitions, and an owner;
- every account marked as a customer has an active subscription in billing;
- every MQL was either accepted or rejected within one working day;
- every rejected MQL has a coded rejection reason;
- every contact used in outbound has a consent status that is not blank.
The failures go to a short daily list, owned by the GTM engineer, with the person who created each failing record named so that the fix also teaches. After a month, the list was usually under twenty items a day.
Checks like these are cheap to build and expensive to skip. Every later part of this series assumes they exist.
What it cost, and what it fixed
The definitions meeting took an hour. The field register took a week. De-duplication rules, entry checks and nightly checks took most of the GTM engineer's first two months, alongside syncing payroll activation from the product database.
What it bought was the end of the monthly argument. Marketing and sales now report MQL, SAL and opportunity counts from the same definitions in the same system. The rejection reasons that used to say "not interested" now show which lead sources produce companies that are too small, already locked into a competitor, or not running payroll at all. Together with the payroll activation sync, that repairs the two highest-ranked broken loops from Part 1.
Start this week
- Write one entry rule per lifecycle stage and test them on twenty real records with marketing and sales in the room. Rewrite any rule that produces disagreement.
- List the ten fields your reports and automations rely on and name one system of record for each.
- Write three nightly checks that should always be true, and look at the first failure list before deciding what to fix.
Next: Part 4, Signals are hypotheses, not buying intent. All parts are on the series page.
How CloudNala can help
CloudNala helps commercial teams build revenue data they can trust. We facilitate the lifecycle-definition session, design the account and contact model, write the field register and matching rules, and set up nightly data-quality checks that run as a process rather than a one-off clean-up. We work with the CRM you already have.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Go-to-Market Systems Review or write to us at consult@cloudnala.co.za