Ask who is accountable for the company's CRM and you will get a name. Ask the same about the accounting system, the help desk, the warehouse system and the hiring tool, and each question has an answer. A vendor supports the product, an administrator configures it, a department head owns the process it runs. The company has an owner for every system it uses.
Now ask a different question. The CRM says a customer's contract renews in March. The accounting system says June. Who answers for that? The CRM owner points at accounting, the accounting owner points at the CRM, and the person who asked finds that the thing that is wrong has no owner at all.
That is where IT accountability breaks, and it is not at the systems. It is at the seams between them.
A seam is any place where two systems hold the same fact or hand a record to each other. The customer's name, the contract date, the stock count, the employee's start date. Each system has its own owner and its own definition of correct, and the owner of each is rightly accountable for their own.
Nobody is accountable for the pair. The vendors support their products and say so in their contracts. A vendor will tell you that the integration between two of their products is supported, and that the integration between theirs and someone else's is your responsibility. An internal IT person owns the tools, and the fact that two tools disagree is a business problem that may or may not reach them.
So the disagreement sits. It gets found by a customer, by month-end, or by someone running a report that does not match. The fix is manual, the cause is not recorded, and the same disagreement appears again next quarter.
We described the commercial side of this, what you are buying when you buy operations, in hours, headcount or an outcome kept. The working side is simpler and starts with admitting the seams exist.
A seam register is a single page with one row per pair of systems that exchange or share data. Most companies of fifty to two hundred people have between ten and twenty. Each row has six cells.
The pair. CRM and accounting. Help desk and CRM. Hiring tool and payroll. Name the two systems.
What crosses. The facts that appear in both: customer, contract, product, price, employee, start date, status. A short list, not a data dictionary.
The record owner for each fact. For each fact that crosses, which system is the system of record. One answer. If the answer is "both", that is the finding, and it is a decision to make, not a state to live with.
The direction. One-way from the record owner to the other, or the other direction, or, rarely, both with a rule. We think two-way sync is usually an avoided decision, as we argued in bidirectional sync is a design failure most of the time.
The tie-break. What happens when the two disagree: which one wins, and who corrects the other. In nearly every case the system of record wins and a named person corrects the loser.
The clock. How long a disagreement may exist before somebody is told, and who. The clock turns "someone should look at that" into a duty. A discrepancy older than a day is reported to a person; older than a week, to their manager.
The pair is the CRM and the accounting system. What crosses: the customer's legal name, billing address, payment terms and contract end date. Record owner: the accounting system for name, address and terms, because the invoice depends on them; the CRM for the contract end date, because the account manager sets it. Direction: accounting to CRM for the first three, CRM to accounting for the fourth. Tie-break: the record owner wins, and the finance administrator corrects the CRM when it differs. Clock: a mismatch older than one working day is reported to the finance administrator, and older than five to the head of finance.
That is six cells and about a hundred words. It answers the March-or-June question before it is asked, and it makes the discrepancy somebody's job on the day it appears.
Filling the first register takes a couple of hours with the people who use the systems. Most of the time goes on one cell: record owner. The answer "it depends" is common, and it points to a fact stored in two places for convenience. That is the first list of things to decide, usually five or six, and each can be resolved in a short conversation once someone has asked.
The second discovery is the number of seams with no mechanism at all: two systems that hold the same fact, with a person retyping from one to the other, and the person's name is on no document. That retyping is also an accountability gap, because the person is accountable for typing and nobody is accountable for the result.
The third is the clock cell, which is usually blank everywhere. The company has no definition of how long a discrepancy is allowed to exist. In practice the clock is "until someone complains".
The register changes the question a person is asked when something is wrong. Before, it was "whose fault is this?" and the answer was a discussion. After, it is "which row?" and the answer is a name, a rule and a time. The person on the clock corrects the loser, records the cause, and if the same row appears twice in a month, the register is where the fix is proposed.
It also makes outsourcing precise. A managed provider that takes accountability for the stack is taking accountability for the register: the rows, the rules and the clocks. That is a different promise from supporting the systems, and the contract can say so in the register's own terms. Our video on the point, Nobody Is Accountable for the Whole Stack, So We Are, puts the same idea in a few minutes.
Pick the three systems that matter most to revenue. Write down the three pairs. For each pair, fill in the six cells in one sitting with the people who use both systems, and mark every "it depends" and every blank clock. Then choose the single row whose disagreement has cost the most in the last quarter and resolve it: name the record owner, set the direction, name the person on the clock.
That is one row of a register, and it will be the most useful thing in your IT governance folder.
We build the seam register with a company's own people, enforce its rows through the integrations we run, and take the clock: when two systems disagree beyond the time allowed, we are the ones told, and the correction is ours. Discovery is no-risk: we draw the register for your three revenue systems and show which rows have no owner, and you pay only if you go ahead. The build carries a guaranteed estimate, so if we estimate low, we absorb the difference.
Every system has an owner. Accountability is what you have when the disagreement between two of them has one as well.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
