Why a Customer-specific Price Needs a Clear Owner

Imagine a trade paint supplier handling this situation. A regular customer's agreed rate appears in the sales spreadsheet but not the quoting tool.

Staff choose whichever value they find first. The example is hypothetical, and the appropriate response depends on how the business works. Still, it provides a useful way to examine whether the current process gives staff enough context before they act. The useful goal is a dependable handover that ordinary staff can understand.

Price agreements are copied into operational tools without an authoritative record, effective dates or approval history.

A price agreement has scope as well as a value. Product coverage and effective dates help prevent a legitimate exception from becoming a permanent default for everything.

The agreement should remain traceable when a quote is reviewed. Staff can then see whether the rate applies to this product, customer and date rather than assuming every unusual value is an error. The downstream system should receive the relevant approved result with its context. The cost is not limited to entering a value incorrectly. Staff also spend effort deciding whether they can trust the next step. When that confidence disappears, they start checking routine work manually even on days when the information happens to be correct.

Maintain reviewed customer pricing with scope and dates in the appropriate system. Feed supported downstream views and route exceptions for approval.

Identify the meaning of the information rather than starting with a plan to copy whole records. Keep enough source context to understand a correction and determine which downstream records it should affect. Uncertain matches and conflicting values should be reviewed rather than resolved by an unexplained overwrite. Stable references help connect records, while names and display labels may change over time. Investigate supported field-level mappings before allowing updates to flow in both directions. Removing copying is useful only if the resulting information still means the right thing in its destination. Choose where each fact is maintained and which systems only need an appropriate view of it.

The integration should not make commercial pricing decisions or apply unreviewed tax assumptions.

For background relevant to customer-specific pricing, see What Happens When Two Systems Disagree. The issue here is the narrower workflow described in this example.

Prepare a draft quote before and after an agreement expires and include a product outside its scope. Run the first trial in a controlled environment or with an approved copy of the relevant information. Compare the result with the intended business outcome, not merely a success notification. Ask the operating staff to explain what they would do if the result were wrong.

For customer-specific pricing, review the proposed outcome with the staff responsible. Inspect record identity, field meaning and the source of each changed value. Check that the receiving system has not acquired a confident but incorrect interpretation, and that uncertain matches remain available for review instead of becoming silent overwrites. Record the decisions made during the trial and assign responsibility for keeping them current. Otherwise the same uncertainty can return after the next staffing, software or process change.

Software Logic approaches consistent information across existing tools by examining the actual handover, the information involved and whether a modest improvement would be sufficient. Which price would your team use if the customer agreement and the quoting screen disagreed?