A customer's address differs between the CRM and the invoicing system. A product code exists in three spellings. Someone asks who is allowed to correct it, and the room goes quiet. In most growing companies the honest answer is "whoever notices first," which works until two people correct the same record in two different ways.
This article is for a product or data lead who wants to end that quiet. It describes a one-page register that says, for each business system, which data it holds, who answers for it and who may change it. It is a small piece of paperwork, but it prevents a surprising number of arguments.
What data ownership means
An owner is not the person who types the data in. An owner is the person who answers for its quality: whether it is complete, current and correct enough for the work that depends on it. The owner decides what the rules are, approves changes to those rules and is the first call when something looks wrong.
Ownership is also not the same as system administration. The person who manages the accounts and backups of a system may have no idea which customer records are valid. Keep the two roles separate in the register, or the technical team will end up answering business questions.
The columns of the register
One row per system, or per major data set inside a large system. Six columns are enough:
- System: the name people actually use, such as "the CRM" or "the order sheet."
- Data it holds: two or three phrases, such as "customers, contacts, deal history."
- Owner: one named person, not a team and not a department.
- Deputy: who decides when the owner is away.
- Who may change it: roles or names allowed to edit, delete or import records.
- Where the rules are written: a link to a short description of how records should look, even if it is only a shared note.
If you cannot fill the owner column with a single name, that is a finding, not a failure. Write "nobody" and keep going.
A short example
The following example is invented for illustration and describes no real company.
| System | Data it holds | Owner | Deputy | Who may change it |
|---|---|---|---|---|
| CRM | Customers, contacts, deals | Head of sales | Sales operations lead | Sales team; imports only by sales operations |
| Invoicing | Invoices, payment terms | Finance lead | Accountant | Finance team |
| Order sheet | Open orders, delivery dates | Head of customer service | Senior service agent | Service team |
| Product catalogue | Product codes, descriptions | Nobody | Nobody | Whoever has access |
The last row is the useful one. The catalogue feeds the other three systems, and nobody answers for it. That is where the three spellings of one product code come from. Giving it an owner is probably worth more than any new tool.
How to fill it in within a week
Day one. List the systems. Start with the five that cause the most disputes or manual corrections; add the rest later. Ask the people who do the daily work, because they know which spreadsheets matter even when nobody has officially listed them.
Days two to four. Hold a fifteen-minute conversation per system with the person who seems to own it. Ask three questions: who do you call when the data looks wrong, who may delete a record, and what is the one rule that must never be broken. Write down their answers in their own words.
Day five. Resolve the gaps. Where two people each believe they own a system, or nobody does, bring it to the manager who can decide. Avoid long debates: pick a name, write it down and agree to review the choice in a month.
End of the week. Share the register with everyone listed in it. A register that its owners have not seen is only a wish.
When owners disagree
Disputes usually have one of two causes. Either the data serves two teams with different needs, such as sales wanting short company names and finance wanting legal ones, or the system has grown to hold data from several areas. In the first case, name one owner and record the rule that the other team can rely on. In the second, split the row: the same system may have a different owner for customers than for contracts.
If a decision is truly shared, name a primary owner anyway. Two owners usually means no owner.
Keeping the register alive
Review it every quarter, with the same people, in under thirty minutes. Check three things: has anyone changed role or left, has a new system appeared, and was there a data incident that the register did not help to resolve. Also review it whenever you adopt or retire a system. Our article on retiring an old system is a reminder that data left without an owner is the usual source of trouble during a migration.
Store the register where people already look, such as the shared drive or the wiki, and link it from the onboarding checklist. If it takes more than a minute to find, it will not be used.
Common mistakes
- Naming a team. A team cannot be called at six in the evening; a person can.
- Confusing the owner with the administrator. The administrator keeps the system running, the owner answers for the content.
- Writing too much. If the register grows beyond one page, split the detail into per-system notes and keep the summary short.
- Doing it once. Owners move on, systems change, and a stale register is worse than none because it points to the wrong person.
- Starting with every system. Five systems done well beat thirty half-filled rows.
What to do this week
Pick the five systems that cause the most corrections. Copy the six columns into a shared document, hold the short conversations and settle the open rows on Friday. If you also plan to prepare documents for AI tools, the register is a good first input, and this article on source of truth, owner and validity shows how the same idea applies to documents. For the cost of fixing data by hand, see the true cost of manual processes.
Sources
- Our related articles linked above.
- The register layout and the example are a general working approach and are invented for illustration; they do not describe a particular company or system.
