Systems, Data & Process
The infrastructure and data discipline everything else depends on — systems of record, integration, governance, and the field-level ownership question that resolves most reporting disputes.
The question that resolves most reporting disputes
"The CRM is our source of truth" sounds like a decision and is not one. No single system is authoritative for both marketing engagement and invoice history, and asserting otherwise guarantees the assertion is quietly violated.
The workable unit is the field. The CRM may own account owner while the billing system owns contract value and the product database owns usage. Each field has exactly one writer and every other system reads it. Where two systems both consider themselves authoritative and sync bidirectionally, records flap — a value changes, syncs, is overwritten and syncs back — and the symptom is a field that will not stay set.
The rule
Documenting the stack usefully
A tech stack inventory that lists tools supports no decision. A useful one records, per tool: its owner, what it is system of record for, what it integrates with, in which direction, and what breaks if it is removed. The safe test for retiring a tool is that its function is covered elsewhere and it is system of record for nothing — low usage alone can indicate an under-adopted but necessary system.
Integration documentation needs direction of flow, trigger, conflict rule and failure behaviour. Failures are usually silent: without alerting, a broken sync is discovered through its downstream consequences weeks later.
Governance as change control
Data governance is not bureaucracy for its own sake — it exists so that a change to a definition is a decision rather than an accident, and so it is recoverable when a report built on it starts disagreeing with another. The minimum viable version is a short list of who may alter fields and definitions, a review step for changes historical reporting depends on, and a record of what changed and why.
This is why unrestricted administrative access is a data-integrity problem before it is a security one. Configuration changes made without review degrade the reporting layer, and historical data cannot be retroactively repaired once definitions have drifted.
Hygiene as a process, not a project
Hygiene achieved by campaign decays predictably, because nothing about the system changed. Making it structural requires a named owner per measure, rules enforced at the point of entry rather than stated in a document, and a standing view surfacing violations continuously — replacing the periodic clean-up with continuous small correction.
27 terms
Association
A defined relationship between two CRM records — which contact belongs to which company, which deal to which contacts. The structure that decides whether reporting can follow revenue across objects.
Attribution Model
The specific rule assigning credit for a conversion across the touchpoints that preceded it.
Calculated Property
A field whose value is derived by formula from other fields rather than entered. Cannot go stale through neglect, which makes it preferable wherever the value is derivable at all.
Champion/Challenger Testing
Running a proposed process change against the current one concurrently, so the comparison is controlled rather than sequential.
Cohort Analysis
Grouping customers by a shared starting characteristic — usually the period they were acquired — and following each group over time.
CPQ (Configure, Price, Quote)
The system governing how products are configured, priced and quoted, enforcing rules about what may be sold and at what discount.
CRM
The system of record for customer relationships — the accounts, people, deals and interactions a revenue team works from. Its value is decided by what is entered into it, not by which vendor supplies it.
Custom Object
A record type you define yourself when the standard objects do not describe your business — subscriptions, properties, vehicles, matters. Powerful and expensive: every one is a schema somebody maintains forever.
Data Enrichment Waterfall
Querying multiple data providers in sequence, using the next only where the previous returned nothing, to raise coverage without paying for duplicate lookups.
Data Governance
The rules determining who may change what, how changes are reviewed, and how they are recorded. The control that stops a designed system from drifting back to whatever it was before.
Data Hygiene
The continuous practice of keeping records accurate, complete and current — as distinct from data quality, which is the state that practice produces.
Data Mapping
The documented correspondence between fields in two systems: what moves, in which direction, and what happens when both sides change. The artefact that decides whether an integration is maintainable.
Data Orchestration
Coordinating how data moves and transforms across systems so a multi-tool stack behaves like a single one.
Data Steward
The named person accountable for a defined set of data: its definition, its quality and who may change it. Governance without a steward is a document nobody enforces.
Deal Desk
A cross-functional function reviewing non-standard deals — pricing exceptions, unusual terms, complex structures — before they are committed.
Deduplication
Identifying and merging records representing the same person or company.
Dunning
The process of recovering failed payments through retries and customer communication.
Field Governance
The rules controlling who may create, alter or retire fields, and the review that applies before they do.
Handoff
The transfer of an account or opportunity between teams — marketing to sales, sales to onboarding, onboarding to customer success.
Integration Layer
The connections moving data between systems, and the rules governing direction, timing and conflict.
iPaaS
A hosted platform for building and running integrations between systems. Buys you speed and observability; costs you a dependency and a bill that scales with volume.
Lead-to-Revenue (L2R)
The end-to-end process and measurement connecting an initial inquiry through to recognised revenue.
Process Automation
Replacing manual steps with system-executed ones, so the process runs the same way every time.
Property
A single field on a CRM record. The unit of everything a CRM knows — and the unit of everything it gets wrong, because each one is a promise that somebody will maintain it.
Single Source of Truth (SSOT)
The declared authority for a given piece of data — the system whose value wins when two systems disagree. Correctly applied it is decided per field, not per system.
Systems of Record
The set of systems that each hold authoritative data for part of the business, and the map of which owns what. The architectural decision underneath every reporting question.
Tech Stack
The set of systems a revenue team operates, and — more importantly — how they relate to each other.
COMMON QUESTIONS
- What is a single source of truth in a CRM?
- The declared authority for a given piece of data — decided per field rather than per system. The CRM may own account owner while billing owns contract value. Attempting to name one system authoritative for everything fails immediately.
- Why do two systems show different numbers?
- Usually an undeclared owner for a field, differing filters hidden in a saved view, a different date basis, or partial deduplication. Take one record that appears in one report and not the other — the cause is normally obvious within minutes at record level.
- Should we sync data bidirectionally between systems?
- Not for a field where both sides can write. Bidirectional sync without a declared owner produces flapping records. Declare one writer and make the other a consumer.
- Who should have admin access to the CRM?
- Very few people. Unrestricted admin means uncontrolled configuration change, and the resulting damage to the reporting layer is not retroactively repairable — historical data cannot be corrected once definitions have drifted.
Course: CRM Admin 101
See the course