How often does a source-of-truth conflict cause rework?

Question and scope

This review asks how often a conflict between two sources of the same fact causes rework. The unit is a task that had to be redone, corrected, or clarified because two records disagreed. The scope covers recurring assistant workflows that read from a CRM, a billing system, a document store, or a client portal. The review does not estimate a universal rate, because the systems and the work mix vary.

The question matters because a source conflict is often invisible until someone acts on the wrong value. A duplicate contact may cause a message to the wrong person, and a stale price may cause an incorrect quote. The correction takes time, and the client may lose confidence. The conflict is a process defect, not a one-off mistake.

The review separates a conflict from a simple error. An error is a wrong value in one source, while a conflict is a disagreement between two sources that both look authoritative. A conflict may require a decision about which source wins. An error may only require a correction. The two need different controls.

Find the conflicts

Start with the tasks that were reopened or corrected in the past month. For each one, ask whether two sources disagreed. Record the systems, the fields, the values, and the source the team used. A short list of fields is enough to see the pattern. Do not try to reconcile every record at once.

Check the fields that are most likely to conflict: contact details, legal names, payment information, prices, dates, and status. These fields change often and are copied into many places. A conflict in a stable field may be a one-time data error, while a conflict in a changing field may be a design problem. Record which field changes most often and who owns its update path.

Include the informal sources that people actually use. A saved spreadsheet, an email thread, or a personal note can become the working truth even when the official system says something else. Record the informal source and why it was trusted. That reason is the clue to the fix.

Measure the rework

For each conflict case, record the time spent finding the correct value, the time spent correcting the output, and the number of people involved. Add whether the client saw the error. A conflict that is caught before delivery is cheaper than one that reaches the client, but both consume capacity. Record the stage where the conflict was found so the report can show where the check is working.

Report the count of conflict cases and the share of reopened tasks they represent. Add the most common field and the most common pair of systems. A count without a field is hard to act on. The field and the system pair point to the owner who can fix the source.

Compare the rework from conflicts with the rework from other causes. If conflicts are a small share, a one-time cleanup may be enough. If they are a large share, the team needs a source map and a change to the update path. The comparison prevents over-investing in the wrong fix.

Why conflicts persist

A conflict persists when two systems are both treated as official. The team may have moved to a new CRM without retiring the old spreadsheet. Each system has an owner, but no one owns the relationship between them. The result is a permanent race to see which value is used first.

A conflict also persists when the update path is unclear. A person may update the CRM while another updates the billing tool, and neither knows the other exists. The field has two editors and no rule. Writing the allowed update path is more effective than asking people to be careful.

A third cause is a convenience copy that outlives its purpose. A report exported for a meeting becomes the source for the next report. The copy drifts, but it looks familiar. Marking the copy with a refresh date and an owner helps, and retiring it is better when the source can be linked directly.

Controls that help

Name one source of truth for each field and publish the update path. The map should say who may edit, who must approve, and where the evidence goes. A field with two official sources will always conflict. The decision about which source wins is the control.

Retire the copies that no longer have a purpose. For the copies that must stay, add a refresh date and a link to the source. A copy without a date is assumed to be current. The label should make its status obvious to a reader who was not there when it was created.

Add a source check to the task where the conflict is most costly. A payment change, a legal name, or a price quote should require a second look at the official source. The check should be short and specific. A general instruction to verify is easy to skip.

Method and limitations

This review describes a local tracing method rather than a study of data conflict rates across providers. The sample depends on the reopened tasks the team can find. Some conflicts are resolved silently before anyone records them, and some rework is never logged. Treat the result as a minimum count.

The team may also change its behavior while the review is running. People may check the source more carefully or avoid the informal copy. That is a useful effect, but it makes the first period a weak baseline. Use a later period and note when the review began.

Decision checklist

Sample reopened tasks and record whether two sources disagreed. Capture the systems, fields, values, and the source used. Measure the time and the people involved. Report the share of rework and the most common field.

Name one source of truth for each field and publish the update path. Retire stale copies and label the ones that remain. Add a source check to the costliest tasks. Review the conflict pattern again after one change.