“Master data management” (MDM) is usually discussed in the context of large enterprises with dozens of systems. But the problem it solves — keeping the core facts about your business consistent everywhere they’re used — shows up in businesses of every size. A small business just experiences it as “why is this customer’s address different in every system?”
What master data is
Master data is the relatively stable, shared information about the core things a business deals with:
- Customers — who they are and how to reach them.
- Locations — properties, sites, service addresses.
- Products and services — what you sell or deliver.
- Assets — vehicles, equipment, tools.
- People and teams — employees, crews, departments.
It’s different from transactional data — orders, visits, invoices, submissions — which records events involving those things. Transactions refer to master data: an invoice is for a customer, a visit is at a property.
Why it goes wrong
Master data degrades in predictable ways as a business grows:
- Duplication. The same customer is entered separately in the CRM, the accounting package and a spreadsheet.
- Divergence. One copy is updated; the others aren’t.
- Inconsistent definitions. One system stores the service address, another the billing address, both labelled “Address”.
- No owner. Everyone uses customer data; nobody is responsible for keeping it right.
Because transactions refer to master data, every master-data problem multiplies: a wrong address affects every visit, invoice and document that uses it.
A lightweight MDM approach
You don’t need an enterprise MDM platform to get most of the benefit. Five practices go a long way.
1. Decide the system of record for each kind of master data
For customers, locations and assets, choose one authoritative system. Other systems may display or copy the data, but corrections are made in the system of record.
2. Define each kind of master data once
Write down what a customer or location record contains, which fields are required, and what each means. Build every form and record that captures it from that single definition, so there’s only one idea of what an address is.
3. Give every record a stable identifier
Names change and get misspelled. A stable ID, stored in every system that holds a copy, lets records be matched exactly. When integrating systems, the shared identifier is what makes reconciliation reliable.
4. Assign ownership
Name the team responsible for each kind of master data. They decide what “correct” means, resolve duplicates, and approve changes to definitions.
5. Control changes to definitions
When a definition changes — a new required field, a renamed attribute — version it, so older records keep their original meaning, and let people know.
Where to start
Start with the master data that causes the most rework. For service businesses that’s usually customers and locations, because every job, visit and invoice depends on them. Consolidate those first, then move on to assets and services.
Signs your master data is healthy
- Each customer and location exists once in the system of record.
- Other systems can be matched to it by ID.
- Every intake form captures master data using the same definitions.
- Someone is responsible for each kind of master data — and knows it.
A duplicate-prevention playbook
Duplicates are the most visible master data problem. A few practices prevent most of them:
- Search before creating. Make it standard to look for an existing customer or location first.
- Use a consistent naming convention for topics — for example, addresses in a fixed format — so near-duplicates are easy to spot.
- Capture an identifier at creation, especially when the record also exists elsewhere.
- Have one place where records are created. Duplicates multiply when three systems can each create a customer.
- Review periodically. Sort by name and scan for near-matches; merge or archive as needed.
Deciding what counts as “the same thing”
Some duplicates aren’t duplicates. Two units at the same street address may be genuinely different locations; two people with the same name at one company are different contacts. Agree, in writing, what makes two records the same thing:
- For customers, is it the email address? The business name and address?
- For locations, is it the full address including unit?
- For assets, is it the serial number?
That definition is the basis for both prevention and cleanup.
A 90-day plan
Days 1–30: Define. Choose the one or two kinds of master data that cause the most rework. Write down their definitions, required fields and identity rules. Name owners.
Days 31–60: Consolidate. Choose the system of record. Create clean records there for what’s active. Store external identifiers for matching. Make old copies read-only.
Days 61–90: Route and maintain. Point intake at the system of record. Set the review rhythm. Start on the next kind of master data.
What good looks like after a year
- Each customer, location and asset exists once, in one authoritative place.
- Every other system can be matched to it by identifier.
- New records arrive through forms built from shared definitions.
- Someone is responsible for each kind of master data.
- Changes to definitions are versioned and communicated.
Frequently asked questions
Is MDM a product or a practice? Both exist, but for smaller businesses it’s primarily a practice supported by whatever system holds your records.
Do I need to consolidate everything? No. Start with the master data that most transactions depend on — usually customers and locations.
How do I handle data that’s wrong in the old system? Clean on the way in. Migration is the best opportunity you’ll get to fix inconsistencies, because the new definitions will reject what doesn’t fit.
How Atlas helps
Stratosphere Atlas was built around these practices. Reusable data schemas define each kind of information once, and published schemas are versioned. On Enterprise, classifications give customers, properties and assets a single structured home, topics carry an External ID for matching with other systems, and topics are owned by user groups. See External IDs and topic properties and What a single source of truth really means.
